Problem with 3 Independent Z-axis motors and Endstops

Phaedrux

Just on a lark, try commenting out your M117 message commands.

Phaedrux

Also, what firmware version?

B3D

No change with commenting out M117 messages.
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet WiFi 1.02 or later + DueX5

Phaedrux

One last ditch try, upgrade to 2.01 full release, and if that doesn't work, 2.02 RC2.

Phaedrux

Also, have you tried sending each command from the macro individually through the console? Does the recombine axis command work then?

B3D

@phaedrux Thanks for your suggestions. I commented out the last M584 in homez.g and sent the following commands from the console:
M584 Z2:3:4 P3
G91
G1 Z-5 F200
Same thing. Drive 2 (Z) rotates in the correct direction, while drive 3 (U) and drive 4 (V) axes rotate the wrong way.

JoergS5

@b3d I would try to remove the separated movement commands and check whether the combined movement works as intended. Or whether the wrong movements remain.

This is to isolate the problem (reason a) something wrong with changing from separate to combined b) backwards rotation handled differently for Z and U/V).

B3D

Its starting to look like a firmware bug. Upgraded to Firmware Version 2.01(RTOS) (2018-07-26b2). Now the 3 z-axis rotate in the correct direction after recombining Z, U and V. However, this only works the first time after firmware reset. If Home Z is run a second time, at the first G1 command, only the Z axis moves (U and V do not move).

homez.g
; Home 3 Independent Z-Axis Drives

M117 Homing Z axis...

M400 ; Wait for movement to stop
G91 ; relative positioning

M584 Z2 U3 V4 P5 ; separate Z axis motors. P5 to display/drive 5 axis.

; This only works the fist time after firmware reset.
; The second time Homez is run, only the Z axis moves (U and V do not move).
G1 Z400 U400 V400 F500 S1 ; lower all z motors until each corresponding z-stop reached
M400 ; Wait for movement to stop

G1 V-3 F200 S2 ; raise Z3 axis slowly (S2 Ignore endstops and ignore axis not homed)
G1 V10 F200 S1 ; lower Z3 motor slowly until its endstop reached
G1 V-3 F200 S2 ; raise Z3 axis slowly (S2 Ignore endstops and ignore axis not homed)
M400 ; Wait for movement to stop

G1 U-3 F200 S2 ; raise Z2 axis slowly (S2 Ignore endstops and ignore axis not homed)
G1 U10 F200 S1 ; lower Z2 motor slowly until its endstop reached
G1 U-3 F200 S2 ; raise Z2 axis slowly (S2 Ignore endstops and ignore axis not homed)
M400 ; Wait for movement to stop

G1 Z-3 F200 S2 ; raise Z1 axis slowly (S2 Ignore endstops and ignore axis not homed)
G1 Z10 F200 S1 ; lower Z1 motor slowly until its endstop reached
G1 Z-3 F200 S2 ; raise Z1 axis slowly (S2 Ignore endstops and ignore axis not homed)
M400 ; Wait for movement to stop

; This test move before combining axis works
G1 Z-5 U-5 V-5 F200 S2 ; raise Z1 axis slowly (S2 Ignore endstops and ignore axis not homed)

M584 Z2:3:4 P3 ; Combine Z, U and V. P3 to display/drive 3 axis.

; This test move after combining axis also works now
G1 Z-5 F200 ; test raise all axis slowly

G90 ; absolute positioning

M117 Homing Z axis done

deckingman

@b3d Well it sounds like some sort of progress. Now that you have upgraded the firmware, can you try assigning all drives in each M584 command as detailed in my earlier post. So always assigne X,Y and E as well as Z (and U and V). If you take a look at this https://duet3d.dozuki.com/Wiki/GCode#Section_M584_Set_drive_mapping and especially the warning paragraph underneath the example which states:

Quote...........
"Assigning a drive using M584 does not remove its old assignment. Therefore, if you assign a drive that defaults to being an extruder drive, you should also assign the extruder drives explicitly as in the above example. Failure to do so may result in unexpected behaviour."
..end of quote.

So I'm just wondering if it's something along those lines that is screwing things up and drives 3 and 4 are resorting to being extruders.

It is possible that you have unearthed a hitherto unknown bug in the firmware but what makes me doubt that is that there are other users who do what you are trying to do and AFAIK, yours is the only case where it isn't working. On the other hand, maybe everyone else with 3 independent screws home to Z min so you might be the only user using 3 independent screws homing to Z max.

Hopefully now that the TCT show is over, David (DC42) might find time to take a look at this thread.

Edit. One other thing. If you send M584 with no parameters through the gcode console, it will report the current state of the drive mapping. So if you entered each command in your homeZ file one at a time, then entered M584 after each command, it might show at what point things get screwed up.

B3D

Thanks @deckingman, appreciate your help and gave your suggestions a try this morning. Good to know that M584 returns the drive mapping. I changed the M584 to define all drives every time in config.g and homez.g.
After config.g M584 -> Driver assignments: X0 Y1 Z2:3:4 U3 V4 E5, 3 axes visible
After homez.g M584 -> Driver assignments: X0 Y1 Z2:3:4 U3 V4 E5, 3 axes visible

