Beta testers for multiple motion system support

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!

dc42

@oozebot alternatively you could have daemon.g monitor the rawPosition or position value for the extruder concerned. Those values are available in the object model.

oozeBot

@dc42 good call. Sorry to semi-hijack this thread, but can you please take a look at the following snippet? It works from daemon.g, but it is pausing the print when the C axis is moved. I thought this would be out of process from the job?

Hopefully I'm doing something wrong.. If not, would this scenario be supported by the update for multiple motion systems?

var rawExtrusion = 0
if job.rawExtrusion == null
	set global.spoolPosition = 0
else
	set var.rawExtrusion = job.rawExtrusion
	
if var.rawExtrusion > global.spoolPosition + 100
	G1 C{var.rawExtrusion - global.spoolPosition} F1000
	set global.spoolPosition = var.rawExtrusion
	G92 C0

zruncho

@dc42

I don't have the modern Duet boards to make use of this code, but it's still exciting to hear that this is coming along.

Today I released a complete open-source Dual-Gantry CoreXY printer called Dueling Zero, w/configs, STLs, videos, CAD, docs, diagrams, the whole nine yards. The GitHub repo includes a sample RRF config for XY motion, which "just worked"... it was nice.

https://github.com/zruncho3d/DuelingZero/

Curious what you (and others on this thread) think. In particular, the section on collision detection and avoidance in a shared workspace is general for any firmware.

https://github.com/zruncho3d/DuelingZero/blob/main/SOFTWARE.md

dc42

@zruncho the RRF 3.5-dev branch now includes basic collision avoidance. See https://reprap.org/wiki/G-code#M597:_Collision_avoidance. Currently this is limited to checking for a minimum separation between one pair of axes, which is sufficient for IDEXY machines; but I have implemented it in a manner that allows it to be easily extended in future.

zruncho

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

https://reprap.org/wiki/G-code#M597:_Collision_avoidance

If I understand the G-code description, though, this seems like more of a "collision detect & then abort" than proactive avoidance?

"If this is not the case, the job will be aborted prior to starting the first move that would cause the conflict."

Still useful though! If I had this it would have avoided a few head crashes.

BTW, have you seen any other Dual Gantry machines printing? The Links section at the bottom of the README links to every bit of prior art I could find - mostly gantry renders for post (here), or one commercial model, the Essentium HD 280i.

https://github.com/zruncho3d/DuelingZero#links

dc42

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

@dc42 good call. Sorry to semi-hijack this thread, but can you please take a look at the following snippet? It works from daemon.g, but it is pausing the print when the C axis is moved. I thought this would be out of process from the job?

There is only a single motion system in the current RRF, so the C axis movement has to be inserted into that queue.

Furthermore, the G92 C0 command will wait until all pending movement has been completed and there is no movement before it executes. You may get better results if you can rewrite that code without using G92 C0, but there will still be slight pauses.

Hopefully I'm doing something wrong.. If not, would this scenario be supported by the update for multiple motion systems?

Yes.