Beta testers for multiple motion system support

[dc42]

@o_lampe wouldn't a Nema 11 or Nema 8 stepper motor with leadscrews be suitable? Although the Nema 8 ones tend to be expensive. https://www.omc-stepperonline.com/linear-motor

[breed]

@o_lampe I haven't gotten near the point of adjustable z on one of the tool heads. I have 2 printers with makertech tilting hotend. They have grub screws for adjusting the heatbreaks, seems to work fine. I was hoping to get this one figured out and together by mrrf, but there are 4 other printers in the que in front of it. Maybe next year. Having automatic z adjustment would be awesome but the weight....I didn't want the common rail double x carriage because of carrying the second x carriage for all the y axis moves. I have an i3 style idex and basically never print mirror or duplicate mode. I def could see a path for simultaneous g code. Printing two different objects would be a useful time saver.

[o_lampe]

@dc42
It would work, but the weight penalty isn't worth the +/-1mm movement we need for Z-hop and mesh leveling.
Even a small hobby servo with excenter could do this, but their speed isn't controlable. That makes it difficult to move them in sync with XY motion.
So IMHO a dc motor with encoder would be the best option.
A mockup picture of a modified PTFE dovetail slider with dc motor/leadscrew

In a perfect world we'd have access to the heightmap(s)-data and route the z-correction to a device of our choice.

[bot]

What about shims to adjust hot end Z height? On my printer, I'm able to add shims to the top of the hot end to lower its nozzle's Z height.

[dc42]

Thanks for all who have responded. I may be able to provide a first build of RRF with dual motion system by this Friday. This version will have some limitations:

• The two motion systems must share a common Z axis
• Standalone mode only (not SBC mode)
• Resume-after-power fail will not be supported
• Simulation mode may not be supported
• Pause/resume may not be fully implemented
• There will be no attempt to predict collisions between the two print heads, so the GCode commands must avoid potential collisions
• There will be no checking that commands for different motion systems don't attempt to drive the same axis simultaneously
• No mesh bed compensation

It's time to think about preparing GCode files that case use both motion systems. There is some documentation at https://docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems on how the different motion systems are addressed in GCode.

The simplest way to use the two motion systems is probably to load two objects on the build plate in your slicer and space them far enough apart so that they can be printed independently by your two motion systems without collisions. Then change the GCode file produced by the slicer so that the commands for one object are assigned to motion system 0 (by using the M596 P0 command before a block of commands for that motion system) and commands for motion system 1 are assigned to motion system 1 (using M596 P1 before a block of commands for that motion system).

You will need to add a M400 command to sync the motion systems before and after each G1 Z command that does a layer change. Obviously you cannot use Z hop on travel moves. Don't let the blocks of contiguous commands for one motion system get too long, or the other motion system might pause for a short while as it skips the block.

You will need to select one tool for each motion system at the start. One of those tools should map the X and Y axes to the corresponding axes of your second motion system, for example U and V.

In the future I hope we will be able to do the splitting of objects into multiple motion systems either in the slicer, or in a standard post-processing script.

[o_lampe]

@dc42
That'll be exciting to try!
You should also mention that mesh leveling must not be enabled.

I wonder, how a waiting tool behaves when layer times are way different? Will it go in parking position or just sit and wait for the other tool to finish the layer? Will it automatically retract/unretract?

[o_lampe]

@dc42 said in Beta testers for multiple motion system support:

There will be no checking that commands for different motion systems don't attempt to drive the same axis simultaneously

How do we address layer changes then? Isn't Z-axis a common axis of both systems? Do we need to define a third tool just for the z-axis and switch to that tool before layer change?
Putting M400 before a layer change will only wait for the other tool to empty the print queue, but it's not guaranteed to be finished with the layer...

[dc42]

@o_lampe said in Beta testers for multiple motion system support:

@dc42 said in Beta testers for multiple motion system support:

There will be no checking that commands for different motion systems don't attempt to drive the same axis simultaneously

How do we address layer changes then? Isn't Z-axis a common axis of both systems? Do we need to define a third tool just for the z-axis and switch to that tool before layer change?
Putting M400 before a layer change will only wait for the other tool to empty the print queue, but it's not guaranteed to be finished with the layer...

When multiple motion systems are in use, M400 causes them to synchronise at that point, i.e. no motion system proceeds past that M400 until all motion systems have finished executing it.

