Multiple motion system

gloomyandy

@Alva Do you have anything in the various tool change macros?

Alva

@gloomyandy i am just setting the led strip colors of the corresponding active tool and moving the u or w axes based on which tool is activated to its minimum position

Alva

@Alva I tried another test, while the machine was printing i trigerred daemon with a flag global.called and created the condition when global.called= true to select the second motion system and move the W axis. then the axes moved to the Y max and crashed and machine still remains in the printing state doing nothing.

gloomyandy

@Alva The system staying in the printing state is to be expected when you get a motion error, it is basically partially shutdown when that error occurs. The question is why are you getting those errors. I assume if you just run whatever it is you are printing then you do not get that error. I'm not sure if running the second motion system from another gcode stream is causing a problem. From what I remember I think there may be some assumptions that both motion systems are running from the same gcode file (possibly forked using M606).

It might help if you post your config.g file and maybe a picture (or video) of your printer. I'm struggling to work out how all of this fits together, you seem to have two tools but six extruders and 5 axes. I'm also a little confused as to how the tools are controlled what moves when you command X and Y moves?

Alva

@gloomyandy Hello ,
Sorry for the late reply. Was on vacation for few days. I have continued the "experiment". Ignore the number of extruder drivers i had above. I rewired and reconfigured everything to the very simple set up. I have a Duet 3 mini 5+ board with CAN expansion motor board and a tool board. I have X;Y;Z set up via the motor board and the tool axes from the tool board. I have a stepper motor connected to the mini board and i configured it as U axis. It is just for the experimental set up. (My intended use is to load filament in the other tool while the machine is printing). So the U axis is my fake tool for example. I am just experimenting before i want to really implement it.
My findings so far.:

With the firmware version 3.5.3 , it is working.
With the firmware version 3.6.0.beta1 i am getting the error that i reported before.
daemon(1).g config(3).g .
Thank you .

gloomyandy

@Alva I think the first step will be to wait for 3.6.0-beta.2 (due shortly I think) and test again with that. If it still fails then try and create a simple test case that recreates the problem and then we will need to try and reproduce the problem.

Alva

@gloomyandy Okay, I will wait for the release then. Thank you

droftarts

@Alva It is available now: https://github.com/Duet3D/RepRapFirmware/releases/tag/3.6.0-beta.2

Ian

Alva

@droftarts

daemon(2).g
mini(1).gcode
Hello , i have updated the machine to 3.6.0.beta2 and tried a simple logic as seen in the mini-1.gcode which is attached. while it starts the print i manually set the flag to enable the daemon.g and the daemon.g is also attached. And the same error occurred again. Do you think there is something wrong with the way that i understood the second motion system? or am i doing something wrong? weird that my logic worked in 3.5. fw version.
Please let me know. Thank you.

Alva

@Alva Looks like there was a mistake in the 3.6.0.beta2 release and David updated the new one today. I will try out that one.

dc42

@Alva here are a couple of clarifications:

When you select a tool (which becomes the current tool for the current motion system), the axes that X and Y are mapped to for that tool become owned by the current motion system.
It's fine to drive the two motion systems from different GCode streams.

dc42

@Alva I just noticed this in your mini(1).gcode file:

G4 P0 S0.5

You should use either P or S in G4, not both. Similarly in daemon.g. However, this doesn't explain the error.

dc42

@Alva my best guess is that the move G1 X0 Y0 U0 in mini(1).gcode hasn't completed when daemon.g starts commanding U axis motion. This shouldn't be possible, because if U hasn't finished moving then U should still be owned by MS0, so the attempt to move it in daemon.g should fail with the "axis already owned by another MS" message. I'll check the M400 code.

Alva

@dc42 I have edited the code and logic a bit. Found different cases:

; File Name: 		/sys/daemon.g
if(!exists(global.daemonStop))
	global daemonStop = false	; Set to 1 to stop the daemon.g, it can be use to upload a new daemon.g file

while( global.daemonStop == false )
    if(state.status== "processing")
        G91
        M596 P1
        G1 U5 F300      
        M596
    G4 P0
M99; Exit

test_2nd_MS.gcode
.
This happened when i activated the daemon before the move to X0 Y0. But if i activate the daemon after that then it works perfectly. Cannot relate whats going on.

set global.daemonStop = true ; stopped the daemon
M118 S{"starting to move"}
G90
G1 X0 Y0
M400 S1
G91
set global.daemonStop = false ; activated the daemon which only use U axis
G1 X100 Y100 F200
M400 S1
G90
M118 S{"move done"}
M99

Alva

@Alva

Alva

@Alva Looks like it is a timing problem or something.

dc42

@Alva thanks, I will try to replicate it.

Alva

@dc42 Thank you

dc42

@Alva I have reproduced this and I am looking into it.

dc42

@Alva I created https://github.com/Duet3D/RepRapFirmware/issues/1064 and I am testing a fix.

dc42 created this issue in Duet3D/RepRapFirmware

Multiple motion system

open Use of multiple motion systems causes Code 3 halts in 3.6 beta1 and beta2 releases #1064