Allen Bradley MSG commuication

I have a CompactLogix communicating to a SLC using MSG, however sometimes the communication stops. The symptoms are the command is enabled(.EN) however the done(.DN) never energizes and the Error (.ER)never energizes.



In the programme I have 3 MSG command, one to write to SLC, one to read from SLC and one to read Floats from SLC. They are reading/writing to the same SLC. However it is only one MSG that stops.



Has anyone seen this and do you know what causes it.



Thanks

How are you communicating to the SLC (Ethernet, DH+, DH-485)? Is this through a ControlLogix gateway? What firmware version do you have in the CompactLogix?

I usually have a delay timer so that after a message is requested and no response occurs I will re-trigger. Also note that this can cause issues with your message buffers and you should really try to determine if there is some other issue going on.

Is the message being triggered by logic or continuous?

Darren

I'm communicating via Ethernet and I use a 200msec timer to drive the logic to trigger the message. The timer is reset using the message .DN signal.

What you are most likely seeing is some issues with your Ethernet setup and the limitations of the SLC communication buffer. It can take 15 seconds or more for a Ethernet message to time out.

It would be best to trigger after receiving a DN or ER bit and re trigger. If there are any issues with your SLC (what else is it communicating with) you can possibly fill up the buffers on the SLC and start losing data.

Darren

I had a similar problem communicating with 2 SLC's. Initially I had MSG's in both processors which was causing the problem. I also then increased the timer to 5 seconds or so to actuate the message or reset it. This seem to take care of it.

Another question to ask is whether there is acually a problem or not. The Logic your looking at is not real time on the screen. If you were to look at the MSG instruction that is triggered every 200 millsec you would not see the .dn bit come on every time. Only ocasionally because your PC cannot keep up with the PLC. You say you dont see the .dn but you also dont see the .er Are you sure your acually losing communications. If so then I apoligize for all this nonsense.

Good point. Don't forget the simple stuff. Sometimes I also add counters on DN and ER bits (when you are blindly toggling a MSG) to check for issues you may not see on screen. Since the MSG is on the CLX you can also graph the bits to see if they are missing or not. Also, along the same lines as Bob above, remember that when you re-trigger the MSG it will clear you error bit (ie may happen to fast to see).

You also need to ask youself how critical this data is. If something can wreck or overflow if the data goes stale you need to build in some safe guards to detect the problem. Something as simple as the SLC you read from allways sets a bit in a word and the CLX that is reading allways resets the bit. You can then test the bit as a watchdog to detect problems.

I had a CompactLogix communicating over ethernet with 7 ML1100s. Our distributor's tech support told us that that MSG read/write had to be in both the CompactLogix program and the ML1100 programs (kind of like a handshake).

It turns out that the ML1100s do not need any MSG instructions, and it just clogs the communications. The CompactLogix just uses a SLC Typed Read/Write and it can access any of the data in the ML1100.

I also noticed that one SLC Typed Read/Write instruction that is having timeout issues can cause instability on your network, and cause other instructions to error even if they are setup correctly. This would happen if a node was removed from the network that was being read from/written to.

I used counters to follow the DN and ER bits to monitor my network. I had all 7 Read and Write instructions being executed every 20ms with no errors once I removed the instructions that were being sent to IP addresses that did not exist.