UVW movement issues with [3.6.0]

[dwuk3d]

@droftarts

Your understanding of my V axis is correct - it moves in the Y direction, and moves itself, plus also the U and W motors - to keep them in the same place.
U & W IDEX axis then move directly (on top of any movement needed by the V axis).

So the IDEX Axis is Dual Markforged, and the XY Axis is CoreXY.
This all was surprisingly easy to configure and worked first time (other than perhaps the odd direction reverse change).

It all worked pretty well - though apart from 3 issues

Until recently I have had the tools setup with
T1 X=U Y=V Z=Z
T2 X=W Y=V Z=Z

I currently have 3 issues. (I guess I should raise separate threads for each one).

1. In 3.5.4 - layer shifts - which seem to be related to my Z hopping AB&D Axis and/or the Z Axis.
   These are rapid movements of usually non printing Tools a short distance - while the other tool is doing things in the other motion system.

As part of an attempt to resolve this issue I have changed the tool definitions for T1 and T2 to have dummy X&Y axis (lower case a and b in my config.g - which are actually mapped to 2 of the 4 Z gantry motors) - and are then using the actual UV&W axis in my G1 movements - which I changed in the GCODE using a post processor. - see extract of GCODE at the end of this reply.

I thought RRF might be getting confused about the X and Y's being different thinks on the two motion systems - so thought if I completely removed the connection between these from the tools definitions it might stop them being affected. - This didn't work by itself.

Though this, together with changing my Z Axis layer change moves instead of just G1 Zn - to be T-1 G1 Zn M400 T0 may have fixed the layer shift issue - as it is no longer occurring in my small test prints. NB/ I have seen it before on T0 too - when T1 or T2 were doing something.

Specifically the last occurrence of this I nailed down to T0 doing a G1 Z.4 - which caused T2 to rapidly move in the V direction until it hit the back - but for the V coordinates not changing in RRF.
It may also be linked to the B A & D Axis - because my previous workaround to this issue was to not use these extra Zhopping axis at all for Z Hopping.

2. In 3.5.4 - speed issues -
   Some of the tools, particularly T1 and T2 in Multiple motion systems seem to be going 3-4 times faster than the feed rates specified. My workaround to this at the moment is to put a feedrate on every move, and divide it by a fixed amount on the T1 and T2 tools to slow them down to a usable speed - Seeing if this still occurred on 3.6.0 was one of my main motivations for moving to 3.6.0.
   @dc42 has made some comments on this directly on my main thread - the last of which was asking for a M584 dump

3. in 3.6.0 only -
   This actual issue - where I am getting some issues with the W axis not moving - With G1's and DWC moves directly asking for moves of the W Axis - and it sometimes not responding - which makes me think that maybe it is an issue with the fact that these axis are on the slave Mini5+ board - as I know there were issues with things like slow movements and jumping about in earlier 3.6 rc's

Filled in squares - consisting on WV and UV. G1 movements, which work ok on 3.5.4. coming out as simple diagonal lines (in the opposite direction to what you would get if only V movements were happening on VW - i.e. Right to Left (-U and -W). as V increases.

Corrections: The two diagonal lines are facing outwards - so this would indicate that maybe the W and U motors are not working and only V movement is happening. NB/ This is only for the printing in the middle of the bed, not for the priming at the edge. I will put some M99's in to see if I can do a dump of the settings while the error has actually occurred.

If it would be easier I could try restoring the tools definitions to put the redirects back in - and try to recreate it again on 3.6.0 with T1 and T2 moves being X&Y redirected to UVW by the tool definitions.

(Once I have restored my system - as my attempt to downgrade back to 3.5.4 has currently bricked it. Update - Had to erase firmware on 6HC board again to get 3.5.4 installed.

Some example square drawing GCODE for T2 that I had the issue with.
NB/ M802 is a macro that I added in to try and detect if a layer shift had occurred and report it - at present it just does an M99

M106 S0
; Filament gcode
G10 S220 P2 ; set nozzle temperature
;prev preheat:0:T2:**NO PREHEAT**
M116.1 ; wait for temperature to be reached
; printing object Cube id:0 copy 0
; stop printing object Cube id:0 copy 0
; printing object Cube id:2 copy 0
G1 F300.0 E-.8
M486 S-1
M486 S2
G1 A{global.aOffset+0.4} F7500.0
M802 L607; 
G1 F7500.0 W181.417 V203.485
G1 F7500.0 A{global.aOffset+0.4}
M802 L610; 
G1 F7500.0 A{global.aOffset}
M802 L612; 
G1 E.8 F300.0
;TYPE:Inner wall
;WIDTH:0.499999
G1 F750.0
G1 F500.0 W162.832 V203.485 E.69225
G1 F500.0 W162.832 V184.899 E.69225
G1 F500.0 W181.417 V184.899 E.69225
M73 P19 R3
G1 F500.0 W181.417 V203.445 E.69076
G1 W181.874 V203.942 F7500.0
;TYPE:Outer wall
G1 F750.0
G1 F500.0 W162.374 V203.942 E.7263
G1 F500.0 W162.374 V184.442 E.7263
G1 F500.0 W181.874 V184.442 E.7263
G1 F500.0 W181.874 V203.902 E.72481
G1 E-.8 F300.0
M73 P20 R3
G1 A{global.aOffset+0.4} F7500.0
M802 L632; 
G1 F7500.0 W180.342 V185.036 A{global.aOffset+0.4}
M802 L634; 
G1 F7500.0 A{global.aOffset}
M802 L636; 
G1 E.8 F300.0
;TYPE:Bottom surface
;WIDTH:0.506511
G1 F1500.0
G1 F1000.0 W181.075 V185.768 E.03911
G1 F1000.0 W181.075 V186.424 E.02477
G1 F1000.0 W179.893 V185.242 E.06315
G1 F1000.0 W179.237 V185.242 E.02477
G1 F1000.0 W181.075 V187.079 E.09818
G1 F1000.0 W181.075 V187.735 E.02477
M73 P21 R3
G1 F1000.0 W178.581 V185.242 E.1332
G1 F1000.0 W177.926 V185.242 E.02477
G1 F1000.0 W181.075 V188.391 E.16823
G1 F1000.0 W181.075 V189.046 E.02477
G1 F1000.0 W177.27 V185.242 E.20325
G1 F1000.0 W176.614 V185.242 E.02477
G1 F1000.0 W181.075 V189.702 E.23828
G1 F1000.0 W181.075 V190.357 E.02477
G1 F1000.0 W175.959 V185.242 E.27331
G1 F1000.0 W175.303 V185.242 E.02477
G1 F1000.0 W181.075 V191.013 E.30833
G1 F1000.0 W181.075 V191.669 E.02477
G1 F1000.0 W174.648 V185.242 E.34336
G1 F1000.0 W173.992 V185.242 E.02477
G1 F1000.0 W181.075 V192.324 E.37838
G1 F1000.0 W181.075 V192.98 E.02477
G1 F1000.0 W173.336 V185.242 E.41341
G1 F1000.0 W172.681 V185.242 E.02477
G1 F1000.0 W181.075 V193.636 E.44844
G1 F1000.0 W181.075 V194.291 E.02477
G1 F1000.0 W172.025 V185.242 E.48346
G1 F1000.0 W171.369 V185.242 E.02477
G1 F1000.0 W181.075 V194.947 E.51849
G1 F1000.0 W181.075 V195.602 E.02477

[dwuk3d]

@droftarts Update - ran it again - with an abort mid print.

While it is printing on UV.

I have found that something is stopping the U motor from working - which now I have corrected the direction of the diagonal lines makes more sense.

The U motor works ok when it is priming - but not while printing.

At the time of the error W is still working - but I suspect that something after my priming is going to stop that motor from working too.

Also - just discovered that the loss of movement of the U Axis motor also spans Emergency restarts - so something in my Job when run in 3.6.0 is causing my motors to turn off.
So after an Emergency stop U doesn't work, but W still does.
If I do a G1 H2 U-1 then the motor turns back on again.

Kinematics is CoreXY, no segmentation, modified matrix:
1.00 1.00 0 0 0 0 0 0 0
1.00 -1.00 0 0 0 0 0 0 0
0 0 1.00 0 0 0 0 0 0
0 0 0 1.00 0 0 0 0 0
0 0 0 1.00 1.00 -1.00 0 0 0
0 0 0 0 0 1.00 0 0 0
0 0 0 0 0 0 1.00 0 0
0 0 0 0 0 0 0 1.00 0
0 0 0 0 0 0 0 0 1.00

Driver assignments: X0.3 Y0.4 Z0.1:0.2:0.0:1.3 U1.0 V1.5:1.6 W1.1 (r)(c)A1.4 (r)(c)B0.5 (r)(c)D1.2 E121.0:122.0:123.0, 9 axes visible
Motor current % of normal - X:100, Y:100, Z:100, U:100, V:100, W:100, A:100, B:100, D:100, E:100:100:100

Motor current (mA) - X:800, Y:800, Z:800, U:800, V:800, W:800, A:750, B:750, D:750, E:800:800:800, idle factor 30%, timeout 30.0 sec
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0 (2025-05-25 08:05:42) running on Duet 3 MB6HC v1.02 or 1.02a (standalone mode)
Board ID: 0JD4M-958L1-M2NS0-7JTDG-3SN6K-91FKZ
Used output buffers: 16 of 40 (36 max)
=== RTOS ===
Static ram: 137420
Dynamic ram: 136672 of which 0 recycled
Never used RAM 68444, free system stack 134 words
Tasks: NETWORK(1,ready,33.8%,180) ETHERNET(5,nWait 7,0.3%,316) HEAT(3,nWait 6,0.0%,350) Move(4,nWait 6,0.0%,209) TMC(4,nWait 6,3.3%,343) CanReceiv(6,nWait 1,0.1%,768) CanSender(5,nWait 7,0.0%,329) CanClock(7,delaying,0.0%,350) MAIN(1,running,62.3%,103) IDLE(0,ready,0.0%,29) USBD(3,blocked,0.0%,144), total 100.0%
Owned mutexes: HttpGCodeReply(NETWORK) File(MAIN)
=== Platform ===
Last reset 00:05:31 ago, cause: power up
Last software reset at 2025-06-06 15:37, reason: User, Gcodes spinning, available RAM 71836, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
MCU temperature: min 49.2, current 49.4, max 50.0
Supply voltage: min 24.0, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.2, max 12.4, under voltage events: 0
Heap OK, handles allocated/used 198/82, heap memory allocated/used/recyclable 2048/1776/576, gc cycles 13
Events: 0 queued, 0 completed
Date/time: 2025-06-06 15:42:36
Slowest loop: 80.45ms; fastest: 0.05ms
=== Storage ===
Free file entries: 16
SD card 0 detected, requested/actual speed: 25.0/25.0MBytes/sec
SD card longest read time 2.8ms, write time 3.4ms, max retries 0
=== Move ===
Segments created 30, maxWait 278179ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 3200.00/3200/-0.00 0.00/0/-0.00 107.00/107/-0.66 27439.00/27440/-1.00 14962.00/14962/-0.00 9839.00/9838/1.00 9282.00/9281/0.11 7368.00/7368/0.00 8317.00/8317/-0.62
Next step interrupt due in 119 ticks, disabled
Driver 0: standstill, SG min 0, mspos 616, reads 55597, writes 0 timeouts 0
Driver 1: standstill, SG min 0, mspos 248, reads 55597, writes 0 timeouts 0
Driver 2: standstill, SG min 0, mspos 488, reads 55597, writes 0 timeouts 0
Driver 3: standstill, SG min 0, mspos 792, reads 55597, writes 0 timeouts 0
Driver 4: standstill, SG min 0, mspos 472, reads 55597, writes 0 timeouts 0
Driver 5: standstill, SG min 0, mspos 184, reads 55598, writes 0 timeouts 0
Phase step loop runtime (us): min=0, max=100, frequency (Hz): min=671, max=10273
=== DDARing 0 ===
Scheduled moves 212, completed 212, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x20000000, drives owned 0x20000000
Code queue is empty
=== DDARing 1 ===
Scheduled moves 131, completed 131, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x80000003, drives owned 0x80000003
Code queue is empty
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1 -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.0
Heater 3 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is ready with "M290 R1 Z-0.05" in state(s) 0
Telnet is idle in state(s) 0
File is ready with "M122" in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is doing "G4 P91" in state(s) 0 0, running macro
Queue2 is idle in state(s) === CAN ===
Messages queued 2465, received 13422, lost 0, ignored 0, errs 0, boc 0
Longest wait 3ms for reply type 6061, peak Tx sync delay 216, free buffers 50 (min 48), ts 909/909/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 42.50ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0
= Ethernet =
Interface state: active
Error counts: 0 0 0 0 0 0
Socket states: 6 2 2 2 2 2 0 0 0
=== WiFi ===
Interface state: disabled
Module is disabled
Failed messages: pending 0, notrdy 0, noresp 0
Socket states: 0 0 0 0 0 0 0 0

Cancelled printing file 0:/gcodes/Box3.gcode, print time was 0h 1m
'abort' command executed

[dwuk3d]

@dwuk3d UPDATE - The turning off of motors seems to be intermittent - They started working half way through layer 1 on Red on attached photo (might relate to a few commands like M122 that I added in) , and on layer 2 on White

[dwuk3d]

@dwuk3d Further update

Have tried various combinations of inserts of G1 H2's into print to try and kick motors back into action.

Adding this to the start of the extruding section seems to kick U & V back into action.
But they drop out again after priming.

;M98 P"0:/macros/changeFilament.g" A previous_extruder  B new_filament_temp  L layer_num  N next_extruder   F first_layer_temperature1

M98 P"0:/macros/changeFilament.g" A0 B220 L0  N1  F220 
M203
M201

M106 S0
; Filament gcode
G10 S220 P1 ; set nozzle temperature
;prev preheat:0:T1:**NO PREHEAT**
M116.1 ; wait for temperature to be reached
; printing object Cube id:0 copy 0
; stop printing object Cube id:0 copy 0
; printing object Cube id:2 copy 0
; stop printing object Cube id:2 copy 0
; printing object Cube id:1 copy 0
G1 F450.0 E-.8
M486 S-1
M486 S1
G1 D{global.dOffset+0.4} F15000.0
M802 L416; 
G1 F15000.0 U142.213 V205.264
G1 F15000.0 D{global.dOffset+0.4}
M802 L419; 
G1 F15000.0 D{global.dOffset}
M802 L421; 
G1 E.8 F450.0
;TYPE:Inner wall
;WIDTH:0.499999
G1 F1500.0
G1 F750.0 U123.627 V205.264 E.69225
G91
G1 H2 U0.1 V0.1 ; Added to see if it makes a difference
G1 H2 U-0.1 V-0.1 ; Added to see if it makes a difference
G90
M73 P10 R3
G1 F750.0 U123.627 V186.678 E.69225
G1 F750.0 U142.213 V186.678 E.69225
G1 F750.0 U142.213 V205.224 E.69076

Priming within changefilament works ok

  if global.primeLayer[param.N] < param.L
            M98.1 A"clean T1"
            T1
            while iterations <  var.primeLoops
                M203 U{global.xyMaxFeed} V{global.xyMaxFeed}
                G1 F12000
                G1 U48 V295 F12000
                M801 U{50+0.4*(4-iterations)} V{295+0.4*(4-iterations)} T1 S{10+0.8*(iterations-4)} A{20+0.8*(iterations-4)}  ; Prime
            set global.primeLayer[param.N] =  param.L

    if exists(param.L) && param.L > 0 && global.primeLayer[param.N] < param.L
        T1
        M203 U{global.xyMaxFeed} V{global.xyMaxFeed}
        G1 F12000
        G1 U48 V295 F12000
        M801 U50 V295 T1 S10 ; Prime
        set global.primeLayer[param.N] =  param.L

    G1 D{global.dOffset} F500
    


    set global.T1Clean = false
    var timeC = state.upTime+state.msUpTime/1000

    ;echo {state.thisInput},"M598 started"
    ;M598
    ;M400
    ;echo {state.thisInput},"M598 waited for ",{state.upTime+state.msUpTime/1000-var.timeC},"secs"
    if param.A != 0 
        echo {state.thisInput},"No need to wait for Y Axis, Move W Over"
        
        G1 W300 F10000
        
    else
        set var.timeC = state.upTime+state.msUpTime/1000

        while global.startParkXY == -1  ; move.axes[1].machinePosition > 25
            G4 P59
            M400

        echo {state.thisInput},"waited for xy to start Parking ",{state.upTime+state.msUpTime/1000-var.timeC},"secs"
        if global.startParkXY < var.timeC
           echo {state.thisInput},"too late by ",{state.upTime+state.msUpTime/1000-global.startParkXY},"secs"
           echo >>>"delays.g" ",",var.startHeat-var.startWait,",-",{state.upTime+state.msUpTime/1000-global.startParkXY}
           set global.delayAdjust = state.upTime+state.msUpTime/1000-global.startParkXY
        else
            echo >>>"delays.g" ",",var.startHeat-var.startWait,",",{state.upTime+state.msUpTime/1000-var.timeC}
            set global.delayAdjust = 0
        set var.timeC = state.upTime+state.msUpTime/1000
        if global.startParkXY+0.1 > var.timeC
            G4 P{floor((global.startParkXY+0.1 - var.timeC)*1000)}
            echo "waited further",floor((global.startParkXY+0.1 - var.timeC)*1000),"ms"

        set global.uvParked = false
        set global.startParkUV = -1


    M800 T2 H1
    M203 W{global.xyMaxFeed} V{global.xyMaxFeed}
    G1 F12000
    G1 W310 F20000
    M203
    M201
    echo {state.thisInput},"finished changeFilament"

With the M801 having the following Gcodes for the priming - which always seem to work

        var speed = 1500

        G1 D{global.dPrimeOffset} F300
        G1 F{var.speed}
        G1 U{param.U} V{param.V} F{var.speed}
        ;M800 T{param.T} H0  ; ZHop down
        G1 U{param.U} V{param.V+param.S} E{var.E} F{var.speed}
        G1 U{param.U+var.S2} V{param.V+param.S}  E{var.E*2} F{var.speed}
        G1 U{param.U+var.S2} V{param.V}  E{var.E*2} F{var.speed}
        G1 U{param.U} V{param.V}   E{var.E} F{var.speed}
        G1 U{param.U-2} V{param.V+param.S/2} F{var.speed}
        G1 U48 V295 F2000
        
        
        G1 D{global.dOffset} F300
        M400
        echo {state.thisInput},"prime time T1",{state.upTime+state.msUpTime/1000 - var.primeT},"s"

I added in the M203's due to the speed issue - will try removing them to see if that makes a difference.
Update - it's not the M203s or M201s - removed them all and still get the same issue.

Also just went back to 3.5.4 - it didn't brick this time, and have run the exact same config and print and it is again as expected working fine on 3.5.4 (not withstanding the speed issue).

[DIY-O-Sphere]

@dwuk3d said in UVW movement issues with [3.6.0]:

From your config.g:

M84 S30 ; set motor current idle timeout

I don't know if it has anything to do with the problem, but M84 is deprecated in RRF3.6.

[dwuk3d]

@DIY-O-Sphere thanks for the suggestion.

I tried commenting out the M84 and M906 in caee it was some sort of timeout issue - but it didn't remove the issue.

; Motor Idle Current Reduction
M906 I30 ; set motor current idle factor
M84 S30 ; set motor current idle timeout

The only other things I can think of to try are:
A. Reinstating the redirects in the tools definitions - and then seeing whether using X&Y instead of the real axis makes any difference
B. Removing the U&V axis adjusting motion from the V axis kinematics - and instead doing the adjustment in the actual G1.
C. Changing my driver wiring around to put XYUVW all on the master 6HC board - as I suspect its probably 3.6.0's changes to handling of toolboards that is the issue,

Think I will investigate sourcing/making up some 6HC<>mini5+stepper driver cable adaptors before doing this - to make swapping steppers around between boards less hassle.

Thinking about it I guess sourcing in line male 6HC and Mini5+ stepper connectors is going to be hard - maybe it would be easier if I just put inline 2.54mm plugs and sockets into the stepper wires I need to swap around.

Or even easier just make up some extension cables at the nema17 end of the cables so that I can swap the other ends of the stepper cables around instead.

[droftarts]

@dwuk3d is it the motors connected to the Mini 5+, which is a mainboard-as-expansion, that are misbehaving? There are other reports of mainboard-as-expansion problems, may be related. If so, one for @dc42 to look at.

Ian

[dwuk3d]

@droftarts yes UV&W are all connected to a connected Mini5+, will try swapping them with 3 of my Z axis motors to see if that makes a difference.

[dwuk3d]

@dwuk3d Tried a simple test - just swapping around the cables and driver allocations for U<>X and W<>Y.

So now XY and are on the Mini5+ board
UW are on he 6HC board, and V is on the Mini5+ board

On 3.5.4 homing worked fine - but printing on XY was a bit odd - it seem to pause and not finish its object - and go slow when the 2nd motion system started

Then when the 2nd motion system started to try and print things went a bit haywire - with heads moving W direction when they shouldn't.

So my conclusion from this test is as per documentation - you can't mix motion systems and driver boards.

Therefore I don't think swapping over my XY,UVW onto the 6HC board is going to be feasible - because their Z hopper/mesh adjustment axis AB&D will all be on a separate board within the same motion system - so will likely cause the same issue.

I could swap over XYB onto the Mini5+. and UVWAD to be on the 6HC to confirm that the Mini5+ has issues on 3.6.0 with the XY axis instead of UVW - however that is going to involve rewiring 12 stepper cables (due to plug size differences) - so not that keen to do it.

PS/. I have had Z split across the 2 boards for months - and that hasn't caused any issues - including when it was Z Hopping one motion system while the other one was priming - although - thinking about it - I wonder if that split might be the cause of my 'layer shift' issue - so maybe I should move Z completely off to its own separate Mini5+ board if the layer shift issue comes back again.

[dc42]

@dwuk3d said in UVW movement issues with [3.6.0]:

So my conclusion from this test is as per documentation - you can't mix motion systems and driver boards.

That's correct. Each motion system needs a separate movement pipeline. Expansion boards, including main board used as expansion boards, have only one pipeline.

[dwuk3d]

@dc42 Thanks - but confirming this unfortunately that does not resolve my issue.

My setup is currently

Motion System 1
XYB on Master 6HC board - works ok.

Motion System 0
UVWAD - on Slave Mini5+ board

Motion system 1 works fine on both 3.5.4 and 3.6.0

Motion System 0 works fine (apart from excess speed and layer shift issues - which I will report on separate threads) on 3.5.4

But on 3.6.0 Motion System 0 hardly works at all - with U & W motors seeming to stop working early in the print - The 'switch off' sometimes persists across emergency stops - but If I do G1 H2 U or W they seem to start working again.

[dc42]

@dwuk3d please try setting idle current percent to 100 (i.e. M906 I100) in the expansion Mini5+ config.g file, in case the expansion Mini5+ is incorrectly implementing its own idle detection.

[dwuk3d]

@dc42 OK
Config file now

M906 I100
M954 A01

Retested on 3.5.4 - Still works ok
Upgraded and Retested on 3.6.0 - Same issue - with UV axis not working on Mini5+ board

Doing multi motion system - Printed XY square on Motion System 1 - worked.
Printing same Square on UV Axis - just got a diagonal line - from right to left, back to front.

After Emergency restart while still doing UV print - U Motor seemed to work ok, but interestingly W not working (not U) after emergency start - with normal Duet Web move. G1 H2 W-1 F1000 started W moving again.

[dc42]

@dwuk3d ok. After UV stops moving, please run both M122 and M122 B# where # is the CAN address of the expansion Mini5+, and post the responses here.

[dwuk3d]

@dc42 OK

After. a few of the UV G1's I inserted the following into the job

G1 F1500.0 U141.87 V188.859 E.09818
G1 F1500.0 U141.87 V189.515 E.02477
G1 F1500.0 U139.377 V187.021 E.1332
G1 F1500.0 U138.721 V187.021 E.02477
G1 F1500.0 U141.87 V190.17 E.16823
M122
M122 B1
abort

PS/ Abort and cancel only abort one of the motion systems which does cause me a few issues - so if you have any ideas on that it would be good - I usually have to emergency stop to stop the other one from looping.

At the time of aborting (before the emergency stop I can confirm that U wouldn't move from the dashboard - but W was still moving ok.

M122 for 6HC board

09/06/2025, 15:21:22	=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0 (2025-05-25 08:05:42) running on Duet 3 MB6HC v1.02 or 1.02a (standalone mode)
Board ID: 0JD4M-958L1-M2NS0-7JTDG-3SN6K-91FKZ
Used output buffers: 1 of 40 (27 max)
=== RTOS ===
Static ram: 137420
Dynamic ram: 136640 of which 0 recycled
Never used RAM 68476, free system stack 134 words
Tasks: NETWORK(1,ready,33.9%,180) ETHERNET(5,nWait 7,0.3%,316) HEAT(3,nWait 6,0.0%,331) Move(4,nWait 6,0.0%,209) TMC(4,nWait 6,3.4%,343) CanReceiv(6,nWait 1,0.1%,784) CanSender(5,nWait 7,0.0%,329) CanClock(7,delaying,0.0%,350) MAIN(1,running,62.2%,103) IDLE(0,ready,0.0%,29) USBD(3,blocked,0.0%,144), total 100.0%
Owned mutexes: File(MAIN)
=== Platform ===
Last reset 00:03:52 ago, cause: power up
Last software reset at 2025-06-09 15:16, reason: User, Gcodes spinning, available RAM 72684, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 44.5, current 45.7, max 45.9
Supply voltage: min 24.0, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.2, max 12.4, under voltage events: 0
Heap OK, handles allocated/used 198/82, heap memory allocated/used/recyclable 2048/1624/424, gc cycles 12
Events: 0 queued, 0 completed
Date/time: 2025-06-09 15:21:20
Slowest loop: 79.51ms; fastest: 0.05ms
=== Storage ===
Free file entries: 16
SD card 0 detected, requested/actual speed: 25.0/25.0MBytes/sec
SD card longest read time 2.5ms, write time 3.1ms, max retries 0
=== Move ===
Segments created 30, maxWait 191105ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 3200.00/3200/-0.00 0.00/0/-0.00 108.00/107/0.00 27440.00/27440/-0.00 16461.00/14898/-0.50 8347.00/9902/0.50 9830.00/9829/0.11 7860.00/7860/0.00 6732.00/6732/-0.62
Next step interrupt due in 132 ticks, disabled
Driver 0: standstill, SG min 0, mspos 88, reads 44695, writes 0 timeouts 0
Driver 1: standstill, SG min 0, mspos 776, reads 44695, writes 0 timeouts 0
Driver 2: standstill, SG min 0, mspos 8, reads 44695, writes 0 timeouts 0
Driver 3: standstill, SG min 0, mspos 136, reads 44695, writes 0 timeouts 0
Driver 4: standstill, SG min 0, mspos 776, reads 44695, writes 0 timeouts 0
Driver 5: standstill, SG min 0, mspos 424, reads 44696, writes 0 timeouts 0
Phase step loop runtime (us): min=0, max=90, frequency (Hz): min=1138, max=8720
=== DDARing 0 ===
Scheduled moves 177, completed 162, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x20000178, drives owned 0x20000170
Code queue is empty
=== DDARing 1 ===
Scheduled moves 131, completed 131, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x80000003, drives owned 0x80000003
Code queue is empty
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1 -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.4
Heater 1 is on, I-accum = 0.0
Heater 3 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is ready with "M122" in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is doing "G4 P91" in state(s) 0 0, running macro
Queue2 is idle in state(s) 0
=== CAN ===
Messages queued 1965, received 10741, lost 0, ignored 0, errs 0, boc 0
Longest wait 2ms for reply type 6013, peak Tx sync delay 277, free buffers 50 (min 48), ts 727/727/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 11.50ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0
= Ethernet =
Interface state: active
Error counts: 0 0 0 0 0 0
Socket states: 2 2 2 2 2 2 0 0 0
=== WiFi ===
Interface state: disabled
Module is disabled
Failed messages: pending 0, notrdy 0, noresp 0
Socket states: 0 0 0 0 0 0 0 0

M122 B1. For mini 5 board.

Diagnostics for board 1:
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.6.0 (2025-05-25 08:05:07) running on Duet 3 Mini5plus Ethernet (expansion mode)
Board ID: ADDM5-SU8LU-F65J0-409NA-JR03Z-RNLV2
Used output buffers: 0 of 40 (1 max)
=== RTOS ===
Static ram: 94764
Dynamic ram: 107880 of which 0 recycled
Never used RAM 41196, free system stack 142 words
Tasks: NETWORK(1,ready,9.6%,547) HEAT(3,nWait 6,0.0%,341) Move(4,nWait 6,0.0%,349) TMC(4,nWait 6,1.5%,65) CanReceiv(6,running,0.0%,588) CanSender(5,nWait 7,0.0%,336) MAIN(1,ready,88.0%,929) IDLE(0,ready,0.1%,29) USBD(3,blocked,0.0%,147) AIN(4,ready,0.8%,261), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:03:52 ago, cause: power up
Last software reset at 2025-06-09 15:16, reason: User, numModules spinning, available RAM 41968, slot 0
Software reset code 0x0013 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 34.7, current 40.0, max 40.2
Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 3 queued, 3 completed
Date/time: 2025-06-09 15:21:20
Slowest loop: 5.53ms; fastest: 0.16ms
=== Storage ===
Free file entries: 20
SD card 0 detected, requested/actual speed: 25.0/24.0MBytes/sec
SD card longest read time 3.1ms, write time 0.0ms, max retries 0
=== Move ===
Segments created 20, maxWait 0ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 10989.00/10990/-0.32 8106.00/9628/0.11 -2267.00/-2267/-0.25 -40037.00/-40037/-0.14 304.00/303/0.78 1697.00/167/0.02 1697.00/167/0.02
Sync err accum 48, peak jitter -5/4, peak Rx delay 192, resyncs 0/0, 
Next step interrupt due in 170 ticks, enabled
Driver 0: standstill, SG min 0, r/w errs 0/0, ifcnt 17, reads/writes 21089/17, timeouts 0, DMA errs 0, CC errs 0
Driver 1: ok, SG min 0, r/w errs 0/0, ifcnt 15, reads/writes 21091/15, timeouts 0, DMA errs 0, CC errs 0
Driver 2: standstill, SG min 0, r/w errs 0/0, ifcnt 15, reads/writes 21090/15, timeouts 0, DMA errs 0, CC errs 0
Driver 3: standstill, SG min 0, r/w errs 0/0, ifcnt 15, reads/writes 21090/15, timeouts 0, DMA errs 0, CC errs 0
Driver 4: standstill, SG min 0, r/w errs 0/0, ifcnt 15, reads/writes 21091/15, timeouts 0, DMA errs 0, CC errs 0
Driver 5: ok, SG min 0, r/w errs 0/0, ifcnt 15, reads/writes 21091/15, timeouts 0, DMA errs 0, CC errs 0
Driver 6: ok, SG min 0, r/w errs 0/0, ifcnt 15, reads/writes 21091/15, timeouts 0, DMA errs 0, CC errs 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x00000000, drives owned 0x00000000
Code queue is empty
=== DDARing 1 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x00000000, drives owned 0x00000000
Code queue is empty
=== Heat ===
Bed heaters -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== CAN ===
Messages queued 1990, received 5245, lost 0, ignored 0, errs 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 3, free buffers 26 (min 26), ts 2/1/0
Tx timeouts 0,0,0,0,0,0
Motion dup 0, oos 0/0/0/0
Cancelled printing file 0:/gcodes/Box3.gcode, print time was 0h 1m
'abort' command executed

[dwuk3d]

@dc42

M122's supplied in previous response.

Not sure if this is any value - but when I had issues with slow movement on the slave mini 5 board in an earlier version of 3.6.0 I tried keeping that board at 3.5.4 - with master board and tool boards at 3.6.0 as a workaround.

Just tried that same setup - incase downgrading just the Mini5 board to 3.5.4 was a workaround again - but this time it didn't work - I am getting the same issues with the main 6HC board at 3.6.0 and the slave board at 3.5.4.