Messaging to 1756-L8x on-board port with / without un-needed backplane CIP path

[5618]

I noticed something that’s mostly just a curiosity. Maybe someone here knows.

An IT system is reading a L82 with the on-board IP and 1,0 added. That’s leftover from an older processor and a ENxT module, addressing the backplane from the Ethernet module and the processor in slot 0. I wonder if it’s slightly detrimental, or just pointless. Is there any unnecessary additional data movement with the backplane and slot defined?

I tried a quick test reading a 280 byte UDT with and without 1,0 in my source MSG. The MSG was completing in 1-3 ms and I didn’t notice any difference capturing a timer.acc value to measure. As I write this, I’m thinking I could try again someday with more data, a private network, a sparse program, and the system uS.

So, I have four possibilities: The processor ignores the path to itself. That path is baked into the architecture and defining it is redundant. That actually adds a bit of overhead to the communication. Or, something else my simple mind didn’t fathom.

I would guess that adds a tiny bit of overhead. If not backplane traffic, then at least burning some amount of backplane interface power. A PLC will do whatever else you tell it to do, even if it’s not what you actually want it to do.

 

[drbitboy]

I don't have an answer, but a possible diagnostic: how about ten or twenty ,1,0 pairs in a row and remeasure the MSG completion time? If there is any overhead, it may be in the noise of the total overhead when measuring with just one ,1,0 pair; perhaps more pairs would give a better estimate of the overhead, if any, due to a ,1,0 pair.

 

[5618]

how about ten or twenty ,1,0 pairs in a row

An interesting idea, and it worked. I set up a L81 reading from itself, out an EN2T, through an unmanaged switch, and to the on-board port. The only enabled program was this one. Interval times were min .016 ms, max .076 ms. It wasn’t completely independent. I was online through the on-board port and the EN2T was owned by another processor in the rack.

Without any extra backplane hops, the messages averaged about 1.29 ms to 1.3 ms. Adding 10 cycles through the backplane added about 110 to 130 uS to the time. But wait, there’s more…

The first backplane hop seems to add about 50 to 80 uS to the time, and higher jumps into the 1.4 ms range were more common. Another round through the backplane adds a bit more time and variation. Adding more hops adds a bit more time each, and at ten rounds the times seem a bit more consistent with high ones only maybe 50 uS high instead of 100 uS with one or two rounds.

So, the answer appears to be yes, the un-needed hop is processed and slightly detrimental to system performance. Not enough to notice for this, but maybe in a heavily loaded system with lots of motion…?