I got two robots in multimove stations.
Options of control module:
Thanks for advice
Hello,
Unfortunately there is no “smart” way of dynamically have the robots avoid eachother. Not as a standard feature at least (there could be custom solutions).
You’ll have to resort to hard coding each robot from crossing paths with other robots at any given time.
I hope I am linking this other, similar thread correctly.
Thanks guys. I can program logic into robot/PLC to make sure, that only one robot at time can enter collision area.
I’ve been thinking about using STOP function in case robots TCP’s get too close to each other (using Distance function).
What about using timed interrupt ITimer to check positions? Would it overload CPU?
The above thread is a little confusing because it involves a lot of work-around ideas – using World Zones to set outputs high is the most traditional way of knowing where a robot is.
As far as stopping the robot, it’s best to use logic to never have to stop execution – rather WaitUntil before being allowed into the common work area.
That said, looks like you have the SafeMove option – so possibly use that instead of World Zones.
RS is limited to 20 World Zones. With current configuration, I need more then 20 DO to indicate position to PLC. My local rep recommended me to use multitasking option, to run another Task in background (STATIC type), which is going to take care about indication bits for PLC. So if this approach is going to work, I should have more then enough world zones for robot handshaking.
I’m not 100% what are capabilities of SafeMove, I will read the manual if I could benefit from it.
You should NEVER use world zones to avoid collisions. Read the manual and look at the examples, especially regarding path resolution, the robot tcp can pass through a corner, esp. if travelling really fast, and never trigger the output. Not only that, but also only the tcp is monitored, thus allowing the arm or wrists to collide. Furthermore, you run the slight risk that, because of timing, both could be heading for a collision, but both see clear until it is too late. Use the PLC or set outputs in one robot program for clear/ not clear and write the other robot task program to wait for clear before proceeding. In addition, you could write a background tasks to monitor the robots and Stop motion if you see that they are both not clear at the same time.
Building on what @lemster68 is saying, any background position sensing (including SafeMove) as the primary way to avoid collisions is dangerous. Use logic and have control of the situation. And better yet, when using logic, use the ClearZone signal rather than NOT the in the WorkZone signal to allow the other robot to take a turn in the common work area. Any signal lag you have is going to add to cycle time, but is better than crashing because the in the WorkZone signal lagged a little. Make sense?
The issue with World Zones using only the TCP is very true but can be improved by a SafeMove Tool Zones which allows you to draw a box around the actual dimensions of the tool.
Saw your post, so thought I’d make a comment
It looks like you only have safemove basic, so you don’t have the protective bubble options to my knowledge. Safemove-Advanced should only be a robotware keystring away, but I believe that is an expensive option.
The way I had robot collision confirmed was to used well planed world zones and logic within motion tasks, and that was from very experienced ABB R&D & Automotive Project robot guys that do our in-house training. The well planed parts of the worldzones is to avoid the points raised about fast movement, and/or cutting corners, oversize tools etc.
A current project I’m pushing a lot harder on speed and moving the simple logic from WaitDO, to TrigCheckIO. Basically switching, from asking before proceeding into the zone, too assuming good and this avoids slow fine points, but it will hit the anchors hard if it happens to be potential crash (The PLC should be avoiding these anyway)
This is potentially overkill, but I also hook up both robots worldzone outputs via a cross connection to another virtual signal. If this goes high, then it triggers an interrupt to do an quick stop and fault. It is effectively just another layer of protection. You can also use collision detection, which granted doesn’t stop the collision, but should lessen the damage if all else fails.
You could look at getting the upgraded multimove-synchronized option as well.
I’ve hit the worldzone limit as well(Seems like 20 per motion task, not controller thou), and have created “virtual” worldzones in another static task as you’ve mentioned. However, I only use that for process, and data control, I wouldn’t be trusting it for inter robot collision avoidance. Possibly look at temporary worldzones, but I dont think they’ll help - my understanding is they still use the worldzone resources and your just turning them on/off
You can, power cycle the controller, switch modes and move the worldzone allocation around. Maybe it can’t help you in production, but i have a different worldzone group for error recovery.
Hope I’m not revealing too much here.. RobotWare 6.08 will have built-in collision prevention for most robot types, similar to what is already present in Yumi. In a multimove system it will stop execution if a collision between the robots is predicted, no setup needed (except correct baseframes). Additional configuration (adding tool geometry etc) can be done in RobotStudio.
