emergency stop in next release about grbl

[simen]

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.

[jgeisler0303]

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.

[chamnit]

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.

[aldenhart]

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.

[jgeisler0303]

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.

[aldenhart]

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

[chamnit]

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.

[jgeisler0303]

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?

[chamnit]

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.

[aldenhart]

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 :)

[jgeisler0303]

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'.

[chamnit]

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?

[chamnit]

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?

[aldenhart]

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.

[gregrebholz]

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=oh_o06_s01_i00_details 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.

[chamnit]

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?

[aldenhart]

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.

[jgeisler0303]

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.

[aldenhart]

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

[chamnit]

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?

[aldenhart]

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.

[chamnit]

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.

[aldenhart]

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?

[chamnit]

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.

[aldenhart]

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.

[chamnit]

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.

[1bigpig]

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

[jgeisler0303]

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.

[simen]

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 <
[email protected]

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:
#51 (comment)

[aldenhart]

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.

[chamnit]

Hi Bruce. Very interesing comments. Lots to think about.

I've used the physical reset button on my Arduino as an e-stop, but found it hard to hit at times. Although I had forgotten that there is a RESET pin on the Arduino and that could be explicitly used as the e-stop pin for users to wire their e-stop buttons into. This would be a great and simple solution to this "issue". I'd like to see what you all have to say about this: Mandate the Arduino reset pin is to be used for e-stop buttons. Place a simple wiring schematic example in the wiki. Keep the limit switch pin for homing and managing hard limit stops.

As for your comment about the need for the e-stop, for the most part you might be right that all users may not need an e-stop, but I do. I have a Sherline benchtop mill and would rather not crash the tool into the XY base or dovetails. The idea here is have the minimal functionality of a full CNC system without too many comprimises.

As Simen stated, the homing and limits routines are ad hoc and are in need of some TLC. It's pretty far down the list of priorities right now to come up with a general solution. Although grbl's source is designed to let users easily write their own.

True that a reversible spindle may not exist on most hobby machines, but grbl or its code has been used on many non-standard machines like a tensioned line hanging painter, water jets, laser cutters, 3d printers, etc. Although there may not be use for it directly on a mill, there could be elsewhere. It's easy to implement and there really isn't a major reason not to.

Jogging is something that really needs to be discussed on how to implement it before it's done. I like your idea of using the g-code parser to interpret the axis enabled and feed rate. To simulate it, many users have just sent grbl short G0/G1 commands. Works but not a great solution as timing it can be a chore on different machines. I'm in the camp of using a pin for toggling movement on and off and using the parser to interpret the feed rate and axis to move.

The serial buffer size on a standard Arduino is 128 bytes. It's being reduced back to 128bytes (from 256) mainly to free up some memory space and keep the planner buffer size as large as possible. I personally have not run into buffer starvation at those speeds using a curve heavy g-code test ( I have heard it runs up to 10000mm/min, but not verified. ) Also, there are two effective buffer layers in grbl, the planner and serial read. It should have no problems if the interface is able to take full advantage of them. Even if this would be a problem, grbl is written to be hackable and re-configurable. Increasing the serial buffer is very easy to do.

Also, if Arduino speed is an issue, there are ARM-based solutions that use grbl's codebase or have been porting it. At some point, I'd like to see grbl start using faster and more capable controllers (like the Arduino Due), but the standard Arduino is a great platform to introduce hobbyists to CNCing without the fear of too much investment. This is the main reason that I'm working on this project.

[gregrebholz]

I'm fine with using the reset pin for estop on my machine as well. The problem I had with power-strip estop was that the 24V power supply feeding my grbl-shield had enough capacitance to keep the steppers running a disturbingly long time. By physically interrupting the 24V DC I resolved that issue. Grounding a reset pin on the Arduino would be fine too. We just need to make the g-code streamer has stopped sending commands when the reset pin is released and the grbl code boots up. One benefit of a true abort pin is that the code can handle it by communicating back to the client, or refusing non-homing g-code commands, etc.

I've been jogging manually with G0/G1 but dreaming of a day when I have PS3-controller-esque control over the axes for quick positioning. I'll leave it to others to decide on implementation, but I'd be happy to see some analog read pins used for "pressure sensitive" feedrate control. I'll live without it too though.

This whole project got me into my first CNC mill. Huge thanks to Simen, Sonny, Jens and Alden for their contributions so far!

[1bigpig]

