Multiple motion system

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

jay_s_uk

@dwuk mixing 3.5.4 and 3.6b4 based boards, with the amount of changes that have happened between the two, is a really bad idea

gloomyandy

@dwuk said in Multiple motion system:

plus in my case I am finding a connected Mini5+ board runs slow in 3.6.0b vs 3.5.4

Can you provide more details on that? What exactly is slow?

dwuk3d

@gloomyandy The U&V axis don't react instantly when you press the +1/+10 etc. button - there seems to be a small delay.

Also when homing the U Axis - it is a two pass process - normally the first hit happens, the tool head immediately moves back, and then has its' second attempt, but with 3.6.0 again there is a slight delay.

The the Mini5+ board is on 3.5.4 there is no noticeable delay.

If there isn't any obvious answer I will make a short video at some point to demonstrate the difference.

dwuk3d

@jay_s_uk Yes I am sure you are right. I am not really seeing any advantage in 3.6.0b4 over 3.5.4 at the moment - so will probably revert the whole lot back to 3.5.4 - as all 3.6.0 is unusable for me.

dwuk3d

@gloomyandy Just realised this is @Alva's thread - if you look at my one you will see a lot more detail of the 'slowness' problem

jay_s_uk

@dwuk if you're doing any remapping of axes after movement in 3.5.4 that's unusable too.
You'll notice a difference when you come to print something as the movement code is way better in 3.6, especially pressure advance and input shaping

jay_s_uk

@dwuk the out of sync/delay issues with a mainboard in expansion mode has been fixed internally. Don't know if a build has been made available