[Logix] MSG instruction seems to ignore timeout length

[defcon.klaxon]

Hey guys,

I'm seeing some odd behavior with some MSG instructions I have set up. Specifically, when I enable the MSG instruction I nearly instantly get an .ER bit back. The error codes are:

.ERR = 16#0001
.EXERR = 16#0000_0204
.ERR_SRC = 8

What's odd is that if I remember right, the 0204 error code means the connection timed out. But, the error is coming back nearly instantly and seems to completely ignore the unconnected timeout (which is the default 30 seconds). Further, the error message in the MSG configuration popup doesn't say "unconnected message timeout", but rather "connection failure". I've dealt with connection timeouts before, but I never had the .ER bit come back so incredibly quickly nor do I ever remember seeing "connection failure"; in my previous experience, the .ER bit only went true after the timeout elapsed and "unconnected message timeout" was the error message.

You may remember me posting about my water treatment project; well that's wrapped up, and now I'm working on the wastewater side of things. I'm using (as far as I can tell) the exact same method of MSG connection; no connection in the I/O tree, and the manual input of the MSG path into the MSG instruction. For reference, the master polling PLC is a 1756-L72 ControlLogix with an EN2T ethernet module (named Ethernet), and the slave is a 1769-L24 CompactLogix. The path in the MSG instruction is:

Ethernet, 2, 172.16.35.73

I've double/triple checked everything, can't find a problem anywhere...and the lack of the timeout before the .ER has me thinking something is up.

I'm going to try pinging remote radios and PLCs tomorrow to verify that level of connectivity is good, but I'm still stumped by the lack of timeout delay...any thoughts on what I should look for? Am I missing something about the error codes?

Thanks guys!

 

[defcon.klaxon]

Quick update:

I went to the water radio polling PLC and intentionally changed one of the MSG IP addresses to something nonexistent to see what would happen. I got the exact same error I'm getting on the wastewater side (16#0001 and 16#0000_0204) with the error message "connection failure". However, the message took 30 seconds to time out, exactly as I'd expect. So I'm still not sure why the MSG instruction in the wastewater PLC is ignoring that timeout.

 

[ASF]

Sounds to me like it's finding the other PLC, but the other PLC is telling it to f*** off (excuse my Australian ). So you're getting an error back saying "sorry, I can't connect to that PLC", not "sorry, I can't find that PLC". When you change the IP address, you get the usual timeout because at that point it's not finding the other PLC at all, so instead of being told to get lost and immediately telling you "no dice", it's trying for 30 seconds to no avail, and then giving up.

I've not done a huge amount of messaging, so I can't be a lot of help unfortunately, but if it were me in that situation, I'd be suspecting that the connection and the path between PLC's is just fine, but there's something else in the configuration that's asking for something that the other PLC can't provide.

 

[defcon.klaxon]

Thanks for the reply, ASF.

I did some more work and think I've got it figured out. The remote PLCs are on a VLAN with a different IP address than the master polling PLC. When I set up a test on my bench and changed the IP address in the MSG instruction to something it couldn't directly talk to because of subnetting, I was able to cause the "no delay timeout" error. If I change the IP address to something in the same subnet but isn't there, then I get the delay before timing out. And of course, if I change the IP address to an actual address, the message goes through just fine.

Thus, it's something to do with the VLANs so I'll need to double check the network settings and make sure the PLC is plugged into the proper port on the switch. Luckily the water network is set up exactly the same so it isn't reinventing the wheel, it's just a matter of finding what isn't set up correctly. And luckily, we have an IT consultant that can check all the server settings as that level of networking is beyond my expertise.

 

[ASF]

That sounds like a fair guess. First thing I'd be checking (if you haven't already) is that your gateway address is set (and correct) in both PLC's. If you haven't got a gateway address set, and you tell it to go looking outside of it's subnet, I would completely understand the PLC giving up without even making an attempt. Sort of like addressing a letter to a friend and giving it to someone to post for you, but you haven't told them where the post office is. Other than that, yeah, if you have a helpful IT consultant then that would be my next move.

 

[defcon.klaxon]

Yeah, the subnet needing to be correctly set was it. I'm now bringing up sites and they're working, minus one...but that'll be another topic, as it's another error.