Thank you everyone for taking the time to respond to my inital post. Here is what I am thinking...

jgeisler0303: I know that I can do it in hardware, but I really want to keep my interface simple. Right now it is just a 25pin D-connector directly soldered to my Uno board. I know that software debounce can be done and I have been thinking about how I can implement it in the current framework. I'm gonna try it...

Simen: First off, sorry for calling to Simon... While I agree that a hardware reset will blotch the job, if something less disastrous happens (toolbit breaks or machine hits a clamp), a simple homing routine from a know position and then a jog back to the starting coordinates will at least give you a chance to start over and try to salvage the work. Also, I sorta assumed that someone had actually tried the homing routines. I had to do extensive surgery to make them work and they are still not there, but it does help knowing that the code was not even verified. I am gonna spend some time on it...

adlenhart: I disagree about using software to do the debounce. Since the homing routines have complete control over axis movement, I am thinking that if I detect a possible switch closure, I can slow down the axis (or even wait a specified time) without the machine moving until I am satified that the contact was really closed. Anyways, I am going to try to prove my suppositions with some actual code/testing. I will report back on my finding.

chamnit: While I realize that homing is a low priority, to me it is pretty important. As for removing the spindle direction pin, well, I have an alternative movtive for that. What I would like to do is use a 4th pin for a tool touch pin. Also known as a Z Zero plate. They are so awesome that once you use one, you will never ever want to go back to using paper or "eye-cromiter" to know when the tool bit is touching the work. This would work EXACTLY like the Z axis homing routine, except it would use a different pin and the opposite Z direction. This does lead to a request to have another eeprom variable stored, which would be tool touch plate thickness. If you are not familar with this technique or what I am ranting and raving about, I will be happy to provide links and videos of the process.

I also figured out a way to do the automatic jogging feature I mentioned in my last post using the existing framework, BUT it needs one more override command. Your current CMD_FEED_HOLD will stop the motion of current movement. The only thing lacking is a CMD_CYCLE_STOP. I guess I could use the CMD_RESET, but I think reseting everything is too drastic...

gregrebholz: I think that once the XON/XOFF is implemented, it would be very easy for the first character out of grbl is a XOFF command. This would effectively stop the incoming data stream after a reset. I don't think a separate pin is needed but that is just my opinion.

I would like to suggestion some changes in the way homing routine is called. I think that this will involve a code change to quite a few of the C code files. I am also pretty confident that a generic homing routine will cover about 95% of machines out there--at least 3 axis router/mill type machines. I guess this should be moved to another "Issues" thread.

I am willing to work on the homing part of grbl, but I have to be 100% honest. C is not my first language. Still, I can and have programmed in it. I just don't know if it will be up to Simen's standards. On the upside, I will comment liberally so readers will at least understand WHAT I am trying to do or WHY...

So, do I create another branch or should I submit those code changes to someone? I am not familar with Github and the interworking of code repositories in general...

Bruce

[chamnit]

Bruce: That's not a problem if you're not fluent with C. The hardest part of programming is getting the thoughts organized and the order of operations down. I've been working at getting the other things that would make homing truly possible or useful, like the distinction between machine coordinates and work coordinates (G54+). There are other things like settings and storing variables such as offsets into eeprom memory and real-time status and location reports, along with the things discussed here. If you'd like to start on getting a homing routine worked out, you can fork the grbl repository and hack the code at will. When you feel like it's at a point to submit to the main repo, we can merge it and work out of the details then. I know that this is something that is really needed at some point, but there are bigger fish to fry, so to speak.

A z-zero plate would be awesome to support at some point. I know what you mean by offsetting the tool z-position can get to be a chore, but not impossible.

I'm unsure what you mean by a CYCLE_STOP and what the funtionality of this would be. The reset command re-initializes grbl, retaining both machine position and the work coordinate offsets(available in the next push). It clears the planner buffer of any leftover blocks and wipes the serial buffer of anything lingering in there. It resets all of the g-code modes back to it's defaults and starts clean. Other than the positioning data, I can't see what else there would be needed.

[aldenhart]

To put a slightly finer point on it - the homing routines have complete control over the software of axis movement - physics has control of the actual axis movement. They don't stop instantaneously. What debouncing needs to do is (1) detect switch closure as soon as possible - so as to put the least mechanical stress on the switches when hit, and (2) not fire more than once when the switch is hit. Spurious closures before the machine reaches it's limit are not really an issue.

