G1 H4 with RRF 3.x
-
I'm wondering if there might be a typo in the documentation for the H4 parameter on the G1 command (for RRF 3.2 and up) in the gcode dictionary.
I'm using this command on a U axis with endstops and it seems the axis limits are being ignored, as documented with the H1 and H2 parameters.
Heres what it says in the gcode dictionary:
G1 Xnnn Ynnn Znnn H4 Sense endstops while moving, update the current position at which the endstop switch triggers (supported in RRF 3.2 and later).
-
@mikeabuilder said in G1 H4 with RRF 3.x:
it seems the axis limits are being ignored,
That's the point though. It's moving to the switch and updating the axis limit with the new found value.
What are you expecting it to do?
-
@Phaedrux - I expected the G1 with the H4 parameter to follow the description I pasted in from the dictionary page above. Specifically:
-
Move until the endstop is reached, but do not ignore soft limits. I say this about the limits because the H1 and H2 parameters are explicit about ignoring soft limits and the H4 description omits this.
-
When the limit switch is reached, update the current position but do not change the axis limit.
In my use, I find the second bullet point is followed, but not the first - specifically, the soft limit is ignored.
My use case is with a Jubilee Remote Elastic Lock, a clever (but complicated) bit of design used for locking an E3d-type tool onto the printer carriage. Turning the motor in one direction finds a fixed limit switch, which is used to set the 0 position of the axis. Turning the motor in the other direction moves easily until there is resistance to turning, then a spring is stretched until a second limit switch is triggered. The spring ensures a certain amount of torque was applied. This all means that this second limit switch is not at a "fixed location" and so can't be used to reset the axis limit.
When I use G1 with the H4 parameter to lock a tool onto the carriage, I give it a move beyond any reasonable value, expecting the second limit switch will be triggered and stop motion without resetting the axis. This is working, and I can see that with a particular tool, the lock engages are a position of 110. As an experiment, I set the soft limit to 100 and reran the experiment. Based on the description of H4, I expected the axis to stop when it reached position 100, but it continued to (and stopped at) 110.
-
-
@mikeabuilder in https://docs.duet3d.com/en/User_manual/Reference/Gcodes#g0g1-h-and-s-parameter, it only states that G1 H0 applies axis limits, and H1 and H2 ignore them. It's not stated either way for H3 and H4, and though one could assume it either way, the whole point of the H parameter (other than the default H0) is to ignore axis limits to find the endstops (apart from H2, which ignores that as well). I'll add some text for H3 and H4, that they ignore axis limits, just to make it clear.
If you want the axis to stop at the second endstop, using G1 with an H parameter, I guess you are redefining the second switch as the endstop before the move, as there's a limit of one endstop per motor. Or have you wired the two endstops in series if they are connected Normally Closed (or in parallel, if Normally Open)?
ian
-
@droftarts - Ian, thanks for the clarification and additional info. I always learn something from this forum. Knowing that the endstops are ignored on all but H0 helps me understand more clearly how it works.
The more important thing I learned is that there can only be one end stop per motor and the design we are using does indeed have two NC endstop switches wired in series. We have recently been contemplating separating these to two inputs because in normal use, this motor is at rest with one of them triggered. In this situation, we can only know which end of travel we are at rest on by keeping track of it in sw - a risky proposition that a second input would eliminate. Now we know there will be additional macro work to do if we follow that path (re-define the endstop before making any moves). That'll be something for us to really look hard at.
