Dual Z-axis endstops
-
What do you have in your homez.g and homeall.g files? Perhaps you still have driver 3 assigned to Z as well as U when you are Z homing.
Edit: i just spotted that your M350 command doesn't set microstepping for the U axis.
-
I'm pretty sure I had it in there before I switched back to 1 Z for testing but I'll add back and test again tonight, just in case.
Here is homez.g. Homeall.g hasn't been updated yet.
[[language]] ;DUAL Z M584 Z2 M854 U3 G1 S1 Z-320 U-320 G92 Z.04 M584 Z2:3 -
M854 in your homez.g file is not a valid gcode, I presume you meant M584.
-
Good catch. I'll report back results.
-
I am really looking forward to the dual z end stops as well how long do you think it will be until the beta release?
-
Have you read the recent posts in this thread to see how you can [probably] do it already?
-
Yes I saw the post have that working but would like to get my NPN probe back eventually if possible.
-
If you mean that you can't connect your NPN probe to the E0 endstop connector because it is used for the second Z homing switch, you can connect your NPN probe to E1 endstop connector or to the Z probe connector instead if you select the appropriate probe type in your M558 command.
-
I got this working fine and will post my setup here soon. There is some oddities when lowering Z after hitting the endstops and only one axis move if I do not add S2 as instructed by David. I did report this as an bug on github as it seems it should not behave like that.
https://github.com/dc42/RepRapFirmware/issues/91
closed Inconsistency in dual Z axis movements #91
-
I'm working on a big IDEX build. Would the method you guys have described here also work for a Y axis using 2 steppers? It could be nice to tram the X axis at the start of a build.
-
Yes it should be possible to use dual Y homing switches in the same way.
-
Having fiddled with dual Z now for a while I'm not to fond of the extra axis in the UI. Z controls both Z motors but U only controls the one. How can I hide the U axis or at least disable it so I don't accidentally move only one Z motor?
Pretty easy to hit U instead of Z
-
I can think of two potential solutions, both requiring firmware changes:
1. Implement support for multiple Z homing switches directly in firmware, so you don't need to configure additional axes. This is what I had planned before I realised that you could do it using additional axes.
2. Add a facility to specify a number of displayed axes that is lower than the total number of configured axes.
In the meantime, you could avoid the risk of moving only one Z axis by mapping the U axis to a non-existent motor except during Z homing
-
Are there any updates to official firmware that has support for this? If not, would it be possible to use a macro to temporarily reassign drivers, home both sides, then revert back to the assignments in config.g (or manually copy and paste those settings into the macro)?
I'm hoping to avoid the need to have extra axes controls that can be messed with on accident or the need to mod the firmware to mitigate this. Plus, I only intend to perform this action once at startup, not before each print since I want to level my gantry and let my probe handle normal homing. Once current is applied to the motors I shouldn't need to do this again.
-
Firmware 1.19beta6 will support hidden axes. So you will be able to use the U axis for the second motor during homing, but the user interface will not provide a Home U button, nor jog controls for the U axis.
The firmware changes for this are already implemented, but not tested yet.
-
Marvelous! I think I'm on 1.17 so I'm due for an update! I only see the beta5 on github, is there somewhere I can get the latest? Is there any documentation on the new functionality and how to setup?
-
1.19beta6 will be released when I have tested it. The M584 command has a new optional parameter P which specifies the maximum number of visible axes. So if you use M584 to create a U axis but also specify P3 in that command then the U axis will be hidden.
-
Ahh, I'll keep an eye out for that and let you know if I have any questions, thanks David!
-
Is the dual Z-endstops implemented, or going to be implemented in 1.19, or do we use the solution you outlined below?
I'm homing to Z-max using 2 independent motors and want them to "sync up" when homing, as all sorts of things can happen to make them go out of sync.
I expect to implement multiple Z homing switches in firmware 1.19. In the meantime I think you can achieve the same thing as follows:
1. Put this command in config.g:
M584 X0 Y1 Z2:3 U3 E4
This assigns your second Z motor (connected to the E0 motor output) to both the Z and U axes.
2. In your homez.g file, do this:
M584 Z2
G1 S1 Zxxx Uxxx
G92 Zxxx
M584 Z2:3This splits Z into the Z and U axes, homes them simultaneously, and then restores normal Z movement. Fill in the xxx values to suit your machine - see https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Cartesian_printer#Homing_files.
3. Change the Z homing section of homeall.g to do the same.
4. Connect the second Z endstop switch (the one you use for the U motor) to the E0 endstop input.
Test the above carefully, with low motor current and a hand on the power switch, in case I have forgotten something.
-
The advice remains the same for now, except the detail has changed. I now suggest the following:
1. Put this command in config.g:
M584 X0 Y1 Z2:3 U9 E4 P3
This assigns your second Z motor (connected to the E0 motor output) to the Z axis, and creates a U axis that uses driver 9 (which I am assuming is not connected to any motor). The P3 parameter limits the number of visible axes to 3 in firmware 1.19beta6 and later, so that the U axis is not visible in the user interface.
2. In your homez.g file, do this:
M584 Z2 U3
G1 S1 Zxxx Uxxx
G92 Zxxx
M584 Z2:3 U9Assuming that driver 9 is not connected, assigning the U axis to it other than during Z homing prevents inadvertent movement of the U motor if a G1 command with a U parameter is executed.