Only one motion system needs to move the Z axis to do the layer change. Another M400 command after that Z move will ensure that the other motion system waits for it to complete.

@o_lampe said in Beta testers for multiple motion system support:

I wonder, how a waiting tool behaves when layer times are way different? Will it go in parking position or just sit and wait for the other tool to finish the layer? Will it automatically retract/unretract?

Currently it will just sit there. In the future I will add an option to park waiting tools, probably by using an extra parameter on M400. Meanwhile you could call a parking macro just before the M400.

[bot]

I will begin work shortly preparing a rudimentary minimally-viable custom PrusaSlicer build to support concurrent printing of multiple objects. So far, the plan would be to copy and modify the sequential object printing feature to interleave the two object g-codes instead of outputting them sequentially. M596 and M400 would be emitted when needed. Is there anything else that would be required or helpful to get started testing this? At first, time estimates and other helpful features would not work.

[o_lampe]

@bot
I thought from the beginning, that such a project can only be done with a slicer-dev in coop.

Interleaving the two objects has it's charm, but there is also the problem with unequal path length (or path print duration to be exact).
You'd have to chop (straight) path' into equal portions to make sure, both nozzles are finished at the same time.
A waiting tool at the end of a layer is one thing, but a waiting tool at the end of every path is another.

It would be cool, if you could slow down the nozzle of the object with the slightly smaller layer-area, to make them both fotofinish the layer.

[dc42]

@o_lampe when printing multiple objects, it should only be necessary for the two motion systems to synchronise at the end of each layer and again after the Z move, provided the objects are separate sufficiently for there to be no risk of collision of the two tool heads.

[bot]

@o_lampe Yes, certainly it would be nice to have the speeds of moves automatically adjust, if requested. However, I'm still trying to ort out a way to use the time estimates in such a way. So, for now, I'm going to try and get a quick-and-dirty test build up, so testers can have a bit of help. It doesn't seem, to me, like there is an easy way to interleave two object g-codes, besides with a slicer or script. But, if there was a script or method to easily achieve the quick-and-dirty interleave, I could focus more time and effort on the coordinated timing, etc., and skip the mvp... it's up to the testers really, which they would prefer.

[dc42]

Unfortunately I don't have a test build ready yet, and I now have to stop working on this feature. I will return to it later this month.

[T3P3Tony]

@bot @dc42 Is there an "optimal" amount of interleaving?

At one extreme having a line addressed to one motions, followed by a line addressed to the other motion stream, then back to the first does not appear good due to the overhead of switching the addressing and also because frequently the motion systems would not be that closely synchronised - one may be doing long moves and the other short ones.

At the other extreme it would be a layer at a time.

If both motion streams are reading the SD card file independently then presumably there is quite a lot of flexibility in this?

[bot]

@t3p3tony This is a good point. An idea that just came to mind is to use the approximate length of the move queue. iirc, about 40-60 moves? Or perhaps, half the move queue? There might be some logic behind the number of lines to send to each system. I'm open to ideas. Perhaps I will make it configurable at first, by the user.

[dc42]

@t3p3tony I suggest around 10 to 30 commands before switching to the other stream. This keeps the overhead of reading and processing M597 commands reasonable low, without having very large blocks for the other GCode processor to skip over which could cause stuttering.

[o_lampe]

For me it's obvious, that in the future the SBC will play a major role in this.
I know, it's not in the scope yet, but why not start the project with that in mind?

If we had a way to merge two gcode files into one SBC-stream, we would also overcome the RAM limitations of Duet2.
I'm sure the Klipper guys would go that way. I already regret mentioning that, sorry.

[oliof]

I don't see a single threaded non-realtime process (and I don't even want to start consider multiple threads or processes...) being reliably able to emit interleaving gcode that requires cooperation. So I am not sure the SBC will be a help here.

[o_lampe]

@oliof
You think of a real-time process, but I believe the pre-processing can take place in such short time, that it's done before the bed is heated.

I've seen it on my K40 laser: the controller is dumb with no memory. A raster-file or vector-graphics are fully controlled by the PC or a RasPi400 in my case. Although it's written in python, which only uses one CPU-core, it's fast ( upto 500mm/s raster engraving) and reliable.

[oliof]

@o_lampe slight deviations are not a problem as long as you have a single tool. Coordinated moves from independent streams are another story.