RSLogix 5000 - Compact Logix Connection Timed Out

Hi all,

I have 2 Allen-Bradley CompactLogix PLCs (1769-L35E) talking to each other over ethernet. One is producing tags, the other is consuming. When I go online with the producer PLC through RSLogix 5000 (v15), it shows that it is connected happily to the consumer PLC.

However, when I go online with the consumer PLC, the producer's ethernet port and backplane are showing running fine, but the controller keeps trying to connect, but shows:

Status: IO Faulted
Module Fault: 16#0203 Connection timed out

I've tried increasing the RPI on the consumed tags to 1000ms, but I don't know what else to try. Any suggestions?

Thanks

Please check connections on both PLCs, speed, full, half duplex, autonegotiate, comm switch port config etc. Are these plcs connected to other devices at the same time ??

Both PLCs are 100Mbps, Full Duplex, Autonegotiate Speed and Duplex. Both are showing 6 TCP connections (limit 64).

Yes, they are both connected to the SCADA computer running FactoryTalk View, where data from both PLCs are showing up as they should. I'm logging in to the PLCs through this same computer via RSLogix 5000.

The only wrinkle in this config is that the producer PLC is beind a VPN router, and the SCADA computer and consumer PLC are accessing it through a VPN server. All the IPs are set as they should, and I'm getting a 56ms ping from SCADA computer to producer PLC (1ms from SCADA computer to consumer PLC since they're on the same local).

I remember having seen something similar to your case and the solution is on Rslinx configuration.

The RSLinx configuration would affect how one PLC talks directly to another? I'm not sure how that works. Definitely for how the PLCs talk to the SCADA computer, in which case I can only assume it's configured right since there is no problem with the SCADA computer seeing the proper data from both PLCs.

SCADA uses Rslinx Enterprise and Rslogix use RSlinx classic.

Thanks for the input. I still can't figure it out. RSLinx Classic seems to be configured fine, as I'm able to go online with both PLCs. It's just that the consumer PLC isn't finding the producer PLC, while the opposite way is connecting.

I've seen this happen before and in my case it was related to the max consumers at one end.

If PLC1 can read from PLC2 but PLC2 cannot read from PLC1, go to PLC1, go to the produced tag properties and check the maximum number of consumers. If PLC1 is only allowing one consumer for the produced tag, and another PLC is already reading it, PLC2 won't be able to read the data.

And the other thing I've seen cause this is a tiny typo double, triple and quadruple check your tags at both ends, make sure you don't have a stray full stop or underscore or a couple of letters the wrong way around

It definitely seems to be an issue with the produce consume tags. If I remove all the consume tags, it connects properly on both ends. However, I just created a simple produce tag on PLC1 (max 8 consumers), set up to consume it on PLC2 (1000ms RPI, quadruple checked typos!!), and PLC2 doesn't connect to PLC1 anymore (but PLC1 connects to PLC2).

[the Producing controller] shows that it is connected happily to the consumer PLC.

Click to expand...

I think this may be misleading you. The Producer controller doesn't even need to have the Consumer in its I/O tree. If it's there, there will likely just be an ordinary icon with no yellow triangle.

I don't know if you can even programmatically tell in the Producer controller if the Consumer is connected. It will show up in the 1756-ENBT web page connections list, but I don't know of a way to see that sort of status in the Producing controller.

My hypothesis is that the VPN router is the problem. In general, routers are set up to block multicast traffic and/or UDP traffic and not tunnel it through the virtual private network.

Unicast connections for Produced/Consumed Tags wasn't added until Version 16 firmware.

If I were in your shoes I would try to set up the Consumer controller to read the tag with a MSG instruction instead.

I'm a little confused - when you say "If I remove all the consume tags, it connects properly on both ends", what do you mean? If there are no tags being produced and consumed, how are you judging that they are connected properly on both ends?

Can you post a screenshot of the produced and consumed tag setup windows for each PLC?

[edit] Ken's pretty quick off the mark today. I see what you mean now

Thanks for the input. Yes, I do believe I was being misled with the lack of yellow triangles. Unfortunately, I had bench tested the VPN setup with a couple of L33ER on version 20 with no issues. I'm reluctant to reflash these field PLCs past v15 as the client's RSLogix 5000 license is the old floppy, so I'm not sure what version Rockwell moved away from that.

Producer/Consumer Screenshots:

I can't see your screenshots - but I think Ken has you going in the right direction anyway. I must have missed the mention of the VPN

Thank you all for your help. The problem has been solved!

It was indeed an issue with multicasting! From the VPN Q&A: "... doesn't support any kind of Multicast communication". I had no idea v15 did multicasting, as the VPN setup was a retrofit to replace ethernet radios that could no longer get signal through the growing foliage.

So rather than deal with a substantial bit of recoding to move to MSG, I reflashed to v16 and everything is working like a charm! (Sidenote: I almost had a heart attack as I lost comms with one of the PLCs mid-flash and feared I bricked it. Luckily I was able to reflash without an issue and all is well.)