Automation – More than Robots
Photo by Steve Jurvetson licensed via Creative Commons
When people think of automation, they tend to think of things like the automotive assembly lines you see on Television. The ones that have the big arms that are swinging car doors around at top speed. While this is absolutely true, I want to focus on the opposite side of the coin. Today I would like to share a practical example of how we can use automation to save time and reduce errors in daily manufacturing operations. The cases we are covering today are ones that I personally deployed as solutions to two separate situations where programmers and operators were required to manually compensate for odd functionality or perform repetitive tasks on Okuma VMCs. While only taking a few extra minutes each time, even a few minutes a week adds up over a year.
The first is the notorious alarm generated by commanding a tool change for the tool that is already in the spindle. More than likely anyone who has ever run an Okuma mill has seen this one. The second was on machines equipped with a tool touch probe. It was necessary to hand type a lengthy “CALL” command in MDI for each tool or run a separate program to set the Tool length offsets during a setup. What I ended up with was a single custom tool call that fixes both issues.
Scenario #1
[Wrong T command] alarm on the control during program execution. The issue arises because most CAM software will call the tool before the first operation that uses it. In some cases a part only requires a single tool to complete the entire program. The CAM software doesn’t insert any other tool calls. As a result, the tool remains in the spindle between cycles causing the alarm during the next run. This leaves a few options when it comes to programs for production.
You could hand edit the tool change out of every program you post from your CAM software that uses a single tool. Another solution would be to send it to the machine as posted and run the risk of someone unknowingly breaking your code in the control in an attempt to edit it themselves. While this may not happen often, it only takes one mistake to cause a loss of production. What do these solutions have in common? Both of them take time, every time.
The best solution in my opinion is to add the logic to the tool change itself to evaluate whether or not a tool change is needed. You give the machine control the ability to check the tool in the spindle against the tool being called in the tool change. It performs a quick comparison before the tool change is commanded. If the values match, the machine will automatically skip the tool change and return to the program. If they don’t match, the tool change will occur as normal.
How it Works
By registering a LIB file in the control, you can assign a macro from it to a custom G code in the control. (Check your machine manuals for the correct procedure to register and assign your macro.) In my case I will use “G111 T#” for tool changes in my CAM software post processor The macro I used is very simple:
OTCHK
IF [PT EQ VTLCN] NEND
T=PT M6
NEND RTS
This is what each line does. Line 1 is the name that the control will look for in the LIB file. Line 2 reads “If PT (variable assigned in the G111 call.) Equals VTLCN (System parameter containing tool number in spindle) go to NEND. This will only happen if they match and will skip Line 3. If the values don’t match, it will ignore the rest of the line and the next line will execute. This line inserts the T variable into the built in tool change and calls it with M6. Line 4 simply ends the macro and the control returns to the main program.
It’s as simple as that. If it needs to change it, it will. Otherwise, it will act as though the tool change isn’t there. No alarm will be generated since no T command actually took place.
Scenario #2
Now we’ll take a look at the other scenario. To command the machine to measure and record the length offset for a tool, you load/call the desired tool into the spindle and enter the following line of code: “CALL OO30 PLI=-2.5”. This is calling a built in machine macro for measuring tool length called OO30 and passing the value of -2.5 to the parameter PLI. These values and syntax will vary from machine to machine.
If you are doing a new setup, you may have several tools that will have to be called and measured. You could write a program to pick up and measure each tool in the changer but what if you are only using half of the changer? Would you write another one? What about finish work or high precision jobs where accuracy is critical?
One option would be to add the call to your program. Another one is to add the measurement cycle to the tool change itself. This means that when a tool change is commanded, the machine will change to the new tool and then automatically perform the tool length measurement. This eliminates the necessity for measuring tools individually during setup while giving the most accurate tool length compensation possible.
Add it Once
OTCHK
IF [PT EQ VTLCN] NEND
T=PT M6
CALL OO30 PLI=-2.5
NEND RTS
As you can see, I added a line between the tool change and the NEND. This way the macro will skip the tool change and the measurement cycle if the tool is already in the spindle. This approach may not be ideal in situations where the overall cycle is short or accuracy is not as important as total part count. The machine will touch every tool to the probe, which will increase cycle times. When it comes to long programs involving multiple tools, the ability to adjust your tool offset as you go will compensate for any dimensional changes caused by tool wear and/or the machine itself heating up throughout the production run.
The Only Limit is your Imagination
Image by Pixabay
While I created a single macro that is capable of performing the length measurement while avoiding the tool alarm, it would also be easy to create 2 separate tool change cycles. One that will command the measurement cycle and one that doesn’t. In that case, you would just have to create a separate macro with a different name in the LIB file and register it to a different G code on the Okuma settings page. Then you have the ability to use whichever works better with your current setup but you will have to decide ahead of time which one to post in your code.
I chose to share these examples of automation because they are very specific. This is illustrating how even something small like removing a trivial alarm can lead to big time savings when you consider it over a year. Any situation where you are repeating the same action over and over is an opportunity to automate. The trick is training yourself to identify those situations in your daily routine. Then you can systematically find and implement a solution. Now that I have given you an example of how I did it in my shop, I would love to hear about processes in your own shops where you were able to save time through automation.
