L83ES stops communicating to ABCIP IO server

[robertmee]

Have a customer that has a running 1756-l83es, communicating to redundant ABCIP IO servers for Wonderware 2020. This configuration has been running a little over a year.

Had an extended 2 week downtime, and upon restart the WW apps would not communicate to the L83. There's about a dozen WW HMIs that hit this PLC and none of the tags on those apps would update. The IO server diagnostics showed all green, as in valid tags, but all values were 0. Things tried:.

Cycle power on PLC
Cycle power on IO servers
Ping PLC from IO PC...fine
Create new topic in IO server, no help
Go online with PLC with studio (ver 32), no issues
Connect laptop directly to L83 with local IO server and test app, still no comms

Finally, they re downloaded the program to PLC, and it started communicating again.

I had never experienced this scenario before...Ive had ABCIP topics become corrupt, but recreating them always resolved. It almost seems like the PLC was in some memory protect mode that was disallowing CIP Connections. However, peer to peer message instructions to other PLCs were still working. Run to Program to Run or even power cycles wouldn't revive it, only a download of the program again.

Any thoughts as to what could have happened?

 

[robertmee]

Interesting. Sounds just like this, only its WW not PV. And also ver 32.

https://www.plctalk.net/qanda/showthread.php?t=124573

 

[JohnCalderwood]

We have a similar problem with WW 2014R2 and L8X PLCs on V32. If we switch off a PLC, or we downloaded a new version to a PLC or sometimes even just adding a new tag to the WW SCADA, the WW Application loses communications to all PLCs. We can disable the comms on WW and restart, or restart the application.
I would say we have noticed this since late 2018, both with the ABCIP and the OI drivers.

We have never been sure if it is a WW issue or a Rockwell issue.

 

[kekrahulik]

When we converted our first L72 --> L82 processor, we struggled to get online with the processor. One person could usually get online, but a second person couldn't. We finally discovered that our backup WW IOServer was running at the same time as the primary one. Once we turned it off - no more problems. I think (I'm not sure) that was the newest OI Server.

On my other lines, we still have WW 2014R2 and DASCIP IOServer. There are multiple servers running with the same configurations so they can be readily used as backups. I have tried several times to convert one of my L72's to an L82. Each time I have found the exact same issue with multiple users not being able to get online. My one production line needed the speed of the L82, so I have eliminated it from all IOServers except for one.

When I first discovered this issue, I had contacted Rockwell support. Some one there gave me an explanation something like "you can only have so many class 1 messages and a so many class 2 messages. In an L72, if it has too many class 1 messages and spare class 2 messages, it would spill over and keep talking. An L82 is more rigid and will not. So it cuts off connections". I wish I had noted who that person was because I have not found another person at Rockwell that knows anything about it.

 

[robertmee]

When we converted our first L72 --> L82 processor, we struggled to get online with the processor. One person could usually get online, but a second person couldn't. We finally discovered that our backup WW IOServer was running at the same time as the primary one. Once we turned it off - no more problems. I think (I'm not sure) that was the newest OI Server.

On my other lines, we still have WW 2014R2 and DASCIP IOServer. There are multiple servers running with the same configurations so they can be readily used as backups. I have tried several times to convert one of my L72's to an L82. Each time I have found the exact same issue with multiple users not being able to get online. My one production line needed the speed of the L82, so I have eliminated it from all IOServers except for one.

When I first discovered this issue, I had contacted Rockwell support. Some one there gave me an explanation something like "you can only have so many class 1 messages and a so many class 2 messages. In an L72, if it has too many class 1 messages and spare class 2 messages, it would spill over and keep talking. An L82 is more rigid and will not. So it cuts off connections". I wish I had noted who that person was because I have not found another person at Rockwell that knows anything about it.

Interesting....has anyone tried moving their comms to a secondary en2t module instead? Is it the port on the l83 that is causing the issue or the processor itself?

 

[kekrahulik]

Nope - not using the port on the processor - I have multiple 1756-EN2TR's. Was wondering if the front port might help me.

 

[robertmee]

Nope - not using the port on the processor - I have multiple 1756-EN2TR's. Was wondering if the front port might help me.

The one we had an issue with yesterday was on the L83 port. The other L83's we use the EN2T port, and haven't had the issue using the same I/O server setup.

 

[robertmee]

Found this too.....Time to dump Wonderware

https://cdn.logic-control.com/docs/...cause incorrect tags to be written to PLC.pdf