@dc42 Thank-you for the warning and insight! Perfectly valid for long processes such as 3D printing or CNC machining. Fortunately, in my application, power loss shouldn't be a problem as it is simply for statically positioning objects - so the G-code is only a couple of lines and the process is only a few seconds. If power is lost, I'll just start the process over.

@droftarts Thanks Ian!

@dc42 Thank-you for the warning and insight! Perfectly valid for long processes such as 3D printing or CNC machining. Fortunately, in my application, power loss shouldn't be a problem as it is simply for statically positioning objects - so the G-code is only a couple of lines and the process is only a few seconds. If power is lost, I'll just start the process over.

@EasyTarget Thank-you! I'll have to dig deeper into the documentation as I somehow missed it. Anyway, it is great to know the capability exists.

After much searching here and online, I can't find the answer I'm looking for. I'd like to use Duet3D hardware to control a custom CNC positioning device and stream instructions from software on a local host Windows PC.

Is it possible to stream G-code data into Duet3D controller boards instead of loading from a file? From this thread, it seems that Pronterface and Slicer3D can stream files directly to a 3Dprinter, so I am optimistic.

If so, is there any feedback mechanism such as checksum or "OK" to notify the sender that the data was received?

If not, can other firmware (besides RepRap) with streaming capability be used with the Duet3D controller boards?

@o_lampe I had not thought of that. Thank-you for pointing it out.

This application would be TPU, which I have yet to print with (mainly ABS/PLA). Does TPU require a perimeter for an object the size on an infill? If so, seems the G-Code would need to be edited. Or, perhaps the perimeter could be designed into the CAD file so that it exists for adhesion, but eliminate the perimeter from the slicer settings.

@o_lampe Good idea! Some have mentioned that different speeds results in difference in print quality if not appearance. Perhaps this could be addressed by having the outer wall speeds, the same, but have differing infill speeds.

@o_lampe said in Multiple Motion System:

openScad

Thanks! I'm not familiar with openScad but am quite proficient with Fusion360. It seems slicing the model is the easy part. As you mention, it the synchronization that I am not sure about.

@o_lampe No, the zones are in a row, not a square. See image. This is the top view of the zones (perpendicular to Z axis). Nozzle 1 would always left of the red line in Zone A or B, and Nozzle 2 would always be to the right of the red line. So the sequence is:

1. Layer 1A prints: Nozzle 1 stays in Zone A, Nozzle 2 stays in Zone C.
2. Layer 1B prints: Nozzle 1 stays in Zone B, Nozzle 2 stays in Zone D.
3. Layer 2A prints: In Layer 2A, the zones shift slightly so that there is an interweaving joint between layers instead of a butt joint (hence shift of the red line).
4. Layer 2B prints.
5. Layer 3A prints: In Layer 3A, the zones shift slighty back to the same positions in Layer 1, and the process loops.

Nozzle 1 would move to the left when not printing while Nozzle 2 would move to the right. As long as the toolhead is narrower than the adjacent zone, and each "half" layer is finished before printing the other "half" layer, collision is not possible.

How difficult would it be to script something like this? It seems it would be much simpler than true collision avoidance collaboration, particularly if the single part was divided into 4 parts (one for each zone) with the interweaving layers in CAD.

@T3P3Tony said in Multiple Motion System:

As an interim step for the path generation, a post processor could be written that printed two different parts on the bed at the same time, synchronised each layer. With more work the slicers could be modified to use the built in "painting" and tool functions to specify areas of a single model that are tagged per tool, and then a post processor (or built in function) would then use those flagged areas in the different motion streams.

Thank-you for the insight. The interim step you describe would be a satisfactory solution for my application. I want print custom shoe insoles, so the printed parts are always similar, but not identical.

I envision there being four zones in a row for each layer (A,B,C,D) with each nozzle just printing in two zones (A & C, then B & D) simultaneously which are not adjacent. Each nozzle would be assigned to stay in one of its seperate zones in which collsion is not even possible. When both nozzles are finished printing each zone, they shift to their other zones. After the four zones are completed, the next layer begins and the process repeats. Every other layer, the zones would shift a little or randomly from the previously layer so that the zones are not just butted joints vertically, but interweave like a zipper.

Such a setup would not be optimal for maximum efficiency as one nozzle may finish before the other (and introduce drooling problems), but it should still provide significant improvement in reducing printing time. With the four zone, two independent nozzle described above, is anti-collision even necessary?

My expertise is obviously not programming, but I imagine this could be accomplished with scripting/postprocessor without too much difficulty as the same zones could be applied to each insole or scaled appropriated accounting for overall insole length. In other words, in an application in which similar, but not identical, parts are produced, does that simplify collaborative programming/scripting?

FWIW, in my application, the tool path generation would have to be automated/scripted, rather than manually editing the G-Code.

I completely understand the chicken vs. egg challenge - I'm just on the other side of it. Why build a collaborative capable printer if I cannot run it with collaboration? In my application, collaboration is the best means of achieving printing time targets.

@o_lampe That was my fear that this was a hen&egg, or chicken&egg problem as we say in the USA.

It is surprising that there has not been more progress with colloboration modes as the fastest way to increase print times of a single object is to increase the nozzles.