Logix5000 and msg

It seems to me when we updated to a new version of 5000 our msg writes and reads get stuck sometimes. They will be enabled but never error or done. When this happens you just toggle off the .en and it will reset it self. Seems like this only happened after we upgraded to version12.whatever. With the old version, we never had this problem. So now im having to add code to jumpstart the msg's, is there any one with info as to why msg statements are hosed with the new version of 5000?

ControlLogix v12 firmware changed some of the message flag behavior, so some methods of MSG management that worked in earlier versions don't work in v12 and later. This includes not-recommended-but-possible functions like manually resetting the .DN bit.

Can you describe the message handling logic you have now ?

Your description of "jumpstarting" the logic makes it sound like you have a continuous re-trigger sort of logic.

Well originally it is just a trigger that sets the msg and thats it, however do to it locking up i have a unlatch on the .en after 8 seconds, so when it does get locked up it resets. I should not need to reset it tho. the basic idea of a msg statment is it .en then .dn or .er This is enabling and just staying that way never getting done or erroring.


According to rockwell we should never unlatch the .en on a msg statement, but also according to them a msg statment wont just lock up either.

The only really acceptable way of "resetting" an MSG instruction is to manually set the .TO timeout bit, which forces a timeout error.

What network is this MSG going out on ? ControlNet, EtherNet/IP, DH+, DF1.... ?

What logic triggers the MSG instruction ? Is it a repeating timer, or a machine event ? What keeps this logic from triggering the message repeatedly before each message is complete ?

Is there any indication of noise or errors on your network ?

The msg is DH+ writes and reads from the 5000 to a 5 processor. The msg's are constant. we do a write then a read then a write then a read. The trigger is if there is control power and there isnt a write or a read going already. It keeps it from getting a write and read at the same time. Back before we flashed to version12.something we could do writes and reads at the same time. Now they have to be seperated and even seperated it gets llocked up.

Basically this is the way it looks.
msg write is mg17_0
msg read is mg17_1

XIC_controlpower XIO_mg17_0.en XIO_mg17_1.en MSG_MS17_0

XIC_controlpower XIO_mg17_0.en XIO_mg17_1.en MSG_MS17_1

Now after googling my problem i have added OTU_mg17_0.en.cc and OTU_mg17_1.en.cc but this doesnt seem to help, tho what i have read says to use it before your message statments.

Now also we have some reads and writes that are triggured with rsview screens that write data changed through rs-view32 to the 5000 then to a diffrent plc5, and we have problems with them locking up as well. I have to go in and toggle off the .en manually then they are fine again for a few days or so.


It is prossible there is noise on the network but shouldnt the message error out if thats the case? it went from working fine when we were using revision8.something. To totally hosed when we went to revision 12.something.

just a quick bump/update. For whatever reason after adding the OTU on mg17.en.cc i have only gotten 2 falures in 20 hours. We were getting 4-6 in the same time period. So if we go up to a newer revision will this correct the issue or do I need to rewrite all the code and set a .TO latch on all our msg's?

Your read/writes shouldn't have any failures.
Interlock the messages, alter the TimeOut connection, & there is no reason you can't see 0 failures in 24 hours.

CroCop what do you mean interlock the messages? I think they already are, and what do you mean by alter the timeout connection. It seems to me that is part of the problem it doesnt timeout on its own.

Looks like CroCop logged off.. By interlocking, he means that all the messages to a particular device are only triggerred one at a time. You appear to have done that if those are the only two messages to that node.


I am not sure what he means by "altering the TimeOut connection" He may be referring to the T.O. bit, or a timeout value setting in the message instruction...

oh.. hmm didnt know you could set the time out value....

rbnice1 said:

CroCop what do you mean interlock the messages? I think they already are, and what do you mean by alter the timeout connection. It seems to me that is part of the problem it doesnt timeout on its own.

Click to expand...

The connection time can be altered programatically. Your timeout is set to default, which is far too long, so you're trying to force the ER or TO bits manually. Change the timeout length, & the controller will handle it automatically.

It would be a MOV 10000 MSG.UnconnectedTimeout

ok just looked at the help file and it shows the timeout is defualt at 30 seconds but when i moved the value to a int to see it its at 30000000.

That isnt 30 seconds is it? And also when it locks up with out me reseting it with code it will lock up long enough for me to open and run the project then get online and then see it locked up. so its not timing out for 5 minutes or maybe longer. i have never tried to time it.

Yes the 30000000 is the 30 seconds default. I lower it always, as I expect my messages to work consistently & reliably.

ok thanks CroCop, im gunna try that when they go to break. However it still doesnt account for why they lock up for 5+minutes sometimes.

rbnice1 said:

ok thanks CroCop, im gunna try that when they go to break. However it still doesnt account for why they lock up for 5+minutes sometimes.

Click to expand...

I would turn down the time out, FIFO the error,timeout, or DN bits into an array, as well as error codes.

I think you've got to get a handle on this, as the messaging function has alot of built in diagnoistics, that will take alot of the work out of troubleshooting for you.