Multiple motion system

gloomyandy

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

dwuk3d

@jay_s_uk Great - I was imagining it was some sort of comms issue - happy to test out the fix.

dwuk3d

@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.

Alva

@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?

dwuk3d

@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.

dwuk3d

@Alva - update - I think I have found out the cause of my M598 issue -
See https://forum.duet3d.com/post/352006

I 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.

dwuk3d

Update on 3.6.0.rc1

The same issue is occurring as far as I can see.

On 3.5.4 you can get an axis released by doing T-1 followed by M400 (or probably M598), but on 3.6.0.b4 and rc1 once you have used an AXIS in a motion system it seems to never be released- whatever combination of switching tools, motion systems, M400 and M598's I have tried.

Alva

@dwuk3d Thank you so much for informing me. Sorry that i haven't got time to experiment further on this topic. I hope @dc42 and his team is looking into it .

dc42

@dwuk3d said in Multiple motion system:

On 3.5.4 you can get an axis released by doing T-1 followed by M400 (or probably M598), but on 3.6.0.b4 and rc1 once you have used an AXIS in a motion system it seems to never be released- whatever combination of switching tools, motion systems, M400 and M598's I have tried.

Thanks, I'll try to reproduce this.

EDIT: reproduced, created https://github.com/Duet3D/RepRapFirmware/issues/1099. I intend to fix it before we release 3.6.0-rc.2.

dc42 created this issue in Duet3D/RepRapFirmware

closed Axes not getting released in RRF 3.6.0-rc.1 #1099

dc42

@dwuk3d this is now fixed. Please try the 3.6.0-rc.1+3 binaries from https://www.dropbox.com/scl/fo/geqmn8gbn97n6b587mkbk/AJ2hBIqO-L57_QpR_uqHJ9c?rlkey=fw37wycbp2gil8rvxhe7aopy7&dl=0. Release notes are at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC#reprapfirmware-360-rc2-in-preparation.

dwuk3d

@dc42 Thanks -thanks that seems to have fixed my issue - I can for example assign T1 to M596 P0, Release T1 with a T-1, and then assign T1 to M596 T1 ok.

Will run further homing sequence and parallel printing tests once I have put machine back together - as am working on some improvements to the rear gantry (P1) at the moment.

dc42

@dwuk3d thanks for confirming. Please start a new thread if you find any further issues as this thread is already rather long.

Alva

@dc42 Thank you. Confirmed as fixed from my side as well.