Multiple motion system

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

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

dc42

@Alva please try the new Duet 3 Mini firmware binary at https://www.dropbox.com/scl/fo/pasag1g18orahwvn49qp2/ABWgw6D-TyKWxxurTmGwiUE?rlkey=r9h3rjyw1l4wh7xbr8yho37gw&dl=0.

Alva

@dc42 It seems to be working. I have tried all the above conditions and works as intended. Can i expect the same fix for Duet3 6HC board as well, as i observed the same behavior in it as well. Thank you

dc42

@Alva I have just put a 6HC build at the same location.

Alva

@dc42 Thank you , I will check it out

T3P3Tony

@Alva please can you confirm if you have tested this.

Alva

@T3P3Tony Hello sorry, i haven't checked it out. The 6HC board i have is bit different from the original version. So i need to build it differently. I am actually waiting for the beta 3 version of the firmware now.

dc42

@Alva you could try 3.6.0-beta.2+5 at https://www.dropbox.com/scl/fo/1l1t3h52jkapaszdpcruz/AOWakD9qTwZ2HRnV7N3vVvQ?rlkey=42ehcpbas7rwgz6z1318mbceh&dl=0 if you like. Use it with care because the changes in it are quite substantial. You may wish to reduce motors currents until you are happy that it behaves correctly. See https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-beta3-in-preparation for important changes.

Alva

@dc42 Thank you. I will try it out and let you know the status.

Alva

@dc42 g binary "0:/firmware/Duet3_SDiap32_MB6HC.bin" not found , in the drop box this file is not available