External Deadman via Robot I/O

    First off, I'm using an R-J3iB V6.40 controller with an R-2000iA-165F. I'm a new programmer in the robot world and I'd like a suggestion to the following problem:

    So my boss wants an external deadman switch that the operator has to keep pressed in order to keep the program running. Here are a few conditions:

    1. We cannot use the teach pendant because it's heavy, expensive, and impractical for the operator to hold while they do other tasks. We have a handheld switch with 1 NO and 1 NC contact wired to RI 2 and 4.

    2. My boss is adamant that he wants to use the Robot I/O via EE cable instead of installing a peripheral I/O like I suggested. This is because he doesn't want a "custom cabinet" that can't be switch out easily.

    3. I have a main program calling sequential subprograms for different stations in a pick and place operation if that matters.

    4. As soon as the switch is released, both motion and logic execution must stop until the switch is pressed again.

    5. No additional buttons must need to be pressed to resume the program. Only the switch should need to be operated.

    6. The program must resume where it left off and not Abort.

    7. T2 mode can be used with the speed override limits already removed.

    8. I've briefly tried activating a User Alarm via a concurrent program and setting the effect to Pausing all programs and stop motion (Value 38 (6+32) according to Robot Whispering) without success.

    9. My colleague suggested setting Max Speed to 0, but I haven't tested that and my chief concern is that it won't interrupt a motion currently being executed.
    10. My boss has "solved" this problem by simply putting a WAIT instruction before each command. I will do that if that's what is necessary, but it bloats the program significantly. I'd like a much more streamlined option that doesn't literally double the number of lines in the program.

    Please reach out with suggestions, thanks.

  • Go to Best Answer

  • Nation February 19, 2024 at 5:15 PM

    Approved the thread.

    First off, why does the operator need to hold in a deadman? Is the operator in the workspace of the robot while it is running? Because if so, hoo boy.

    Second, no, the EE connector can't be used for an external safety device. Also, are you hooking into the connector on the arm, or splicing into the connector on the servo amp?

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

    No, the operator certainly isn't in the path of the robot when it's moving. We save that for interns and programmers that know exactly what they're doing. The operator just has to move into the operation area during a cycle, and this is the desired method of stopping the robot. I'm following the instructions of my boss, who is our current robot programmer. He wants the deadman to remain active throughout the cycle instead of just when the operator needs to move into the operation area.

    What we have is a safety limit switch that the operator will press. It is wired to RI 2 and 4 in a small enclosure on the side of the robot, which connects the sensors to the End Effector cable that plugs in by Servos 4, 5 & 6.

    I guess I am having trouble parsing what you want to do here. Pictures would help.

    Tell me if I have it right:

    • The robot moves around an area that both the robot and the operator need to be in occasionally, albeit not at the same time.
    • You want the robot to stop when the operator needs to be in that area. I am assuming to load or unload product or materials or to do maintenance.
    • You want the operator to actuate this safety switch when they need to do this, before entering the area.
    • When the leave, they will switch the safety switch to the opposite state, and the robot will resume operation.

    If I am correct, the proper way of going about this is to use the fence safety circuit. It is safety rated (at least to 1998 RIA standards). The EE connector is the absolutely wrong way of going about this, as it is not safety rated.


    This particular line confuses me, as it implies the robot is still moving while the operator is in the area:

    Quote from Ace's_Robot_Delivery

    He wants the deadman to remain active throughout the cycle instead of just when the operator needs to move into the operation area.

    So active at all times? If that is the case, definitely fence circuit.

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

    It's more of a remote Enable switch. It's not just to stop the robot in order to move safely into the area, it's to stop the robot period. My boss (not to throw him under the bus, but it should be said that I'm following instructions instead of just my own intuition) wants this to be active during the entire program as a sort of remote pause switch instead of a safety switch. It needs to be activated in order for the robot to do anything. I was recommended to make a subprogram that sets Max Speed to 0 when the switch is released, so I'll go try that.

    1st the switch you are using has 1 NO and 1 NC contact, and it is not safety rated. "I'm following the instructions of my boss, who is our current robot programmer." Well he should know better.

    None of what you are attempting is safety rated, all I will say is will your Boss jump in front of the bus when it comes. Because it will come.

    We are talking Human safety here, it will not/can not be done with a 20 dollar non-safety push button and programming.

    DCS at the least, dual channel safety rated deadman device, with a 0% speed tied in through DCS speed check is doable.

    We would utilize light curtains/area sensors with DCS position checks, a 0% speed in background if the operator entered the area, and a DCS speed check. Of course only the future of our company as an integrator relies on the operators safety.

    With 43 years of industrial maintenance and robot programming/installation background I can tell you when the $#!t hits the fan, YOU will be the fall guy. I'm sorry, it needed to be said and it's not meant as a slam against you ACE.

    That robot is too old for DCS, at least of the software variety. Earliest software DCS was V7.5 I believe.

    It does have hardwired DCS, and this is what you need to use. The fence circuit would be the proper way of doing this. That, or maybe the servo off circuit. Depending on the cell setup, you man need additional J1/J2/J3 safety rated cam switches, and/or multiple light screens for watching the robot position, safely. You need to have a proper risk assessment done.

    Not knocking you. I'm glad you are here asking questions. Your boss's approach to the problem is wrong, and could be DEADLY wrong.

    Your boss is exposing your company to some serious liability by not following standard practices in the robotics industry regarding safety.

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

    In his defense he only has experience and not formal instruction, but yeah I agree. I'm going to put my foot down and demand that this be done properly. It crosses a line when someone's life is at risk.

    On another note, are there defined standards in place for this case? I know there are OSHA regulations and that, but is there like a handbook or other reference material I could look at?

    ACE,

    here's a way to get zero speed, before they had 0 speed. Dirty deeds done dirt cheap. LOL


    Override override.

    I wanted the Yellow collaborative to “stop” when red zone was broken. MCR_GRP[1].$PROGOVERRIDE is a multiplier of gen override, usually set 100. I set MCR_GRP[1].$PROGOVERRIDE to 10, and $MCR.$GENOVERRIDE to 1, can’t see it moving. Set it back when the zone is clear.

    Quote from Nation

    If I am correct, the proper way of going about this is to use the fence safety circuit. It is safety rated (at least to 1998 RIA standards). The EE connector is the absolutely wrong way of going about this, as it is not safety rated.

    Not to mention, the deadman enabler doesn't have any effect when the robot is in Auto mode.

    I think we need to take a step back, because it sounds like we have two different things here. Rigging a button to stop the robot is easy. Doing so in a Safety-rated fashion is much harder.

    If the operator holding the button is going to be outside the fence, safely out of reach of the robot, then a simple button linked to, say, IMSTP or HOLD on the UOPs would work. Those can be mapped to DOs using Rack 0, Slot 0 (assuming that trick works on a robot that old), and the DO could be fired from a BG program based on the RI wired to the button. A bit hacky, but can work. Letting go of the button would stop the robot, but holding the button again and pulsing the Start input should let the robot resume from where it was stopped.

    But the moment the operator comes within reach of the robot, none of this is valid anymore. The only Safety-rated means of stopping a robot that is in Auto mode are E-Stop or the Fence input, on the dedicated safety connector. In Teach mode, the Fence input is ignored, effectively replaced by the teach pendant deadman.

    So:

    1. What does your boss want this button to do in Auto?
      1. In Teach?
    2. Does your boss expect this button to act in place of a Safety interlock (aka, E-Stop, Fence, pendant deadman?)?
      1. If "yes", then he's in complete violation of all applicable safety standards, full stop
    3. Where will the operator be when this button is used to stop the robot?
    4. Once the robot has been stopped in this non-Safe fashion, what is protecting the operator?
      1. There pretty much has to be a safety gate, wired into the Fence input, that blocks any human access to the robot's working volume without opening that gate
        1. If not, see 2.1
    5. What is the intended sequence of operations for an operator using this button? aka:
      1. Stop robot.
      2. Do something outside the fence
      3. Open the fence
        1. lockout
      4. Enter robot's working zone
      5. Exit zone
      6. Close fence
      7. Hold pseudo-deadman
      8. Hit Start
      9. Something like this

    Thanks for all of your input. I found a "Safety Enabling Switch" from Automation Direct that should suffice, and convinced my boss to use the modular I/O that we have to tie the switch to the UOP and fence signals. Question though: does IMSTP Input count as a safety-rated stop condition? It stops the robot and turns off power to the servos according to the Handling Tool manual.

    Quote from Ace's_Robot_Delivery

    does IMSTP Input count as a safety-rated stop condition? It stops the robot and turns off power to the servos according to the Handling Tool manual.

    No. Basic rule: if it's a DI, RI, UI, GI, SI, or anything else configured through the I/O menu, it is not a Safety-rated input.

    I can't speak specifically to the RJ3, but on the R30s I'm familiar with, there is a dedicated connector just for Safety signals, completely separate from any I/O. This is where the Fence and External E-Stop should already be wired in.

    IMSTP is a bit misleading, because while it has similar effects to losing a Safety input, it does not have the redundancy and anti-tamper protection of an actual Safety signal. For example, you can "hotwire" IMSTP in the pendant configuration settings. An actual Safety signal would require deliberate alteration of dual-channel wiring pairs.

Advertising from our partners