Concurrent gcode processing
-
Putting this here for some community discussion.
We have recently and in the past had a thread discussing multiple independent hotends all printing at once:
https://www.duet3d.com/forum/thread.php?id=1474#p14999
https://www.duet3d.com/forum/thread.php?pid=39829#p39829Also e3d have unveiled a 4 head printer that can pickup and put down the tool heads. This prompted a wishlist from neotko on twitter
https://twitter.com/neotko/status/968153626865819648Having one hotend purge while another is printing could be done with some complex gcode, but it would be simpler (from a user perspective) if blocks of gcode could be executed concurrently. In the e3d/neotko example that would be simple macros running at the same time. In the multihead concurrent printing it would be seperate print files. That also needs alot of slicer work and is relatively niche!
I could envision a version of the e3d machine with a carousel or helper axis that prepared and positioned the next print head for use while the existing one is printing. Depending on the number of tool changes that could make a significant improvement to overall print time.
-
This is something for the generation 3 Duets, because it needs more RAM than the current generation has and an RTOS. I already have plans for the next-generation firmware to read multiple streams of GCode from SD files at once.
-
Also e3d have unveiled a 4 head printer that can pickup and put down the tool heads. … I could envision a version of the e3d machine with a carousel or helper axis that prepared and positioned the next print head for use while the existing one is printing.
I did a little cheer when I saw this, since It seemed obvious to me.. Thirty years ago (yep!) I was programming HP multicolor pen plotters which had a similar problem, the expensive pens they used would dry out/leak onto the plots, and wrecking a A2 plot in the last pass was just as annoying then as a wrecked print is today. So the plotters had a 'drive in' carousel at one end of the X axes which clamped and capped the pens + could rotate to the color needed by Y axes movements. It was quite simple and effective.
So yes, I can see benefits in having some way to continue running gcode on the currently printing axes and tool without interruption, while preparing and presenting the next tool with independent code running in parallel. And I hope this sort of system takes off since purge/wipe towers are so in-your-face wasteful that I think they are almost a 'negative' solution.
-
….........................Thirty years ago (yep!) I was programming HP multicolor pen plotters which had a similar problem, the expensive pens they used would dry out/leak onto the plots, and wrecking a A2 plot in the last pass was just as annoying then as a wrecked print is today. So the plotters had a 'drive in' carousel at one end of the X axes which clamped and capped the pens + could rotate to the color needed by Y axes movements. It was quite simple and effective.
God that takes me back. In a previous life (late 70s\early 80s), the company I worked for had one of those (well an A4 version)! I spent many a happy hour using one to generate graphs of vehicle emission data. The carousel worked well and the precision and repeatability were amazing at that time. The pens moved in X and the paper moved in Y and the I was awe struck when I first saw it write text. I also remember us spending a small fortune on those bloody pens which kept drying out…...
-
This is something for the generation 3 Duets, because it needs more RAM than the current generation has and an RTOS. I already have plans for the next-generation firmware to read multiple streams of GCode from SD files at once.
When is the Gen3 expected?
-
This is something for the generation 3 Duets, because it needs more RAM than the current generation has and an RTOS. I already have plans for the next-generation firmware to read multiple streams of GCode from SD files at once.
Glad to see the requirement is registered ?
-
This is something for the generation 3 Duets, because it needs more RAM than the current generation has and an RTOS. I already have plans for the next-generation firmware to read multiple streams of GCode from SD files at once.
Could it be done atm by assigning all the heads to a color mix mode, and instead of changing the tool, pushing a % ratio of the second, third or fourth color/material? Since for the e3d setup there’s no motion attached to the head but is a parking system if the wipe is fixed a-la bcn3dsigma as long as you can send a gcode to push 2/3/4 purge it would be already be purging (that’s the slowest part along heat/cooling). But for heat/cooling Cura already has a nice code to preheat before use, so mostly the remaining thing is just the purge.
Ofc multi gcode streams could be really nice, specially if the machine doesn’t ise a park system, but maybe (atm) is a bit overkill.
The only issue I see on my % theory is that the gcode will force the purge speed. But maybe that could be separated somehow, like just sending a G0 Purge&DontwaitToolX ?
