What's new
What's new

Preventing a Crash - The 3 Rules - Thoughts...?

Jashley73

Titanium
Joined
Jan 24, 2013
Location
Louisville, KY
I'm writing some work instructions for supervisors/operators, and just drafted a section on "Preventing a crash."

I've practiced these "3 rules" for years, and looking back, every time I've crashed a machine, it's because I failed to follow these 3 rules.

Those 3 rules are,

Rule #1 - Set the Rapid-Override to 25% (Or whatever makes sense on your machine - 2% if we're talking a Brother Speedio, etc...)
Rule #2 - Turn on Single-Block
Rule #3 - Watch your Distance-To-Go



What is your opinion of this idea of "The 3 Rules" ? Am I correct in preaching this to others, or am I missing something?


Feedback is appreciated, and you're welcome to steal or borrow these if desired. Thanks
 
Also, I don't want the conversation to get bogged down or distracted by programming. Let's assume that the program is fine, weather generated by CAM, or G-code. (Actually, the 3 rules would help prevent a crash there too, but I digress...)

My aim here is to focus in on preventing crashes after tool-offsets or work-offsets have been touched off. These changes will be affected by a greater number of people, than just the programmer - thus, something that applies to nearly anyone working on a machine.
 
I'm writing some work instructions for supervisors/operators, and just drafted a section on "Preventing a crash."

I've practiced these "3 rules" for years, and looking back, every time I've crashed a machine, it's because I failed to follow these 3 rules.

Those 3 rules are,

Rule #1 - Set the Rapid-Override to 25% (Or whatever makes sense on your machine - 2% if we're talking a Brother Speedio, etc...)
Rule #2 - Turn on Single-Block
Rule #3 - Watch your G54 (gxx) position



What is your opinion of this idea of "The 3 Rules" ? Am I correct in preaching this to others, or am I missing something?


Feedback is appreciated, and you're welcome to steal or borrow these if desired. Thanks

This is what I do / my preference. In essence the same thing if you look at where you are at in Gxx compared to where you are supposed to be in the program.... Maybe -

#4 check with a scale that you are at Z2. (or whatever your 'default' clearance move is...)
 
I also check whether it is in G00 or G1 and check feed rates
I use my dry run as a feed hold wit it set at zero.
If I like what it's doing I let it go.
I make sure it picks up the comp correctly then turn my rapid over ride to zero and let it go.

I don't cut air and I don't crash
 
Do you want your operators to single-block the whole program?

I would say instead verify on approach to your default clearance plane as Mike says, or initial approach point, that your work and tool length is set correctly.

Generally I program the first move to Z1. (unless I don't have the origin set to part top, then 1" above the highest point) for each tool, but each toolpath might be lower, like .1 or .2 or whatever. But at least that first move is easy to check with a scale or block.
 
I also check whether it is in G00 or G1 and check feed rates
I use my dry run as a feed hold wit it set at zero.
If I like what it's doing I let it go.
I make sure it picks up the comp correctly then turn my rapid over ride to zero and let it go.

I don't cut air and I don't crash

Uh oh! You went and done it now! :hole:
 
Single blocking a program is not feasible for us however I try and program consistently for my guys and will use standard values such as 0.1" above top of part clearance planes and a 4" master clearance plane (part depending). At that point my guys are expected to watch the distance to do screen, low rapids and maybe ease into the cut but generally if they follow the setup sheets and something bad happens it's something I need to answer to not them.
 
I like to feather the rapid override knob between 0 and 1%, while checking distance to go, and then up to 10-25% to speed things along during a long distance traverse.

I find the jump from 0 to 25% to be practically worthless. 25% on a 2000 IPM machine is still too fast for a short distance approach. If the machine can't be configured to make the first rapid detent 5% or less, I'll use the feed override knob instead, which isn't ideal but gets the job done. There's risk in forgetting to bring the feed back to 100% after the program has been proven.

Single block is used where appropriate, but the constant cycle start pushing gets tedious. I'll use it for rigid tapping and lathe threading where feed and rapid override knobs won't stop the machine mid cycle.
 
I would also add on machining centers and barrel turret style lathes to program all tool changes far away from the work holding. It can be edited in closer once the set-up is complete.
 
This is just not possible in rapid prototyping or job shopping to me. I'll run the verify on the cam with another set of eyes, probe the part and tools and let it go. Granted we do get an occasional tool slam or skim vice jaws but the cost of an occasional crunch is cheaper than tiptoeing around each part.
 
Funny you should start this thread I've had thought about exactly this.

I would like a way to make sure that no tool could possibly operate without a length offset in MDI program.

I've thought of adding relevant code to the M06 help macro. Then again that won't work when in MDI.

Also thought of simply setting g54 to machine zero and refuse to touch it. You enter "z-700" you probably deserve to crash.

Another thing is subprograms. Writing pseudocode here cuz too lazy to look up vars:

"If H value is #0 then m99" at the beginning.

How many people have crashed by running subprograms by mistake instead of the main? I have. Then again I'm super clumsy.
 
This is just not possible in rapid prototyping or job shopping to me. I'll run the verify on the cam with another set of eyes, probe the part and tools and let it go. Granted we do get an occasional tool slam or skim vice jaws but the cost of an occasional crunch is cheaper than tiptoeing around each part.

Sure it is. Maybe *I* wasn't clear when I posted, but I was referring specifically to the first tool of the program. It is just a quick check to make sure I

A) touched off the tool
B) picked up and set the correct work offset

