Digital Input RPI or Change Of State

I am using a ControlLogix L71 controller with a 1756-IB16 Digital Input Module in one of my applications. I see that in the DI module's property settings and I can specify the RPI interval and also enable Change Of State.

My question is, can I have BOTH RPI and COS enabled on the module, or it can only be one or the other?

If I use BOTH, would I potentially experience problems?

Thanks in advance.

The RPI is not a choice; it is a fundamental property of any implicit communications (I/O Class) Logix system connected module.

You could specify COS for any 1756 DC or AC Inputs if you don't need the state to be included in each read data packet unless a Change Of State occurs.

There are no caveats to it, however, especially when within the Local Chassis, it is hardly necessary to 'improve' the Backplane bandwidth by leaving out of the data packet said 'idle' Inputs.

I guess, if anyone deploys remote 1756 hardware on 'slow' networking (such as RIO) or reaches high remote I/O counts on 'fast' communications links (EtherNet/IP or ControlNet) the use of COS settings for Input modules will enhance the data exchange efficiency.

Thanks for the reply.

So would the module send the information twice?

For example, when the input to the module transitions from the OFF to the ON state, the DI module will IMMEDIATELY send the Change of State to the PLC, and then upon the next RPI scan time, send the same information again to the PLC ?

Not quite...When an Input COS occurs, the state of the Input will be included within the next scheduled data packet...

dmargineau said:

Not quite...When an Input COS occurs, the state of the Input will be included within the next scheduled data packet...

Click to expand...

My understanding was that the COS transfer of data is similar to a "Write By Exception" where the status changes is immediately sent to the processor?

So then, what defines the Next Scheduled Data Packet ?

jjimen03 said:

So then, what defines the Next Scheduled Data Packet ?

Click to expand...

The RPI (Requested Packet Interval) of the 1756 Input module.

Let's say you are RPIing a 1756 Input module at 20 ms (the module multicasts the Inputs' states packet every 20 ms); if one of the Inputs is set for COS and changed states 5 ms after the previous packet had been read, its state will be included within the next packet, obviously 15 ms after it changed states.

You could RPI a module as often as 2 ms; again, the Inputs's states are part of a 'packet'; the CPU does not read them individually hence any Input point pertinent setting is referenced to the module's RPI setting.

dmargineau said:

The RPI (Requested Packet Interval) of the 1756 Input module.

Let's say you are RPIing a 1756 Input module at 20 ms (the module multicasts the Inputs' states packet every 20 ms); if one of the Inputs is set for COS and changed states 5 ms after the previous packet had been read, its state will be included within the next packet, obviously 15 ms after it changed states.

You could RPI a module as often as 2 ms; again, the Inputs's states are part of a 'packet'; the CPU does not read them individually hence any Input point pertinent setting is referenced to the module's RPI setting.

Click to expand...

So then let me ask you this, if I Unselect/Disable COS ( Both On->OFF and OFF->ON), what would happen when the Input changes state ? Will no information be sent to the processor ?

jjimen03 said:

So then let me ask you this, if I Unselect/Disable COS ( Both On->OFF and OFF->ON), what would happen when the Input changes state ? Will no information be sent to the processor ?

Click to expand...

If you disable (uncheck) the Default COS On/Off and Off/On for any Input point said input state will be multicasted at every RPI interval of the module as part of the module's data packet.

COS selection occurs on a per-point basis, but all module data is multicast when any point enabled for COS changes state. COS is more efficient than RPI because it multicasts data only when a change occurs.

You must specify an RPI regardless of whether you enable COS. If a change does not occur within the RPI timeframe, the module will still multicast data at the rate specified by the RPI.

It is recommended that you use a larger RPI value if the COS option is used and the module is located in the same chassis as its owner.

Again, this day and age or at least since V.18 I believe, all Logix I/O modules could (and should) Unicast their data hence rendering the COS feature unnecessary; prior to V.18 all I/O module's data was multicasted and the available COS feature was intended to optimize the bandwidth (data transfer capacity) of a system.