L82E v30 Messaging Issues

mjp123gp

Member
Join Date
Mar 2012
Location
Savannah, GA
Posts
94
We just tried updating an L55 processor running version 15 to an L82E processor running version 30. Nothing in the program was changed other than the processor type and firmware revision. We're still using the same ENBT card. When we tried running it, most of the messages to other SLC and CLX processors are getting an error with the extended err code "16#204 unconnected message timeout". Whats weird is the messages would go done occasionally but most of the time get the error.

Just to see if it was an issue with the new processor, I stuck the old one back in and everything worked fine and all messages go done. Stuck the L82E in one more time just to make sure and the errors comes back.

I've searched the Rockwell knowledgebase but can't find anything that talks about message issues with version 30.

Any ideas? This is my first time working with the L82 and version 30 so I'm not familiar with any of their quirks or AB anomalies yet.
 
How are the messages being triggered ? Timers ? Counters ? As-fast-as-possible ?

The L82E executes many times faster than the L55, so it's possible that something that worked because the rest of the program took many milliseconds before re-triggering a MSG will instead fill the buffer because the processor is faster.
 
They're on timers. I just went back through and counted 47 message instructions being triggered by 30 different timers so I guess it's possible too many of them are being triggered at the same time.
 
I seem to remember a check box in the MSG instruction that was added between those revs.

Maybe open the old rev program and the new rev program MSG instructions.
 
I have an L72S that I have tried to convert to an L82S. It's been an adventure and I'm still not there.

I was thinking that I was going from a CLX processor to another CLX processor - no problem because I've gone from L6x to L7x processors several times without any issues. Our local distributor helped to restructure my mindset. He pointed out that an L6x and L7X are just different hardwares(processors). The L8X is an all new beast. It is so much faster because it has mutiple processors AND because it handles instructions differently. The software is different too. So you need to think of this conversion as something between a L6x to L7X conversion and a PLC5 to CLX conversion. Not quite as easy as the first and not quite as hard as the second since the IO hardware is the same.

There is a 158 page document for replacing an L7x with an L8X processor. I scanned thru it and thought I picked up the few details that mattered to me. I was wrong - I needed to read in much greater detail. Here's the link.

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm100_-en-p.pdf

I got my program to convert from an L72S to an L82S (ver 31) without too much problem. When I loaded it in to the processor, it seemed to work - at least it didn't puke. However, it was difficult to get online sometimes. We ultimately found that our Wonderware was using the primary IOServer and Backup IOServer at the same time. The two IOservers were barraging the processor with too many messages. Apparently the L7x could handle the excessive class 3 messages by taking the extra in as class 1 messages where it had some extra room. The L8x will not do that and was therefore drowning from the excessive class 3 messages.

After fixing the WW, we tried again. All initially seemed good. However, once an hour or so, I would briefly lose my safety produce consume tags for a blimp - just enough to trigger an Estop - so I had to bail before running production. We ultimately got an AB engineer into help. He found that some of the ENET cards were not set up as unicast and we didn't have gateway addresses specified in all the ENET cards. Again, the L72S NEVER showed any issues with this, but the L82S did. Once he fixed those things, the comms were solid and we thought we were good to go.

When production started up, everything seemed to be working well for a few minutes and then we had an error on a MAOC instruction (OT-if you motion types don't know what that is, look it up - pretty cool). Anyway, we couldn't figure out what was causing the issue, so we aborted back to the L72S again.

After talking with AB, they are recommending that we read the entire 158 page document very carefully and then go through the program in slow detail to find all the things that could be affected. We are contemplating having AB do this ($$$$). Hoping we can learn from them and do the next one ourselves.

I don't know how much this helps you, but be warned that it may not be as straightforward as you initially thought. Read the document!

As some guesses. Your ENBT may not be set up right or may not be sufficient. You may need to go to a newer revision or to an EN2T. Don't assume that because your setup worked with the L55 that it is right and will work with the L8.

If you are using any produce consumes, READ THE DOCUMENT. There are some distinct differences in how an L8x handles them versus previous generations. I don't recall MSG's, but they may also be different. READ
 
They're on timers. I just went back through and counted 47 message instructions being triggered by 30 different timers so I guess it's possible too many of them are being triggered at the same time.

I trigger the messages by itself using a XIO bit with the .En bit of the message in the continuous task. Never have issues.

Something like this:

MSG_1.EN
-------|/|-----------------------------------[MSG_1]-------
 
I trigger the messages by itself using a XIO bit with the .En bit of the message in the continuous task. Never have issues.

Something like this:

MSG_1.EN
-------|/|-----------------------------------[MSG_1]-------

Ours our conditioned with the MSG enable bit like you've shown and also have the timers so they're not executed every scan
 
Thanks for the reply. I'll check out that document when I get back onsite tomorrow and see if there's anything that applies to our issue. We did have some issues with our SCADA as well which is iFix. Ours HMI issue was a little weird cause some data was reading just fine but certain data types were not being read. After updating the OPC topic with a few different settings we got that part working. The only issue that remained was the messages getting errors and that still hasn't been resolved. May give Rockwell a call too and see if they've seen the issue and can maybe save us some us time.
 
I'd recommend that you check with Ifix about compatibility with Rockwell ver 30.

We have upgraded our WW IOServer to the newest platform (forget the name right now) because it seemed to struggle with rockwell versions 29 and up.
 

Similar Topics

Hi I have been knocking my head against the wall trying to figure out why these two plcs won't talk with Produced and Consumed Tags data. The...
Replies
14
Views
417
Can't install firmware higher than v29 on an L82E CPU Fails at end when polling for power up AB-CIP pop-up reads 'Failed to communicate with the...
Replies
11
Views
2,328
We upgraded a machine which had 1756-L62 Ver 15 to 1756-L82E running version 32. Every once in a while the processor faults with Type 01 Code 61...
Replies
11
Views
3,249
We have 1756-L82E PLCs here and now we have issues with one PLC having a lot of used program memory, which bothers the client, and wants us to...
Replies
0
Views
1,218
Hi guys, seems that our HMIs are making too many CIP connections to PLCs (application connections) and we reach 256 max limit. After that no...
Replies
8
Views
2,912
Back
Top Bottom