How do I avoid dial table crashing the robot ?

I've integrated many dial tables at different customer sites which usually are 1. A motion axis part of the controller (Fanuc servomotor) 2. Have DCS Spd/Chk option. That being said, we have always incorporated 2 DCS CPC's for the dial; one 'not stop' for monitoring and one 'Stop Cat 1' which is disabling.

It really depends on your hardware. If it is not a Fanuc servo, I've always found some way to use a reference position (even if it is simply to monitor J1). Sometimes, if I'm lucky, the customer has ordered Space Chk Fnct. and I use that.

I usually use DCS Safety IO to activate one of zones based on some conditions. Most of our projects use Safety PLC + PLC (Allen Bradley Guard Logix, Omron NJ/NX with SL3300), that makes our life easier and more flexible for different application conditions.

You define user frame and user tool when you setup your limits for space function.

I am currently building a system right now with a dial table and LR Mate 200i. We are using a Powerflex 550 from AB.

First thing I did was have a relay wired into the enable bit of the table controller. When that relay is not active the table can't rotate. The Poll for the relay comes from the Robot. I created a reference position for the table. The bit that is set when the robot is in that reference position is then inverted in the I/O. This now means that bit is active when the robot is not in the reference position. So if the table is rotating and the robot moves into that reference area the table will stop immediately.

To prevent the robot from moving into the table area while rotating thus, causing the table to stop, We wire the table's "in position" bit into the robots inputs. In my pick program, which is the only program that moves near the table. There is a wait "DI[109]=ON" for table in position bit, This prevents the pick program from moving into the table area.

Using this setup the table and the robot haven't ever crashed. If the robot is off the table can't rotate. If the table in position sensor goes bad the robot can't move into the table area.

Quote from Fabian Munoz

UPDATE again

Bad news

I used simulation.

I created a box under UF2 then I select on pendant UF4 . Using the same tool and it works

The bad news

If I changed the tool, lets say tool 0 (0.0.0.0.0,0) but I still have the physical tool mounted. I will crash the dial because the space check function was reading tool 0 but I actually had a tool 1 on the robot

Display More

Why don't you just block your UF and UT number (from the program and also SHIFT + COORD), for instance you block it for always using UF2 and UT1, then you always have the same conditions?

DCS all the way!

Or use BG logic with current position system variable and mnutool.

At first you have to prevent controlling devices in one working area from two different HMI at the same time.

Quote from I3ooI3oo

I am currently building a system right now with a dial table and LR Mate 200i. We are using a Powerflex 550 from AB.

First thing I did was have a relay wired into the enable bit of the table controller. When that relay is not active the table can't rotate. The Poll for the relay comes from the Robot. I created a reference position for the table. The bit that is set when the robot is in that reference position is then inverted in the I/O. This now means that bit is active when the robot is not in the reference position. So if the table is rotating and the robot moves into that reference area the table will stop immediately.

To prevent the robot from moving into the table area while rotating thus, causing the table to stop, We wire the table's "in position" bit into the robots inputs. In my pick program, which is the only program that moves near the table. There is a wait "DI[109]=ON" for table in position bit, This prevents the pick program from moving into the table area.

Using this setup the table and the robot haven't ever crashed. If the robot is off the table can't rotate. If the table in position sensor goes bad the robot can't move into the table area.

I've tried to invert a bit for ref pos in the past. I recall this function not behaving as I expected; the controller ignored the bit inversion when assigned to ref pos. Can you confirm that it works?

Quote from retobor

I've tried to invert a bit for ref pos in the past. I recall this function not behaving as I expected; the controller ignored the bit inversion when assigned to ref pos. Can you confirm that it works?

The Bit being inverted does work, however if you look at the I/o on the pendent it shows off when not in the ref pos. Since the bit is inverted it is correct, if you look at the electrical signal it has +24v when the robot is not in the Ref Pos.

Quote from Fabian Munoz

l3ool3oo

The concept of ""DI[109]=ON" does not help me because I'm jogging the robot manually

"If the robot is off the table can't rotate."

This is what I'm talking about. It's not about the robot crashing the table. It's the other way around

In my setup it doesn't matter how the robot is moving when it is in the ref pos the table can not rotate as the signal that controls the rotation is broken by the relay that is controlled by the ref pos.

Quote from Fabian Munoz

what I meant was one guys uses the pendant and another guy uses the PLC HMI. You can not avoid that

I did understand that, but at least in EU you have to avoid that. Whatever it cost.

At least if the safety fence is opened. You can use f. e. the TP switch (that's not safety related).

I'm configuring many robots in conjunction with external machines/devices that can be moved by HMI of PLC. And we always avoid using HMI and teach pendant at the same time.

But you need your solution as well, because one can switch to plc HMI when robot is in the area of the rotation table.

Quote from Fabian Munoz

neighbour1

How do yo do that ? because right now I can change the uf and ut (shift+coord) at any time and if the PLC is reading it, it would react different

I always do it like:

$MNUFRAME_NUM = 2

$MNUTOOL_NUM = 1

and then run it in BG (fast if needed) and then you block also when pressing SHIFT + COORD

I read half of what was going on in this thread...But I don't have much time and wanted to offer my suggestions/experience real quick.

1.) Flags in the program which then activate a check in a BG_Logic job...if F1 = on and UF != 2 and UT != 1, alarm

2.) Use DCS or Interference. Space Check to me is terrible, but I've only been in robots for 4 years, so I may be missing out on a great thing about Space Check...My opinion of Space Check being terrible stems from the fact that I understand it tracks TCP ONLY! Whereas DCS/IIC can track a MODEL regardless of UF/UT.

3.) I was going to suggest you could set up boxes like DCS or IIC and background track with the CUR_TCP variable, but that number of course changes with whichever User Tool you are using (and only updates when the robot is moved). Now I'm curious if there is a CUR_TCP like variable that only tracks robot position if the UT = (0,0,0,0,0,0) and in world frame...Then again you could always write a background track job that is based off of a Null TCP that is always set Null at the top of the program...etc etc etc, but still the CUR_TCP variable only updates when the robot is moved...hmm...

4.) You could have a BG_Logic job that sends the UF and UT to the PLC at all times with a Group Output...or the PLC could explicit message a Register you are background logic setting to the current UF and UT. Then of course the PLC can restrict what can happen if the Robot isn't in the right setup.

I read a bit more of the thread and it seems like you did solve your problem...but anyhow, I'm just going to leave this here anyway