Universal Robots has come to be known as the leader in the collaborative robotics industry. They also have a strong reputation for being easy to implement and program. There is no doubt that, compared to other collaborative robot products and traditional industrial robots, Universal Robots has a very user-friendly interface. And for most applications, has a quick “out of the box to production” implementation. Instead of needing a team of engineers or a dedicated programmer, Universal Robots are being programmed by technicians and sometimes even by operators that previously performed the task for which the robot is being implemented.
With that being said, in my years of experience supporting and being involved with new UR applications, along with programming applications and tests myself, I see a recurring theme among new users. Learning a new interface can take a user’s focus away from being as efficient as possible. The user’s thought is going into where to find a certain button or menu, rather than thinking “what can I do to make this process more efficient and reliable?”
UR: Come for the Safety, Stay for the Ease of Use
Plan Before Programming
This entry will continue the theme of planning ahead before programming. Because URs are easy to program and use, people will often jump straight into programming the application because they know how the application has been running (either with a previous machine or with operators). However, if they neglect to think about how the UR will perform vs the previous method, this will cause frustration and loss of time.
Failure to utilize the built-in setup tools before writing the application program may cause the user to become frustrated with or underwhelmed by their experience. It could also lead to inefficient and unreliable programming. Neither of those is desirable on a production floor, so let’s continue to give your application the edge for success.
Program Segmentation and Organization
Once you are ready to begin programming, you should already have a good idea of what the overall program should look like. If not, take some time to make a simple physical or mental flowchart while going through the application. This may not necessarily be knowing the lines of robot instructions in detail, but more of a basic structure and flow of events.
One more step to take before writing the program commands and programming points is to make use of UR’s Folders Command (Structure Tab -> Basic -> Folders). Folders can easily make the difference between an organized, easy to understand program and a list of commands that would take someone else hours to understand. It is rare that only one person will ever need to be able to read, understand, and even alter a machine’s program. This makes it crucial for a program to be properly organized, segmented, and labeled.
Figure 1: Program without folders vs program with folders
Most programs can be broken down into smaller segments of related commands. An easy example of this is a pick and place application (see Figure 1 - bolded statements in the command tree are folders). One segment may be a homing routine, another for the pick sequence, and a final one for the place sequence. Some complex programs can have levels of minor segments within major segments as well. Regardless, I strongly recommend making a program structure of titled Folders before beginning to write your program. This will help with readability, troubleshooting, and making sense for others on the project. The program on the right of Figure 1 will be much easier for someone else to interpret at a quick glance.
A major advantage of folders is that sequences of commands in those folders can all be lumped into one action. For example, if you need to copy/paste repeated code segments throughout your program, or even across programs, you can. Folders allow you to move entire sequences around as if they were one entity. A user can also suppress an entire segment via a folder, making it possible to run only one segment at a time for testing and debugging. These items can save hours of time through the implementation process.
The program in Figure 1 is a very simple example program and real application programs are likely to be much more complex, so it is easy to see how beneficial the use of folders can be.
Figure 2: Unnamed Waypoints vs Named Waypoints
Another easy step to improving program organization and ease of understanding is to name waypoints. When programming the UR, by default, new waypoints are given the name “Waypoint_X” with X being the last waypoint number plus one. Make it a habit of renaming a waypoint to something meaningful immediately after programming the point. You can see in Figure 2 that the same example with named waypoints conveys so much more information, even at a quick glance. This could easily save another programmer (or even you, if it has been a long time since you last viewed the program) from making costly mistakes due simply to ambiguity.
Planning ahead for program organization can make writing, testing, and using a program much easier. It will improve your ability to maintain and make necessary future alterations. Using Folders, program segmentation, and clear naming conventions are great habits to start early on. These will inevitably lead to less time working on the robot and more time in production!
In the next entry to the series, we will cover the robot’s “Precise Positioning and Testing with the Speed Slider.” This will be a short but very useful series entry showing how to make very precise and controlled moves of the robot arm. This item may seem like an obvious feature, but I have seen most new users struggle to find it and more often than not forget to use it while programming.
Contact Cross Company