Sure, robots can increase your production time. But robot programming can shrink that time back down again if you’re not careful. Offline programming is a great way to save time and get the most from your robot.
Time is our only truly limited resource. As long as your business runs reasonably successfully, almost every other resource can be bought, borrowed or bargained for. But — and I know this is a cliche — there are only ever 24 hours in a day.
In the past, we had much less than 24 hours of production time per day. In the past, operations were fully manual, which meant losing many hours — here and there — to breaks, mistakes and other headaches.
With robots, your process has the potential to be productive for almost all 24 hours of the day. However, this is only possible when your robot is up and running, and performing productive tasks.
There are three basic time losses which reduce the effective production time of your robot:
- Initial Setup Time — The time it takes to design your robot cell then get it up and running in the first place.
- Programming Time — The time it takes to program a new operation into the robot.
- Changeover and Alteration Times — The time it takes to change the robot setup for a new product or update the programming following changes to an existing product.
Offline programming can help you to tackle all three of these time losses. Software like RoboDK streamlines the programming of your robot and allows you to improve the efficiency of the entire robot cell.
10 Excellent Ways to Save Time With Offline Programming
Here are 10 excellent ways to save time by using offline programming with your robot.
1. Shorten Start-Up Times
A huge portion of unproductive time occurs when you first set up your robot cell. It takes time to install the robotic hardware, build fixtures, calibrate the software, etc. However, hardware installation is not even the longest part of the setup process.
With traditional robot programming (e.g. using a teach pendant), you lose a lot of time integrating your application. With offline programming, you can develop the program while robot is being installed, or even before you have bought it! You can then load the program as soon as the physical installation is complete. This significantly shortens the startup time of the cell.
2. Speed Up Robot Selection
Choosing the right robot is difficult. You don’t necessarily know which robot specifications you will need while you are designing the cell. Offline programming lets you speed up the robot selection process by allowing you to test various robots on the same task and pick the best one for your needs. You can compare different robots via the RoboDK Robot Library.
3. Program Faster
Offline programming can be faster than online programming methods, particularly for programming-heavy tasks like welding. As The Fabricator magazine explains “offline programming is infinitely faster than jogging a robot around the part in a weld cell […] The software can trim weeks off the programming and implementation times.” This means you can get your robot cell up and running very quickly.
4. Tweak Programs Quickly
Traditional robot programming is a headache to debug and update. Even small changes can lead to hours of re-programming. With offline programming, it’s easy to tweak your program until it’s just right. In the early days of your robot cell, this can save you days of debugging time.
5. Reduce Quoting Time
As engineers, we usually focus on the operational benefits of a technology, don’t we?
We ask “Will this software make my job easier?” or “Will I be able to produce more product by using this software?”
However, we occasionally forget to consider the impacts of the technology on the rest of the business. For example, offline programming makes it easier to give fast, accurate quotes for jobs. With the software, we can quickly determine if a job will be achievable using our robot cell and how long it will take. Then, we can work out how much to charge for the job.
6. Quickly Change for High Mix Products
According to a Deloitte consumer survey from 2015, customization is changing the way that people buy products. Consumers and businesses are beginning to expect personalization and are willing to pay a premium for it.
This news is great for those of us who use robots. Robots are inherently flexible, you just have to change their programming. However, reprogramming takes a long time with some programming methods.
With offline programming, you develop the program first then load it onto the robot. This reduces changeover time and makes customization more feasible.
7. Reuse Your Code
One huge time waste is when you reprogram the same, or similar, functionality multiple times —e.g. when you program the same functionality on two distinct robots. Wouldn’t it be much better to program one robot once, then just tweak your code to represent any changes?
Researchers from the University of Auckland explain that this is one of the big problems with controller-specific programming languages, which are traditionally provided by robot manufacturers. The same functionality must be programmed from scratch for robots from different manufacturers.
With some offline programming software. RoboDK as an example, it becomes much easier to reuse code.
8. Quickly Change to Another Robot
Imagine you have a pick-and-place application. The robot moves 320kg, loaded pallets from one conveyor to another.
You spent a long time choosing the right robot and settled on the ABB IRB 650, with its 450kg payload. You spent a long time integrating the robot using ABB’s RAPID programming language and tweaking the code until it was just right.
But then your application changes.
Suddenly you aren’t moving 320kg pallets, you need to move 1100kg pallets. The robot’s payload isn’t enough. You look for another robot but the only one you can find which ticks all the boxes is a KUKA KR 1000 Titan, with its payload of 1200kg.
Does that mean you have to start from scratch? Does that mean you have to throw out all of your hard work and program it all again in KUKA’s KRL programming language?
With offline programming software like RoboDK, you can use your previous code as a starting point for your new program, so the new robot will be up and running much quicker.
9. Reduce Downtime
This one is simple. Very simple.
By programming your robot offline, the robot can continue to do productive work while you iron out any problems in the code.
This means less downtime.
I told you it was simple.
10. Reduce Cycle Time
Slightly less simple, but no less important, is the fact that offline programming can help you to reduce the robot’s cycle time.
How? Well, it’s really an extension of the previous point. Offline programming doesn’t impact downtime, so you have more time to tweak the program.
With online programming, every minute of downtime means lost production. With offline programming, there’s less pressure to get the program up and running so you can spend the time necessary to properly optimize the program. An optimized program means shorter cycle times.
If You’ve Got Time Now, Try Offline Programming for Yourself
A great way to see the benefits of offline programming is to try it out for yourself. If you’ve got some time right now, you can do this by downloading a trial copy of RoboDK at this link.
If you’ve got less time right now, you could check out some videos of our example applications on our Examples page.
What’s the biggest time loss in your operations? Tell us in the comments below or join the discussion on LinkedIn, Twitter, Facebook or Instagram.
Thank you for presenting such useful and clear information about offline programming. However, I consider about the accuracy of the estimated cycle time provided in simulation, compared to the actual cycle time. Is there a way to quantify this accuracy? (I am thinking specifically for a UR10 robot simulated in RobotDK).
Hi Giannis,
Thanks a lot for your comment. I’m glad the article was helpful to you.
That’s a very good question!
The results from any simulated process should be taken as a guideline. You will almost always see consistent cycle time results in simulation (i.e. offline programming). In the real-world processes are never so consistent.
For example, I have seen a process with a mean cycle time of 20 seconds vary between 15 and 43 seconds. However, I have also seen a process (using the same robot) where the cycle time is almost exactly the same every time.
This is not unusual. The variance that you will see in the “real-world version” of your application will depend on many factors, especially the task itself.
What can you do to predict this variation? Test!
In my opinion, the best way to really predict the accuracy of your simulated cycle time is to try it out on the robot and collect some real-world data. You can then compare this to the simulated time.
If I was to tell you a percentage accuracy, it would almost certainly be wrong.
The cycle time that you estimate in offline programming can be pretty close, and if you reduce the cycle time in simulation you’ll usually save time in the real-world too. But always test your application in the physical world.
Hope that’s helpful.
Cheers,
Alex