Multiple motion system

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

droftarts

@Alva Get the "Duet3_SDiap32_MB6HC.bin" file individually from here: https://github.com/Duet3D/RepRapFirmware/releases/tag/3.5.1
Otherwise it's in the zip file download in most releases, eg in "Duet2and3Firmware-3.5.4.zip" here https://github.com/Duet3D/RepRapFirmware/releases/tag/3.5.4

Ian

Alva

@droftarts thank you. got it.

Alva

@Alva Tested the second motion system with the new version 3.6.0.beta2 + 5, but i am getting the error shows in the picture below:

tried gcode :

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

daemon.g :

; 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; File Name: 		/sys/daemon.g

Alva

@Alva U axis was trying to use only in the second motion system. so motion system 0 and motion system 1 are not able to execute simultaneously.

Alva

@Alva i have tried the same with the 3.6.0.beta2 +3 it worked as intended

Alva

droftarts

@Alva We're going to release 3.6.0-beta.3 in a couple of days, please retest when we release that.

Ian

Alva

@droftarts Sure will do. Thank you.

T3P3Tony

@Alva it's released:

https://forum.duet3d.com/topic/37289/software-version-3-6-0-beta-3-now-available

Testing is appreciated

o_lampe

My understanding of the dual gcode stream is: you can open two gcode files at the same time and have a daemon.g running in the background?
At the same time you'd have to split the config.g into two portions.
Maybe put the U-axis specific lines in the startcode of the second stream?

Alva

@T3P3Tony Tested the above mentioned testing procedure and got the same error as 3.6.0.beta2 + 5.

Alva

@o_lampe My requirement is to utilize the unused axes during printing, with their movement controlled via daemon.g and triggered by a flag. My understanding of multiple motion systems is that the unused axes should be accessible to the other motion system. However, the error I am encountering indicates that the unused axes are still being treated as part of the motion system responsible for the print job.

Alva

Any updates about this topic? My observation is 3.6.0-beta2+3 worked , but after that it is broken. Thank you

droftarts

@Alva I've asked @dc42 to have a look at the issue.

Ian

Alva

@droftarts Okay , thank you.

Alva

@Alva @dc42 sorry for writing again, but will there be fix regarding this topic in the next version?

dwuk3d

@Alva I think I am getting the same issue as you - in 3.5.4 I can access my U axis in Motion system 1 ok - but not in any of the 3.6.0 beta versions I have tried.

The problems I am getting though the 3.5.4 is that the synchronisation isn't working - with either M598 and M400 don't seem to work. Plus also I can't seem to extend the length of the queue with M595 beyond 5 entries.

dwuk3d

@Alva Update - Just managed to get it working in 3.6.0b4 - by surrounding all references to the U axis in M596 P1 - including in the homing macro's

M598 still not working for me though -

plus in my case I am finding a connected Mini5+ board runs slow in 3.6.0b vs 3.5.4 - so I have left that board at 3.5.4