Preventing a Crash - The 3 Rules - Thoughts...?
Close
Login to Your Account
Page 1 of 4 123 ... LastLast
Results 1 to 20 of 77
  1. #1
    Join Date
    Jan 2013
    Location
    Louisville, KY
    Posts
    2,997
    Post Thanks / Like
    Likes (Given)
    7004
    Likes (Received)
    2533

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

    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

  2. Likes DouglasJRizzo liked this post
  3. #2
    Join Date
    Jan 2013
    Location
    Louisville, KY
    Posts
    2,997
    Post Thanks / Like
    Likes (Given)
    7004
    Likes (Received)
    2533

    Default

    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.

  4. #3
    Join Date
    Nov 2014
    Country
    UNITED STATES
    State/Province
    Florida
    Posts
    3,732
    Post Thanks / Like
    Likes (Given)
    1539
    Likes (Received)
    1764

    Default

    Quote Originally Posted by Jashley73 View Post
    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...)

  5. #4
    Join Date
    Apr 2014
    Location
    Western Mass
    Posts
    76
    Post Thanks / Like
    Likes (Given)
    46
    Likes (Received)
    41

    Default

    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

  6. Likes doug8cat liked this post
  7. #5
    Join Date
    Jan 2015
    Country
    UNITED STATES
    State/Province
    California
    Posts
    709
    Post Thanks / Like
    Likes (Given)
    104
    Likes (Received)
    365

    Default

    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.

  8. #6
    Join Date
    Nov 2014
    Country
    UNITED STATES
    State/Province
    Florida
    Posts
    3,732
    Post Thanks / Like
    Likes (Given)
    1539
    Likes (Received)
    1764

    Default

    Quote Originally Posted by mcmachine View Post
    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!

  9. #7
    Join Date
    Apr 2014
    Location
    Western Mass
    Posts
    76
    Post Thanks / Like
    Likes (Given)
    46
    Likes (Received)
    41

    Default

    Yup...when will I learn!
    Walking on eggshells for the rest of the day!

  10. Likes Greg White liked this post
  11. #8
    Join Date
    Dec 2014
    Country
    CANADA
    State/Province
    British Columbia
    Posts
    1,280
    Post Thanks / Like
    Likes (Given)
    361
    Likes (Received)
    585

    Default

    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.

  12. #9
    Join Date
    Feb 2012
    Location
    California
    Posts
    1,375
    Post Thanks / Like
    Likes (Given)
    884
    Likes (Received)
    1479

    Default

    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.

  13. #10
    Join Date
    Apr 2005
    Location
    Beaverdam, Virginia
    Posts
    7,369
    Post Thanks / Like
    Likes (Given)
    670
    Likes (Received)
    3478

    Default

    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.

  14. Likes Dan from Oakland liked this post
  15. #11
    Join Date
    Mar 2006
    Country
    PHILIPPINES
    Posts
    2,456
    Post Thanks / Like
    Likes (Given)
    547
    Likes (Received)
    783

    Default

    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.

  16. #12
    Join Date
    Jan 2019
    Country
    SWEDEN
    Posts
    190
    Post Thanks / Like
    Likes (Given)
    56
    Likes (Received)
    22

    Default

    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.

  17. #13
    Join Date
    Nov 2014
    Country
    UNITED STATES
    State/Province
    Florida
    Posts
    3,732
    Post Thanks / Like
    Likes (Given)
    1539
    Likes (Received)
    1764

    Default

    Quote Originally Posted by g-coder05 View Post
    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...

  18. Likes g-coder05 liked this post
  19. #14
    Join Date
    Apr 2005
    Location
    Beaverdam, Virginia
    Posts
    7,369
    Post Thanks / Like
    Likes (Given)
    670
    Likes (Received)
    3478

    Default

    Quote Originally Posted by g-coder05 View Post
    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.

  20. #15
    Join Date
    Jan 2019
    Country
    SWEDEN
    Posts
    190
    Post Thanks / Like
    Likes (Given)
    56
    Likes (Received)
    22

    Default

    Quote Originally Posted by Mike1974 View Post
    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.

  21. Likes Jashley73 liked this post
  22. #16
    Join Date
    Sep 2007
    Country
    UNITED STATES
    State/Province
    Washington
    Posts
    5,175
    Post Thanks / Like
    Likes (Given)
    187
    Likes (Received)
    1538

    Default

    Quote Originally Posted by Tichy View Post
    How many people have crashed by running subprograms by mistake instead of the main?
    I may have done this a time or two

    Regards.

    Mike

  23. #17
    Join Date
    Jul 2003
    Location
    Carson City, Nv. USA
    Posts
    903
    Post Thanks / Like
    Likes (Given)
    712
    Likes (Received)
    481

    Default

    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.

  24. Likes Jashley73, Fal Grunt, GM liked this post
  25. #18
    Join Date
    Feb 2008
    Location
    MI, USA
    Posts
    800
    Post Thanks / Like
    Likes (Given)
    59
    Likes (Received)
    314

    Default

    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)

    Attached Thumbnails Attached Thumbnails hoisqvi.jpg  

  26. #19
    Join Date
    Jun 2009
    Location
    Michigan, USA
    Posts
    2,193
    Post Thanks / Like
    Likes (Given)
    3307
    Likes (Received)
    1726

    Default

    I'm not a real experienced CNC guy like a lot of you but "hand near the emergency stop button" comes to mind.

  27. #20
    Join Date
    Jul 2003
    Location
    Carson City, Nv. USA
    Posts
    903
    Post Thanks / Like
    Likes (Given)
    712
    Likes (Received)
    481

    Default

    Quote Originally Posted by Big B View Post
    I'm not a real experienced CNC guy like a lot of you but "hand near the emergency stop button" comes to mind.

    Never E stop. Reset stops the machine just as fast without freewheeling the spindle & shutting everything down. Easier on the machine as well.

  28. Likes aj, metlmunchr, NAST555 liked this post

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •