anybody tested limit switches? about grbl HOT 8 CLOSED

As far as I understand, the limit switches aren't fully integrated into grbl. It mostly serves for establishing the home position of the machine. I could be wrong, but this is something that need to be updated and further developed in the edge version.

from grbl.

I have commited some code in my branch related to homing.
I have used motion control subsystem for axis movement and a stepping callback mechanism that I've introduced with g38 - touch probe; You can set a callback that is called after each step ; this callback can take the decision to forcefully complete the current block or to inhibit movement on one or more axis; in this way, for touch probe and limit switched we can stop moving on an axis when limit switches for that axis have been tripped. The overhead for the stepping interupt is minimal for G-Codes other then G38 and G28/30 as this callback is set and cleared only for G38 and G28/30 ;

from grbl.

That's definitely a possiblity. Now that I think about it, the main issue is how to handle the high probability of loss of location after a limit switch or touch probe is tripped. This stems from the fact that steppers have no positional feedback. So if a user is running at a high feedrate, hits a limit switch, the steppers will come to an immediate stop and will likely skip a lot of steps due to the high inertial forces in the motor rotor, leadscrews, and table/head.

I think once a limit switch is hit, the next step would be to force a grbl user to re-home and relocate the machine. Otherwise, this could lead to a lot of questions and frustrations from users down the line. With the touch probe, I think that this would need to be a controlled probing routine, much along the lines of the homing cycle. Not sure, there is still much to think about this and it's not high up on the priority list at least for me.

from grbl.

Should those limit-switches stop the stepper-motors by hardware? At least on my mill it looks like the software must stop the steppers when a switch is hit.
So I successfully destroyed one switch as I entered some wrong G-commands into grbl.
Correct me if I am wrong.

from grbl.

I don't think it matters how its done by hardware or software. With
hardware, you could simply wire up the limit switches directly to the
enable pin of your stepper drivers so that it disables them when
tripped. In software, there's a few implementation considerations but
relatively easy to do. It would also keep the machine and software
synchronized.

On Jan 25, 2012, at 12:14 PM, cody82
[email protected]
wrote:

Should those limit-switches stop the stepper-motors by hardware? At least on my mill it looks like the software must stop the steppers when a switch is hit.
So I successfully destroyed one switch as I entered some wrong G-commands into grbl.
Correct me if I am wrong.

---

Reply to this email directly or view it on GitHub:
#49 (comment)

from grbl.

To make limit switches a real emergency stop, they must physically wired to disable the stepper drivers. But there's a problem with clearing the tripped limit switch then. For me (in branch) software disabling the stepper drivers works fine (and protects my glued on lead screws). I use pin interrupts for the limit switches to get the fastest response possible! Also, I force the user to reset the machine using command "M30" (any other would do). Any other gcode that is sent after the switch tripped is ignored and the machine position is set to 0/0/0. So, homing after the reset is encouraged. Like chamnit, in my view the tripping of a limit switch in an accident and resuming the operation as is nothing had happened is no option, also because of the steps that are probably lost.

from grbl.

I am just getting started with grbl in a conversion of a small mill to CNC.

If I might toss a couple of comments into the conversation...

I would think that the emergency stop button should be just that, an emergency stop. This means that it must halt all motion immediately. To me this means that it absolutely must not depend upon computer control. I would wire the emergency stop button to disconnect all power to the steppers and spindle.

If the emergency stop button is pressed in this situation, the machine will stop, but all position data that grbl has will be useless. Without power to the steppers all that remains is the detent torque and this might not be sufficient to hold the axes in place.

As such, if the emergency stop is pressed, you are effectively done with this particular program run. There is no point in allowing any sort of program continuation without re-establishing your origin, etc.

I would view hard limit switches as emergency stops. If you hit these, you want everything to stop before you damage something. Again, you are done with this particular run.

It would be a good idea to be able to tell grbl that the emergency stop has been tripped so that it can stop trying to send commands to the steppers and perhaps indicate to the program feeding it commands that there was a problem.

A home switch might not be particularly useful as usually the origin for the part is not at the home switch location.

Perhaps what we need is a non-emergency stop input.

When asserted, a non-emergency stop would decelerate all motion to a halt and stop the spindle. When cleared, the spindle would restart and processing would continue with the next command in the buffer. Since this would not drop power to the steppers, the holding torque would remain and the position of the axes should remain valid.

This would allow for pausing operation to clear chips or inspect the part and if coupled to a "soft limit switch" would allow for gracefully stopping the program before reaching the hard limit switches.

This could also be used with a load monitor to stop a program if something were amiss (to high a feed rate about to cause skipped steps, etc).

It strikes me that we would also need the ability to clear the remaining commands in the buffer and/or insert new commands at the top of the buffer (such as a change in feed rate). That would allow us to correct for an overload condition or to issue manual commands after a soft stop to reposition the axes without losing position information e.g. the origin is still valid.

Now that I think about it, there really isn't any difference to grbl between an emergency and non-emergency stop. Either way, grbl stops sending stepper commands and stops the spindle. It would be up to the operator to decide if after clearing the emergency stop they can resume the program or if they need to clear the buffer and start over.

from grbl.

We are agreed on all points and have already discussed this in the emergency stop thread. We will be implementing a hard limit/e-stop pin which will kill everything and prevent grbl from initializing until released. All position information will be lost in this case. It's up to the user to wired everything right. Soft limits is up for discussion and could be maintained in memory from workspace volume settings from a consistent home position, or done as you say with another pin. This would initiate a feed hold and do a grbl reset without losing positioning.

Serial port buffer will be blocked until the initialization is finished and everything is good. It's up to the user to stop sending g-code to grbl. We will be keeping track of the state of grbl and if it's safe to retain positioning data upon a reset. So generally when grbl is not moving, positioning will be retained.

from grbl.