RPI and RTS and Filter settings for ControlLogix modules ...

in Figure 22 both modules were configured as follows:

RPI = 750 ms
RTS = 100 ms

the red trace is from a LOCAL module ...
the green trace is from a REMOTE module ...

in Figure 23 both modules were configured as follows:

RPI = 750 ms
RTS = 11 ms

the red trace is from a LOCAL module ...
the green trace is from a REMOTE module ...

in Figure 24 both modules were configured as follows:

RPI = 11 ms
RTS = 11 ms

the red trace is from a LOCAL module ...
the green trace is from a REMOTE module ...

in Figure 25 both modules were configured as follows:

RPI = 11 ms
RTS = 750 ms

the red trace is from a LOCAL module ...
the green trace is from a REMOTE module ...

in Figure 26 the modules were configured as follows:

the red trace is from a LOCAL module ... RPI = 750 ms ... RTS = 11 ms

the green trace is from a REMOTE module ... RPI = 11 ms ... RTS = 11 ms

so ...

here are my personal conclusions based on what I've seen so far:

regardless of using a LOCAL module or using a REMOTE module, it seems obvious that if you want to get the data in as quickly as possible, then you MUST set the RTS to a LOW number – so that the module will "measure the signal" rapidly/fast/often enough to meet your speed requirements ...

if you're dealing with a REMOTE module, then you MUST set the RPI to a LOW number so that the module will "transmit" the data to the processor rapidly/fast/often enough to meet your speed requirements ...

if you're dealing with a LOCAL module, you can set the RPI to a HIGH number without degrading the speed ...

the inevitable trade-off to this "make-it-go-faster" approach is that the data might be more susceptible to picking up more "noise" as you increase the "measuring" rate with a faster RTS setting ... I'd recommend making it "fast enough" to meet the requirements of the system – but putting the "pedal-to-the-metal" is probably not always a good idea ...

I find this interesting. The graphs make it clear. By default the RPI is 10 ms to a generic module over Ethernet/IP. Most do not change the RPI. Some will slow down the RPI to 20 ms but that is about it.
I vaguely remember a NUT or Network Update Time. What is that? There is also a coarse update time the governs how fast the motion modules get updated. That is a lot of times to keep straight.

I have a local module 1769-IF4FXOF2F. Current settings: RPI=80ms, Filter=100Hz ( 10ms). RTS not enable.

1. Does it send updated data by the RPI rate then?
2. IF RTS is enable, what is the best setting? 10 or 11?

Any body?

Peter Nachtwey said:

I find this interesting. The graphs make it clear. By default the RPI is 10 ms to a generic module over Ethernet/IP. Most do not change the RPI. Some will slow down the RPI to 20 ms but that is about it.
I vaguely remember a NUT or Network Update Time. What is that? There is also a coarse update time the governs how fast the motion modules get updated. That is a lot of times to keep straight.

Click to expand...

The NUT is the base clock for ControlNet. The normal default is I believe 5ms. All RPI's must be some multiple of this.

When Scheduling ControlNet, the remote IO is polled at it's RPI rate, but the NUT allows multiple timeslots for the actual polling... ie: Even if you set every remote rack/module for say a 100ms RPI, they are not all polled at the same time... The first might be polled at 5, 105, 205ms, the second at 10, 110, 210ms, the third at 15, 115, 215ms...

In other words the polling is not synchronous. I assume that this is the means that ControlNet uses to pump what can be a truely large amount of data with guaranteed updates over a relatively slow actual physical network. If I recall correctly, ControlNet is really only a 5MBPS network.