Z homing fails often after update from 3.1.1 to 3.2
-
Thanks for the detail. I have added this to my investigations list. It's likely connected to the way in which endstops connected to a DueX are read.
-
@dc42 said in Z homing fails often after update from 3.1.1 to 3.2:
Thanks for the detail. I have added this to my investigations list. It's likely connected to the way in which endstops connected to a DueX are read.
I will repeat this just in case you missed it.
- The behavior was for one of the steppers to keep moving even though the LED on the end stop sensor activated.
- It was not always the same stepper.
- It was never more than one stepper.
- It always failed on the second G1 Z-25 F300 H1 - see below.
G91 ; relative moves G1 Z-399 F300 H1 ; move up until endstop switch is activated G1 Z20 F600 ; move down a bit G1 Z-25 F300 H1 ; move up until endstop switch is activated
Thanks much.
Frederick
-
Thanks. I suspect the issue may be that when two endstop switches connected to a DueX trigger almost simultaneously, only the first one is detected. I will try to replicate this.
-
@dc42 said in Z homing fails often after update from 3.1.1 to 3.2:
Thanks. I suspect the issue may be that when two endstop switches connected to a DueX trigger almost simultaneously, only the first one is detected. I will try to replicate this.
Well given the 3.1.1 has never failed for me and 3.2.0 fails frequently doesn't that suggest that there was a code change related to the handling of the end stops?
Frederick
-
-
@Phaedrux said in Z homing fails often after update from 3.1.1 to 3.2:
Possibly related?
Yes - I saw that and thought the same thing.
Frederick
-
@fcwilt said in Z homing fails often after update from 3.1.1 to 3.2:
@dc42 said in Z homing fails often after update from 3.1.1 to 3.2:
Thanks. I suspect the issue may be that when two endstop switches connected to a DueX trigger almost simultaneously, only the first one is detected. I will try to replicate this.
Well given the 3.1.1 has never failed for me and 3.2.0 fails frequently doesn't that suggest that there was a code change related to handling the of the end stops?
Frederick
Yes there was a code change in the handling of endstops attached to a DueX. The newer code relies on the interrupt generated by the I/O expander chip when any of the inputs changes, because I am moving RRF towards interrupt-driven endstop inputs. It seems that the interrupt is not always generated. I am seeking clarification from the manufacturer of that chip, and trying to reproduce the issue you experienced.
-
@dc42 said in Z homing fails often after update from 3.1.1 to 3.2:
Yes there was a code change in the handling of endstops attached to a DueX.
Well that is good to know - it would seem narrow your focus for finding the problem.
Thanks.
Frederick
-
It's as I expected. If two endstops are triggered with a delay of about 2.2ms between them, only the first one is registered until another input changes. When the delay is shortened to 1ms or lengthened to 5ms, the problem does not occur.
Now I can test fixes.