How does Gcode streaming work?

Hi All,

I'm attempting to implement Gcode stream from a PLC to a ramps board.

When this is done from Pronterface or S3D how does the software know the board is ready to accept a new line a Gcode.

I understand that any extra command that can't be executed immediately get buffered but how is the sending rate defined?


Thanks,
Charles

Its dumb...

Send a a line, wait for ok and repeat.

If the sender has line numbers and checksums it checks the line, otherwise its just accepts it
.


controller will buffer what it can, and delay sending ok when it has to.

see [reprap.org] for more details

Thanks for the prompt response Dust!

1. Assuming the ok is sent back to the control software when the move has finished executing surely that creates a gap from the OK being received to the next line being sent and executed by the ramps?

2."If the sender has line numbers and checksums it checks the line, otherwise its just accepts it" Could you elaborate?

1) G0/G1 (moves) don't wait till move is executed. That would be painfully slow. They buffer the command and return ok, To be executed when it can. ok is held on a buffer full
Moves are executed in order to make sure its all correct. But other commands can jump the queue. ( a common eg people run into is moving a servo, it doesn't wait for the stepper moves to finish, you have to send a wait for buffer empty first if that is your desired action)
This is also why we have heat and wait and heat without waiting gcodes... heat and wait till temperature is achieved is obviously used before printing starts, but if you want to change temp mid print you probably dont want to to wait.

2) [reprap.org] has all details, but in particular [reprap.org]

Edited 3 time(s). Last edit at 04/19/2018 06:24AM by Dust.

Thanks Dust!

Edited 1 time(s). Last edit at 04/19/2018 12:26PM by CharlesDesign.

Just checking I'm understanding the gcode streaming logic correctly:

In this example, we want to always keep three lines of Gcode queued up on the RAMPS - at the start, we, therefore, send three in short succession.

The ramps will execute the first and queue the two others, and return an 'ok' when it has finished executing.

The returned 'ok's are counted one the streaming software which allows us to keep track how many lines are in the buffer?


Is this correct?


Where things get a little confusing is when we sent commands which are immediately executed such as M114 - the 'ok' no longer allows us to know exactly which line is currently being executed?!

Edited 1 time(s). Last edit at 04/20/2018 04:48AM by CharlesDesign.

Think you will find the "OK" doesn't mean it has executed it means the mesage has been read (and stored) OK. The streamer then sends the next message. If there is no OK the streamer does nothing - however there is a timer running and if it doesn't get an OK in the time limit it assumes theres an error and responds accordingly. This can be showing an error message, may resend the message, may try other actions to restart comunication.
If the controller (RAMPS in your case) reads the next message but the line number doesn't follow it tries to ask for a resend - not sure what happens after that.
Note that the code messages received by RAMPS are stored in a buffer - the size defines how many messages can be stored. If there is no room there is no OK.
These messages are then passed to the processor in the order they arrived.
So if your buffer can hold 10 messages it will read ten from the streamer. If the 1st message is turn on heater and wait for temperature then the 2nd message wont be processed until the temperature is achieved. So the bufer will not accept any more messages until the temperature is achieved.
If your 10 messages were fast like turn a fan on or off then they would action quickly.
Some times stop and pause commands get a delayed response because they are added to the buffer at the end so the previouse 9 messages have to be executed before it gets the stop/pause message.
Actions can apear out of sequence if they take diferent times to execute and are not dependant on each other. The firmware has error protection code to try and stop harmfull situations ariving.
For example its possible to send commands in the order, turn hot end on, move to X/Y, extrude filament. What you observe is the head moves and grinds the filament. you may say it ignored the turn on hot end but actually it just takes longer to notice the temperature rise by which time the other comands have completed. In firmware there is a safety code that actually prevents the extrusion command until the hot end has reached temperature. in this case you observe that the head moved to x/y and did nothing. Its actually waiting for the temperature to be reached.
Hope this helps.

Bear in mind that if you ever want to stream gcode commands to a 32-bit board, they nearly all have native USB ports with driver level flow control, so you don't need to wait for the OK. There used to be an 8-bit board with native USB too.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].