Multiple motion system
-
@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 i have tried the same with the 3.6.0.beta2 +3 it worked as intended
-
-
@Alva We're going to release 3.6.0-beta.3 in a couple of days, please retest when we release that.
Ian
Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth
-
@droftarts Sure will do. Thank you.
-
@Alva it's released:
https://forum.duet3d.com/topic/37289/software-version-3-6-0-beta-3-now-available
Testing is appreciated
-
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? -
@T3P3Tony Tested the above mentioned testing procedure and got the same error as 3.6.0.beta2 + 5.
-
@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.
-
Any updates about this topic? My observation is 3.6.0-beta2+3 worked , but after that it is broken. Thank you
-
Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth
-
@droftarts Okay ,
thank you. -
-
undefined T3P3Tony referenced this topic
-
@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.
-
@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
-
@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
Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is
-
@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?
-
@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.
-
@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.
-
@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
