Rockwell Panelview momentary pushbutton problem

[martinzstl]

We have a compact logix L32E running RsLogix 5000 v.20, connected to two panelview plus 6 1000 over ethernet.

1) One, possibly both panelviews have started losing the connection to the PLC occasionally, after no problems for months. They are connected through a dumb switch. Cycling power on the control panel has fixed the comm loss. We are trying to figure out what would cause the comm loss.

2) We have noticed that when the panelview loses the comms, some of the momentary pushbutton commands from the panelview staid ON in the PLC. (Not sure if an operator was pressing a button when the comms went off). I tested this later by pressing a button and disconnecting the ethernet from the panelview, and the bit stays ON in the PLC. Searching online reveals that other people solve this problem by periodically unlatching all momentary bits from the panelview in the PLC. I was just wondering if there was a more elegant way to deal with this problem.

I tried to set up the panelview in the I/O Config and the PLC can see it, but I get errors because the assembly instance size is incorrect, and I can’t seem to find the correct one. If I could get it to talk is it possible to see a panelview comm fault and then clear the data in the PLC?
Thanks.

[kamenges]

The Panelview Plus 6 cannot be set up as an I/O connection. The connection is a peer-to-peer connection, similar to connecting your computer to the plc. The only way I am aware of to reset bits set from a Panelview Plus is to unlatch them in the program. Not much good for jogs, though.

As a side note, the Panelview 5000 can be set up as an I/O connection to a plc. That doesn't do you much good but that is where you would need to go for an Ethernet/IP connected Panelview.

Keith

[martinzstl]

Ok thanks.

I set up a five second timer to reset the panelview bits. This allows the operator to jog for few seconds before they have to press the button again. Annoying, but better than something running continuously with no control.

I just wish I knew why the panelview is dropping comms. Normally they just work all the time. It's not a complex setup. Panelview, ethernet cable, dumb switch, ethernet cable, PLC. I wonder if overheating can cause the panelview to do weird things.

We do also have a Network Address Translator router to get the plant network to talk to the PLC and HMI. Maybe that can cause problems.

[janner_10]

Have you replaced the Ethernet cable first between the two units?

Do the simple things first.

[mellis]

Rather then use a timer to unlatch the bits, I prefer to unconditionally unlatch them right after the logic that uses them. It's simpler, less instructions and tags. This works fine for start/stop pushbuttons.

In my mind, it's always important to deal with the "stuck on" condition.

[Geoff White]

rather then use a timer to unlatch the bits, i prefer to unconditionally unlatch them right after the logic that uses them. It's simpler, less instructions and tags. This works fine for start/stop pushbuttons.

In my mind, it's always important to deal with the "stuck on" condition.

+1

[Mad_Poet]

Martin > I just wish I knew why the panelview is dropping comms.
Martin > We do also have a Network Address Translator router to get the plant network to talk to the PLC and HMI


Any chance something on the rest of the network has the same IP
as either the panelviews or the PLC?
Poet.

[Ken Moore]

I have run into similar issues, where the number of connections in the PLC is exceeded. For some reason, Ethernet connections do not get closed properly and overtime you end up with a bunch of connections open, the PLC runs out of connections and will not communicate with anything. Cycling power to the PLC, closes all the connections and you are okay for a period of time. When the panels lose comms, can you go online with a laptop?

[rdrast]

Originally Posted by mellis

Rather then use a timer to unlatch the bits, I prefer to unconditionally unlatch them right after the logic that uses them. It's simpler, less instructions and tags. This works fine for start/stop pushbuttons.

In my mind, it's always important to deal with the "stuck on" condition.

That works for many things, but not Jog type functions.

[kamenges]

I'm fairly certain the L32E has a web page. You might want to open that when this happens and look at the network diagnostics section. That might give you some clues as to what is happening. Even if all the Ethernet/IP connections are chewed up I THINK the web page will still serve up pages.

Keith

[martinzstl]

"Any chance something on the rest of the network has the same IP
as either the panelviews or the PLC?"

-The plant network has a different IP range. The local has the standard 192.168.x.x


"Rather then use a timer to unlatch the bits, I prefer to unconditionally unlatch them right after the logic that uses them. It's simpler, less instructions and tags. This works fine for start/stop pushbuttons."

-Unfortunately, most of my HMI buttons are jog buttons that need to stay on for at least a few seconds.


"I have run into similar issues, where the number of connections in the PLC is exceeded. For some reason, Ethernet connections do not get closed properly and overtime you end up with a bunch of connections open, the PLC runs out of connections and will not communicate with anything."

-If it happens again we will try to go online. Also maybe cycle power just to the PLC and then see if the panelview reconnects.

-Thanks for all these suggestions. We have two other systems with a similar setup and they don't seem to have this problem as far as I know. Maybe it is just a flaky ethernet cable on this system. We will have to monitor it for now and see if it keeps dropping comms.