Logix 5000 forced inputs: actual status?

I looked everywhere I could, but I haven't found a solution. Hope this isn't a stupid question, but is there a way to see the actual status of an input that has been forced without access to the actual input module or wiring?

For example, I might have a situation where an open connection occurs in wiring to a non-critical photoeye one afternoon. To allow production to continue, the input is forced on. The maintenance folks run through the wiring and "think" they've fixed the problem. The outcome is reported to supervision, and the maintenance folks leave at the end of their shift. The incoming shift supervisor now wants the force removed.

In the program (remote access), all I see is the forced status of the input. I don't know of a way to check the actual status. Is there a way to see this? I'm running Logix 5000, of course.

Added: ditto for SLCs, if possible, while I'm at it.

Well if you search ' Find forces in rslogix". You will get what you want but anyways. here is the post by ron which explains everything.

http://www.plctalk.net/qanda/showpost.php?p=457074&postcount=9
http://www.plctalk.net/qanda/showpost.php?p=371357&postcount=5

tsmith35 said:

I looked everywhere I could, but I haven't found a solution. Hope this isn't a stupid question, but is there a way to see the actual status of an input that has been forced without access to the actual input module or wiring?

For example, I might have a situation where an open connection occurs in wiring to a non-critical photoeye one afternoon. To allow production to continue, the input is forced on. The maintenance folks run through the wiring and "think" they've fixed the problem. The outcome is reported to supervision, and the maintenance folks leave at the end of their shift. The incoming shift supervisor now wants the force removed.

In the program (remote access), all I see is the forced status of the input. I don't know of a way to check the actual status. Is there a way to see this? I'm running Logix 5000, of course.

Added: ditto for SLCs, if possible, while I'm at it.

Click to expand...

That's an interesting question, to which I don't have an answer. I believe if you look at the input in the controller tag window, it will show you the forced status of the input in red, which doesn't necessarily tell you if it is actually "ON" or not.

I would think there is a way, but I don't know what it is. One workaround I can think of is (depending on how many places in the logic the input is used) is to "branch around" the places in the logic where the input is used to keep the machine running (Temporarily, of course!). For example, if the photo eye input is used as an XIC to insure that something has happened that the machine will shut down if it doesn't, then add a shorted branch in parallel to the XIC. If the input is used as either an XIO or XIC in an alarm rung, then temporarily disable the rung with an AFI instruction. This will in effect do the same thing as the force is doing. Then you can remove the force and see the actual state of the input in the controller tags. If all is working as it should, remove any shorted branches or AFI's. If not, re-enable the force, then remove the rung edits. Be careful about leaving a force on an input though, even on a "non-critical" photo eye! That eye will stop being non-critical the moment some equipment gets torn up because a jam went undetected, or something spills all over the floor, or god forbid someone gets hurt. Then you may get hung out to dry. It's funny how fast some managers can forget ever giving out such an order to force something. Most of the time, if a sensor was not critical, then the designers of the machine wouldn't have gone to the trouble and cost of adding it to the system.

You should tell your boss that you are uncomfortable leaving a force in the system. It is bad practice, and can be a slippery slope. You may well be told that if you aren't comfortable with it, then he will find someone who is, but at least you will have gone on record with your objections. Make the manager own his decision to compromise machine integrity for the sake of production

Anyway, sorry for the rant. I just hate to see forces being used this way, as substitutes for corrective maintenance. IMHO, forces should only be used for commissioning and short-term troubleshooting, and even then only when all personnel near the machine are made aware of the situation. They should NEVER be left on a machine when the technician walks away.

Cheers,
Dustin

bornwild said:

Well if you search ' Find forces in rslogix". You will get what you want but anyways. here is the post by ron which explains everything.

http://www.plctalk.net/qanda/showpost.php?p=457074&postcount=9
http://www.plctalk.net/qanda/showpost.php?p=371357&postcount=5

Click to expand...

Bornwild, thanks for the links. I am able to find the forces, but I just can't see what the "unforced" status (on or off) of the forced inputs would be once the forces are removed.

here's what I "THINK" that you're asking ... please correct anything that is wrong ...

(1) an INPUT signal was previously forced ON – in order to temporarily bypass a missing signal from a defective field device ...

(2) the field device has (presumably) now been repaired ... therefore, the force is PROBABLY no longer needed ...

(3) you are now online with the system from a REMOTE location ...

