Firmware Expected Response reference?

Hi,

I've been writing my own firmware for various reasons, and just realised there's a glaring hole in our documentation- the GCODE and MCODE references have been extremely useful, but I have very little idea of what the host software expects back from the motherboard- does it say OK when it gets each line? how does it tell the host to stop sending commands for a bit because its queue is full? What metadata does the host software expect, and what format is it in? how often should it be sent?

The only mention of replies that I've seen is in the temperature commands in the MCODE reference

I have implemented XON/XOFF flow control but it's basically untested at the moment because I've been wrangling other bugs.

looking at RepRapArduinoSerialSender.py from skeinforge, it looks like my firmware should say "start" when it starts up, T: nnn every so often, and "ok" when it has successfully added each command to the queue, or the command has successfully completed, depending on the command.. Eg M101 apparently waits for the extruder to reach set temperature, but no other command seems to wait for anything- special cases like that are a right pain to code :/

Are those responses case sensitive? I don't know python so can't tell from the code, but I've done enough general programming to follow the flow of the program.

Any suggestions or insights?

_{LibraryGnome: I think this thread lives in software because I don't care what the official firmware sends, I need to know what the host software expects. Feel free to move if you have another perspective.}

Triffid_Hunter Wrote:
> Any suggestions or insights?

If you haven't done so already, I'd suggest searching the entire solution for Serial commands; I would suspect the code uses that class to perform all IO.

For my own rewrite, I plan on keeping things as simple as possible, discarding G code entirely; I want to make the required parse logic take as small as foot print as possible. I've listed a rough outline of the commands I plan on adding:

"R {control-ids} {cr}"
- abort any current action and activity; clear spline buffers, etc.
- reset and home controllers specified by {control-ids}.
- Each {control-id} will be alphanumeric. Up to 36 controllers supported by protocol.
- "R.{cr}" to acknowledge reset recieved and started.
- "R{control-id}.OK{cr}" as each control is homed and ready.
- could be used as an idle 'ping' test with "R{cr}", which should halt all activity and generate a simple "R.{cr}" response.

"S{sid} {steps} {control-id}{spline} {control-id}{spline} ...{cr}"
- add spline path to buffer for controllers specified by each {cid}.
- implicitly add controls not specified as constant based on their last known position.
- {sid} arbitrary; used only for host to identify spline as it completes (except for special "?" which is a query command).
- {steps} and {spline} use some encoding scheme. Planning some compression to reduce bandwidth and processing needs base 32 or base 64 encoding.
- begins executing as soon as all prior activity has completed.
- "S{sid}.{cr}" to acknowledge reciept and (possibly pending) execution.
- "S{sid}!{cr}" to acknowledge reciept and (possibly pending) execution, and buffer full; don't send any more splines until one completes.
- "S{sid}.OK{cr}" as each spline completes; new buffer space available for new spline .

"S? {cr}"
- query spline execution and buffer.
- "S.{current-step} {sid}{sid}{sid}{sid}{cr}" to indicate current spline execution status.
- {current-step} the step index for the spline currently being executed.
- {sid}... the current buffered splines, the first one the one currently being executed.
- "S.{cr}" if engine idling.

"V{cr}"
- respond with firmware version
- "V.{version} {human readable description}{cr}"

"C{control-id}{cr}"
- respond with control state for control {id}.
- "C{control-id}.{type}.{state}{cr}"
- {type} will be an alphanumeric code for stepper, pid driver, on/off, etc.
- {state} will specify current control state; current desired target and current reading, etc. Probably use base64 like encoding, as per all numbers.


At any time, the controller can send an error indication:
- "E{severity}.{id} {text}{cr}"
- {severity} 0 (minimal keep trucking if you want) to 9 (send the machine to the recycler.)
- {id} a firmware version specific code identifying the exact error.
- {text} a human readable string so they can more quickly figure out what went wrong via a timestamped log file.

I have created [objects.reprap.org] to document the results of this exploration

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware