@jay_s_uk I have no idea what the old firmware was. I've upgraded some months ago, but only sporadically use the UVW controls. As far as I can tell I've made no changes to the config file myself, but it's very well possible some trial and error was involved after the upgrade that I can't recall. Homing/leveling the bed is done via G32, but if the bed is tilted too much it will crash with the print head. I'm disabling the axis limits to move the UVW axis independantly, but only when needed (I had 1 stepper loose connection to the B-coil during a print last night which resulted in a prety catastrophic failure).

I've added the UVW assignments back in the M584 comand, but missed that I need to configure all the other parameters (motor current, accell, steps/mm, ...) for the UVW axis as well. This also explains the weird behavior that I saw. This is now corrected and working again!

I was thinking that setting these parameters once per physical drive would be sufficient, but I've proven myself wrong

I know this is an old topic, but I'm running into exactly the same issue. Did you find a solution to this??

My bad, it turns out my coordinates for the leadscrews were way off, I honestly don't even know what I was doing!

@jay_s_uk it's when babystepping in -Z. I've updated to 3.6.0 rc2 and the issue persists. I believe it has something to do with the bed mesh compensation thinking the machine is going outside its limits. Also, when restarting a new print, the babystepping value has to be increased with the previous value to get to nozzle at the correct height, and the reported z axis position will start to drift every time this is repeated (I'd expect this to get reset).

Anyhow, I've now run a first level calibration print and set the probe offset accordingly (g31 in the config) so I don't need to use babystepping for now. I'm also not entirely sure if this is an isolated 3.6.0 issue since I've only had to start messing with the babystepping after I've had a crash with disabled axis limits

Changing babystepping while printing causes erratic stepper movement on 3.6.0 RC1 and fills log with repeating g0 g1 position outside machine limit errors. Can anyone else confirm/replicate?

@jay_s_uk I have no idea what the old firmware was. I've upgraded some months ago, but only sporadically use the UVW controls. As far as I can tell I've made no changes to the config file myself, but it's very well possible some trial and error was involved after the upgrade that I can't recall. Homing/leveling the bed is done via G32, but if the bed is tilted too much it will crash with the print head. I'm disabling the axis limits to move the UVW axis independantly, but only when needed (I had 1 stepper loose connection to the B-coil during a print last night which resulted in a prety catastrophic failure).

I've added the UVW assignments back in the M584 comand, but missed that I need to configure all the other parameters (motor current, accell, steps/mm, ...) for the UVW axis as well. This also explains the weird behavior that I saw. This is now corrected and working again!

I was thinking that setting these parameters once per physical drive would be sufficient, but I've proven myself wrong

I'm running a core XY machine with 3 individually driven Z-axis. Sometimes I wish to take manual control over each individual Z-drive, for example when the bed becomes so tilted that autoleveling would result in a crash. I was using a macro to switch between showing the combined Z-azis and individual (UVW) axis control. However, since upgrading the firmware (now running 3.5.4) this macro is giving an error:

Error: M584: Invalid number of visible axes

This is my drive mapping:

; Drives
M569 P0.0 S1							; physical drive 0.0 Z1 goes forwards
M569 P0.1 S1							; physical drive 0.1 Z2 goes forwards
M569 P0.2 S1							; physical drive 0.2 Z3 goes forwards
M569 P0.3 S1							; physical drive 0.3 X goes forwards
M569 P0.4 S1							; physical drive 0.4 Y goes forwards
M569 P121.0 S0							; drive 121.0 goes backwards
M584 X0.3 Y0.4 Z0.0:0.1:0.2 E121.0				; set drive mapping
M671 X24:333:178.5 Y-33.5:-33.5:275.5 S50		        ; set lead screw position for auto bed leveling

The macros for switching between showing/hiding the UWV axis is a simple:
Hide UVW:
M584 P3 ; Show only first 3 assigned axis

Show UVW:
M584 P6 ; Show all 6 assigned axis

I've tried changing M584 X0.3 Y0.4 Z0.0:0.1:0.2 E121.0 to M584 X0.3 Y0.4 Z0.0:0.1:0.2 U0.0 V0.1 W0.2 E121.0 P3

This causes some very weird behaviour. Moving the Z-axis works as expected, but moving the individual U V W axis results in a small amount of movement, and the drive is turned off after a couple of seconds.

Does anyone have any clue how to get this to work again / what changed in the firmware?

@deckingman Nope, but after some more searching I've found my anwer in an older post: https://forum.duet3d.com/topic/15761/duet-web-control-2-1-1-showing-wrong-job-height/5

My gcode also has a command to lower the bed (100mm) after the print is finished.

@jens55 nope, fixed 0.3mm layer height. Even previous models would also be reported as 100mm (/333layers), even when they're smaller.

Where does the duet web control read the job information from? The print height reported there is incorrect, and I'm trying to narrow down if it a duet or cura issue. Also in the progress window its reporting the incorrect total number of layers

@SignPostMan a plane is defined by 3 points. 4 points make it overconstrained. Bed leveling will try to even out any deviations, but that simply isn't possible when the interfaces aren't mounted to the z axis. The only thing I can imagine is that you'd have the leveling algorithm only take 3 points into account, and then calculate where to move the 4th axis, just for additional support. I don't think the firmware is currently capable of doing that.

What is your purpose for the 4th axis? Why not follow the ratrig/hevort triple z setup?

Small side note; you have to make sure the 'leadscrew coordinates' are actually the coordinates of the center of the balls that support the bed, otherwise the calculation will be off even more.

I know this is an old topic, but I'm running into exactly the same issue. Did you find a solution to this??

My bad, it turns out my coordinates for the leadscrews were way off, I honestly don't even know what I was doing!