Logix5000 and msg

[rbnice1]

will try that. I just turned that down and seems about the same as before, however i have found one of the msg's locked up it is locked up as i type this. It is enabled but never dones, or error's, but if i expand and open the message configuration box it shows at the bottom error text: connection falure.

I perposly caused the connection falure to get the msg to lock up, but why is it not erroring out?

 

[Ken Roach]

The MSG configuration window shows you the current state of the MSG control block, so it's theoretically not possible to have an error code when the .ER bit is zero.

Obviously you see what you see. I've seen that kind of thing when the .ER but was being unlatched elsewhere in the program, so it wasn't visually active because it was being unlatched faster than RSLogix could monitor it. Maybe there's something about the DHRIO Connection Error that does cause an error-code-without-.ER-bit that I'm not aware of.

It IS possible to trigger an MSG instruction that never becomes Done or Errored. But you have to fill up a communication buffer or have a very specific kind of link-layer fault that I don't think can happen on DH+.

I really think I'd have to see your whole program to assist any more on this. Send me a PM or e-mail if you're not able to post the *.ACD file to the Forum.

 

[rbnice1]

ok here is a snap shot of the line that has the msg statment that is currently locked up. there are a lot of other messeges that are working right now, and it i reset the .en it will start working fine again but i would really like to try and figure out what the root cause it.

 

[rdrast]

--- Personal note, that won't help you here...
Manually playing with the .EN bit will cause the MSG instruction to try to run again, without clearing it's comms buffer. Doing that enough will either stop MSG instructions from running at all, or wierdly corrupt the communications buffers. Don't do it.

Second note, are you using "Cached Communications" ? There is a limit to the number of Cached buffers.

 

[rbnice1]

manually playing with the .EN bit has been what i was using will redo it with the .TO bit but what im wondering is why this msg statment is not returning a .ER or a .DN and just hanging like this.

The cached communications box is NOT check marked.

 

[rdrast]

I'm not a Rockwell Engineer, and haven't experimented to see what happens too much, but it seems that if you MANUALLY switch off the .EN bit, the original message instruction still tries to execute in the PLC, but has no place to give it's results to. So now you re-cycle the .EN bit, and an entirely new MSG is queued up and sent/waited for.

ControlLogix MSG's are asynchronous to the CPU scan, so every time you initiate one, it must either finish (with success or failure), or time out. If you manually force the CPU to initiate yet another, the CPU has no place to actually store the result of the one it's trying to work on, so it gets discarded (hopefully). Forcing the MSG instruction to abort itself by manually setting the .TO bit actually cleans up the 'Stack' for that MSG instruction, and readies it to work again.

Depending on the protocol, there might be sequence information in the message reply, so if you manually terminate one (killing .EN) and initiate another, there is always the possibility that the remote device is responding to "SEQ-0001", and now you have a MSG instruction waiting for a response to "SEQ-0002", which will ignore the "SEQ-0001" response.

It gets much worse if both ends are looking for ordered packets (like you get with TCP over any physical layer).

manually playing with the .EN bit has been what i was using will redo it with the .TO bit but what im wondering is why this msg statment is not returning a .ER or a .DN and just hanging like this.

The cached communications box is NOT check marked.

 

[rbnice1]

I understand this, however toggling or not toggling the .EN bit is not causing this issue. The issue was there before we toggled the .EN bits so my question is where do i go from here to trouble shoot it? I have a message stuck right now io can look at.

 

[rdrast]

Hrm.. guess, one thing I have to ask, why did you upgrade from 8 to 12 ? The current revision is 16.

And I have absolutely zero experience with .MSG ing prior to oh, 11. On 11 and past, I've had one single problem with MSG instructions over ethernet, and that is to a device that is so pathetic that the manufacturer told me that "you are overrunning the buffer, only send one message every 2 seconds
"). I don't know what you are talking with, but I direct message PLC5's, SLC500's, Micrologix (w/ENI's), Various scanners, temperature controllers, drives, and others, and can't count comm's failures for the past year on one hand.

Just a thought, is there any chance you are polling too fast for your slave devices? The Logix platform is many many many many times faster than any older AB PLC, and much smarter.

I understand this, however toggling or not toggling the .EN bit is not causing this issue. The issue was there before we toggled the .EN bits so my question is where do i go from here to trouble shoot it? I have a message stuck right now io can look at.

 

[rbnice1]

we had to upgrade to version 12 when we upgraded to a newer 5000processor that is supposedly better with comunications......

Part of the problem i think is that we have a 5000 talking to 15 plc5's all on the same path they just have diffrent nodes. However its still a little strange to me that everything was fine and dandy till we upgraded to version 12 last year.

14 of the 15 plc's read and write less then once a minute but the main plc5 reads and writes constintly and when one of the others writes i see a blip on it when im trending the dh+ msg's