There are a number of ways to accomplish this - my suggestion is just one way. I'm interested to see what you come up with. Thanks for joining in.

[1bigpig]

aldenhart: Yes, technically, you correct. Physics has control of the overshoot, but at the slow speeds that we are talking about (~350mm/m or slower) and that a majority of these machines will probably be under 50kg, I don't really see inertia as a major factor.

As for noise, I am not sure exactly what I am seeing on my machine. It homes perfectly with Mach3, but I am getting a very intermittent closure signal from my Y axis. The X and Z axis home just fine. So, I don't know if I am getting noise, or somehow the limit pin on the Atmel is going low because some logic coding error... That IS why I am planning on adding the debounce routine, so I can eliminate the noise issue.

Bruce

[1bigpig]

chamnit: More to come, but the reason for the extra CMD_CYCLE_STOP is this. Say, I have set my machine up for a particular job. I have homed the machine, set up the absolute mode (G90) and say I am running this part in inches (G20). Now, I want to jog the machine so the toolbit is at the work piece 0,0. Unfortunately, I am a horrible typist and I enter G0X2000 instead of G0X200. Now, this machine only has about 400mm of X travel. So, I hit the '!' key and the machine comes to a controlled stop. Now, what do I do? My only option is to control-x (a full reset) or a hard reset (Arduino reset switch). Either one of these options will result in my loss of all previous states (absolute, inches, ect).

What I am hoping for is something that will not reset the entire controller, but just the last command: CMD_CYCLE_STOP. The machine will no longer try to resume that long jog.

I hope this makes it clear what I am after. Sorry if I got too wordy in my description...

Bruce

[chamnit]

Ok you do make a good point about the g-code modes being also retained. Something like this won't be hard to do. Let me talk with my machinist friend about this. I think this functionality is along the lines of the 'Cancel' feature on production CNC machines. I may have overlooked this when I doing a machine survey.

If this is going to be done, I'll tag it for the following push, not this next one before the end of this week.

[chamnit]

My friend and I looked at our Haas machines and talked in length about this. In general, there really isn't a CYCLE_STOP function. Only a reset, but the reset can function in two ways, retaining the g-code modes or resetting them back to defaults. To not reset the g-code modes back to defaults can be dangerous, especially G90/G91, and result in bad crashes. In practice, g-code modes should always be reset to prevent these problems.

The only thing I can say that would need to be retained is G20/G21 inch and mm modes. This can be placed in eeprom memory and reloaded upon a reset.

I can see how having a CYCLE_STOP command would help you with your implementation of jogging, but I think there are other way to do this without needing this command. How to do this, along with settings, is something that needs to be discussed and figured out.

[1bigpig]

I guess maybe a CMD_CYCLE_ABORT would be a better name instead of STOP. I know that programs like Mach3 have 2 type of stops. One is the emergency stop (the red mushroom button) that you use in a panic and the other is a STOP button or abort command. Used in a machine when you break a tool bit or other non-critical situations. This is what I am asking for. I don't think that the goal of grbl was to replicate a complete Haas or other machine tool controller. I think that if we try to do too many things, the configuration setup for grbl will start to look like the Mach3 configuration page (needless to say, that is MANY pages of options and pin configurations).

I am making some progress on the homing routines. There was some basic logical flaws in the original routines, such as all axis should move in the negative direction) that I am working on. Also, depends on how your limit switches work, the limit switch pins need to be pulled high so that a limit switch closure pulls them low. That and I am trying to track down WHY my Y axis limit switch only stays high for a few seconds and then reads closed (even though the switch is not closed)...

I would also like to support some type of ABORT routine. Right now, I am forced to E-stop/reset if one axis moves in the wrong direction ect.

Hopefully, I will have something to share before too long...

Bruce

[chamnit]

Understood. The configuration issues with both Mach3 and EMC2 are definitely trying to be avoid here. Simple is king.

I guess I'm not understanding what exactly you'd like for the ABORT routine, as it already exists in v0.8 edge by striking the 'Crtl-X' keystroke. Are you asking for a little different output, so that it doesn't display the welcome statement? Do you want the current g-code states to be retained when you hit ABORT (this could be done easily soon)? The grbl reset/abort command is suppose to represent your Mach3 abort button, not the e-stop. E-stop should be handled by the Arduino reset pin, as this discussion has progressed to.

