PanelView not reconnecting to PLC after power cycle

Hi everyone,

I have an issue with a PanelView, and occasionally I see it on others, where when a panel is powered down and then powered back on, no matter the length of time, once the application is loaded and started, everything on all the graphics shows error like its not communicating to the PLC. Sometimes power cycling the entire panel fixes it, other times it doesn't so then I cycle power on the PanelView.

Not sure why this happens. PLC and the network switch are powered on and online by time the application is loaded. Unless occasionally the PLC is waiting for a few EtherNet/IP nodes to come online but I wouldn't think this would hold up communication between the PLC and PanelView.

PanelView is a Plus 7 Performance 10", PLC is a compactlogix L16ER. EtherNet IO is a point IO adapter and 2 IO-Link EtherNet/IP field blocks.

Thanks!

I'll try to describe one situation we've had with PanelViews:

PanelView and PLC are connected through a stratix 5700. When power is cycled, the PLC, switch and PanelView all power off. When the system would power up, occasionally the PLC wouldn't talk. We would switch screens on the PanelView, it would start communicating and be happy. It would sit there unhappy until we switched screens.

Tech note 675876 sort of describes the behavior, though it claims that it would start communicating eventually, we did not experience that exactly. I have this device called a "sharktap", which is a USB powered port mirroring device. When plugged in through the sharktap, it would power up and communicate every time. I think this is because the port is active much faster than when plugged into the stratix. We ended connecting the HMI directly to the 2nd port in our CompactLogix and it powered up and communicated every time. So I think the problem had to do with how long it took the Stratix to power up and activate the ports.

I saw another tech note that says this behavior can happen when the PLC is in the I/O tree also. So if your PanelView is in the I/O tree, remove it. edit: TN 40014

Thanks,

I was thinking of plugging the panelview into the 2nd port on the compactlogix but was wondering if these 2 ports act as a switch to where I would still be able to connect to the panelview remotely through the network. If that is the case then I am fine with doing this.

The panelview is in the RSLinx enterprise communication setup, I have it in there so that I can download applications to the panelview through the network.

Another thing to note which may be my problem, is that every PLC and PanelView on our network, about 20 PLCs and 20 PanelViews, are all in the runtime (target) list.

Well the 2nd port is most likely treated as a switch. The exception to that would be with the new 5069-L3x0ER controllers, their 2nd port can be configured as an additional adapter rather than "as a switch". So if you have a 1769 CompactLogix, it is treated like a switch.

Edit: when I mentioned having the PanelView in the I/O tree, I meant of your PLC program. You can add a PanelView into the I/O tree of your PLC Program, but it is generally considered a bad idea.

oh, ok. I don't think I've ever thought of putting the panelview in the PLCs IO tree.

I did go ahead and try taking all but the target PLC out of the Ethernet configuration for the panelview. Will see if that helped any.

dmroeder said:

I saw another tech note that says this behavior can happen when the PLC is in the I/O tree also. So if your PanelView is in the I/O tree, remove it. edit: TN 40014

Click to expand...

drummin89 said:

oh, ok. I don't think I've ever thought of putting the panelview in the PLCs IO tree.

I did go ahead and try taking all but the target PLC out of the Ethernet configuration for the panelview. Will see if that helped any.

Click to expand...

By chance, did either of you use the COPY button in FTView Studio communications (copies Local communication to Target)?

This is just a side note, that may have nothing to do with the comms issues (or Statix)
But that button really shouldn't be used.
It is much better to delete the entire Target configuration, and manually build it up; leading only to the PLC(s) that you use.