Worst Case RPI Multicast Scenario for 1756 Digital I/O

coolblind · Apr 29, 2008

Hi all:

Please refer to the attached, which is a page from the 1756 digital I/O user manual (1756-um058c-en-p).

The thing I didn't get it is that why when the COS is disabled, the data transferring time can be up to TWICE the RPI.

I believe the reason why they set the RPI is to make sure the data gets updated at least every RPI, so where the "TWICE" comes from?

Also, it shows if you enable the COS, the worst update time is RPI, so can anyone explain this? According to this manual, COS only decides when the module will multicast the data to the LOCAL chassis.

Thanks

OkiePC · Apr 29, 2008

What they are saying as I understand it:

If you disable the COS, and the input card data changes states just after it was scanned, it will not be able to send that information to the backplane until the next RPI scan, so, for example, if the input changed state in the input module 0.0000001us after the module did the RPI (Regular, Repeatable, send the data no matter what Polling Interval), the next opportunity would actually be a unit of time very nearly twice the RPI. Effectively, 2*RPI is the worst possible update scenario when you disable Change Of State updates.

I hope this helps...

Paul

coolblind · Apr 29, 2008

OkiePC said:
What they are saying as I understand it:

If you disable the COS, and the input card data changes states just after it was scanned, it will not be able to send that information to the backplane until the next RPI scan, so, fgor example, if the input changed state in the input module 0.0000001us after the module did the RPI (Regular, Repeatable, send the data no matter what Polling Interval), the next opportunity would actually be a unit of time very nearly twice the RPI. Effectively, 2*RPI is the worst possible update scenario when you disable Change Of State updates.

I hope this helps...

Paul

Thanks Paul, but I still did quite get it.

Ok, let say this input module is in a remote chassis connected by ControlNet with a RPI=5ms:
1. At t=5ms, the input module does a multicast and send the data to the remote controller
2. At t=5.001ms, the input sate gets changed.
3. These changes should be reflected on the next RPI multicast t=10ms no matter if COS is enabled or disabled, since this module gets to multicast every RPI.

So, can you see any reason why I have to wait to 2RPI, that is at t=15ms to get the updated data in the controller?

OkiePC · Apr 30, 2008

Sorry, I lost my internet connection before I could expand my post...

I think your excerpt is referring exclusively to remote I/O. In hte worst case example, the input card will send it's data to the backplane in which it is located at a time slightly less than the RPI assigned to the card, then, the reserved spot on the remote network may be as much as one more RPI later in time.

Paul

Gil47 · Apr 30, 2008

coolblind said:
Thanks Paul, but I still did quite get it.

Ok, let say this input module is in a remote chassis connected by ControlNet with a RPI=5ms:
1. At t=5ms, the input module does a multicast and send the data to the remote controller
2. At t=5.001ms, the input sate gets changed.
3. These changes should be reflected on the next RPI multicast t=10ms no matter if COS is enabled or disabled, since this module gets to multicast every RPI.

So, can you see any reason why I have to wait to 2RPI, that is at t=15ms to get the updated data in the controller?

A little reality check here this is digital I/O, and you are questioning whether I/O is turned on or off faster than the next cycle of an AC wave form of 20 ms at 50 Hz or 16.66 ms on 60Hz and you can't wait for it to do more than half a cycle.

rdrast · Apr 30, 2008

Gil47 said:
A little reality check here this is digital I/O, and you are questioning whether I/O is turned on or off faster than the next cycle of an AC wave form of 20 ms at 50 Hz or 16.66 ms on 60Hz and you can't wait for it to do more than half a cycle.

Not everyone uses AC inputs and outputs; in fact, we avoid AC I/O whenever possible, since 24VDC is cleaner, safer, less expensive, less power hungry, and directly compatible with almost any sensor out there.

Sometimes it is actually necessary use high speed inputs/outputs to trigger interrupt/event routines, or counters etc.

coolblind · Apr 30, 2008

Ok, I did some research, and I believe I find something here.

In my opinion, the 2x RPI transferring time can only occur when you choose "Rack Optimized Connections" in the communication format.

Again, let assume there is only one input module in the remote chassis, the RPI=5, COS=off:

1. t=5.0001ms the input state changes from 0 to 1 (assume only one bit)

2. t=10ms, the ControlNet module 1756-CNB FIRST sends the I/O states data from its image memory (here, the input is still 0), THEN the CNB module inquires the input module to update the image memory (the input state changes from 0 to 1)

3. t=15ms, the CNB module sends the updated state image to the controller.

So, from t=5.0001ms to 15ms, it is the 2x RPI.

If the COS=0n, the input module automatically multicasts the state change at t=5.0001ms, so the CNB can pick it up and update the image accordingly, then at t=10ms, the updated state can be sent to the controller.

All these above is about my understanding about this issue, even though I am not quite sure if the CNB processes the Rack Optimized Connections like what I assume in step 2 (multicasts first, then updates the image), but this is the best explanation I have, just for your reference. -

Worst Case RPI Multicast Scenario for 1756 Digital I/O

coolblind

Member

OkiePC

Lifetime Supporting Member

coolblind

Member

OkiePC

Lifetime Supporting Member

Gil47

Member

rdrast

Lifetime Supporting Member

coolblind

Member

Similar Topics