Communication between PLCs

I have a situation here that I can't seem to figure out.
There is a main data-concentration PLC (1756-L73) with an EN2T that talks to 16 other PLCs (all 1756-L73) all through EN2T modules. I'm currently working with one specific PLC in the list so I don't know if this problem is propagated to the rest or not, but the MAIN PLC shows the ethernet module and controller in the controller tree and status shows as running, no errors. On the remote end, looking back at the MAIN PLC, the EN2T shows OK, no errors, but the controller has a yellow triangle, says I/O faulted under the status, and then under Module Fault, it says Connection Request Error: Invalid Connection Size. I'm baffled because if there was a communication error, I would expect to see it on both ends, but since the EN2T modules show fine on both ends, I don't believe that's it.
On the remote end, the MAIN PLC controller is shown in slot 1, which it is, as a 1756-L73, which it is, and v18.1, which it is.
What else would generate this error?

You will see that error if you are using produced/consumed tags, and the data area you are reading or writing to is different to the data area in the other PLC.

Hope this makes sense.

Cheers

Mark

MarkNightingale said:

You will see that error if you are using produced/consumed tags, and the data area you are reading or writing to is different to the data area in the other PLC.

Hope this makes sense.

Cheers

Mark

Click to expand...

Produce/consume tags is why I had to investigate this. I noticed data wasn't going across the line. So if one tag is mismatched, NONE of the produce/consume tags will work? I wasn't aware of that.

Thanks.

As far as I am aware that is correct.

Usually any data I pass across to PLC's is all bunched together in a UDT.

But if there is a connection size error, the connection between PLC and PLC is lost, so any data being passed across won't make it, because there is no connection.

When I have had issues before the main culprit was array sizes being mis-matched, so this may be a good place to start.

Cheers

Mark

MarkNightingale said:

As far as I am aware that is correct.

Usually any data I pass across to PLC's is all bunched together in a UDT.

But if there is a connection size error, the connection between PLC and PLC is lost, so any data being passed across won't make it, because there is no connection.

When I have had issues before the main culprit was array sizes being mis-matched, so this may be a good place to start.

Cheers

Mark

Click to expand...

Good to know. I found the UDT that had a type set to one of a similar name. Quick change and re-download and all is well. Thanks again.

The reason it worked one way and not the other is:

PLC1 says to PLC2 "I want tag ABC of size/type XYZ". PLC2 replies "here you go, data ABC of size/type XYZ". PLC1 receives the data, stores it in it's destination tag. All happy, no error.

PLC2 says to PLC1 "I want tag ABC of size/type XYZ". PLC2 replies "I have tag ABC, but it is size/type 123". PLC1 says "well, s***, that's not what I wanted, keep your data to yourself." Hey presto, invalid size error!

Produced/Consumed tags, like explicit messages, are not bi-directional, you have two completely separate operations going on. One of them was set up correctly, and one wasn't.

Moot point since you got it working, but just in case it was keeping you up at night

ASF said:

The reason it worked one way and not the other is:

PLC1 says to PLC2 "I want tag ABC of size/type XYZ". PLC2 replies "here you go, data ABC of size/type XYZ". PLC1 receives the data, stores it in it's destination tag. All happy, no error.

PLC2 says to PLC1 "I want tag ABC of size/type XYZ". PLC2 replies "I have tag ABC, but it is size/type 123". PLC1 says "well, s***, that's not what I wanted" and generates your size mismatch error.

Produced/Consumed tags, like explicit messages, are not bi-directional, you have two completely separate operations going on. One of them was set up correctly, and one wasn't.

Moot point since you got it working, but just in case it was keeping you up at night

Click to expand...

Yup, I understand.
What I did learn is that a produce/consume error shows as an IO fault in the controller tree. Would have never guessed that.

Oh, yes, that's caught me quite a few times. The biggest thing to remember with an "I/O Fault" in the controller tree is that it's not limited to just the hardware. If it can't get all of the information it's configured to get, it'll show you the yellow triangle. As you saw, in the case of the produced/consumed tag, even though it's clearly talking to the other PLC without issue, it can't get the required information, so I/O fault. If you have a point I/O rack with a card missing, it might be happily talking to the 1734-AENT hardware, but it can't get the data from that card, so I/O fault. And so on. While it does make sense if you think about it, it's still enough to make you kick yourself for spending two hours in a roof troubleshooting your ethernet network and then finding a typo in your produced/consumed tag setup