Beta testers for multiple motion system support

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.

dc42

@o_lampe we are already planning to use one SBC controlling multiple Duets to implement larger numbers of concurrent motion systems. For example, one SBC controlling two or three Duets, each of which controls two or three motion systems.

wiego

@dc42 I have built the latest 3.5-dev RRF. M596 is accepted. But I can't get asynchronous motion running. It doesn't start the second (P1) motion system and waits forever.
What I am trying to do is simply running X and Y asynchronously.

Could you please provide an example?

dc42

@wiego unfortunately I had to pause work on multiple motion system support due to other pressing work. The current state is that multiple motion systems won't work in SBC mode, but might work in standalone mode. However, pause and resume will not work because the changes have not been completed.

Hoops40

@dc42 was wonder if there is a way to implement a trigger function. This might allow independent z axis.
I'm not a programmer so probably asking a stupid question.
Thinking if each head has trigger for layer completion to tell the system to send next line of commands to specific head.
Mechanical or digital not sure which would be best.
Sorry if it's a stupid question.

slaughter2k

@dc42 just to let you know: I am new to Duet3d but not new to mechanics and 3d printing --> I have already built a corexy multi gantry system, will purchase the latest duet 3 board with extension to 11 drivers and install the latest 3.5 beta for testing. It is definitively aimed to run in SBC mode as the printer has to download and start print jobs via firebase cloud triggered via API.
Side comment: I raised a question in the general thread regarding "is it possible to let reprap run a complete separate stepper motor in parallel to the print job". If'd get this solved in addition, my dreams coming true

dc42

I've updated the preliminary documentation on multiple motion systems at https://docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems.

slaughter2k

is there a special login / permission needed to see this beta documentation? Or are we talking about this one https://docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems

I am currently studying this

dc42

@slaughter2k I'm sorry, I accidentally gave the URL of that page that allows editing. Your link is correct.

slaughter2k

no issue...
"one" thing I don't fully understand yet from the documentation:
"For command streams that originate from file, each motion system uses a separate GCode processor..."
--> Is my understanding correct that ...from file... means that the gcode has to be stored on SD card?

dc42

@slaughter2k yes, to make maximum use of the multiple motion support, you must print from SD card on the Duet, or if using attached SBC then from a file n the SBC. The beta1 release may not support using multiple motion systems when printing from SBC.

It's possible to use multiple motion systems when not printing a file, however in this case a single GCode processor is used so it will only possible to move the two motion systems concurrently while both movement queues are not full. Whereas when printing from file, each motion system has its own GCode processor that reads from the file independently of the other one.

o_lampe

I started a discussion about various printer kinematics here.
Meshleveling with two tools is still unsolved, but it's worth keeping this option in mind for a future build.

dc42

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

I started a discussion about various printer kinematics here.
Meshleveling with two tools is still unsolved, but it's worth keeping this option in mind for a future build.

Independent mesh levelling requires independent adjustment of Z heights. Unfortunately there is a patent on that in (at least) US and EU. There is another patent on independent motion systems, but I have been told it is US-only.