[grbl Issue#1017] Limit switches and homing

#1 – jahnj0584 于 2016-06-13

you have to recompile GRBL so that the homing switch is in the other direction.

#2 – chamnit 于 2016-06-13

@vlachoudis : To address the moving off a hard limit issue, I’m going to introduce a $X=line command that will allow you to bypass all of the safety protocols to be able to move during an alarm or hard limit.

With having two switches on each end of an axis, Grbl has no way to know which way to go or which limit switch has been triggered, since it uses one pin for each axis. For a quick fix, you can enable a special compile-time option to prevent Grbl from starting the homing cycle if it detects any limit switch is engaged. I think it’s called HOMINGTWOSWITCHESONAXIS or something similar.

#3 – vlachoudis 于 2016-06-14

Thanks @chamnit. My problem is how to retract the gantry when the switch is enabled.
I like the $X=line to permit a motion command ignoring temporarily the limit switch.

Otherwise my above hardware solution is working great, however it requires a modification on the homing algorithm.

#4 – chamnit 于 2016-06-14

@vlachoudis : Not sure why a version change would be any different, as the hard limit code hasn’t changed significantly in a long time. One of the reasons why hard limits are so annoying to users is because Grbl will throw a hard limit alarm whenever it detects a pin change. This includes releasing the limit switch, as well as, if there is noise when the switch is in-between. So, users will usually have two or more hard limit errors, unlock, and try to move sequences before they can get off the limit switch, if they are lucky. Hence, the reason for the introduction of the $X=line command.

Let me ask you this. What does Grbl report back when you can’t move off the limit switch? Does it keep throwing a hard limit error, or does it just not do anything (and what’s Grbl state)? There shouldn’t be anything in the code that would prevent you from moving other than the alarm.

#5 – vlachoudis 于 2016-06-14

Before some upgrade (I don’t know when I don’t run on the limit switches often) when a limit switched was pressed, I could reset + unlock and send send a g0 command, which was moving by a fraction of a mm. After 2-3 times I was able to move the gantry off the limit switch. After some grbl upgrade, now I hear only a clacking noise from the stepper, which tries to move (or the enable) and then it stops immediately. Last time I was unable to move it back, so I was forced to disable the hard limits.

The same problem appeared also on the probe sequence. I have in bCNC a Center ring probing finder which probes first in +X until it hits the ring and then immediately it was issuing a probe in -X direction. In the past after the +X probe it was correctly moving and detecting the -X border. Now I had to add first a g0 with a small step in -X and then send the probe command. https://github.com/vlachoudis/bCNC/issues/356

I am not proposing to go back to the past behavior, I find the new behavior more correct, so I will simply wait for the $X=line implementation

#6 – chamnit 于 2016-06-14

@vlachoudis : Ok thanks. The probe issue is not related. This was the result of updating the g-code parser to check for initial probe state before executing a new probe command. There was indeed a period of time that Grbl allowed the probe to be triggered and a new probe command to be valid.

I’ll consider this matter closed since there is a pending solution.

#7 – vlachoudis 于 2016-06-15

After thinking of it, I will modify my shield to send the home switch as is to grbl while the opposite end-switch to make the logic operation with the direction of the command. This way homing will work also in the case that the opposite switch is triggered.