Everybody crashes, I was once told. It’s likely true. However, not all crashes are created equal. There are fender benders that may just break small tools, and then there are head on collisions that may ruin your day.
Crashes are relatively easy to avoid in CNC machines. They often occur during setup and debugging. If you can recognize high-risk situations, you’ll be in a better position to avoid them.
Before discussing the mechanics of avoiding crashes, I’d like to highlight something many of you already know: One of the most effective ways of avoiding crashes is to avoid being interrupted while programming and setting up. That’s easier said than done, of course.
Having said that, this chapter provides a set of tips that have saved me numerous times!
1.Avoid moving around too much in Handle Jog mode.
If you are not familiar with the term, Handle Jog mode allows you to move the table around manually with a CNC machine. I don’t like to do much of anything with a CNC machine in Handle Jog mode. I use Handle Jog mode mostly for the bare necessities such as edge finding, indicating, and clearing the cutter. However, Handle Jog mode can be used for some simple machining.
Occasionally I use Handle Jog mode to face the end of a bar or fly cut blocks of material. However, I generally prefer machining parts under program control. We’re only human and it is relatively easy to forget which axis and feed increment you have engaged when you start cranking the feed handle. A good habit to get into is to be cautious when you start cranking the feed handle. Turn the handle just one or two clicks to verify that the spindle is moving in the direction and feed rate you want.
2.Before running a new program, scan through the program at the machine to check for gross errors. (see Fig. 3-1)
Check the Z negative moves in a new program to see if they make sense. This is an easy and often fruitful way to avoid crashes. For example, if your first tool is a center drill and you are drilling a plate, then you know the Z negative move for the center drill should be somewhere around Z –.150. If the value in the program is something like Z –1.150, then you know right away something is wrong.
You should also scan other Z negative moves in a program for drilling, reaming, tapping, etc. The Z negative moves for those operations can be easily found within the canned cycles that execute them.
Figure 3-1 Gross Z negative errors in a program translate into gross machining errors. In this example, the center drill was mistakenly programmed to go Z–1. instead of Z–.1, which resulted in a scrapped part. Machinists should do a visual scan of a new program to check for these types of errors.
3.Perform a quick visual scan of feed rates.
If you see something like F500., and you are machining stainless, then you know right away that something is wrong, at least with the feed rate. Feed rates for machining stainless are generally in the F10. to F20. range. F500. would certainly break a cutter.
4.Perform a quick visual scan of spindle speeds. (see Fig. 3-2)
Spindle speeds are sometimes incorrectly input in a program. It is easy for a programmer to add another zero to a spindle speed by mistake. Suppose a spindle speed for a reamer was meant to be 300 RPM and the programmer adds another zero and makes it 3000 RPM. In this case, the reamer is going to get fried if you don’t catch the mistake.
Before running a program, also make sure that all tool numbers are correct and that they have the correct corresponding “H” value. (The H value calls up the tool length offset for a specific tool.) For example, in a section of programming for a specific tool, you would not want to see “T2 M06” followed by “G43 H4.” The correct programming would be “T2 M06” followed by “G43 H2.” Only after calling up T4 would you want to see G43 H4 in a program.
I’ve gotten to the point where I shy away from letting other machinists run my unproven programs because a lot of them won’t take the time to do these simple checks. Further discussion of programming code will follow in Chapter 8.
Figure 3-2 It’s a good idea for machinists to physically lay out all the tools used in a program in sequential order before installing them in a machine. Most tool numbering errors can be caught early in this way.
No programmer can provide perfect programs all the time. I’ll even go so far as to say that if I’m the machinist, and I run your program, which results in a crash, it’s my fault. In other words, with few exceptions, I believe the machinist has the responsibility and the means, within reason, to make sure everything is going to run OK.
Tool numbers get screwed up in programs for various reasons. During program construction, programmers have to decide what tools to use. Tools often get added or subtracted by the programmer. If the programmer fails to renumber the final tool selections in a program, confusion can occur while setting up the job.
5.Reduce the “Rapid” speed (G00) during setup and debugging by activating a lower rapid speed percentage button.
Reducing the rapid speed is a precaution that gives you more time to hit the feed hold button if something doesn’t look right. I often use these lower percentages during setup and debugging, especially when I am working on expensive parts.
6.For first runs and debugging, toggle between the “Cycle Start” button and the “Feed Hold” button on the controller as the cutter approaches the part. (see Fig. 3-3)
It is difficult to see where a cutter is in relation to a part when the spindle is at Machine Z Zero (retracted). The closer the cutter gets to the part, the easier it is to see the relationship between the part and cutter. Sometimes I toggle half a dozen times when a cutter is on its way down, especially if I’m doing something like engraving expensive mold cavities.
Figure 3-3 The machinist is being careful here by toggling between the cycle start button and the feed hold button as the cutter approaches the part. If there is a programming error, the machinist is in a good position either to catch the error before any material is cut or to reduce the damage the programming error may cause.
7.Insert M1 “Optional Stop” commands in the program before each tool change. (See Fig. 3-4)
For first runs and debugging, it is useful to have the “Optional Stop” activated so that you can be at the machine for the start of a new tool. Often, the first few moves a new tool makes will let you know if there is a problem. Once you determine all tools are running okay, you can deactivate the “Optional Stop” button and start running.
8.Clamp large remnants in place or remove them so they can’t fall behind the machine table. (see Fig. 3-5)
One time I screwed up one of the sheet metal covers that cover the back column. I failed to remove a remnant that had fallen behind the machine table. When the table moved toward the column while a program was running, the remnant got jammed between the machine table and the cover, which destroyed the cover. Lesson learned.