How do I avoid dial table crashing the robot ?

    I've been handshaking with presses, other robot, dial tables, fixtures, you name it but recently I've been interrogated by the PLC guy about it.


    The question I have for you is: How do I avoid dial table crashing robot ? Assume I have a taught user frame for the dial station (UF#2) and UT#1


    First problem: I jogged the robot on top of the dial and I left there on uf0 and ut0. How does the PLC not allow dial to rotate ?


    Second problem : While running auto, I change the user from the pendant Can I disable that ?


    There are more situation to describe

    I just want open the post to opinion and see what people do to avoid interference

    Retired but still helping

  • Fabian Munoz

    Changed the title of the thread from “How do I avoid dial table crashing robot ?” to “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.

    Sometimes I dont get DCS. I need an answer that does not involve DCS


    Thanks for the answers but here is my issue. If I'm using Space Check Function and lets say I used UF#2 BUT then I jog the robot in UF#whatever inside the space check. Does the function works properly ?

    I'm going to try that on the simulation and see how it works

    Retired but still helping

    UPDATE


    I tried it on the simulation.

    Seems to me that once you define the zone (box) using whatever tool and frame, the box stays there regarding. SO, if I jog to that box in different ut and uf, the software still detects the interference

    This is good, I'll keep testing

    Retired but still helping

    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


    I guess I can use the space check but internally the PLC needs to read the tool that I have. With a simple logic the PLC can find out if it is safe or not

    Retired but still helping

    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.

    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?

    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


    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


    Sorry guys, I'm not want to be a pain but i'm not asking questions when the conditions are perfect and the operator are angels. If the maintenance guy jogs the robot on top of the table under any circumstances (i mean , any UF or UT) how is other maintenance guy that's playing with the dial from the HMI not enable to rotate ?

    I many years of work, the condition was simple Robot has to be home or at a reference postion, period. In the company that I'm now they basically want to know where the robot is all the time

    Retired but still helping

    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?

    Thanks everybody. I think I have some tool to explain the PLC guy how this process suppose to work.


    HawkME

    Sometimes I do not get DCS

    For the read out, instead of BG we use explicit messaging


    So, based on the posts I'm using space check. The plc checks two things. The tool and the DI from space check and it works. If the incorrect tool is selected, dial does not rotate OR if the correct tool is set but the space check detect the robot the dial does not rotate



    hermann

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


    Thank you again. I'm happy with the results

    Retired but still helping

    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 :smiling_face:

    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 :smiling_face:

Advertising from our partners