Z homing fails often after update from 3.1.1 to 3.2

Phaedrux

Well the only other thing I might ask you to check on 3.2 would be M98 P"config.g" and sending M574 to see if it echoes back to expected endstops.

fcwilt

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

Well the only other thing I might ask you to check on 3.2 would be M98 P"config.g" and sending M574 to see if it echoes back to expected endstops.

Results of m98 p"config.g"

FTP is enabled on port 21
TELNET is enabled on port 23
Print will be terminated if a heater fault is not reset within 10 minutes

Frederick

fcwilt

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

Well the only other thing I might ask you to check on 3.2 would be M98 P"config.g" and sending M574 to see if it echoes back to expected endstops.

Results of M574

Endstop configuration:
X: low end switch connected to pin xstop
Y: high end switch connected to pin ystop
Z: low end switches connected to pins !duex.e2stop !duex.e3stop !duex.e4stop

Frederick

dc42

Thanks. Please revert to 3.1.1 and see if the problem goes away again.

I note from your config that you are using active low endstop switches for Z. If they are simple normally-open switches, this is against our advice to use normally-closed switches, because it has two consequences that you need to be aware of:

A bad connection to one of them would exhibit this behaviour (i.e. endstop switch not triggered). Is it always the same Z motor that continues to run? If so then I suggest you check the connections to the corresponding endstop switch. It wouldn't be the first time that a bad connection started causing a problem by chance at the same time that a firmware upgrade was installed.
The cables connected to normally-open endstop switches are sensitive to capacitive pickup from nearby sources of noise, for example stepper motor cables in the same wiring bundle. However, I would not expect the sensitivity to interference to have changed between firmware versions.

If they are not simple microswitches (for example, they are optical sensors, or makerbot-style switches mounted on a PCB with one LED and two resistors) then item #2 does not apply.

fcwilt

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

Thanks. Please revert to 3.1.1 and see if the problem goes away again.

Prior to reverting I tried homing 5 times under 3.2.

It failed 3 times. The behavior was for one of the steppers to keep moving even though the LED on the end stop sensor board turned on at the appropriate location. 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

I realize 5 times is not enough but I wanted to get back to you.

I reverted to 3.1.1 which, as I mentioned, I had been using for months and months without any problems.

I tried homing 5 times under 3.1.1.

No failures.

I will be glad to "upgrade" again to 3.2 and run more tests if needed.

Frederick

fcwilt

@Phaedrux

I don't want to be a pest but do you have any idea if dc42 has had to chance to investigate this issue?

I have continued to run homing tests - 3.1.1 simply does not fail whereas 3.2.0 fails "without fail".

Thanks.

Frederick

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.