(4) you want to know if there is any way to determine (solely from your REMOTE location) whether or not the signal from the field device would indeed be ON – if you were to remove the force ...

if all of my assumptions above are correct, then the answer is "no" ... in simple terms, you'll see a status of ONE in the bit/box – and there is no way to tell (remotely) whether that ONE status is being provided from the input device - or from the force alone ...

explanation: since the FORCE on an INput signal is applied UPstream of the processor's bit/box, the force DOES affect the status of the bit/box ... specifically, there is only a single bit/box associated with the input signal that you're dealing with – and that bit/box is now being held at a status of ONE by the force ...

suggestion (1) ... consider having someone locally inspect the LED on the front of the input module ... a force for an INput signal will not affect the LED ... therefore, if the LED is ON then presumably the field device is now providing the ON input signal that you require ...

suggestion (2) ... IF (big IF) it's safe to do so, then you might consider temporarily removing the force ... if the bit/box retains its status of ONE, then it would seem that the field device has been repaired – and is now providing the ON input signal that you require ...

DISCLAIMER! ... personally I take a dim view of working on systems from a remote location ... it's hard to imagine a way to INSURE that operations like this could be done in a completely safe manner ... I strongly recommend that you – or someone else – do this type of operation LOCALLY so that the machinery could be closely monitored for safety reasons ...

bmacattack33 said:

That's an interesting question, to which I don't have an answer. I believe if you look at the input in the controller tag window, it will show you the forced status of the input in red, which doesn't necessarily tell you if it is actually "ON" or not.

I would think there is a way, but I don't know what it is. One workaround I can think of is (depending on how many places in the logic the input is used) is to "branch around" the places in the logic where the input is used to keep the machine running (Temporarily, of course!). For example, if the photo eye input is used as an XIC to insure that something has happened that the machine will shut down if it doesn't, then add a shorted branch in parallel to the XIC. If the input is used as either an XIO or XIC in an alarm rung, then temporarily disable the rung with an AFI instruction. This will in effect do the same thing as the force is doing. Then you can remove the force and see the actual state of the input in the controller tags. If all is working as it should, remove any shorted branches or AFI's. If not, re-enable the force, then remove the rung edits.

Click to expand...

That's a good workaround. Thanks! There are only a few references to the PE, so it won't be too painful.

bmacattack33 said:

Be careful about leaving a force on an input though, even on a "non-critical" photo eye! That eye will stop being non-critical the moment some equipment gets torn up because a jam went undetected, or something spills all over the floor, or god forbid someone gets hurt. Then you may get hung out to dry. It's funny how fast some managers can forget ever giving out such an order to force something. Most of the time, if a sensor was not critical, then the designers of the machine wouldn't have gone to the trouble and cost of adding it to the system.

You should tell your boss that you are uncomfortable leaving a force in the system. It is bad practice, and can be a slippery slope. You may well be told that if you aren't comfortable with it, then he will find someone who is, but at least you will have gone on record with your objections. Make the manager own his decision to compromise machine integrity for the sake of production

Anyway, sorry for the rant. I just hate to see forces being used this way, as substitutes for corrective maintenance. IMHO, forces should only be used for commissioning and short-term troubleshooting, and even then only when all personnel near the machine are made aware of the situation. They should NEVER be left on a machine when the technician walks away.

Click to expand...

Yes, you're correct; I don't like forcing I/O, especially while away, but in my example, it's for a PE that is used for early jam detection. There is another sensor that is used for jam detection, but this PE detects them within 1/2 sec (vs about 5 sec for the other PE). It was added to minimize scrap generated by jams, and not for any other purpose. The location of the PE makes it susceptible to damage (both to the PE and the wiring). Perhaps the best solution will be a protective bracket and damage-resistant cabling.

The PE is mounted on a removable assembly that connects all I/O and power through a single plug. Assemblies can be swapped out to change tooling, but the plug and associated cord and receptacle hardware are prone to trouble ("if it moves, it will eventually break").

The normal method that is used to bypass the PE while troubleshooting and repair is to put a jumper on the input terminal of the module, but this led to another issue: the maintenance guys couldn't remove the jumper to check for continuity through the PE without risking a machine shutdown. Worse yet, jumpers could be forgotten or placed on the wrong inputs. I was looking into using forces to make it easier to find the problem and verify the solution, which is the origin of my question. Everything has its own advantages and disadvantages.

Ron Beaufort said:

