Have You Ever Crashed A Robot?

Good luck!

If you find them, you've either found God, or the world's best con artist.

My standard is that if you don't crash a robot at least once per project, you're not really doing the job.

Quote from ablant527

I'm in search of the programmer with 5+ years of programming that has never crashed a robot.

I really don't have anything constructive to add to this thread.

Quote from SkyeFire

My standard is that if you don't crash a robot at least once per project, you're not really doing the job.

I think anyone that deals with robots, would categorically agree with you there.

I'm very proud to say I am not a virgin in this area.

Anyone who has never crashed a robot has never programmed a robot.

The one I remember the most was a cell with two ABB 1400 facing each other. I started it the run, there were at home and I guess my initial point was bad (obviously) are they just went full speed toward the fixture, they crossed their arms like forming and X. I just heard one sound. But, you know what, I fixed the motion and the rest was perfect

Owning a robot is like owning a reptile. It's not yours till it bites you, or in this case crash it.

I program off the teach pendant on old robots that still work great.

Some of my early crashes were pretty spectacular. With programming with the operators we have

now, my programs are getting the job done, with as much error proofing (idiot proofing) as i possibly

can. Have had many more crashes caused by the operators lately.

No such thing.

I remember installing a Yaskawa robot. We were exhausted. Pulled a few 20 hour days to get the application up and running. And when we started the SAT the robot thought he'd finished a stack, went straight for the next one without resetting the counters, and made short work of the rather sensitive gripper.

We called it a day. Packed up. Went home. 23rd of December. Came back on the 4th of January, had the application running on the 6th.

Only ones I can think of are sim guys.

ABB project I was working on, one of the pounce points was all zeros. Robot proceeds to happily punch itself, folding the vision camera bracket in half, requiring re-calibration. Only delayed the project by about half a day, but it was embarrassing.

Another project where I was doing line tracking with a Fanuc, accidentally deleted a via to home, and took out the lift gate window on a fully finished Ford Escape. Plant was surprisingly cool with that though.

overall i am pretty happy with my track record even if it was not without a stain... I did bump robot against various things plenty of times but fortunately damage if present was always minimal and easy to fix. two times scratching paint on the robot wrist, once broke plastic gripper fingers etc. other than that I never damaged robot arm... The worst case was some sloped tray that was supported by own post made of ALU extrusion. in one week it was pushed three times. each time it was couple of hours to fix the stand and do the touchup. i heard that same tray being bumped later as well...

maybe should have trimmed down speeds in T1 for that robot as tooling is long.

another one worth mentioning was 5-axis palletizer that needed PAL mode turned off so it can pick and place parts that are tilted. well, there is a thing with KUKA that jog motions can get weird in such case if points are Cartesian. fortunately this one was only a near miss as i managed to stop it in time. i noticed that robot in this configuration was moving really weird and differently than expected when stepping though program to touch up motions. then changed declarations in DAT file to use AXIS instead of POS and problem went away.

The worst crash I think I have had is when we were out of town working onsite and in the sweep table job I forgot to put WAIT for R1,R2 and R3 home...well with all things combined, the guy touching up some points never sent the robots completely home. Table went to sweep and took out all 3 robots. We ended up staying for a couple more days after that

I love how this topic turned into a set of stories from our experience. Keep them coming.

You learn from your mistakes

I tell you, once you crash, you will remember what you did and you'll never do it again. I'm at the point now, after teaching many brands from more than 25 years, that I check and recheck, and triple check motions and scenarios at different speeds. Sometimes I failed in the logic but (because of a misunderstanding). I DO NOT TRUST THE PLC HANDHSAKING PROGRAM AT ALL. I always simulate I/O and run the program a million times. Then I give control to the PLC. Another thing, and I can write a book in this topic, many times, things (cylinders, dial tables, fixtures) crash the robot a without a robot fault. How many times I get the OMG "the robot crash the fixture", then you go and check and the fixture was in the wrong location OR after picking thousand of parts with a vacuum tool, I get " the robot is not picking parts, can you check the program, maybe the point moved ?", My blood boils when I hear that

