I have just built a grbl machine, and running Control software. When limit switch is triggered, serial console reads "timestamp - MSG:check limits". I untrigger the switch, and hit the unlock button several times, but timestamps keep coming for almost a full minute before i get and OK and the machine is again responsive.If the limit switch stays triggered it just timestamps away into eternity. So if my machine hits the limits, how am I supposed to get it working again? Homing is working as intended so I am inclined to think it may be a setting in either Control or grbl ?
Running standard Grbl or some 3rd party fork? Limits with filtering or cheap bouncy switches that retrigger on exit?
standard grbl 1.1h cheap switches edit - I have just tried universal gcode sender. This has no problems releasing when i click unlock
And are you moving a big enough move to clear the switch in one go? For example if your switch needs 5mm of pullaway to properly release, then sending a 1mm move will alarm as it did not clear the switch. CONTROL, UGS etc are just UIs. Alarms, Limit Interrupts, etc are internal to Grbl running on the microcontroller. It may reveal something the operator does differently though (jog size for example)
Well, the problem is that the software seems unresponsive when the alarm is triggered. I can do absolutely nothing at all until the limit switch is untriggered. And when untriggered it takes roughly 10 secs before it becomes responsive and the msg check limits to stop scrolling on the console. The diff to UGS is that when untriggered, it becomes immediately responsive when i press to unlock.
That's not typical. Are you 100% sure its stock vanilla Grbl from Release v1.1h (2019-08-25) Release · gnea/grbl If it is post the output from a '$I' and a Grbl Settings backup (CONTROL > Grbl Settings tab > Backup Settings button)
Thanks for confirming. Yes CONTROL expects Grbl (official Gnea version). If in doubt, grab a BlackBox https://docs.openbuilds.com/blackbox