I completely agree that we don't have to replicate a complete Haas production machine, but I think it would be a good idea to make them very similar, albeit stripped down. This will make it easier for newly adopted experienced users to easily familiarize themselves with grbl and current grbl users to easily use other machines.

[scottrcarlson]

Hello All!

I'd like to pitch a solution. It would add 3 additional DO (along side the 3 for limits).

E-Stop Button -- Wired in parallel with step driver enable and grbl, that way e-stop does the right thing and notify's the controller which would no longer trust the current known position. Until I pull the E-stop back out, nothing happens. No firmware involved. I think the user is totally responsible for what happens after that reset e-stop. Other than a flag notifying user that the machine doesn't trust its current position.

I propose a hard limit with an over-ride relay in series (on the way to step driver enable)

Hard Stop -- Limit Switch wired in parallel with step driver enabled and grbl. In my opinion, I don't want to know why the machine is about to slam into the frame, I just want it to stop and ask questions later :)

Hard Stop Override -- I don't have the option of manually moving the axis. I have to return control back to the system to move away from the limit switch. So I propose a relay between the limit switches and step driver enable. The relay is a limit override. The system can recognize where it is, and override the limit to move,home,jog away. This also takes care of the homing sequence -- Send off in a direction, hard limit + step disabled, turn on override, go home, turn off override.

Scott

[jgeisler0303]

I think the hard wired e-stop with notification input is the way to go. But I didn't really understand your proposed wiring. The e-stop button would have to be connected to the stepper enable and a grbl input. If the driver enable is active low then it should have a pull-up, grbl pulls it low for activation and the e-stop button breaks the connection for deactivation. The notification input is wired directly to the enable pins. Could that work?
What if a user doesn't want to use the e-stop notification? Then the input should be in a defined state to always notify "no e-stop", so grbl can run in a minimal configuration out of the box.

My machine doesn't have manual jog wheels either and I did think about the override relays for hard limits as well and like the idea very much. But on the other hand I do trust grbl enough that I could go with soft limits. The question here again is: how can we make grbl run out of the box in minimal configuration and still enable more functionality for more advanced users/hardware setups? Maybe we should start to think about a compile time configuration scheme. Well thought out, well implemented, flexible and expendable modifications are always welcome.

[scottrcarlson]

JGeisler --

I agree with using soft limits primarily, although personally, I would like to have the hard stops there "just in case". Especially during the coding/testing phase? If the limit switches are normally closed, then the user could have the option of wiring a pull-up resistor to grbl limit pin, and ground the limit switch. If they don't want hard limits, then just ground the 3 limit pins. No software involved.

As far as the E-stop wiring, I was thinking the E-stop when engaged will pull up both the notification pin on grbl and the step drive enable. If a user does not want/need the e-stop notification, they can just wire the e-stop pin to ground? That would allow us not to worry about handling the notification if it wants to be ignored? I suppose if the user doesn't want to waste a pin on the estop notification then it would have to be in the software.

If we can spare the 4 digital inputs, then we can have minimal startup requirements? Grounding any of the 4 pins to ignore them. The software can go about its business either way.

[chamnit]

I've been of the opinion that e-stop should be just wired directly to the Arduino reset pin. This will do exactly the same thing and force Grbl to completely stop and reset. As long as the pin is held, the machine shouldn't move. The main problem with hard limits is that everyone has a different setup and requirements. We can't assume one general solution will support everyone, and this can become a major headache down the road.

Also, I think that most, if not all, stepper motors that Grbl supports do not have enough torque to cause damage to a frame or leadscrews. So, I think even if this was not wired by a user, simple physical hard limits will work fine.

As for soft limits, I think this is essential. This will allow a user to keep positioning by doing a controlled deceleration stop and not losing steps. This goes hand in hand with a homing routine, without it, it's pretty much useless. The homing routine need some TLC, but once that goes in and is robust, we can do soft limits without much of a problem.

[komradebob]