Behavior is still the same. Running Homez.g the first time after firmware reset and everything works as expected, with the Z, U and V axes rotating the same direction. But when Homez is run a second time, the first G1 Z400 U400 V400 F500 S1 command causes the Z axis to rotate in different direction from U and V. Homez then hangs for a couple of minutes before continuing on with the G1 V-3 F200 S2, and subsequent commands.

Also tried @phaedrux suggestion to enter commands individually from console. Did this after running homez once after reset. Same behavior. Checked drive mapping after the G1 Z400 U400 V400 F500 S1 and it returned Driver assignments: X0 Y1 Z2 U3 V4 E5, 5 axes visible

dc42

Make sure that in your homez.g sequence, you switch into relative movement mode using G91 before you make the G1 S1 ZUV move.

B3D

Thanks for the suggestion @dc42, G91 is already there before the first M584 splitting the drives and before the G1 ZUV move in Homez.g, and the G90 is at the end.

dc42

Try adding M400 after the M584 command, before the G1 S1 command.

B3D

@dc42 Adding M400 after M584 did not resolve the issue. In fact, adding M400 after the second M584 caused homez.g to hang.

homez.g
; Home 3 Independent Z-Axis Drives

M117 Homing Z axis...
M400 ; Wait for movement to stop

G91 ; relative positioning

M584 X0 Y1 Z2 U3 V4 E5 P5 ; separate Z axis motors. P5 to display/drive 5 axis.
M400 ; Wait for movement to stop

; The second time Homez is run, only the Z axis moves with this command (U and V do not move).
; Homez then hangs here for a couple of minutes, before continuing ...
G1 Z400 U400 V400 F500 S1 ; lower all z motors until each corresponding z-stop reached

G1 V-3 F200 S2 ; raise Z3 axis slowly (S2 Ignore endstops and ignore axis not homed)
G1 V10 F200 S1 ; lower Z3 motor slowly until its endstop reached
G1 V-3 F200 S2 ; raise Z3 axis slowly (S2 Ignore endstops and ignore axis not homed)
M400 ; Wait for movement to stop

G1 U-3 F200 S2 ; raise Z2 axis slowly (S2 Ignore endstops and ignore axis not homed)
G1 U10 F200 S1 ; lower Z2 motor slowly until its endstop reached
G1 U-3 F200 S2 ; raise Z2 axis slowly (S2 Ignore endstops and ignore axis not homed)
M400 ; Wait for movement to stop

G1 Z-3 F200 S2 ; raise Z1 axis slowly (S2 Ignore endstops and ignore axis not homed)
G1 Z10 F200 S1 ; lower Z1 motor slowly until its endstop reached
G1 Z-3 F200 S2 ; raise Z1 axis slowly (S2 Ignore endstops and ignore axis not homed)
M400 ; Wait for movement to stop

; This test move before combining axis works
G1 Z-5 U-5 V-5 F200 S2 ; raise Z1 axis slowly (S2 Ignore endstops and ignore axis not homed)
M400 ; Wait for movement to stop

M584 X0 Y1 Z2:3:4 E5 P3 ; Combine Z, U and V. P3 to display/drive 3 axis.

; Adding M400 here caused the homez.g to hang
;M400 ; Wait for movement to stop

; This test move after combining axis also works now
G1 Z-5 F200 ; test raise all axis slowly
M400 ; Wait for movement to stop

G90 ; absolute positioning
M400 ; Wait for movement to stop

M117 Homing Z axis done

B3D

HI @dc42. Wondering if you had any further insight into this issue. Is it a firmware bug, or something with the configurations/gcode? Thanks.

dc42

I'll need to replicate your configuration and test it - that's on my list to do.

dc42

I've finally got round to testing this. There is certainly something odd going on. More later.

dc42

The strange behaviour I observed was because my config.g file already created an A axis before I added your bits. I fixed that, and now the Z homing of the 3 motors independently is working correctly. Both the original Z homing file in your original post and the most recent one that you posted work.

The only changes I made to your files were to change the M574 command to use NC switches, which is what my test rig has. The firmware I am using is slightly later than 2.02RC2.

I did find that adding the extra M400 command in homez.g caused the movement system to lock up, as you reported. I will fix this before I release 2.02RC4.

The config I am using is for a Cartesian printer. Is that what you are using, or is your printer a CoreXY? It may help if you post your complete config.g file.

dc42

PS:

On machines with heavy beds and high Z steps/mm, one possible cause of a Z motor sometimes moving the bed down when it should move up is that you are using too high a Z speed, acceleration or jerk; or just too low a current for the motors you are using.
If the Z motors that correspond to U or V move the wrong way after they are recombined, that can because by the U and V axes still being visible. You can run M584 without parameters to check the axis mapping and visibility.

dc42

It turned out that the "hang" when the extra M400 was added wasn't really a firmware hang, it was that the next move was being carried out so slowly that it was hard to see the motors move. I've fixed it in my latest firmware build. The same bug might have been responsible for other strange behaviour when axes are changed from visible to hidden and vice versa; so please try firmware 2.02RC4 on your machine when I release it - later today I hope.