[grbl Issue#51] emergency stop in next release

#1 – simen 于 2012-01-27

Something like this? http://dank.bengler.no/-/bulletin/show/622731_mad-professor-control-unit

We tried this with the controls branch which also included an analog input where you could also adjust the overall speed of the job with the potentiometer. It is indeed very useful! The branch is just a couple of hacks, and lice speed adjustment is of course harder now that we have the planner in the loop.

#2 – jgeisler0303 于 2012-01-27

Yepp, easy to reach and hard to miss even if in panic.

The speed pot is already on the wish-list in the wiki. But as you said: that’s one of the more advanced challenges.

#3 – chamnit 于 2012-01-27

Simen, I really digg that button!

I’ve thought a bit about how to implement an e-stop when I had began coding the run-time commands. E-stops should generally be always hardware wired and designed to cut power or immediately disable everything until the e-stop is released. I like the idea of using the limit switch pin in conjunction with the limit pin, since it’s already there, and it would be pulling double duty. If we use a pin for grbl abort, the e-stop should also likely be tied into this as well. We may have to do some minor re-arranging of the abort code to keep abort from looping when engaged.

So I guess the question would be: how do we do the limit switches? and would be provide a simple wiring schematic for users that want to add their own nice big red button? Also, if a limit switch disables the motors, how will we do homing cycles, let alone move the axes so that they disengage the limit switches through grbl commands, rather than physically moving them?

Variable feedrate is going to be doozy, especially with the planner involved. It may take a lot of ingenuity and refactoring to get something real-time working. The easiest thing to do is to force a feed hold, replan with new feed rates, and then resume. Not real-time but a mediocre solution.

#4 – aldenhart 于 2012-01-27

In researching this topic I found that limit switches and homing switches are 2 different things with totally different behaviors, that are often conflated. For example, in some cases (esp on large machines) the homing switches are in the middle of travel, while the limits are at the end. So if you share switches for both functions it’s useful to know when a switch is used for homing and when its used as a limit switch. Also, if you want to use them as limit switches it’s important to be able to support normally closed switches (as well as NO switches) as typically the limits are wired in series in a failsafe loop.

In doing the TinyG stuff my solution was just to put the limit switches into homing mode if a G28 or G30 is received. This changes the branch the interrupts take. I have independent switches for each axis but I’m not sure this is necessary unless you want to do homing on multiple axes simultaneously. Any insights welcome.

#5 – jgeisler0303 于 2012-01-27

A button that is hard wired to interrupt the enable pin of the stepper drivers is the only safe solution. Alden once mentioned the liability that is possibility involved in calling something “emergency stop” that is not hard wired. But limit switches are a problem then.
Therefore I prefer the “interrupt and software disable” solution. Maybe we have to call it “Immediate Halt” button then.
Alternative solution: separate pins, one for limit switches (OR’ed in series?) and one for the e-stop. The e-stop could then physically disable the stepper drivers (and spindle) and notify grbl about its engagement via the pin. An external AND (or NAND, depending on the driver enable logic) gate would be necessary so the button and grbl can individually revoke the enable signal.

#6 – aldenhart 于 2012-01-27

I agree. For anything to be called a Estop it must work completely outside of the firmware. It’s sole job is to stop the machine as fast as possible, and it has to work even if the controller has gone bat-sh*t-crazy. Estop should shut down the motors electrically via a relay of some sort, and may even apply mechanical braking to parts of the system. The firmware can also execute an abort (triggered by the external Estop), although by that point it really doesn’t matter as the motors should be disconnected.

I wrote some of this up here: http://www.synthetos.com/wiki/index.php?title=Projects:TinyG-Gcode-Support
See Starting, Stopping, Feedhold and Rate Overrides

#7 – chamnit 于 2012-01-27

I agree with Alden about the hardware e-stop. There is a liability issue there.

On traditional CNCs, there is a ‘reset’ button that does an immediate halt like you describe Jens. Its purpose is to stop and reset everything without powering down, unlike an e-stop. The system abort that I put in v0.8a does this exact same thing. It halts the motors, forces grbl to exit back to the main.c loop, and then re-initializes the system (without resetting the machine position).

So what we can do is pin out the system abort command (also keep it as a software run-time command), and use this with an e-stop button to tell grbl to reset. Mainly because grbl is powered by a computer USB port and can’t be powered down quickly or easily. Then all we have to do is modify the main loop to not finish re-initializing grbl until the limit/e-stop pin is released.

#8 – jgeisler0303 于 2012-01-27

I would like that hardware-button-reset calling the same routine, the run time command does. It’s like a poor man’s e-stop and, I think, sufficient for many DIYers.

Any streaming gcode coming in after the button is pressed (and possibly released) must be ignored until a clean start (cycle start?) is signalled.

What do you think?

#9 – chamnit 于 2012-01-27

Not really a poor man’s e-stop. The reset button is a real feature that exists on CNC machines. To get a true e-stop, a user only need to add a circuit that also powers down everything else.

There are a few details to work out. One is how to manage various types of resets and figuring out what to block and when after a reset. Right now, upon a reset/abort, grbl will flush the serial and planner buffers, but this doesn’t block any new incoming serial data after the flushing. So do you block all serial data, which cuts off all communication to grbl? How does this play in with limit switches? Should limit switches force a grbl reset too? …. This is starting to make my head spin.

#10 – aldenhart 于 2012-01-27

To stop heads from spinning how about bringing up a wiki page where we record the desired behaviors under various circumstances. Some people might call these requirements

#11 – jgeisler0303 于 2012-01-27

Ok, one last spinner. I was typing while adlen commented.

Anything that triggers a direct stepper disable should be followed by setting the machine position to zero since we might have lost steps and therefore don’t know where we are anyways. I think this goes for reset and limit switches alike.

After that, processing of gcode should only be resume after a special gcode command is received (I used M30). This forces the user to explicitly acknowledge that something special has happened. A run time command wont do because some interface programs might insert the command in the middle of a stream that is still running. In contrast, a gcode command would be properly queued at the end of all ‘lost commands’.

#12 – chamnit 于 2012-01-28

Jens: It’s not all the time that one would lose steps. If a user issues a feed hold before a reset, the machine location would still be correct. This is especially useful when you realize that the g-code program has a mistake and you don’t want to re-find or have machined away your part zero location. You should be able to go back to part zero, fix your program, and restart it. I suppose we could only reset the machine position if the machine was moving prior to reset or hits a limit switch, otherwise retain it for situations that we know are correct.

Also, using M30 in the non-standard manner is probably not a good idea. It’s basically a legacy program end when tapes were still used and rewound at the end of a program. On today’s CNCs, this just brings you back to the start of the program, which doesn’t apply to grbl, since we stream everthing. I had first thought of implementing a reset string that required a ‘y\n’ response to acknowledge that the user understood that position may be lost and all serial streaming should have stopped. I think this was more confusing than helpful, so I didn’t do it.

On the other hand, should we just let the user handle all of this on their own? What I mean is that it’s very easy to get carried away and keep adding and adding things that may or may not be needed. At this point, it begins to diverge from Simen’s original vision of providing a very simple, portable, hackable CNC software, which I’m a firm supporter of. I’d really like to come up with a good simple solution that follows this vision, even if it takes longer than it should. I’m going to mull on this for a while and see if there is something simple that we can do that can accomodate everyone and grbl.

Alden: Great idea on starting up a requirements list. It would definitely be easier to view and understand everything this way. Are you going to start one or shall I?

#13 – chamnit 于 2012-01-28

This morning I thought up of a possible solution:
– First there are a set of system flags that state what grbl is doing at the time: feed hold, cycle start(running), abort, idle. Others that will need to be included are: jogging, homing, and limit/e-stop switch. These system flags will always be set by each process to let grbl know what it’s doing. So, with these system flags, we can have a good idea of when it’s safe to keep machine position or automatically reset it. Like Jens’ idea, we could use the automatic position reset as a way to enforce re-locating home/part position.
– The only times we can guarantee that the position is not lost is when the machine is not moving or in ‘idle’ mode. So, if any other of the system state flags are enabled (running, jogging, feed hold, etc.) when an abort/reset is issued via run-time command, e-stop, or limit switch, we automatically reset the machine position. Note that the feed hold flag is released when the machine comes to a complete stop.
– Also, just for good measure, we can supply a report for the last known machine position to the user when an abort is executed, and note there that it may or may not be correct. It would be useful for the user to have to get back to the approximate location. As a default, should this be part of the welcome banner? So when a user first connects, it would tell them machine zero is at [0,0,0], like so.

Grbl 0.8a
MPos:[0.0,0.0,0.0]
'$' to dump current settings

What do you all think?

#14 – aldenhart 于 2012-01-28

Interesting idea. I’m not sure you need flags, if these are mutually exclusive it could just be a state variable enumeration – much easier to deal with. I’ve been using the following state enumerations: “reset”, “run”, “stop”, “hold”, and “homing”. “resume” is also used as a transient state for coming back up to speed after a hold. “jogging” could be added.

I’d be happy to start a requirements page for starts and stops, but I expect a lot of editing for all you guys, too! I’d probably just port in a lot of what I have on the TinyG wiki as a starting point for modification.

#15 – gregrebholz 于 2012-01-30

Hey guys, I’m excited to hear about estop/limit support coming down the line. I’ve been hopelessly distracted these past 6 months, but I’m still very interested in the future and direction of grbl, and I hope I can contribute at some point. I just wanted to throw out my red mushroom estop button, which has both a NO and an NC side (a common feature in these mushroom buttons) — http://www.amazon.com/gp/product/B004U4911Q/ref=oho06s01i00details The idea is that NC carries power to the steppers, and the NO side grounds a signal pin to the controller to notify it of the e-stop. Depressing the button cuts stepper power and grounds a pin for the arduino. This would obviously lose steps, but does accomplish the “hardwired” way of doing an emergency stop. I suppose one additional pole for the spindle power would be even better, but I was planning on using a relay to interrupt it when estop is depressed.

#16 – chamnit 于 2012-02-01

gregrebholz: Thanks for the info! That’s good to know.

After talking with my friend machinist mike and reviewing what EMC2 and Mach3 do, we should definitely force a homing cycle after both an e-stop and hitting a limit switch (called a hard limit). All positioning should be reset and lost. Grbl will stay frozen until the limit/e-stop pin is released, where then it will go back to the initialization prompt. I think it’ll be the least confusing and easy to implement if we let the users handle how the limit switch gets release, either by handle jogging manually or something else. This should be relatively easy to do, I would think.

So, this leaves the question how do we now handle the homing cycle if the limit switches are used for it? Do we make the homing cycle completely independent of the rest of the system and let it do it’s thing?

#17 – aldenhart 于 2012-02-01

I think you treat them as completely independent operations that just happen to use the same switches (or not). If the machine shares switches (as most will), then the switches become homing switches when a G28 or G30 is issued. They remain in that mode until the homing operation is complete, then they revert to being limits again.

#18 – jgeisler0303 于 2012-02-01

I agree with Alden. The limit switch interrupt should distinguish whether it was triggered intentionally by the homing operation or by accident.

In homing mode the motion is stopped and the homing function is notified to clear the switch and set the corresponding axis position to zero. In hard limit mode the behaviour is identical to an e-stop. Although I would still like the option to automatically clear a hard limit violation.

btw imho: Contrary to the way it is implemented right now, the homing function should use ordinary (very long) buffered moves to drive the machine into the limits. This way, homing can run at max speed.

#19 – aldenhart 于 2012-02-01

FWIW here are the homing behaviors I’ve been implementing in TinyG. This spec might change as I finish this up. Check out the G30 for homing switch use. http://www.synthetos.com/wiki/index.php?title=Projects:TinyG-Homing

#20 – chamnit 于 2012-02-01

Keeping the homing as a separate operation sounds like a good idea. I think it would really complicate things to put it into the planner/buffer system. This would also help people write their own homing routines as needed, since we can’t really say that one way of homing is the right way for each different machine.

I was thinking that since homing is very much like jogging in that we are only moving one axis at a time. We have all the information we need to compute our own acceleration limits and rapids feedrates in settings. We can gaurantee max speed throughout. It might be a good idea to just combine some of the motion code of jogging and homing together.

Jens: For automatically clearing a hard limit violation, I can’t think of a really simple way to handle this upon a hard limit tripping. I’d like to do something like this, but it may just easier not to and let a user hit the grbl reset/abort and only allow a homing cycle (which re-configures the limit switches) to move the axes.

Secondly, suppose we have two pins that we want to use: grbl abort/reset (same as the runtime command) and the limit/e-stop pin. The issue is how do each of these pins work together when an e-stop is hit, hard limit is hit, during a homing cycle, and most importantly, during a homing cycle AND an e-stop. Should we mandate that an e-stop should always be connected to both the limit and grbl abort pins?

#21 – aldenhart 于 2012-02-01

I have been integrating homing into the planner as I think it’s important need to ensure that no steps are lost in the process and I need the decelerations to work well. I’ve been issuing incremental-mode (G91) commands to the planner to do this. This speaks to a more general “canned cycle” capability for doing homing, probes, and possibly drilling cycles, as well as a way to handle jogging. I’ve been using homing cycles as a way to rough this in.

#22 – chamnit 于 2012-02-01

I disagree. I had played with integrating homing and jogging into the planner and stepper module, but it made the stepper module bloated and unwieldily.

Both homing and jogging are special motion cases, where they don’t need to use a planner. (Jogging by a toggling on/off or rotary dial, not explicit moves that g01 can do.) The same can be said for probing. The big thing is that for homing and probing, you have to make an abrupt and immediate stop when a limit is hit. You lose steps when this happens. For homing this is not a big deal, since you are locating zero anyway, but probing may need some special handling to avoid losing steps.

With other canned cycles like drilling, using the planner is fine, since it is all part of the planned motions.

#23 – aldenhart 于 2012-02-01

OK, OK, want to step outside — Where is “outside” anyway?

Here’s why and how I used the planner for homing. I could easily be wrong about this, but here’s the logic. It may not matter if you lose steps when you jam into the switches on the initial, high speed search, but I do think you want a repeatable latch phase so you have as controlled a halt as you can get – so I like having a clean decel at this point. It may be that to accomplish this you need a different and much faster acceleration (deceleration) profile for homing than for normal operation, but I think you want a repeatable profile in any case.

As for bloating the planner – I believe all you have to do is take advantage of what’s already there, not add anything new. You issue a move then you force a feedhold (albeit a fast decel feedhold) when the switch is hit. Then you reset coordinates, clear the planner, and start fresh. The planner itself doesn’t need to change.

Do you think this makes sense – or is it overkill or perhaps otherwise faulty logic?

#24 – chamnit 于 2012-02-02

My understanding of the saying “want to step outside” is to go out and brawl or get a breath of fresh air. I’m guessing it’s not the latter. Let’s be civil here. We’re all here volunteering our free time to work on this project.

As for the discussion, there are many ways of doing this. Yours may be the right way to go. The same with the idea of separating everything. Another is to use the planner at all. Instead having the homing, jogging, and probing routines write explicit blocks into the buffer is very short segments. It would then be possible to access and use the stepper module with minimal changes and hits to efficiency and readability. Something along the lines of v0.6 when acceleration planning was turned off.

Which is the right one for grbl and its focus on simplicity and hackability? Hard to say until I can review what’s needed for each one.

#25 – aldenhart 于 2012-02-02

It’s just my lame attempt at humor. Sorry if it was misguided in any way. I appreciate that we are all doing this as spare time and I truly enjoy the back and forth.

I agree that it’s hard to know what the right implementation approach is until you try a few things. If you can leverage the planner it might be easiest. If it complicates the planner it’s probably not worth it.

#26 – chamnit 于 2012-02-02

No problem. Sarcasm doesn’t translate well through text anyhow.

Jens: You stated that you were going to look into porting out the limit/e-stop pins into grbl v0.8. Is the offer still available? I’d like to see how you configure the pins and get them to trigger. We can probably just integrate this directly into v0.8 as an immediate stop for now and work in the other details later. It would need to play nicely with the current homing cycle though.

#27 – 1bigpig 于 2012-02-08

Hello. I have a few suggestions, and I don’t know if this is the right “place” to ask/say them. First off, a little about my machine. I am retrofit a small CNC router that started life use a DOS controllers and a proprietary controller. I have since change the control box to some off the shelf stepper drivers and using Mach3 as the control. That works great but it is now getting harder to find a computer/laptop that will run Mach3 AND has a parallel port. So, I am trying to use grbl as a parallel port replacement. What I am wanting to control is a spindle, 3 homing switches and 3 axis of motion with my Arduino.

Like Simon’s original plan of a simple G-Code interpreter without a lot of fancy features, I want grbl to take output from Vectric’s Aspire without too much intervention on my part. Where I DO see user intervention is with getting the toolbit to the start of the cutting job position. I am working on getting the existing homing routines in grbl working on my machine. They are starting to work, but I think we need to implement a debounce feature and I am not sure the best way with the way those routines are written right now.

Now a couple of observations after reading this thread. Most hobby machines that grbl will be controller are not large machines. I don’t think that grbl need a special E-stop that powers down stepper drivers. IF you are in a run away situation, most every Arduino board I have seen has a RESET switch that becomes a VERY effective E-Stop. Also, stepper motor systems are not prone to run-away situations. DC Servo systems are, but grbl is not a real candidate to drive such systems, as it is not really capable of high pulse rates.

I also don’t know of many small 3 axis machines that actually have a reversable spindle. I imagine that most of these machines with be running some type of Dremel or A/C router as a spindle and will those motors will only go one way.

Second, I saw another “issue” about using hand controllers and needing extra pins to implement jogging. I am probably wrong here, but why not just create a special G-code that starts a user selectable axis in a user selected direction and goes until the serial port recieves any data. Say “G100 X25 F50” This command would start the X axis moving in the positive direction at the commanded feedrate of F50 until ANY data comes in on the serial port. If no data is received on the serial port by the time X=25, then the machine stops on it own. This would work for -25 as well, moving the axis in a decreasing direction until data is recieved on the serial port or the position is aquired. This would implement the JOG functions in software and make it so you could still do easy setup/jogging from a terminal program OR a dedicated G-Code drip feeding program. The upside is that if you did a dedicated control program, you could issue the jog command on the KEYDOWN command and interrupt the movement on the corresponding KEYUP command.

Lastly, (for now) I would LOVE to see XON/XOFF implemented, as I could then use ANY terminal program to drip feed the controller G-codes. BTW, I am not really excited to see that the serial buffer size is being decreased. My router runs about 1500mm/m, and I am worried about data starvation.

Bruce

#28 – jgeisler0303 于 2012-02-08

Hi, and thanks for the input.

Regarding the debouncing, may I suggest you use an RC filter. That is much simpler “to implement” than hardware debouncing.

You are probably right about the machine that grbl is used to control. But then again, some hobbyists go further than others. Just checkout the amazing DIY CNC machines on youtube.

Since many small machines don’t have wheels for manually moving the axis I personally like the idea of having hardware buttons on the machine for jogging. I think we also resolved the “shortage of pins” issue.

XON/XOFF will probably come in the next release as an eeprom-able option. Buffer length will then no longer be a problem.

#29 – simen 于 2012-02-08

Very interesting. The end stop code in Grbl right now is still just
something I threw together for the Lasersaurus-people to complete. My
machine have no end stops and I am not planning to add any. My experience
is that unattended milling is rarely possible as so much can go wrong, and
also using my powerstrip as an emergency stop works just fine. It powers
down everything. Of course Grbl loses track of position, but at that point
the job is probably botched anyway.

On Wed, Feb 8, 2012 at 11:01 AM, Jens Geisler < reply@reply.github.com

> wrote:
>
> Hi, and thanks for the input.
>
> Regarding the debouncing, may I suggest you use an RC filter. That is much
> simpler “to implement” than hardware debouncing.
>
> You are probably right about the machine that grbl is used to control. But
> then again, some hobbyists go further than others. Just checkout the
> amazing DIY CNC machines on youtube.
>
> Since many small machines don’t have wheels for manually moving the axis I
> personally like the idea of having hardware buttons on the machine for
> jogging. I think we also resolved the “shortage of pins” issue.
>
> XON/XOFF will probably come in the next release as an eeprom-able option.
> Buffer length will then no longer be a problem.
>
> —
>
> Reply to this email directly or view it on GitHub:
> https://github.com/grbl/grbl/issues/51#issuecomment-3865195

#30 – aldenhart 于 2012-02-08

I’ve used the power strip once or twice myself Perhaps that’s where the big red button should go.

Debouncing isn’t much of an issue for limits, but for homing it can be. I use the RTC to provide a 100 ms (approx) exclusion region on a switch closure so that no other closures are read. I wanted switch closure to be detected as early as possible and the possibility of spurious closures is minimal. An integrator scheme – either in hardware or in software delays the onset of closure and that’s not good when you are jamming into a switch.