A note about limit switches...(note, I'm new here and have not seen this solved anyplace yet. Please forgive me if it has)

A pretty famous and pesky bug in the software for 8" Tandon floppy drives, way back when, lead to replacing a large number of drives, which use optical sensors as limit switches, when, either due to an electrical fault ( generally a spike at power on) or mechanical shock, caused the 'flag' used to trip the optical limit switch to pass the limit switch. In the case of the floppy drive, the limit switch is used to detect when the head is at track zero. When the bug happened, the head was behind track zero. The solution was to write some code which ignored the limit switch, steps out 5 units, then step 10 negative or until it hit the limit switch.

I say this because while my new XY table has very nice, adjustable limit switches, the Z axis is optical, though the flags are big enough to avoid the problem.

This also brings up homing, in which, again, I invoke the old floppy 'seek to track zero' routines, in which the heads were stepped at a low speed to find home, never at high speed. it took a while longer, but never damaged anything. The same approach is used for print heads.

On jogging.
In an open loop system such as this, jogging is easily accomplished by issuing a few g code commands. If one has a plethora of buttons, adding a few to do XYZ jog is great, but we seem to be limited in that area. Might one add some jog code to take input if, for example, jog switches somehow appear on a port expander to new hardware with more ports?
Of course, the easy way out is go closed loop and use switches that are wired straight to the stepper controllers. :)
Quadrature DRO sensor input anyone?

[csdexter]

The switches:
The problem with the floppy drives was clearly a hardware design one. That's why it's called "a limit switch": it should trip when the mechanical linkage it supervises reaches its limit, no matter how it does that. It should work in all cases: if it doesn't, it's bad design.
Talking about optical switches in particular, a good design won't only ensure that the flag has the proper size, orientation and position so that it will always actuate the optical sensor, no matter the movement; but also has the whole switch assembly fail closed (e.g. if power is lost to the optics, the switch should immediately read as tripped).
The good design story extends to software as well: in a production setting (i.e. machine that cuts real metal and could endanger humans around it if slams into the end of the carriage), the sensors themselves would be tested as part of the power-up procedure (e.g. by cycling power to them and checking that they read tripped as a result, and open when power is back) and only then the homing procedure would start. Of course, any detected failure in sensor operation makes the whole machine cease any movement and signal an error to the operator.

The floppy seek:
I've used countless 8", 5 1/4" and 3 1/2" floppies and none of them had any notion of acceleration, let alone "slow and fast". Needless to mention, I hope, that the floppy has no brain -- it is the controller on the motherboard that tells it how many steps to move its head and that controller also has nothing to do with acceleration or going fast or slow. The whole mechanical assembly is stiff enough and the motor's characteristics are tuned to it in such a way that it can move from a rest (or stop, if moving) without any need for an acceleration curve (i.e. Vstart > Voperation, for the stepper in floppies, where Vstart is the maximum speed a stepper can be started at). The only thing that the controller does is wait after the last step (and before attempting to receive/send data from/to the heads) for any mechanical vibrations to subside.
The seek is simply implemented as "while(!TRACK0) STEP_MINUS;" in the i8272.
Some of the very light CNC-like things we're seeing nowadays, like some 3D printers whose body is made from wood or plastic, could fit in that niche too (i.e. be able to use seemingly infinite acceleration values and operate fine like that).

The jogging:
It's generally impossible to tie the MPG directly to the stepper drivers for geometry reasons: the MPG is usually marked in human length units (e.g. 0.001" or 1mm) while the length of one step pulse at the input of the stepper driver may move the machine any distance -- it all depends on the parameters of the linkages used.
What you could do if wire the MPG (and its multiplier and axis selection switches) either to the G-Code parser (make it generate G00/G01 commands) or directly to the motion controller (make it generate moves of that many human length units on that axis).

Quadrature decoder/counter for DRO:
Implementing this probably goes over the pin count and MIPS resources of the ATmega328p though it may well be possible on other architectures or if implemented in hardware external to the MCU. You would need to read it at least (rpm/60) * 4 * CPR times a second to get an accurate result (where rpm is the current rotational speed of the stepper in revolutions per minute and CPR is [quadrature] cycles per revolution of the encoder used). Since, in order to achieve rpm, we're sending (rpm/60) * SPR * MST pulses to the stepper each second (where SPR is steps per revolution of the motor itself and MST is the microstepping factor of the driver), this means you would need to read the encoder (in the worst case) as fast as you're stepping the motor.
This would spawn a whole range of electrical noise, cable-length and time interval adjustment problems you probably don't want to be dealing with in a DIY project :-)
The hardware market has good and bad news in this department: a dedicated quadrature decoder/counter (with a 32bit counter inside) chip is about four times as expensive as an ATtiny84A (which could do other things as it's counting your pulses as well). On the other side, larger MCUs of the ARM family often offer quadrature inputs to some of their internal timer/counters, so you could do it in one chip and without having to write code for it.

Hope this helps.