Quote from Fabian Munoz

You learn from your mistakes

Sometimes you win, sometimes you learn.

Quote from Fabian Munoz

I DO NOT TRUST THE PLC HANDHSAKING PROGRAM AT ALL.

Me neither. Sadly, lately I keep getting stuck on projects where 90% of the robot code is "black boxed", including all the PLC interfacing, and I'm supposed to just "follow the recipe" and not ask questions about how it works. Which makes it fun when something in the black box fails, and I'm expected to somehow fix it.

"Can I get some information on what's happening inside the black box?"

"Sorry, that's confidential, just fix it."

Quote from Fabian Munoz

I always simulate I/O and run the program a million times.

And write test programs that emulate what the PLC or other equipment should (and shouldn't!) send. At some point you're at the mercy of the PLC program, but at least you'll know how your program will respond if the PLC sends over some invalid value (and hopefully protected against some of them, like showing an actuator in two places at once, negative style numbers, etc)

Quote from Fabian Munoz

after picking thousand of parts with a vacuum tool, I get " the robot is not picking parts, can you check the program, maybe the point moved ?", My blood boils when I hear that

Oh, that one. And they won't admit that someone changed something upstream on the part or process -- they just want to make it Your Problem so they can stop worrying and blame Somebody Else (you).

A fun story in that category: I get called in because my vision system is suddenly failing to find parts. Turns out, the part was changed, and one of the key features the vision was looking for had been eliminated. But of course it was my/the robot's fault....

If you do not know, ABB is my favorite. Many do not know about the simulated motion available on those. It works exactly like the robot is actually moving. Other brands call it "machine lock", I think. I have used it many times for debugging and NOT crashing. Especially when I do not trust the PLC programming. It is great for debugging handshakes and such because I can watch what is going on in the pendant without having to watch the robot at the same time.

There was one job where the robot had crashed into a fixture a few times and the mechanical guys were going to kill the plc guy if it happened again. I put the robot in simulated motion, watched the pendant, and if the machine cycled when the robot was "in" it, I would tell him that he had just crashed it, but only simulated. Saved his behind several times while he debugged.

When I say it is exactly like real motion, I mean it. World zones even work. If you change the speed override it "moves" slower and faster, accordingly. I have even had to update the rev counters if the power got cycled while in simulated motion. I do not believe it is the case like that with the newer robotware anymore.

Lemster68

Absolutely.........

Kawasaki has 'Dry Run Mode', requires ALL safety to be engaged as per normal running.

Executes all code as it would, all axis monitoring values are changing (as though it is moving, but it is not).

Very good technique to use.....in fact the current installation(s) I'm involved in, I shall be utilizing this feature to prevent the robot from being turned into mush.

The worst crash I had was a program where I was incrementing a position register to move to different positions along the X axis. I had completed the first cycle and everything worked perfectly. Then I started the 2nd cycle and the robot went full speed all the way to the other side of the work cell and smashed the end effecter into a fixture. I had forgot to reset the Position register back to 0 at the beginning of my program.

Fortunately it was minor damage (broke some bolts on the end effector) and did not hurt the robot at all.

Copy and paste issue for me......the reason I steer clear from it now.

2x 4 axis Kawasaki palletizer robots.

Both are used to sequentially pickup 6ft x 4ft panels ejected from a saw from the same location alternating doing an 'up and under'.

Both were waiting, for PLC signals

I copied the same wait signals and command to both robots and forgot to change the other robot.

I was the other side of the saw (out of view).

Heard the start, the crunch and then the silence descended as I sheepishly peered round the corner.

Luckily the aluminium frame grippers made great shock absorbers that day and were soon squared up.

Resolved the mistake and then a quick..............

To add to that, even the jogging will be simulated. Also, If I am walking away from a robot I am not finished teaching, I might put it in simulated mode so no one can come along and try to do something stupid like run it.