Judging from your output it looks like not all the characters are getting to the serial reader, or are being clobbered in the serial buffer due to some kind of problem. For example this exchange:
Sent: G10 L2 P1 X3.6 Y0 Z0
Sent: {rx:n}
Received: {“r”:{},”f”:[1,0,21,101]}
Sent: {rx:n}
Sent: {rx:n}
Received: {“r”:{“err”:”{r”},”f”:[1,108,3,7863]}
If I read this correctly, what’s happening is that the sender sent the G10, then sent an rx:n immediately (before waiting for a response from the G10), then received the response from the G10, then sent another rx:n, then another, and finally received the response from the first rx:n which was mangled.
The error response indicates that of the first ‘{rx:n}\n’ only the ‘{r\n’ was received by the board (with the \n being the newline character). This is evidenced by the footer reporting that the line read 3 bytes – the ‘3’ is the number of bytes read by this command in the 3rd footer position, and the error response saying that it only say ‘{r’ and could not process it. Returning status code 108.
It’s a good idea to wait for a response from one command before sending the next. It may also be helpful to you to increase the JSON verbosity to max: {jv:5}. That way you can see what command was issued in the {r response – at least during debugging.
My take is that the system is in an unresponsive state after the G10, as it has to write to EEPROM. Waiting for the response will allow the write to complete. You might also try delaying your next send by at least 50 milliseconds, but waiting for a response is a better way to synchronize.
This is due to a flaw in the Xmega EEPROM write functions that force turning interrupts off while EEPROM is being written. So the serial interrupts may be off explaining the dropped characters from the rx:n request. This update window affects any command that writes to EEPROM, which is all configuration commands that write values (e.g. {xvm:1200}) and the G10 in Gcode, which is the only Gcode command that actually writes to persistent memory.
(Technically, these writes are deferred while the board is in a machining cycle, but since it was not in a machining cycle in your example the write occurred immediately after the G10 parameters were received).
Alden
