ControlLogix 5575 (L75): Sudden/Repeating "Unconnected Message Timeout" (0204)

If you have connected the three devices in a ring but not enabled a ring supervisor, you would almost certainly experience problems. I'd try disconnecting one link and seeing if the problem goes away. If that works, reconnect the ring but set up a ring supervisor (or two) and you'll likely solve the problem and have a properly redundant network!
 
If you have connected the three devices in a ring but not enabled a ring supervisor, you would almost certainly experience problems. I'd try disconnecting one link and seeing if the problem goes away. If that works, reconnect the ring but set up a ring supervisor (or two) and you'll likely solve the problem and have a properly redundant network!

Ok, but like I said at the top - this PLC has been running flawlessly since 2015 with only some very minor (in-house) logic changes made to it. How could it suddenly start failing like this and be a Configuration issue that was presumably there since Day-1?
 
Is there a chance that EN2TR was replaced?
"Supervisor Enabled" setting stays with the module, not with ACD project, so if module was replaced, then Supervisor must be enabled again.

Another possibility that it was linear topology (not a ring) and someone decided to improve it connecting an extra cable creating ring?
 
So you have a ring configuration that isn't setup to act as a ring.

You could have a redundant network without using a ring. You basically just make two separate cable runs from A to B to C. Two cable from A to B and two cables from B to C. Or one goes A, B, C and the other goes A,C, B. Your data is always sent on both cables in case of a failure.

But what you do not do in that instance is what Contr_Conn mentions and "improve" the network by connecting C back to A and creating a ring. That said, with a limited amount of data, this could still function. A PLC and two remote chassis would be a limited amount. Throw an HMI in there and everything goes to pot. Anything that broadcasts would bring the network to its knees.

You have your cable in a ring configuration and you have equipment capable of using the ring. You just need to enable it at this point. Select at least one device as the ring supervisor. You can select two, or even all three. that would provide a backup if the supervisor failed.

Once you have a supervisor you should also be able to connect with the DLR tool.

OG
 
Last edited:
Is there a chance that EN2TR was replaced?
"Supervisor Enabled" setting stays with the module, not with ACD project, so if module was replaced, then Supervisor must be enabled again.

Another possibility that it was linear topology (not a ring) and someone decided to improve it connecting an extra cable creating ring?

There was one person in our Automation Group who handled all the PLCs prior to his retirement in the Fall of 2016. This system was installed in 2015. I never knew of him ever replacing an EN2TR module, but he probably did somewhere along the line on some PLC rack. And I have never known anyone from the Maintenance Group to replace one. They will only replace I/O modules on our DCS system (MTL). I've never known any of them to touch any hardware on a PLC rack. So I would say, for this particular PLC, there was a narrow window of about a year or so where it could've been replaced, but probably not. We also do not use DLR anywhere on site, so I think this is just linear with an extra cable.

I still don't understand how this really works. For example, there are AO I/O modules (yellow) in both Remote Racks. The PLC is trying to send data packets containing AO data to a specific AO module in one of the racks. Are duplicate data packets being sent out on both LINK1 and LINK2 of the PLC's EN2TR module (??) ... because LINK1 is hard-wired to one of the Remote Racks, and LINK2 is hard-wired to the other Remote Rack. Looking at the blinking lights on the PLC's EN2TR right now, only LINK2 is blinking ... LINK1 is solid green ... which seems to indicate data is only being sent over LINK2. So - if that's true, without the cable connecting the two Remote Racks, the PLC's AO data packet might never reach its intended destination, right? I'm thinking this is why the cable connecting the two Remote Racks is there. At some point, instead of both LINKs on the PLC blinking, one of them went solid-green, which made some I/O unreachable, so someone added the crossover cable and it started working again. Does that sound plausible? And if it is ... why did the LINK on the PLC go to solid-green (or why did it never start blinking again)? Could that mean "bad EN2TR" card?
 
Last edited:
We also do not use DLR anywhere on site, so I think this is just linear with an extra cable.
You can't have a linear with extra cable (to close the loop). This can only be done if supervisor is enabled. So make it true linear and all will work. Linear must be linear without any additional cables.
 
You can't have a linear with extra cable (to close the loop). This can only be done if supervisor is enabled. So make it true linear and all will work. Linear must be linear without any additional cables.

Yeah, but if I make it linear I'll be changing it from the Configuration it was running successfully with since 2015! So ... I'm just confused as to what's happened here. What changed? Why did it suddenly start having this issue after all this time ... when it's been running continuously, and no one's touched it in years?

I did replace that crossover cable (because it failed a Line Test) and, so far, it hasn't failed ... so while it's still running, I'm gonna ask around (Maintenance, the retired PLC guy) to see if they can shed any more light on what might have happened here, then I'll post back again ...
 
I would check the ethernet statistics at each ENxx card, and check for dropped packets and collisions. You can use a web browser or use RSLogix/Studio5000 (in the I/O card properties) to see these numbers.

Rockwell support claims that their #1 network-related call is due to auto-negotiate vs fixed mismatch. Both ends of a network connection both need to be auto-negotiate, or both need to be fixed at the same rate (ie 100/full). You can not intermix auto-negotiate and fixed. It will work for a while, but will cause collisions and cause the connection to drop out - and yes even after years. Loading the network will cause the dropouts to be more frequent.

I have seen this issue many many times myself.

Not sure if this is your problem, but worth looking into.
 
I think what you had here was the metaphorical "time-bomb". The problem was always there, and it was bound to go off at some point like a Ford Pinto :) (if you don't know, look it up).

One of my first service calls was to fix a problem in a PLC that had been running for six years. No issues with that system until that day. The problem was a programming issue that had been present since day one. It just needed the right conditions for the time-bomb to go off.

I was asked the same thing. Why did it run without issue for all those years, and only now start causing problems. In that case I could explain the exact conditions in the program and in their process that caused the problem. In your case it is the extra cable along with something else (maybe environmental, electrical) that was the trigger.

mdumond's post above about checking the statistics for the ethernet module is an excellent suggestion. Though you aren't likely having fixed versus auto negotiation issues. I would expect you will see errors piling up.

OG
 
Take a look at technote BF22344, it states that a EN2TR/C module running firmware 10.007, on a DLR without a active ring supervisor will eventually cause a module assert. Have you looked at the assert logs on the rings EN2TR modules to see if any of them have asserted recently?
 

Similar Topics

Hi everyone i have a customer, who wants to show an alarm on the machine, if the I/O forces are enabled and set, on at ControlLogix L81E with...
Replies
3
Views
141
Does anyone know of a way to detect if someone is online with the controller in ControlLogix (from logic) I'm thinking that maybe there is a CIP...
Replies
7
Views
293
I've never paid attention to this, is this normal?
Replies
13
Views
421
Hi. I need suggestions. I want accumulate operating hours from a simple XIC condition, so I'm thinking a RTO with a 60000 or 3 600 000 preset, 1...
Replies
7
Views
225
Hello, So i managed to read the string coming from control logix and put a string display in PanelView 800. Now I am struggling to do the other...
Replies
1
Views
115
Back
Top Bottom