sometimes it is not programmers fault. improper wiring methods can be to blame as seen here. without arc robot does fine. but when arc strikes robot looses control.
Been doing palletizer robots forever. Luckily those crashes are usually vertical or smashing some cardboard boxes, nothing too dramatic. Hit a fence once in a while. I run into ghost crashes left and right from people that don't seem to know how to set up payload properly and get some unexpected series of motions that result in spinning the tool a bit too quick for the improper payload setting, so lots of troubleshooting to find those outside fault cases. Similar with the fence hits - never fails to be a joint move when some edge case jumps around some linear motion.
Used to work with a guy that was a bit high strung and thought pretty highly of his own skills. Would reprogram to add a station or add in a new unit load and just press go at 50% of automatic speed instead of doing the sensible thing and just jog through a layer or two to confirm the paths. I got used to tossing a couple extra cables and photoeyes in my bag if I knew I would cross paths with him. Nothing grinds my gears more than arrogance combined with impatience
i have done some tests where robot was intentionally crashing into things to test products. It is a lot of fun. may sound fun but it is not very exciting. i envy guys that did this fence test
Nice, I will show this movie every time somebody says "We put a fence around the robot" or "Is the robot is going to stop when it crashes the fence ?"
All the new robot controllers are safe. The 'crazy' robot don't exist now but erverybody know a 'crazy' programmer :).
Fortunately crash is not equivalent to accident...
Even with collaborative robots, and fences, prudence is the mother of survey !
All the new robot controllers are safe. The 'crazy' robot don't exist now but erverybody know a 'crazy' programmer :).
"All safe"? Hardly. It's true that "wild orbit" scenarios are almost non-existent on modern robots, but they can still happen in rare circumstances. I had it happen a few years ago when a servo amplifier died in a very strange fashion -- for about 3sec, the axis was uncontrolled before the following error tripped. The root cause was that a capacitor in the amp burned out in "slow motion", instead of simply failing, and created a brief situation where the controller could not see the error between the axis' actual position and commanded position.
The far more likely scenario is bad programming, but that happens easily. Bad data from a sensor, bad directions from a PLC or vision system... some sort of failure is inevitable. And programs have to be edited regularly by... insufficiently qualified personnel, shall we say? DCS/SafeMove/SafeOperation are the final line of defense, like airbags or seatbelts in a vehicle.
That fence video reminds me of this:
Oh, geez, that Chemical Brothers music video! I've always wondered how much of that was practical VFX with a real robot, and how much was just CGI.
I think the cast on his arm, suggests that scene took a couple of takes..... 
LOL...
doing robot operator training has it's moments... i have ripped weld torch off a robot (a few times) and even snapped an axis 5 motor by releasing the wrong brake .. not my fines moments, They were followed by "This is an example of what NOT to do.." and "do not use the PP to main button"...
like they say, if you haven't crashed a robot, you aren't working hard enough.
"PP to main button" and run
I learned to do as soon as I get a robot, to check for "WAIT Is the robot is not home".
Countless times that save me from crashing when the PLC aborted and run me again.
Goes back to my statement ---Never trust the PLC--- Do you own checks
Rule 1: always put okay-to-run checks in your code
Rule 2: someone will always find a gap in what you wrote to satisfy Rule 1
If you don't want to crash then there is a simple process you can follow.
1. Step through your entire program.
2. Run continuously through your entire program at slow speed.
3. Run continuously at full intended speed.
Repeat steps 1 - 3 for each variation of state (inputs/data) that can cause different actions in your program, such as logical branching (If/else, jump labels, loops, select statements) or variable positioning (modifying position registers or frames). You have to set up and test boundary conditions. For example if you are going to vary a Position offset programmatically , then you must first set a validation check of the upper and lower limit, and then test that your validation works and positioning works. That is actually a minimum of 5 tests, (outside upper limit, inside upper limit, middle, inside lower limit, outside lower limit).
If you really don't want your robot to crash you must consider all state variations and create a comprehensive test plan that covers all situations. By doing this you will start to realize better ways to program to reduce and bound your states so that you don't have such a large test plan required.
Without fail, if you miss a single test, the robot gods will come for you and make your robot crash.
I'm agree with HawkME, but the difficulty is to think about and to test ALL the configurations.
So, Try to test all configurations...and try to write "simple" programs, to reduce, as much as possible, the logical branchings.
When on installation use different controlers (PLC/Robot/Vision) control all external datas in all program to be sure that a modification can't create a bug in other program.
Reduce "Global variables and parameters" and prefere Local datas...
Regarding Nation's #47 post - The robot would have had him if it wasn't for the WaitUntil diGun_Open,1
Regarding crashes:
Does that include dress packs and cables/hoses, forgetting to turn off weld enable, etc.
I would add 2.5 to HawkME's steps with some intermediate speeds especially in tight spaces.
Sometimes I try to anticipate how future touchups may affect path & cycle time. What can I do to keep others from crashing and how to minimize damage if they do occur.
I think it's the near misses that have helped with the testing mindset as much or more than scratched paint. What really stays with me is when the robot does something unexpected, not the occasional jog in the wrong coordinate mode.
Following on Skooter's talk of minimizing damage, I always make sure that the motion supervision is at its best by setting armloads as best as possible before running LoadiID. That is the most often overlooked setting. I had a robot crash one time into another and the motion supervision triggered. The only damage to the robot that was struck was a bent bracket for the motor on lamp, which was easily straightened by hand.
You need to be a member in order to leave a comment
