Beta testers for multiple motion system support
-
@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.
-
@dc42 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?
"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.
-
@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.
-
@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.
-
@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. -
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.
-
undefined o_lampe referenced this topic 1 Nov 2022, 20:17
-
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
-
@dc42 any updates? Also was wondering if there is capability in independent z axis as well?
-
@Hoops40 RRF3.5b1 has been released with support for multi motion systems. I don't believe there is currently independent Z axis support
-
@jay_s_uk OK thank you.
-
@dc42 could you please share a sample file of how the file looks?
is it something likeM596 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. -
@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.