here's what I "THINK" that you're asking ... please correct anything that is wrong ...

(1) an INPUT signal was previously forced ON – in order to temporarily bypass a missing signal from a defective field device ...

(2) the field device has (presumably) now been repaired ... therefore, the force is PROBABLY no longer needed ...

(3) you are now online with the system from a REMOTE location ...

(4) you want to know if there is any way to determine (solely from your REMOTE location) whether or not the signal from the field device would indeed be ON – if you were to remove the force ...

if all of my assumptions above are correct, then the answer is "no" ... in simple terms, you'll see a status of ONE in the bit/box – and there is no way to tell (remotely) whether that ONE status is being provided from the input device - or from the force alone ...

explanation: since the FORCE on an INput signal is applied UPstream of the processor's bit/box, the force DOES affect the status of the bit/box ... specifically, there is only a single bit/box associated with the input signal that you're dealing with – and that bit/box is now being held at a status of ONE by the force ...

suggestion (1) ... consider having someone locally inspect the LED on the front of the input module ... a force for an INput signal will not affect the LED ... therefore, if the LED is ON then presumably the field device is now providing the ON input signal that you require ...

suggestion (2) ... IF (big IF) it's safe to do so, then you might consider temporarily removing the force ... if the bit/box retains its status of ONE, then it would seem that the field device has been repaired – and is now providing the ON input signal that you require ...

DISCLAIMER! ... personally I take a dim view of working on systems from a remote location ... it's hard to imagine a way to INSURE that operations like this could be done in a completely safe manner ... I recommend that you – or someone else – do this type of operation LOCALLY so that the machinery could be closely monitored for safety reasons ...

Click to expand...

Ron, you're right on the mark. Suggestion (1) is the current method that we use for checking inputs. Works pretty well, too.

bmacattack33 proposed a workaround to allow suggestion (2) to be used with decreased risk, so that will probably be a good solution for inputs that are minimally referenced.

As for the disclaimer, I agree with your views. I am extremely picky about what can and can not be safely done remotely. If there is any risk of damage to equipment, or if I have any hesitation about anything being done remotely, I either use a trusted pair of eyes for observation (via cell phone) or go in and see it myself. If it's something safety-related, my own eyes on the equipment are the only acceptable solution.

Thanks to everyone for the insight. Just another reason I like visiting this site!

The normal method that is used to bypass the PE while troubleshooting and repair is to put a jumper on the input terminal of the module, but this led to another issue: the maintenance guys couldn't remove the jumper to check for continuity through the PE without risking a machine shutdown. Worse yet, jumpers could be forgotten or placed on the wrong inputs. I was looking into using forces to make it easier to find the problem and verify the solution, which is the origin of my question. Everything has its own advantages and disadvantages.

Click to expand...

Here is another method I have seen used that you can consider to ease troubleshooting. Like any kind of "bypassing", it has to be used at your own discretion, of course.

If the machine has an HMI that has decent security features, you can add a maintained push-button on a secure screen that will bypass the input in the logic. Address the button to a boolean tag in your PLC. Branch around XIC's of the input with XIC's of the bypass tag. Put an XIO of the bypass tag in series with an XIO of the input. If you are going to go this route, consider having an XIC of the bypass popping up a message banner on your HMI that states that the eye is bypassed, for transparency, and to help the technician that turned on the bypass remember that it is there.

It's certainly easier than installing jumpers on running equipment. If it's a frequent issue, it may be worth consideration.

Cheers,
Dustin

Thanks, Dustin! That's a nice idea, and it would help keep me out of the loop. Thank you.

This is one reason I like to buffer IO and when you need to force something do it to the buffered IO and not the field IO.

If the OP had this he would not have this issue.

The Plc Kid said:

This is one reason I like to buffer IO and when you need to force something do it to the buffered IO and not the field IO.

If the OP had this he would not have this issue.

Click to expand...

That's another good solution, though it will take some time to get it set up. The programs I inherited were written by a half-dozen different programmers. Some of them used buffering, and some did not. Some used the unbuffered tags directly, ignoring the buffered tag or used both.

I like the idea, though. Thanks!

I agree with buffered and then you can just setup a debug as an OR statement to the actual input.

IMHO forcing should not be used to "simulate" the response to an I/O device failure.

IMHO forcing should not be used at all, unless you are commissioning the plant or process.

There's so many things can go wrong with forcing - it's better to have appropriate "override" code in the PLC