Forum Replies Created
-
Thanks. A couple of questions for you.
– Have you tried 380.08 – which is what’s currently on Master? Same results?
– What are you using the run the file? Coolterm, tgfx? If tgfx, what platform (Win/Mac) and build?(Added)
– Do you know where in the file i messes up? If Cambam can generate line numbers it makes this part a little easier.OK, I’m going to look into this a bit more. I need to see what you are getting back from the end of homing. I also want to see what behavior should occur if a non-drawable line is received. It should return a value, but I need to look into this.
Also be aware that the status code (see Status Codes page on the wiki) is returned in the footer for all ‘r’esponses. It’s the second element of the array.
https://github.com/synthetos/TinyG/wiki/TinyG-Status-Codes
FYI, here is a diagram of the TinyG state model. The picture may be a bit dated and need updating, but the enumerations below are the current settings taken from the canonical_machine.h file. Be aware that the “program stop” and “program end” states are Gcode defined intermediate and end states triggered by the STOP and END M commands (and some other cases for stops)
What problems are you running into?
Every command is responded to in the JSON mode ‘r’ response. The footer contains the status code of the executed commands. Perhaps what you are referring to is that the system queues motion and other synchronous commands for execution in sequence. To see the completion of queued commands you need to use the status reports.
Best practice is to use the JSON commands, use the footer to tell the results of the command, and set up a filtered status report with all the state variables you want to track for queued commands. See the JSON and Status Report guidance on the wiki. The ‘stat’ variable is the universal idle state indicator. See those pages for guidance.
The other thing to be aware of is that it’s better to manage flow control at the planner buffer level than at the serial buffer level. In other words, instead of stuffing the serial buffer until it’s full, keep the planner buffers operating between a low and high level. Use Queue Reports to return the planner buffer level. If you are sending a file the planner should have at least 8 or 10 buffers in the queue to avoid motion starvation, and use no more than 24 of the 28 buffers available in the planner queue. Over 24 the serial buffer starts to back up. Things still work, but now you are queueing in the serial buffer. (FYI: 4 buffers are reserved for the next Gcode block, which may occupy as many as 4 planner buffers)
@Makerboost: All commands are responded to; perhaps what you are remembering is that status reports are not delivered faster than the maximum rate, so some state may be skipped (like position updates).Status reports will always deliver completion status, however. The main way to find completion status is track the “stat” variable.
