Conditional G Code & Multiple GCode streams - Duet3

HebigT

I remember hearing that both of these features may be in the works. Is that still true?

What applications are there for being able to run multiple 'streams' of Gcode?
Running multiple machines from one Duet board?

A Former User

Haven't seen any actual implementations of either. Suspect conditional g-code will be implemented first.

With regards to multiple streams ,are you refering to the request someone made to delay a single command while the rest continiued executing? Not sure if it'll be usefull outside of toolchanging and such things, if it gets implemented. Seem to recall it was a maybe?

Would expect the conditional g-code to be sorted by or not long after the release of Duet 3 hardware which needs a stable version of RepRapFirmware v3, but thats just a random guess and possibly wishfull thinking.

T3P3Tony

@jpomo10 multiple gcode streams is one of the design goals for Duet3. not sure if it will be part of Duet 2.

As @bearer has said a tool changer is one possible application so you can have a lower priority stream managing the tools (preheat, purge etc) while the print is going on.

HebigT

@bearer , @T3P3Tony

Thank you for the reply!

dc42

To confirm, multiple GCode streams will not be supported by Duet 2 (there isn't enough RAM), but I intend to support them on Duet 3. It may be a while because there is lot of other Duet 3 work to complete first. One of the applications for multiple GCode streams is to have the second stream reading the print file ahead of the main one and simulating it, so that it can predict a tool change or colour mix change in advance, and prepare the new tool or change the colour mix ahead of time.

Conditional GCode will be supported by RRF3 on both Duet 2 and 3. It is partly implemented already, but not enough to be useful.

deckingman

@dc42 said in Conditional G Code & Multiple GCode streams - Duet3:

One of the applications for multiple GCode streams is to have the second stream reading the print file ahead of the main one and simulating it, so that it can predict a tool change or colour mix change in advance, and prepare the new tool or change the colour mix ahead of time.

That'll come in really handy and save me having to write Pythion scripts to post process gcode files.

bot

While we are talking about the progress of FW dev, dc42, what are your current thoughts on S-curve/a better approach to motion planning? I read your thoughts from last December, and it seemed like you had figured out a solution to the jerk/instant speed change problem by the way you were speaking about S-curve.

HebigT

@dc42 Great, I look forward to developing applications for both!

dc42

@bot said in Conditional G Code & Multiple GCode streams - Duet3:

While we are talking about the progress of FW dev, dc42, what are your current thoughts on S-curve/a better approach to motion planning? I read your thoughts from last December, and it seemed like you had figured out a solution to the jerk/instant speed change problem by the way you were speaking about S-curve.

That's still on the work list, but will come after completing the firmware for Duet 3 and implementing conditional GCode. S-curve acceleration helps if your printer suffers for resonance at higher frequencies, but not if the resonances are at low frequencies - which seems to be more common.

Bipotronic

@dc42 are there any news about the development stage of the "multiple GCode streams"?

jay_s_uk

@Philipp-R it's part of 3.5b1