Limit switch alarm triggered also when releasing

[SebastianKusykIFJ]

Hello,
I hit a limit switch, got error info from GRBL and resetted and unlocked it. However, when I started moving in the opposite direction, I also got the limit switch error when the switch was released and had to reset and unlock again. How to prevent this? Is it caused by switch bouncing / electrical oscillations or by GRBL itself? First I had NO wiring, changed to NC (and of course changed GRBL configuration - inverted limit pins), but it doesn't help. Also I have very long homing switch debounce time, 250 ms, but does this setting work only in homing mode or always for limit switches?

[GrahamJB]

Perfectly normal behaviour, when a switch is triggered and the router stops the switch will still be triggered. When you move away from it the axis will move but the switch is still triggered so another alarm is generated. It can take 2 or 3 tries to jog away far enough before the switch un-triggers, how many tries depends on a load of things, mostly mechanical, not software related. From: SebastianKusykIFJ ***@***.***> Sent: 18 July 2023 12:32 PM To: gnea/grbl ***@***.***> Cc: Subscribed ***@***.***> Subject: [gnea/grbl] Limit switch alarm triggered also when releasing (Issue #1222) Hello, I hit a limit switch, got error info from GRBL and resetted and unlocked it. However, when I started moving in the opposite direction, I also got the limit switch error when the switch was released and had to reset and unlock again. How to prevent this? Is it caused by switch bouncing / electrical oscillations or by GRBL itself? First I had NO wiring, changed to NC (and of course changed GRBL configuration - inverted limit pins), but it doesn't help. Also I have very long homing switch debounce time, 250 ms, but does this setting work only in homing mode or always for limit switches? — Reply to this email directly, view it on GitHub <#1222> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABN5WWFJ6IX6YIOJYX3DRI3XQZX33ANCNFSM6AAAAAA2OIEYMI> . You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/ABN5WWAIC6VZM3GWFZLUXMLXQZX33A5CNFSM6AAAAAA2OIEYMKWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHGXXT5ME.gif> Message ID: ***@***.*** ***@***.***> >

[SebastianKusykIFJ]

How can I prevent this from happening? I want the limit switch error to appear only when it's pressed, not released. Does GRBL interpret every change in input state as limit switch error, disregarding whether it's change from 0 to 1 or vice versa? Or can it be fixed with some low-pass filter, i.e. RC?

[GrahamJB]

It’s mechanical! The router approaches a limit switch at a certain speed, when it triggers the axis stops. But nothing stops instantaneously so it has kept moving a certain distance, depends on speed, inertia…., past the trigger point. Also the trigger point, the position where the switch triggers, is not the same as the ‘un-trigger’ point, the position at which the switch releases. No RC filter or anything else will change this behaviour. From: SebastianKusykIFJ ***@***.***> Sent: 19 July 2023 10:25 AM To: gnea/grbl ***@***.***> Cc: GrahamJB ***@***.***>; Comment ***@***.***> Subject: Re: [gnea/grbl] Limit switch alarm triggered also when releasing (Issue #1222) How can I prevent this from happening? I want the limit switch error to appear only when it's pressed, not released. Does GRBL interpret every change in input state as limit switch error, disregarding whether it's change from 0 to 1 or vice versa? Or can it be fixed with some low-pass filter, i.e. RC? — Reply to this email directly, view it on GitHub <#1222 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABN5WWFNRIEEMCLL33EZ2W3XQ6RX5ANCNFSM6AAAAAA2OIEYMI> . You are receiving this because you commented. <https://github.com/notifications/beacon/ABN5WWD7LAXQEPUAHN65LXLXQ6RX5A5CNFSM6AAAAAA2OIEYMKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTB3L7I6.gif> Message ID: ***@***.*** ***@***.***> >

[SebastianKusykIFJ]

But nothing stops instantaneously so it has kept moving a certain distance, depends on speed, inertia…., past the trigger point.

It doesn't change anything. After I read the "limit switch" message, click reset, click unlock, send a command to move in the opposite direction, it has more than enough time to stop moving. Even if it were moving, it wouldn't affect limit switch's state (of course unless it's crushed) - it can be either pressed or not, nothing else.

Also the trigger point, the position where the switch triggers, is not the same as the ‘un-trigger’ point, the position at which the switch releases.

I know the 'trigger' point is a bit deeper than 'un-trigger', but again: the switch is still pressed when I reset GRBL, then I start moving in the opposite direction and I release the limit switch - so why GRBL behaves like I pressed it, not released?

[GrahamJB]

Because when it starts to move it is still pressed, if you look at the wiring the limit switches at each end of an axis are connected to the same Arduino Pin. Grbl doesn’t know which one is triggered, just that one of them is. Grbl is reacting to a switch being triggered, , still triggered, left or right one, it just does not know. From: SebastianKusykIFJ ***@***.***> Sent: 19 July 2023 2:37 PM To: gnea/grbl ***@***.***> Cc: GrahamJB ***@***.***>; Comment ***@***.***> Subject: Re: [gnea/grbl] Limit switch alarm triggered also when releasing (Issue #1222) But nothing stops instantaneously so it has kept moving a certain distance, depends on speed, inertia…., past the trigger point. It doesn't change anything. After I read the "limit switch" message, click reset, click unlock, send a command to move in the opposite direction, it has more than enough time to stop moving. Even if it were moving, it wouldn't affect limit switch's state (of course unless it's crushed) - it can be either pressed or not, nothing else. Also the trigger point, the position where the switch triggers, is not the same as the ‘un-trigger’ point, the position at which the switch releases. I know the 'trigger' point is a bit deeper than 'un-trigger', but again: the switch is still pressed when I reset GRBL, then I start moving in the opposite direction and I release the limit switch - so why GRBL behaves like I pressed it, not released? — Reply to this email directly, view it on GitHub <#1222 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABN5WWCTNORFZZ6IUB3RAF3XQ7PJTANCNFSM6AAAAAA2OIEYMI> . You are receiving this because you commented. <https://github.com/notifications/beacon/ABN5WWFNVDYXZWZ6O6YBYQ3XQ7PJTA5CNFSM6AAAAAA2OIEYMKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTB4B4DO.gif> Message ID: ***@***.*** ***@***.***> >

[lalo-uy]

The limit switches are level trigered, not edge. El El mié, 19 de jul. de 2023 a la(s) 10:47, GrahamJB < ***@***.***> escribió:

…

Because when it starts to move it is still pressed, if you look at the wiring the limit switches at each end of an axis are connected to the same Arduino Pin. Grbl doesn’t know which one is triggered, just that one of them is. Grbl is reacting to a switch being triggered, , still triggered, left or right one, it just does not know. From: SebastianKusykIFJ ***@***.***> Sent: 19 July 2023 2:37 PM To: gnea/grbl ***@***.***> Cc: GrahamJB ***@***.***>; Comment ***@***.***> Subject: Re: [gnea/grbl] Limit switch alarm triggered also when releasing (Issue #1222) But nothing stops instantaneously so it has kept moving a certain distance, depends on speed, inertia…., past the trigger point. It doesn't change anything. After I read the "limit switch" message, click reset, click unlock, send a command to move in the opposite direction, it has more than enough time to stop moving. Even if it were moving, it wouldn't affect limit switch's state (of course unless it's crushed) - it can be either pressed or not, nothing else. Also the trigger point, the position where the switch triggers, is not the same as the ‘un-trigger’ point, the position at which the switch releases. I know the 'trigger' point is a bit deeper than 'un-trigger', but again: the switch is still pressed when I reset GRBL, then I start moving in the opposite direction and I release the limit switch - so why GRBL behaves like I pressed it, not released? — Reply to this email directly, view it on GitHub < #1222 (comment)> , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABN5WWCTNORFZZ6IUB3RAF3XQ7PJTANCNFSM6AAAAAA2OIEYMI> . You are receiving this because you commented. < https://github.com/notifications/beacon/ABN5WWFNVDYXZWZ6O6YBYQ3XQ7PJTA5CNFSM6AAAAAA2OIEYMKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTB4B4DO.gif> Message ID: ***@***.*** ***@***.***> > — Reply to this email directly, view it on GitHub <#1222 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXBW4KHAJM5FW2QDLYSGVDXQ7QNVANCNFSM6AAAAAA2OIEYMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[SebastianKusykIFJ]

Which parts of source code are responsible for limit switches? I tried to find it, but I couldn't.

[mar0x]

grbl/limits.c