After the first tool I generally just let it run. It is for me (personally) more of a sanity check than anything. Sometimes I am back and forth between machine and office / programming so I want to make sure I did indeed set the tool / offset before I got sidetracked with something else...
 
This is just not possible in rapid prototyping or job shopping to me. I'll run the verify on the cam with another set of eyes, probe the part and tools and let it go. Granted we do get an occasional tool slam or skim vice jaws but the cost of an occasional crunch is cheaper than tiptoeing around each part.

Speak for yourself. A bad crash can incur a $5-$10,000 service call plus whatever down time you have, preventing that is definitely worth "tip toeing." I would say "tip toeing" adds 15 minutes to a set-up.
 
Sure it is. Maybe *I* wasn't clear when I posted, but I was referring specifically to the first tool of the program. It is just a quick check to make sure I

A) touched off the tool
B) picked up and set the correct work offset

After the first tool I generally just let it run. It is for me (personally) more of a sanity check than anything. Sometimes I am back and forth between machine and office / programming so I want to make sure I did indeed set the tool / offset before I got sidetracked with something else...
I very much agree with this practice.

Honestly for me it's an absolute must. I'm a pretty absent-minded guy. I'm also often overworked. Anyone can slip up when overworked. I've slipped up my fair share at our shop. Not actually a great operator, a terrible manual worker, my qualities are in theory, innovation and coding.
 
As a good share of our programs are multiple hrs. long, single blocking & or dry running a program is not an option. Doing tooling work, most of our programs are also single use & are not proven (beyond our cam systems) until the job runs.

Here is what we have implemented over the years in effort to prevent crashes:
It is important to note, we do all of our programming with cam & do 100% simulation verification prior to posting programs.

We have found that most all of our problems occur at tool changes, either from a programming mistake (E.I. origin location, etc.) Or from setup errors, bad tool touch offs, etc. With this in mind, we do not allow unattended tool changes on first run programs. To insure that we do not have an unattended tool change, we put M00's at all tool changes. This insures that the tool someone walks the machine through the tool change.

At the start of our program & at tool changes, rapids are turned down or off as needed & the machine is controlled with the feed rate override.
We have found that you have more control over the machine with the feed rate override, as opposed to single block. With the override, you can simply turn the feed rate to 0 anytime you want to stop the machine & evaluate the situation. You are never hunting for feed hold, or any other control feature.
As the tool approaches the work, if the position & distance to go looks correct, then we have verified that the tool position is correct & we let the machine go at that point. As stated above, for this to work, careful review & study of the CAM simulations is critical.
We have other catch all's for the setup that take place with the setup sheets such as work holding instructions, tool protrusion requirements & holder types to be used.

This of course has not cut out all incidents, but had reduced them dramatically over time.

As a side note, we do not even allow unattended tool changes for lights out operations. Our policy is to either have someone come back to the shop & perform the tool change, or allow the machine to sit until the following morning.
 
I don't have much to add because most things said already I agree with (distance to go, rapids, dry run, etc).

But if you're making a manual or instruction pamphlet, may I suggest you make a version of this sticker as the last point? (Ass-uming a little bit of humor would fit into an official instruction manual at your workplace)

hOISqvi.jpg
 

Attachments

  • hOISqvi.jpg
    hOISqvi.jpg
    13.2 KB · Views: 92








 
Back
Top