Beta testers for multiple motion system support

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.

o_lampe

@dc42
As it turned out in my thread, there are only two candidates left for independent z-adjustment: dual delta or dual SCARA option.
I don't believe, the patents you mentioned forbid me to build such a printer?
Or is it about a certain software method?

Finding workarounds or improve the patented methods is still an option...
Do you have a link to the patents, please?
THX

oliof

@o_lampe I don't think those patents necessarily bar you from building a printer with those features yourself, but you may not be allowed to commercially exploit them. I'm not a patent lawyer so this is a random claim on the internet and don't rely on it as legal advice (-:

dc42

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

Do you have a link to the patents, please?

Here are links to some relevant patents. There may be others.

https://patents.google.com/patent/US20150231827A1/en
https://patents.google.com/patent/US11086295B2/en
https://patentimages.storage.googleapis.com/dd/95/ae/df14d6ce71d74b/US20200233399A1.pdf
https://patentimages.storage.googleapis.com/dc/d9/a1/69e28a28a70d1e/EP3347190B1.pdf

oozeBot

@dc42 we have a unique use case that this might solve - or there may be an existing way that you can point us towards. We are interested in using a second extruder as an automatic filament unwinder as we use 10KG spools that put a lot strain on primary extruder.

The idea would be to create another axis (F). It would be simple to have our post-processor duplicate the E commands into F commands like:

G1 X124.761 Y43.556 E2.46118 F2.46118

That would work, but its not how we want to tackle it. I threw together an algorithm which calculates the amount of filament used per layer and then generates a new command before the layer begins.

;LAYER_CHANGE
G1 F304.84405
;Z:0.5
;HEIGHT:0.5
G1 Z.5 F9600
G10 ; retract
G1 X95.404 Y57.128
G11 ; unretract
;TYPE:Skirt/Brim
;WIDTH:0.75
G1 F1440
G1 X102.111 Y45.927 E1.74422
G1 X103.445 Y44.47 E.26393
G1 X105.244 Y43.654 E.26393
G1 X106.339 Y43.531 E.14722
G1 X124.761 Y43.556 E2.46118
G1 X127 Y43.935 E.30343
G1 X128.648 Y44.49 E.23234
G1 X130.206 Y45.262 E.23226

This would allow the second extruder to advance the next layer's filament at once. This would work as well, but currently, the print would pause while the F-axis "extruded" the next layer's filament.

So our question is, with the new multiple motion system or anything existing, is there a way for commands to be executed out of process from the primary job's gCode stream?

dc42

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

So our question is, with the new multiple motion system or anything existing, is there a way for commands to be executed out of process from the primary job's gCode stream?

It looks like timing isn't critical for that application, so you could use the daemon.g file to run the filament unwinder.

A problem I can see is that any error in the relative steps/mm of the two motors will cause the reel to unwind either too fast or too slowly. Have you considered using a switch to detect tension in the filament, and using it to run a DC motor to unwind the spool for a few seconds?

dc42

PS - I am currently testing and debugging the multiple motion support, and I hope to release 3.5beta1 soon.

oozeBot

@dc42 The idea would be to advance F some amount (~100mm) at the beginning of the print so it is considerably ahead of E. We also have it worked out where there won't be any tension between the extruders.

So gCode executed by the daemon is out of process? We'll consider how we can cleanly get this information piped over to it. Thinking 'out loud,' from the job's gCode, we could call a custom mCode with the F value as a parameter. That mCode's job could be to convert the F-value into something consumable for the daemon. This would be a great use case for Arrays.. looking forward to that being introduced.

Thanks!