gnea / grbl

An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino
https://github.com/gnea/grbl/wiki
Other
3.98k stars 1.59k forks source link

Limit switch alarm triggered also when releasing #1222

Open SebastianKusykIFJ opened 11 months ago

SebastianKusykIFJ commented 11 months ago

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 commented 11 months ago

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 https://github.com/gnea/grbl/issues/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 commented 11 months ago

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 commented 11 months ago

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 https://github.com/gnea/grbl/issues/1222#issuecomment-1641741967 , 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 commented 11 months ago

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 commented 11 months ago

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 https://github.com/gnea/grbl/issues/1222#issuecomment-1642100791 , 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 commented 11 months ago

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 < https://github.com/gnea/grbl/issues/1222#issuecomment-1642100791> , 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 https://github.com/gnea/grbl/issues/1222#issuecomment-1642116568, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXBW4KHAJM5FW2QDLYSGVDXQ7QNVANCNFSM6AAAAAA2OIEYMI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

SebastianKusykIFJ commented 11 months ago

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

mar0x commented 11 months ago

grbl/limits.c