BLTouch Not Working After Firmware Update to 3.4
-
@alecsanchez said in BLTouch Not Working After Firmware Update to 3.4:
@Phaedrux If I can avoid converting to standalone mode that would be great... but if that is a better move forward to test, I can do that. This just very much feels like a possible bug since it occurred immediately after updating
Well testing standalone mode would at least cut down one variable and is pretty easy to do.
If you have a spare SD card you can set it up with the DWC files in the /www folder, and backup your current config files through DWC and place them in a /sys folder. Then put the SD card into the Duet itself and disconnect the ribbon cable. Move the network connection over to the Duet. May need to add network details to the new config.g file.
-
@alecsanchez said in BLTouch Not Working After Firmware Update to 3.4:
It seems that is the more likely issue
You are right. What I'm curious about is which signal is affected by the Y endstop - if at all… Perhaps, we get a hint at what's going on. It's a faint hope…
Maybe it's better to follow @Phaedrux' path first - with an experimental setup in standalone mode, you can try modifications or even a fresh config from the online-configurator tool.
-
@alecsanchez Just an idea: could you please try to change this line in your config
M574 Y2 S1 P"io1.in"to this:
M574 Y2 S1 P"^io1.in"I assume this is your port for the Y endstop … The caret (^) activates a pull-up, which might stabilise the signal of the NO switch. Don't know if that helps though.
-
@infiniteloop This appeared to pull the signal high when the endstop wasn't activated. So no luck
-
@infiniteloop @Phaedrux Are there any other io pins I can use for endstops on the board that aren't the 8 IO_X pins?
-
This appeared to pull the signal high when the endstop wasn't activated. So no luck
Right, I intended to pull the inactive signal high. In a previous post, you confirmed on request that the active signal is low. I asked:
How is the Y endstop wired: two lines from the Duet to the switch, GND and signal?
Your answer:
Those are all correct
From the result of the pull-up test, I think it must be the other way round, I.e. the signal of the Y switch is active high.
Please investigate this: measure the voltage on the signal pin against GND. Is it high when the switch is active? And: what voltage do you get when the switch is inactive?
Counter check: Which pins of the I/O port are connected to the switch? Please refer to this wiring diagram of your board. Best would be an additional photo of the wires and the connector to illustrate the situation.
What puzzles me is that just the Y switch somehow interferes with the BLTouch, regardless of the port you use, but that the X switch works apparently fine (if assigned to X).
-
@infiniteloop Sorry I made a mistake yesterday regarding the caret (^)
M574 Y2 S1 P"io1.in"is reading 0v while inactive, 3.3v while active
M574 Y2 S1 P"^io1.in"is reading 0v while inactive, 2.97v while active
The switch is connected by two wires to GND and io.1in as shown in this picture:
-
@alecsanchez said in BLTouch Not Working After Firmware Update to 3.4:
M574 Y2 S1 P"^io1.in"
is reading 0v while inactive, 2.97v while active
That's weird. As a NO switch, it should read something near 3V if open and 0V if closed. Instead, this one works in NC mode. Is this the same with your X endstop?
-
@infiniteloop Well I have both X and Y endstops wired as NC endstops
-
This is how I wire all of my X and Y endstops, and it was not a problem until I updated to 3.4
-
@alecsanchez said in BLTouch Not Working After Firmware Update to 3.4:
This is how I wire all of my X and Y endstops, and it was not a problem until I updated to 3.4
No offence intended
It's just that a lot of boards have been upgraded to 3.4 - admittedly, some had problems, but up to now, AFAIK never related to endstops. Your case is quite unique, so I try to figure out what hinders your BLTouch to extract. TBH, I see no way how to explain this with firmware (be it a setting, feature or bug …), that's why I concentrate on electrical effects.My suspicion is that pulling io1.in to GND somehow causes a slight voltage drop, either on 3.3V or 5V, which in turn affects operation of the BLTouch. To follow this route, you'd have to try some things (if you want):
- After X/Y are homed (but both not in their homing positions), activate the X switch instead of Y. Does this let the BLTouch deploy?
- Move the BLTouch to IO_3 - does this help?
- Measure the voltages on an easy accessible port (IO_8, IO_6 or IO_2) on the outmost pins (3.3 and 5V): can you observe a shift when you manually activate the Y endstop?
Prior to all this, you should remove the caret (^) from M574: it's counter-productive.
-
@infiniteloop I changed the output voltage to the bltouch to 3.3v and it fixed the problem. No more interference from the y endstop
-
Was that a bltouch setting?
-
@phaedrux said in BLTouch Not Working After Firmware Update to 3.4:
Was that a bltouch setting?
No, just another pin on the connector.
-
@alecsanchez said in BLTouch Not Working After Firmware Update to 3.4:
I changed the output voltage to the bltouch to 3.3v and it fixed the problem. No more interference from the y endstop
Interesting: I had put my bet on interferences with the 3.3V rail. Instead, the 5V seam not to be as stable as supposed. Nevertheless: good that it works with 3.3V, although the BLTouch should be supplied with 5V
-
@infiniteloop @Phaedrux Just a follow-up regarding this issue. The 3.3v pin on the duet connector has been working great, but with two small nuances:
-
The bltouch red light is constantly blinking as if its in alarm mode, although it functions as normal
-
the bltouch does not retract when triggered anymore. I had to add an m402 command in all moves that require probing. It is nice when it is doing a mesh bed leveling though as it is not constantly deploying and retracting
-
