I am running a 2D plotter using GRBL and UNO. One limit switch isn't working and I can't figure out why. The X-axis limit switch is always read as closed. (I have shielded cables, ferrite cores and capacitors, but the problem is not noise - it's that GRBL is seeing the switch as closed.) - The plotter works fine if I disable hard limit checking, so the motors etc are all good. - Home command does the Y axis correctly. Then it jogs in +X, as if it is trying to get away from the limit switch. It tries this three times then gives up. - Both limit switches check out OK with a multimeter (infinite resistance default, a few ohms when triggered). This is checked at the shield connector. - I modified and uploaded the Arduino example "Button" and manually operated the carriage to trigger the limit switches. The on-board LED operated as expected. - I get exactly the same effect using UGS and my home made sender. - If I remove the cable for the X-axis limit switch, the Home command drives the X-axis towards home and it runs into the stops. So there is something in that switch or cabling which I cannot detect with a multimeter or using the UNO as a test unit, but which causes GRBL to see it as always closed. I am using the default 382p CPU map without changes (pins 9 and 10 for the limit switches). I have a ? report but I can't see where it reports the limit switches: <Idle|MPos:0.000,0.000,0.000|Bf:15,127|FS:0,0|WCO:0.000,0.000,0.000> Any ideas? $0=10 $1=10 $2=0 $3=0 $4=0 $5=0 $6=0 $10=255 $11=0.010 $12=0.002 $13=0 $20=1 $21=1 $22=1 $23=3 $24=12.000 $25=2000.000 $26=250 $27=2.000 $30=1000 $31=0 $32=1 $100=20.100 $101=20.000 $102=10.000 $110=3000.000 $111=3000.000 $112=500.000 $120=30.000 $121=30.000 $122=10.000 $130=350.000 $131=245.000 $132=200.000
Thank you for the response, however the 'button' test has proved that it is not the UNO. I thought about what could be different between my testing and the real thing, and decided that simply testing that the switch was either open or closed was not enough. The UNO actually responds to the connection between the GPIO pin and the UNO ground, and that's not necessarily the same as whether the switch is open or closed. In particular, if one side of the the switch is somehow connected to UNO ground, then it could appear to be closed all the time. So I did a thorough test of both sides of both switches but I could find no connection to UNO ground. Then I thought about how the 'button' test could work OK, but the home command would fail, when they ought to be exactly the same thing. But the 'button' test was done with the carriage disabled and centred - when I repeated it for different positions for the carriage, results were variable. Somehow the position of the carriage (ie,near the Y-axis home position) is creating a connection of one side of the X-axis switch to UNO ground. The best suspect would be a stray wire from the cable shield, and I believe that's what it is, although I haven't yet found the actual culprit.
Solved. The answer was: 1 - Separate the X and Y homing commands : #define HOMING_CYCLE_0 (1<<X_AXIS) // COREXY COMPATIBLE: First home X #define HOMING_CYCLE_1 (1<<Y_AXIS) // COREXY COMPATIBLE: Then home Y 2 - Test both sides of the limit switch for continuity to ground while the carriage moves to the other limit switch. This meant that the problem could be tracked down to a single strand from the shield braid that had escaped its heat shrink and was causing an intermittent earth at a specific position of the Y-axis.
