View Full Version : Control Logix to PV Plus Ethernet comms problem

Rick Campbell
August 31st, 2013, 03:54 PM
Please help. I'm upgrading a SLC 5/04 communicating with a standard PanelView to a ControlLogix communicating with a PanelView Plus 6. So far I've converted two screens. One works great, but on the other the comms keep dropping in and out and I get messages saying something to the effect that CLX Processor packet disconnected in route, and then I get messages saying tag nnnn now resolved in processor. The kicker is that if I go from this screen to the other working screen, I still don't have comms. The screen with the problem is mainly momentary pushbuttons and multistate push buttons. Most of the tags referenced are arrays of DINTS. I was wondering if maybe array size matters - some 60+ elements. Does the PV request info for the whole array even if the object only looks at one element? Any ideas would be appreciated.

Ken Roach
September 2nd, 2013, 04:30 PM
My guess is that you accidentally used an element that's not in the array, like using ArrayName[50] on an array that's only 50 elements long (0 through 49).

You should be able to test this on your development PC, where you get the full benefit of the FactoryTalk Diagnostics window, which might be able to tell you exactly which tags are generating the error.

Is the ControlLogix heavily utilized ? Sometimes I've seen this kind of thing on older CompactLogix controllers that were almost out of CIP connection capacity.

Rick Campbell
September 2nd, 2013, 05:06 PM
Ken, Thanks for the suggestions. I double checked the arrays referenced in the "Connections" tab like you said to make sure I'm not referencing any elements outside of the defined arrays - no problems there.
No the ControlLogix isn't heavy utilized. Also, I have another screen sending just as much data back and forth that works with no problems - until I go to my problem screen. Then, if I go back to the first screen, I get errors o that screen as well. So I think the error lies somewhere in that particular screen.
I'll run the app from the development screen like you suggested. Also, I was thinking about temporarily removing all the multi-state push buttons from my "problem" screens to see if that makes a difference - just because the only difference between my "problem" screen and my "good" screen is that the "problem" screen contains multi-state push buttons and the "good" screen doesn't. Although, the "good" screen does contain some multi-state inidicators.
One other interesting piece of information is that even on my "problem" screen, the buttons and inidicators go back and forth between working properly and showing errors.

Thanks again.