Don’t Break Your Robot! Use RoboDK to Test Limit Cases

Robots can be a valuable part of many manufacturing and production processes. But they can also be dangerous if you don’t use them correctly, especially in “limit cases.”

In some cases, taking the wrong action can lead to physical damage to the robot, other equipment, or even human workers. This can lead to costly and dangerous failures.

In an ideal world, you would test all possible situations to avoid failure, but this is physically impossible.

What if you could test more situations with your robot to reduce failure?

That’s where RoboDK comes in!

By using RoboDK to test your limit cases, you can predict the results of many different actions quickly and safely.

What Are Limit Cases and Why Are They Dangerous

A limit case is a situation that you wouldn’t normally encounter in the normal use of the robot. It can cause physical damage to the robot or your equipment if it occurs.

Limit cases can be dangerous because they are difficult to predict and even harder to test.

An example of a limit case might be what happens if all the power fails on the robot when it is right in the middle of a key step of a task. Testing this could be costly and damage your machinery unnecessarily.

One way to avoid such failures safely is to use simulation to test limit cases. This is often done in the field of structural engineering where much physical testing is impossible.

Why It’s Impossible to Physically Test Every Limit Case

Why don’t you just test all the potential situations with your robot?

There are several reasons it’s practically impossible to test all limit cases with your robot.

First, doing so would be incredibly time-consuming and expensive. The cost of damaged equipment and repairs would quickly add up. Even if you didn’t cause damage, the time you’d need to spend testing everything would slow down production.

Second, some limit cases are simply too dangerous to test physically. This is especially true if the robot is working with hazardous materials or in a high-risk environment. There can be ethical concerns involved in testing limit cases and could put people in potentially dangerous situations.

Finally, limit cases are often specific to each different robot model. It’s not always possible to generalize your results. As a result, physical limit case testing can be impractical as you need to run the tests on every new robot model you use unless you use a good simulator.

How You Can Use RoboDK to Test More Limit Cases

RoboDK is the perfect tool for testing limit cases. By using its powerful simulation environment, you can test many more situations than you would be able to with physical testing or other methods (such as “back of the napkin” calculations).

With RoboDK, you can alter your robot programs, then use simulation to determine the results of your changes. You can make more ambitious changes than you would with physical testing, which allows you to identify more limit cases.

Another great way to use RoboDK is to auto-generate custom tests using your favorite programming language and run these through the RoboDK API. This is a similar process that software developers use to test their code.

When you use RoboDK for limit testing, you will soon see various ways you can create a range of different tests.

5 Great Examples of Simulated Tests for Robots

What might a limit case test look like in a robot simulation?

Here are 5 examples of situations where you could benefit from using RoboDK for limit case testing:

1. When Testing to Destruction

If your test would cause you to physically damage or destroy the robot or other equipment, a simulation is a much better option.

Testing to destruction is a valuable tool in manufacturing products to ensure they meet specifications before you send them to customers. However, you don’t want to break your robot just to test an unlikely limit case.

2. When Power Is Lost

Most robots have a safety feature that means they stop when power is lost. However, robot applications comprise multiple constantly moving parts.

It’s hard to know the impact of a power loss on the various parts of your system unless you test.

3. When Mistakes Cause Errors

Many limit cases will only show up when an item is placed in the wrong location in the task area or another mistake is made.

With physical testing, you can only ever test a few of these (e.g. try placing the workpiece in 5 or 10 wrong locations). But with simulation, you can test dozens of similar mistakes automatically.

4. When There’s an Emergency Stop

The safety features of the robot should mean that it stops when an “emergency stop” situation is reached.

You should test emergency stops both physically and in simulation. But it makes sense to test in the simulator first so you can have an idea of what will happen in the real world.

5. When Physical Tests Take Too Long

Often, a physical test will take far too long to set up. You need to move all the items in the work area to the correct places for the test, set up the robot, and run the program. Then you have to do the same again in more configurations.

Simulating your limit cases in RoboDK speeds up the testing process significantly, allowing you to test even more situations.

How to Start Testing Limit Cases With RoboDK

You can get started with RoboDK limit case testing quite easily.

First, get a copy of RoboDK and familiarize yourself with its programming environment.

Start by identifying some simple limit case situations and build these in the simulation environment.

With a very little setup, you can start to reliably test limit cases that would be difficult or expensive to test in the real world. This can help you avoid costly mistakes and keep your robots and equipment safe for continued use.

What limit cases would you never like to test? Tell us in the comments below or join the discussion on LinkedIn, Twitter, Facebook, Instagram, or in the RoboDK Forum.. Also, check out our extensive video collection and subscribe to the RoboDK YouTube Channel

About Alex Owen-Hill

Alex Owen-Hill is a freelance writer and public speaker who blogs about a large range of topics, including science, presentation skills at, storytelling and (of course) robotics. He completed a PhD in Telerobotics from Universidad Politecnica de Madrid as part of the PURESAFE project, in collaboration with CERN. As a recovering academic, he maintains a firm foot in the robotics world by blogging about industrial robotics.

View all posts by Alex Owen-Hill

Leave a Reply

Your email address will not be published. Required fields are marked *