When I home, the unit continues to engage the motors even after tripping the Y limit switch. This is new behavior, the machine has been working for 6 months with the limit switches working exactly as expected. I first saw this yesterday when I attempted to home with Universal GCode Sender. I had assumed it was a config problem with UGS and it was late, so I packed it in until today. Today, I reinstalled Carbide Motion 3 to make sure I was on the latest, and I’m seeing it there too.
I’ve read the articles about this, but I’m still having the problem. I’ve checked connections, checked for interference and I think I’ve configured it correctly ($20=1, $21=1, $22=1 and homing = true on the settings page.
When I manually trip the limit switch, it registers in the Carbide Motion log:
gc_wait_for_idle
___________N0 G4P0.005 ___________
<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,0.000,Buf:0,RX:0,Ln:0,F:0.>
ok
gc_sync
<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,0.000,Buf:0,RX:0,Ln:0,F:0.>
ALARM: Hard/soft limit
SET MACHINE STATE: MACHINE_ALARM
GRBL_RESET
SET MACHINE STATE: INIT
[Reset to continue]
Grbl 0.9g
[’$H’|’$X’ to unlock]
___________$X ___________
[Caution: Unlocked]
ok
<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,0.000,Buf:0,RX:0,Ln:0,F:0.>
gc_unlock
___________$X ___________
ok
I’m on grbl v.09, running carbide motion v3.0.366.
I’d love to know where to go from from here.