Multiple motion system
-
@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
-
@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 shapingOwns 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 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
-
@jay_s_uk Great - I was imagining it was some sort of comms issue - happy to test out the fix.
-
@jay_s_uk Yes - I am currently testing with T1 mapping U&V as X&Y in the second motion system - with the real X&Y in T0. It seems to work on 3.6.0 (with the Mini5+ on 3.5.4) - but I haven't tried that approach on a completely 3.5.4 system.
It is not essential that I use U&V that way - as I can fairly easily change X&Y to U&V in my post processor.
-
@dwuk It was working in the 3.6.0-beta2+3 and it broke on the later versions. But i haven't tested the 3.6.0-beta4 yet though. Have you tested it?
-
@Alva It works differently between 3.5.4 and 3.6.0b4 - but I have been able to get it to work - but only if I home the U axis with M596 P1, and XY within M596 P0
I can't actually get multi axis really working properly though - because I can't get M598 syncing to work.
-
@Alva - update - I think I have found out the cause of my M598 issue -
See https://forum.duet3d.com/post/352006I have so far been doing most of my tests as Macros.
If I download the macro's and then upload them as Jobs then run them they work much better - with the M598's seeming to work correctly.
This also might have fixed my M595 problem (although that might be a firmware based fix).
Not sure if this will also have any impact on my 'axes in use' issues (that I worked around by putting M596's into my homing macro's) - but will now try running my homing and tests all using jobs rather than Macro's - so see if that sorts out any other issues.
