Z homing switch randomly reports triggered when it's not.
-
This has been happening coincidentally after installing RRF 3.2.2.
I have these lines in my homing file
if sensors.endstops[2].triggered abort "Z endstop already triggered at the beginning of the homing move - aborting"On a number of occasions, after powering up the printer and doing the first homing of the day, I've received this error and when checking DWC, sure enough, the end stop shows being already triggered. Now I know that it isn't because it has an LED across it which lights when it's triggered and is out when not. Manually triggering the switch shows no change to the end stop status - it always shows triggered regardless of the actual state.
Cycling the power restores correct behaviour. After that power cycle, everything behaves normally for the rest of the day. Some days, everything works fine from that start.
To save me typing, details of the switch and wiring are shown in the blog post. https://somei3deas.wordpress.com/2020/04/18/my-6-input-mixing-hot-end-part-7/
Edit. For info, I use and old version of DWC if I want to check end stop status. This is accessed by adding \reprap to the address.
-
Hi,
In the little schematic you linked to it shows a 5 volt connection. Where is that 5 volts coming from? I doubt that is part of the problem but you never know.
I do know that 3.2.2 contained a fix for a problem with multiple endstops on the same axis, in my case the Z axis (3 steppers and 3 associated endstop sensors).
The problem in 3.2.0 was that during my Z axis homing sometimes the activation of 1 of the 3 endstop sensors was missed.
Since upgrading to 3.2.2 I no longer have that problem, nor have any other endstop problems occurred but since 3.2.2 contained changes to endstop handling perhaps you have uncovered a new problem.
At the start of a homing procedure I test the state of the endstop sensor but instead of aborting I back off enough to insure the endstop is deactivated. So if a endstop sensor was "stuck on" there would not be the clear indication of the issue that the abort provides.
I should mention that my printers are using Duet 2 WiFi/Duex 5 combos or Duet 3 Mini 5.
Instead of cycling power have you tried M999 or invoking config.g with M98 to see if the clears the problem?
Frederick
Printers: A FT-5 with the 713 upgrade bits. A custom MarkForged style. A small Utilmaker style and a CoreXY from kits. Various hotends. Using Duets (2 and 3) running 3.4.1
-
@fcwilt said in Z homing switch randomly reports triggered when it's not.:
In the little schematic you linked to it shows a 5 volt connection. Where is that 5 volts coming from? I doubt that is part of the problem but you never know.
From the pin labelled 5V-EXT on the IO connector header.
I do know that 3.2.2 contained a fix for a problem with multiple endstops on the same axis, in my case the Z axis (3 steppers and 3 associated endstop sensors).
The problem in 3.2.0 was that during my Z axis homing sometimes the activation of 1 of the 3 endstop sensors was missed.
Since upgrading to 3.2.2 I no longer have that problem, nor have any other endstop problems occurred but since 3.2.2 contained changes to endstop handling perhaps you have uncovered a new problem.
Maybe.
Instead of cycling power have you tried M999 or invoking config.g with M98 to see if the clears the problem?
No. But I will try that the next time it happens.
-
@dc42 Do you think there could be an issue with the 5V sneaking through the resistor and keeping the processor powered-on through the I/O pin?
Could this be causing a problem during a power-cycle if the two supplies are not falling and rising in the correct order?
