Drive 3 is slower as drive 2 at homing in Z [Solved]
-
Thanks for that @dc42 that is good to know
-
@dc42
new M208 in config.gM208 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 = maximumAfter 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 -
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.
-
@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.
-
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?
-
@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?
-
-
for my dual z mapping i have not mapped u at all i just have the two entries for Z
-
@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.
-
@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
-
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_motorsi have it set up for 2 motors and it does not require a U axis
-
@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.
-
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? -
@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.
-
@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!
-
@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
-
@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.
-
@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
-
@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
-
-
@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.
-
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.
