1756 AB PLC - Input Bits Getting Latched

When did this get discussed by telephone with Allen Bradley's local representative and what was the outcome of that discussion?

anbarasu,

Greetings.

Most likely the root-cause is either:

1. Induced noise (Voltage spikes) in your field cables due to them being unshielded or the shield drain wires not being properly connected to system ground. (Cable shield drain wire must be firmly attached (at one end only) to the electrical and equipment system ground and all equipment grounds must be bonded throughout the system to each other and at a potential of less-than-one (1) ohm.)

OR

2. Allen Bradley/Rockwell International uses sequential numbering protocol for all of their I/O points and periphal equipment on and in the backplane so to eliminate addressing errors and mistakes.

Hence it is very easy and common for programmers to "duplicate" addresses from one terminal node into another on the network when sharing Global DATA in a network.

For instance:

An address of I:0/1.0 used at node 0 in your network can false trigger I:0/1.0 at Node 2 and so on if there is not clear delineation set up in the blocks of Global DATA assignment. ( "N", "B", etc. Register Tables)

To avoid this "overlap" of I/O logic and prevent uncontrolled, erratic execution of the program I/O, the "shared" Global DATA table(s) bit addresses need to be organized very carefully and "grouped" into segregated sections specifically assigned to a node (rack) so that their numbers do not overlap.

Example:

Given the issue is in a PLC that is resident as one of multiple nodes in/on a network that shares GLOBAL DATA exchange.

At Node 0 => N file assignment could be N:10 with all bit addressing grouped within the N:10 register range.

At Node 1 => N file assignment should be N:11 with all bit addressing grouped within the N:11 register range.

At Node 2 => N file assignment should be N:12 with all bit addressing grouped within the N:12 register range.

And so on.

Doing this prevents execution of a GLOBAL control logic statement from erroring when polling and execution of the program is in progress during GLOBAL information/DATA transfer.

If the system is quite large it might be necessary to asign more than one DATA table file to accomodate the I/O and/or program logic. (N:10 and N:11 for one node then N:12 and N:13 for the next and so on.

Responding to a power system voltage level control issue at one site recently I found:

1. Every time the access door to the substation control room at one of the remote substations was opened, the Load Tap Control on all of the main power transformers in the local power gird would index one or more steps up or down depending on LTC lead status selection and raising or lowering the distribution primary power system voltage level. (Caused severe electrical disruption and failures in/on everything attached to the system.)

2. This was due to an program bit addressing mistake wherein the door security alarm switch (a Binary input) added after the power distribution system was built had been addressed in the N table within the LTC control logic numbering range instead of the local PLC bit addressing for that location.

Looking at your I/O input terminals with an oscilliscope will identify the "noise" issue and careful review of your DATA register addresses will reveal the other.

Hope this helps.

Jim

The problem isn't clear to me.

Do you mean that input bits are turning ON even when there is no ON signal going into them?

Or do you mean that the input data table is not changing even when you switch off the input?

The input data table follows the physical inputs states not the other way around. Perhaps you're referring to the outputs?

Please describe the problem in more detail.

What is the device connected to the input that is latching? "Solid State Relays" commonly have SCRs (Thyristors) as their output device - these will latch on if they are driven with DC.

If you are using an active DC input card (i.e. the input card applies voltage and measures if current is flowing or not) to detect the state of a Solid State Relay, this will latch on until the power is removed from the DC input card.

Is this a new system, or is it a system that used to work fine and now suddently has a problem?

If this is a new system, I would look for programming errors. If a coil in the PLC program is writing to an input bit, it can "set" the bit after the input scan which would cause what you're seeing. Similarly, if the HMI panel is writing to an input bit, it can do the same thing.

As a general rule, one should never write a PLC or HMI program so that it either sets or resets a PLC input bit -- those bits should only be set or reset by the physical states of the input terminals on the input cards. I mention this possibility, however, because it is a novice programming error, which I have seen done many times.

A test you could perform is to clear the PLC and HMI programs entirely, then monitor the input bit states with the PLC running but no program in place. If the bits are still not following the hard-wired input statuses, then you know you have a hardware problem.

I have had an HMI go bad and latch PLC bits randomly. Something else for you to check.