Beta testers for multiple motion system support

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.

dc42

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

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

Correct. It's up to the slicer to do proactive avoidance. The collision detection is there as a backup.

o_lampe

@dc42 With a dual gcode stream, would it be possible to run a "colour-splicer" machine?
The idea is to use a single Bowden tube hotend and feed it with filament cutoffs of different colours.
The cutoff length would be calculated by checking the gcode for tool changes. (the toolchange macros are basically for cutting off the current filament and feed forward the next colour)
The "length of the Bowden tube X extrusion speed " would determine the time it takes before colour "X" reaches the nozzle and the second gcode stream would do the motion planning with a fixed delay between splicing and extruding.

misan

I considered this a while ago for CNC machining: https://fightpc.blogspot.com/2017/10/getting-work-done-faster-on-cnc-machine.html

More than going for a self-scheduling system handling collisions, I went for a simpler system where both heads will swipe space from "left to right" keeping a safe distance. But I never went beyond the concept. In my case, each head could have a different Z height.

dc42

I finally got time today to work on this again. Here's an example of multiple motion systems in operation. https://www.dropbox.com/s/v18lgomkg44ald9/20221101_223148.mp4?dl=0

Hoops40

@dc42 any updates? Also was wondering if there is capability in independent z axis as well?

jay_s_uk

@Hoops40 RRF3.5b1 has been released with support for multi motion systems. I don't believe there is currently independent Z axis support

Hoops40

@jay_s_uk OK thank you.

Aurimas

@dc42 could you please share a sample file of how the file looks?
is it something like

M596 P1
G1 X50 Y75 E2
M400
M596 P0
G1 U85 W9 E3
M400

?
I cannot figure it out from the manual.
sorry for a silly question.

dc42

@Aurimas like that but without the M400 commands. Also you can have a block of G1 commands after each M596 command rather than just one.