Just an idea, but I wonder what it would take to make an API for communicating with the Maslow so developers could create alternative clients, etc.
I’m a developer, but I’m not too familiar with python or kivy. I may look further into this, but a spec would speed things up. What is sent to the Arduino over the serial port. An object? An array?
Let me know what you guys think
There is an API, it’s g-code (and a few other codes) via the serial port.
There’s even work being done to fix problems with another client talking to it.
Ground Control is the client to be replaced. Right now it’s needed to do the
initial calibration, but should not be needed for anything else.
Well, yeah. It’s pretty obvious that gcode is sent over the serial port, but as what data structure? The firmware is expecting the gcode to be formatted a certain way, and in a certain order.
As I’ve said before, I’m no python developer, but skimming the source seems as if the gcode is sent over as a ‘queue’ of utf-8 encoded strings.
I believe a queue to be an array with special methods, kind of a first in, first out approach.
But you also must receive information over the serial port, like machine current settings and position, or is that all stored in the client?
A spec on how things are done would make developing libraries for other languages much easier.
I can sift through GC source and firmware source, but it will take much longer to understand exactly what is happening rather than having it laid out. Maybe that is what’s necessary though.
Its really not necessary.
But, this is roughly what is happening.
A line of g-code looks like:
A line number, followed by a space, a G or M code, followed by a space, followed by any required parameters, separated by spaces. The line is terminated, if I recall by carriage-return newline (\r\n).
The line number looks line N followed by a span of digits,
G or M code is usually followed by 2 digits. Some implementations allow a single digit, so G01 can sometimes be written G1. (G01 is ‘draw a line’).
GC just sends the lines one at a time to the firmware. It then waits for a response, indicating that the command has been completed. This is normally ‘OK\r\n’.
GC does not have to keep any knowledge of the state of the client. It assumes that if the client signals OK, it is ready for the next line.
This is really primitive, and was designed for being loadable from paper tape, even.
We have tried to maintain compliance with the GRBL protocol that most CNC machines use:
I’m aware of the structure of gcode - does it just send the line as a string?
‘G01 X2.5 Y7.0 Z1.0 F20\r\n’
It gets sent to firmware as is?
yes, it is just a string. And actually pure ASCII, utf-8 is a bit of a red herring here. Well, on second thought, maybe non-ASCII characters are allowed in comments.
Yup!
When the line is finished being run the machine will respond with an ‘ok’ command to indicate that the space that line took up in the Arduino buffer is free
Yes, it really is that primitive
you can connect a terminal program to the serial port and start typing g-code
and the machine will cut it.
Interesting…I want to play around with writing an interface with JavaScript. Hopefully that extends to the calibration process as well
If you have a spare Arduino Mega, you can set a switch in the firmware (Config.h FAKE_SERVO) that let’s you play without having chains and motors attached 
, one of my favorite ‘hidden options’!
The firmware sends position and position error information 5 or 6 times a second, so prepare to ignore or filter out a lot of chatter in the channel. Watch those values to see your gcodes have effect - they are used by GC to put position and speed on the screen. Send “$$\r\n” to see a dump of internal settings from the firmware.
That’s awesome! I don’t have a spare Arduino lying around…but I’m willing to be that I might have one soon 
There are a lot of CNC controllers out there, look for g-code sender for a bunch
of options
I would really like to see the calibration math changed from things in GC to be
functions in the firmware, so that other senders can use it.
I have exactly this thought @dlang. Theoretically, another sender like cncjs could be used in garbl mode for sending gcode, correct? (if maslow firmware adheres closely enough to the grbl protocol) but for calibration it is GC only as of now. The measurements ARE stored on the arduino eeprom, right? Because the firmware must use those measurements to correctly move the motors I guess, so that only makes sense.
Yes!
This thread seems relevant:
Any changes which make Maslow easier to use with all sorts of different software are very welcome!
They (the resulting numbers, not the measurements taken during calibration) are
now, in the past there were times when they were loaded from GC at
startup time.
Well, yeah. Okay, the values resulting from the calibration process (HEREINAFTER REFERRED TO AS “measurements”) are stored in the EEPROM. What about the current position of the machine? Is that information stored firmware side or in GC? Example, I’m in GC…move to X1, Y1, then I open cncjs/alternative client - can it query the Arduino to find the machine position to be X1, Y1?
If you look at the serial stream, you’ll see the present location reported 6 times a second.