Robot Collision

    Morning All,

    I had an issue yesterday with a cell. The cell is quite tight and contains two i710 robots, so have had to create collision zones between them for certain moves. It has been in and running with full functionality since Christmas but yesterday they collided resulting in damage to the robot mounted field IO module and cables.

    My concern is that the collision zone call is in a similar place in both robots, could this have caused an issue? I have tried to recreate the fault in manual and ran both robots from the TP's (T1 50%) and each time they stop and wait for the relevant input back from the PLC, even tried running both collision zone calls simultaneously (with another person on the other TP and R100 took precedence as i expected.

    The only differing factor i can think of is the speed - but it was during a production break so i didn't have time to run in manual at 100% T2.

    I simply can't fathom how it has happened. I'm going to install a space check as a 'belt and braces' check but if anyone has had this happen before then please shout up!

    Cheers

    Thanks for the replies - i'll attach the report that i made for the maintenance department at the time of the collision

    Robot Collision Zones for FIPG.docx

    Hopefully this explains the issue. Both robots were clear of the collision zone but were trying to enter it at almost the same time. I am thinking i may have to put some extra logic in to account for this - the timing of the robot interaction can change from cycle to cycle - depending if one side of the cell has an issue or is doing a different task

    Thanks

    If I had to guess, I'd say this is a switch timing issue. All of the logic is correct, but you finally hit the 'one in a million' timing of the cycle to play Rock 'em Sock 'em. If what I'm thinking is correct, you'll likely be able to run this for months at a time, without any issues - and then this will happen again, seemingly at random. (One in a million is a couple of times a day in some places, remember.)

    If I had to start looking for a way to prevent this, I would look at using a SKIP command on one of the robots tied to a Flag, driven by outputs from the other robot (set up zones, if you have the memory available.) If any of the conditions of the 'other' robot cause the Flag to turn on, the motion of the other robot would be halted. Might actually have to be both, depending on the positioning of the robots - even if you stop the one in the zone, it could still get smacked by the other, potentially. In which case you could volley a bunch of flags back and forth - if the one halts due to a flag from the other, have it throw a flag back that halts, etc.

    This is not an elegant solution, to be sure, but for the couple of times a year it will force a stop (and probably require operator intervention to recover from) it'll save you having to replace FieldBus I/O stuff every time it happens. And is fairly straightforward to implement and test (which is the type of solution I usually go for first.)

    Best of luck!

    Consider that that communication between the robots and plc is not instantaneous. Could be on the order of tens of milliseconds. This delay can leave inputs on in both robots at the same time for the duration of the communication delay.

    Simple fix, add a small wait in between the request and waiting for the plc response.

    DO[75]=On

    Wait 0.2 sec

    Wait DI[75]=on

Advertising from our partners