Drive 3 is slower as drive 2 at homing in Z [Solved]

[thwe]

Hello,

Unfortunately I have to open again a thread with a problem and ask for help:

After correcting the M574 command in the config.g (see thread) I have a puzzling behavior of the U axis (Drive 3) when homing Z -> Drive 3 runs slower than Drive 2 but only at homing in Z

Here is a video that illustrates the behavior: video on youtube

and here my config.g
0_1542559236968_config.g

and the homez.g
0_1542559266412_homez.g

as well as the macro, which produces the movements in the film
0_1542559353801_X-TEST.g

Why runs drive 3 slower than drive 2 during z-homing?

[dc42]

The only thing I have spotted that isn't right is that you are not setting the U axis limits in your M208 commands.

If it's still a problem after you have corrected that, please send the following commands without parameters, and check that the values are as expected, i.e. the same value for both U and Z. If necessary, send M584 P4 first.

M92
M906
M913
M350
M208
M574
M201
M203
M566

[samlogan87]

Forgive me if I am wrong as I am still a bit new around here @dc42 do you need to in the z axis part of each of the parameters also have a semicolon for the other axis that are being tied to it? He has done it for the driver assignment, but no other one.

ie:

M203 X12000 Y12000 Z4500:4500 U4500 E1200 ; Set maximum speeds (mm/min)

Instead of:

M203 X12000 Y12000 Z4500 U4500 E1200 ; Set maximum speeds (mm/min)

Kindly Regards
Sam

[dc42]

No, you don't need to provide multiple Z values in any of the usual M commands when you have multiple Z motors, only in the M584 command to tell the firmware which drivers you are using.

[samlogan87]

Thanks for that @dc42 that is good to know

[thwe]

@dc42
new M208 in config.g

M208 X-2.50 Y-26.75 Z0.00 U0.00 S1 ; Set axis S1 = minimum
M208 X302.50 Y326.75 Z290.00 U290.00 S0 ; Set axis S0 = maximum

After newstart or reboot the first Z homing is OK -> both drivers run evenly, but all other z-homing calls produce the error again.

For all sent M commands as stated above, there was an exact match of the values of Z + U
I put on my extra good glasses - there was no difference

[Veti]

remove the u move from the homing script

since you told the duet that you have 2 z axis you do not need to specify a separate move for the second axis.

[thwe]

@veti
That can not be the solution. After a reboot or a restart (for example after an emergency stop) the homing works correctly - but only once!

In addition, each axis moves individually after the "M584 Z2 U3 P4", so it must also be moved per G1 command per axis - in my opinion.

[thwe]

It raises the question of the meaning of why I want to do the homing again.

Certainly it is normally not necessary, but it is strange, right?

[deckingman]

@thwe Strange indeed. It seems like one of the Z motors isn't retaining it's mapping after the first homing. A couple of suggestions to try.

1. At the start and end of your home Z file, explicitly assign all axes to the configuration you have in config.g. So at the start of homeZ, put M584 X0 Y1 Z2:3 U3 E4 P3. Then remap the drives by using M584 X0 Y1 Z2 U3 E4 P4. Carry out the rest of the homing, then at the end of home Z, re-enter the original drive mapping in full - i.e. M584 X0 Y1 Z2:3 U3 E4 P3.

2. Try initially assigning U to a different but unused axis like say 5. So in config.g use M584 X0 Y1 Z2:3 U5 E4 P3. Then in homez do M585 Z2 U3 before homing Z and U, then put the mapping back to Z2:3 U5.

I've no real idea if either of these will fix the issue but worth a try?

[Veti]

for my dual z mapping i have not mapped u at all i just have the two entries for Z

[deckingman]

@veti said in Drive 3 is slower as drive 2 at homing in Z:

for my dual z mapping i have not mapped u at all i just have the two entries for Z

I think what the OP wants to do is home each screw independently for some sort of bed levelling. He has two end stops on Z. So to do that, you have to create another axis - U in this case. So for "normal" printing, both drives work together in sync so they are both mapped to Z. But to home each one independently, the drives have to be temporarily mapped, one to Z and the other to U. It's similar to what I do on my CoreXYUV.

[thwe]

@deckingman said in [Drive 3 is slower as drive 2 at homing in Z]:

I think what the OP wants to do is home each screw independently for some sort of bed levelling…

That's exactly what I want

Thanks for your suggestions - i will test it later

[Veti]

@deckingman

The individual Bed leveling with multiple Z motors does not require a U axis either
see
https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors

i have it set up for 2 motors and it does not require a U axis

[deckingman]

@veti Yes I know one can use M671 to do bed levelling, but that's not what the OP is doing. I'm trying to help him with his specific problem.

Edit AFAIK, the OP isn't using a bed probe and G32 - just two separate end stop switches. At least, that's how his homez seems to be configured.

[Veti]

@deckingman

he has got a z probe configured.
But why would you level the bed against two endstops at their max rather than the z probe?

[deckingman]

@veti said in Drive 3 is slower as drive 2 at homing in Z:
@deckingman

................. But why would you level the bed against two endstops at their max rather than the z probe?

Dunno. I'm not the OP.

Personally, I don't you use any form of bed levelling or flatness compensation - I built a bed that's flat, level and stays that way. So in this thread I could be saying that the OP should do that too, rather than rely on software/firmware compensation. But that's not what the OP wants to hear. Everyone has their own preferred way of doing things. So rather than say "don't do it that way, do it this way (like I do)", I think it's more helpful to try and assist the OP with his particular choice.

And just because the OP happens to have a Z probe too, someone else who doesn't have a Z probe might stumble upon this thread at some time in the future. So if we can fix this issue, it will be helpful to others too.

[thwe]

@veti : thanks for the interesting link, I'll take a closer look.

I wanted to do the same (or at least similar) with the two limit switches for Z + U, the "bed leveling using multiple independent motors with" M671 is very interesting!

[thwe]

@deckingman : Thank you for the open and respectful view!

My idea comes from mechanical engineering, where usually no direct motor driven axis (not room axis) are operating without limit switch.

That this is not absolutely necessary, I realize - but, is our hobby absolutely necessary

[deckingman]

@thwe I had assumed that the reason you wanted to home to Z max, was that you have a CoreXY and also wanted to be able to resume after power failure. For this, the axes have to be re-homed and as there is a print already on the bed, one can't home to Z min.

So there are reasons why you or someone else might might want to home to Z max using multiple switches. That's why I thought it important to try and resolve your issue rather than simply suggest alternative ways of homing which involve homing to Z min with a probe.

Speaking as a mechanical engineer myself, I prefer to use mechanical solutions that don't rely on electronics to compensate for what are essentially fundamental mechanical problems. But I appreciate that others may not have the resources, time, or skills needed to do that.