Z homing fails often after update from 3.1.1 to 3.2

Phaedrux

I believe he is aware, but I'm not sure beyond that.

Would you be able to test the 3.2.1 beta release to see if the issue is resolved?

https://www.dropbox.com/sh/1lwimb98k6hzz3z/AAApVr_P6roUjnya4riDbGAba?dl=0

fcwilt

@Phaedrux said in Z homing fails often after update from 3.1.1 to 3.2:

Would you be able to test the 3.2.1 beta release to see if the issue is resolved?

Will do.

Frederick

fcwilt

@Phaedrux said in Z homing fails often after update from 3.1.1 to 3.2:

I believe he is aware, but I'm not sure beyond that.

Would you be able to test the 3.2.1 beta release to see if the issue is resolved?

https://www.dropbox.com/sh/1lwimb98k6hzz3z/AAApVr_P6roUjnya4riDbGAba?dl=0

Before installing 3.2.1 I ran 50 more homing tests under 3.1.1 - they all worked.

Sadly after installing 3.2.1 the second test failed in the same way as 3.2.0.

G1 H1 Z-300 F300 <== slow speeds so I can hit the emergency stop button before a crash
G1 H2 Z+25 F300
G1 H1 Z-30 F300 <== to date it has always failed on this move never on the first one

Back to 3.1.1 for now so I can use my printer.

I miss the Object Model Viewer from 3.2.0 but I cannot stand by the printer every time it homes Z.

Frederick

fcwilt

@dc42

Sorry to bother you but I was wondering if this problem of mine was in the queue?

As suggested I tried the 3.2.1 binaries and I was successful in getting it installed.

Under 3.1.1 I had run 50 homing tests and they all worked.

Under 3.2.1 I tried to run the same 50 homing tests. The 1st worked - the 2nd failed.

For now I am stuck on 3.1.1.

Thanks.

Frederick

dc42

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.

fcwilt

@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

dc42

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.

fcwilt

@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

Possibly related?

https://forum.duet3d.com/topic/21451/error-bad-command-xxx-w-rrf-3-2-and-leveling-issue/16?_=1612820446457

fcwilt

@Phaedrux said in Z homing fails often after update from 3.1.1 to 3.2:

Possibly related?

https://forum.duet3d.com/topic/21451/error-bad-command-xxx-w-rrf-3-2-and-leveling-issue/16?_=1612820446457

Yes - I saw that and thought the same thing.

Frederick

dc42

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

fcwilt

@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

dc42

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.