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

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.

thwe

@deckingman : My first priority is definitely a perfect backbone of the mechanics.

My guides (mgn12) and ballscrews are aligned with dial gauge (parallelism and flatness) and it is paid attention to a clean and easy running.
The print bed (alu fine milled 300 x 300 x 8mm) will be resurfaced on a flat grinding machine before installation , etc.

All measures usually do not require a software correction. However, I would like to apply the procedure, which also is used in tool setting measuring machines.

Why? just to learn for me.

Of course, my baby is supposed to print someday, my granddaughter is already waiting for the first figures and a personal name tag for her schoolbag. But the current stage is used to craft, build, rebuild, annoy if something does not work and look happy when it works - and learn.

The aim is to create a mechanical system to look behind the scenes, the machines I've just used. These are the last 25 years of application development on injection molding machines, from whose evolution in the direction of electric drives my curiosity comes.

Conclusion: I do not always and absolutely necessary have to use it, but I can do it (such as your "Dynamic Force Canceling" which is very interesting and implemented great)

PS: Sorry for any grammatical mistakes and wrong expressions - my english is only as well as google translators allowed

thwe

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

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

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.

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?

So I tested all your suggestions - unfortunately without success.
the first call works well, all others as usual: U runs slower

deckingman

@thwe Hmmmmm - very odd.

Try running the list of commands that David (DC42) suggested in his post dated and timed 18 Nov 2108, 17:01, starting with M584 P4 then M92 etc. Make a note of all the values. Then home Z and run those commands again and note the values. Then home Z a second time and run those commands for the third time. See if there is any change in the values reported for Z and U.

thwe

When testing the above suggestion, I accidentally noticed that when homing again suddenly everything is running properly, but what was different?

Well, the command M584 P4 before any other G commands has allowed both engines to run properly.

Now I have only as a first command in my homez.g "M584 P4" and now everything runs as it should.

dc42

I'm glad you solved it.

The homez.g file you posted earlier starts like this:

; homez.g
; called to home the Z axis
;
; Drive 0 as X
; Drive 1 as Y
; Drive 2 as Z -> 1st Z-motor (left one, viewed from ahead) which is normal Z
; Drive 3 as U -> 2nd Z-motor (right one, viewed from ahead) which is now U
; Drive 4 as Extruder

G91 ; relative positioning

M584 Z2 U3 P4 ; Split Z into 2 (Z+U)

Are you saying that putting the M584 command before the G91 command is what fixed it?

thwe

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

I'm glad you solved it.

The homez.g file you posted earlier starts like this:

; homez.g
; called to home the Z axis
;
; Drive 0 as X
; Drive 1 as Y
; Drive 2 as Z -> 1st Z-motor (left one, viewed from ahead) which is normal Z
; Drive 3 as U -> 2nd Z-motor (right one, viewed from ahead) which is now U
; Drive 4 as Extruder

G91 ; relative positioning

M584 Z2 U3 P4 ; Split Z into 2 (Z+U)

Are you saying that putting the M584 command before the G91 command is what fixed it?

Yes, before "G91" as first line.

dc42

That's very strange, because I can't see any possible mechanism for the order of G91 and M584 making a difference. Are you sure that you didn't change anything else?

thwe

Actually, yes, but I will reset it for safety's sake again to reproduce the funny behavior
At the Weekend i will give feedback

dc42

Thanks, I'll wait for that feedback before I do the 2.02 release in case we can identify something that needs to be fixed.

thwe

So, tested again:

Turn on Duet Wifi - homez.g as in the appendix
G28 Z (via Button Home Z in the DWC)
Homing OK!
Moving in Z: G1 Z-10 (via button in the DWC)
G28 Z (via Button HomeZ in the DWC)
Homing OK!
Moving in Z: G1 Z-10 (via button in the DWC)
Edit homez.g -> set a semicolon before M584 P4
G28 Z (via Button HomeZ in the DWC)
Homing NOT OK! -> U slower as Z
Moving in Z: G1 Z-10 (via button in the DWC)
Edit homez.g -> delet Semicolon before M584 P4
G28 Z (via Button HomeZ in the DWC)
Homing OK! -> U as fast as Z

Thus, it is certain that only the first line of content "M584 P4" in homez.g prevents the strange behavior of the different speeds.

Only valid if the z-axis has already been homed. After a new start or reboot, the FIRST homing will always work, whether with or without the above line, until the second homing occurs.

for safety's sake again here my config.g
0_1542973940030_config.g

... and here the homez.g:
0_1542974052538_homez.g