Hello everyone! just got done building my lowrider v3 4x8… everything was working fine until the z1 stop quit responding when homing. I verified that everything is wired correctly and it was homing fine until just now. when homing the z axis z2 works perfect but z1 clicks the microswitch and keeps going. the wiring seems fine and when it hits the microswitch the light comes on, so the board is receiving the signal it just does not stop.
this is completely random sometimes it works and sometimes it doesn’t… anyone ran into this before?
Hello @breed2085, welcome!
What board are you using? Are you using M119 gcode to help verify whether controller thinks endstops are triggered? Was getting inconsistent Z endstop triggers on my LR3, until I lowered the Z stop parts as much as the slotted hole would allow, and bent the metal arms down a bit. This helped make Z endstop triggers more consistent. Digging around https://forum.v1e.com/search?q=M119%20endstop may help spark some ideas.
2 Likes
im using the skr 1.2 with marlin code. thank you I will check the m119 and move the stops… i just thought it was odd because the indicator light comes on when it hits the stop.
Just an FYI, M119 has to be capitalized. So the G and M codes are case sensitive.
I didn’t know that thank you
I’ve seen three topics on this forum where endstops on the SKR Pro board are failing to trigger inside Marlin. I’m not sure we ever got to the root of the problem with these other topics, but the best guess was a manufacturing problem with the board that results in pins not reading high when they should. One person fixed the issue by adding 1.5K pullup resistors between the signal pin and 5V pin of each endstop plug. It is too early in the trouble shooting process to say this is what is going on with your board, but I wanted to make you aware of the potential issue.
1 Like
ill look into that. that makes more since to me. ill see if i can scrounge up a 1.5 k resistor thank you
just checked M119 and it is open even when the switched is pressed and the light is on… makes me think its either a firmware glitch or needs the resistor as suggested.
Did you bend the pin from the tmc2209 it of the way?
I did but I will double check that
1 Like
I snipped mine to ensure no possibility of bent pin touching the capacitor under the drivers. Think someone (who knows more than me) said it wouldn’t be a problem IF the bent pin accidentally touched the capacitor. I was too paranoid to find out and went ahead with snipping.
+1 for what @robertbu called out here:
I’ve wondered if there was a downside to uncommenting from Configuration_adv.h:
//#define GCODE_CASE_INSENSITIVE // Accept G-code sent to the firmware in lowercase
It probably slows down the parser. IDK if it would matter with the quicker skr.
Regarding the OP topic, seems to me if an LED is turning on/off with the switch, everything with the electrical subsystems up to at least the LED should be OK. Could be a firmware issue or a defective board (cold joint on the mcu or whatever). You can maybe rule out a defective board by flashing some other firmware and verifying the MCU responds properly to the pin in question… like swap the pinouts for z1 and z2 endstops in the code, swap connectors, and see what happens. If z2 now has issues and z1 is fine, it’s likely a defective board.
edit: Also, what exact firmware are you using? Not sure if you mentioned that somewhere else but it is very important to know.
2 Likes
The endstop circuit is strange in the SKR Pro. See this post by Steve Ulrich for a circuit diagram. He is right that the LED leg of the circuit acts as a voltage divider for the signal pin, meaning that, even in a correctly manufactured board, the voltage of that pin sits nearer floating than 3.3V.
3 Likes
Aah, yeah that’s good info for sure. It does form a divider, who’s output voltage in the high state will depend on the forward voltage of the particular LED, which can vary significantly with manufacturing tolerances, part substitutions, etc. That’s a poor design I think. I have always designed my input stages with any LEDs on the buffer side to avoid this problem. IMHO, if this resulted in indeterminant logic on my board, I’d lop off the dang LED and call it good. Actually seeing that schem, I’d probably lop off all those input leds on my skr pro’s just for peace of mind, lol.
2 Likes
I have been trying to catch it in the act so I can verify the problem but when it messes up it fixes itself before I can catch it. I did notice it seems to act up more as the board warms up, so I’m suspecting bad solder joints on the resistors. Also now the problem is moving randomly to other stops… I will update when I find the problem. Thank you everyone for your input!
1 Like
I took the risk for the good of the people and took a pair of needle nose pliers and scraped the LEDs off and so far it seems to have solved the problem… I will give it a good run through tomorrow and if there are no more glitches I will mark this solved, thanks for the idea!
I didn’t try the resistor, because removing the LEDs seemed like a simpler solution that the average user could do and it offers a similar result to the resistor… I lose the LEDs but I can still use M119 to check if I need to. And best of all no more ramming into the stops(hopefully)
1 Like
I happy to report that removing the LEDs solve the problem, I ran it for about 6 hours with 0 end stop crashes. Thank you to everyone that made a contribution in an effort to help me fix this problem!
4 Likes