PanelView Plus 7 and 1769-L18 CompactLogix

I have found that when a Momentary Push button is pressed when the power is shut off to the PanelView and CompactLogix controller. After power is restored and everythings comes back up. After resetting the MCR the Button says latched in and the motor is running. The tag for this button is only used in one place.

The version for the PanelView Pluss 700 is 8.20
And the firmware version for the L18 is 20.019

Does anyone know how I can resolve the momentary pushbutton tag to go false before the MCR is reset?

Thank you,
Dave

How can you push a button on a blank HMI display?

I presume the HMI is still powered up when you push the button and only the PLC and MCR are off.

If this is the scenario, then the HMI application will have "Errors" on top of each object.

Are you sure it is a Momentary push button?

If true, then the controller logic programming related to the motor starter is faulty; it does not take in consideration the variable timing of the Broadcast/Multicast communications data transfer.

Look in the CompactLogix. It seems the application controlling that motor is keeping the last state.

The Power shut off both the HMI and the PLC. When both come back online and able to reset the MCR the momentary push button is energized.

I can toggle the tag in the PLC and release the state or I can push the button on the HMI and it releases. Trying to figure out why it doesn't release when power is lost.

Three of 4 momentary buttons are doing the same thing. I copied the one that is working but it did not resolve the others.

There is something wrong with your terminal; most likely the touch display. Are they using sharp objects to operate it instead of fingers?

Do you have a spare?

I have another machine set up the same way and doing the same thing. HMI is a momentary Pushbutton for all the jog button. This is so that the operator can jog the motor in manual mode.

If the jog button is being pushed when there is a loss of power to the panel. I then loose power to the PLC and the HMI. So when power is restore and I can go online with the PLC I will notice that the PLC tag is still energized.

There are 4 motors. 3 of the 4 motors I can duplicate this scenario. I duplicated the button from the motor that wasn't being a problem and created an new button. The problem is still duplicated with the new button.

the fix for the time being is that when the MCR is reset I use a ONS to unlatch the tags that should not be energized. I don't believe this is the true fix but it is temporary solution.

In the HMI and the PLC I am trying to see if there is a setting to hold last state when power is loss. Does anyone know where I can check if there is such a setting?

Do you have "handshaking" setup for any of the pushbuttons?

No ... Not that I have programmed in. The tags are used only one place to manually jog the motors. $ motors 4 individual tags

Correction the tags are now used in two places. One to jog the perspective motor and the other is to unlatch the tag when the MCR is reset.

dmayhugh said:

I have another machine set up the same way and doing the same thing. HMI is a momentary Pushbutton for all the jog button. This is so that the operator can jog the motor in manual mode.

If the jog button is being pushed when there is a loss of power to the panel. I then loose power to the PLC and the HMI. So when power is restore and I can go online with the PLC I will notice that the PLC tag is still energized.

There are 4 motors. 3 of the 4 motors I can duplicate this scenario. I duplicated the button from the motor that wasn't being a problem and created an new button. The problem is still duplicated with the new button.

the fix for the time being is that when the MCR is reset I use a ONS to unlatch the tags that should not be energized. I don't believe this is the true fix but it is temporary solution.

In the HMI and the PLC I am trying to see if there is a setting to hold last state when power is loss. Does anyone know where I can check if there is such a setting?

Click to expand...

There isn't such setting for HMI pushbuttons; just Hold Time.

The controller will maintain the last state of the tag if communications are lost.

I had seen this happening with the first generations of PV+s (Rev.4); it was corrected via firmware updates and I don't recall it for the last ten years or so.

Why do you have to turn the power off to the HMI? If the controller boots up faster and the programming does not account for it you will get what you are experiencing.

Scary.

Is this a new system?

If it is not, has anything else been added on the HMI network?

This is a new system. I am an OEM integrator. Our final inspection of the equipment found this scenario and trying to find what is causing the button to hold the last state and not return to 0 after power is restored with out selecting the button again. this latches on and cause the motors to run with out any warning.

I use a ONS to unlatch the tags that should not be energized.

Click to expand...

I actually have an HMI Initialize routine that I call whenever the PLC goes into run mode for the first time (the S:FS bit is handy for this). One of the functions of that routine is a bunch of un-latch (OTU) instructions for any tag being addressed by a momentary pushbutton object on an HMI.

The momentary pushbutton object on your average HMI (including PV+) writes a TRUE value once when you press the button, then writes a FALSE value when you release the button.

It does not (typically) try to read in order to verify that either value took effect.

So if your controller was shut off when such a tag was True, then it makes perfect sense that the tag would still be True when you restarted the controller.

I've never seen an operator interface terminal that made momentary button values retentive through a power cycle. Power cycles are supposed to be uncommon, and recovery from them via programmed initial values is a normal way to start up a control system.

Older PanelView Plus terminals were notorious for the "stuck momentary button" phenomenon.

What would happen is that the terminal would sometimes fail to write the "FALSE" condition when the button was released. To my knowledge this really was a firmware problem and occurred only occasionally because of the sort of hard-to-find coincidences in communication command buffering that make firmware writers twitch when they talk.

But it was also common that a PV+ would be put on a lousy network where both TRUE and FALSE writes would frequently fail. Operators got used to punching the momentary button repeatedly until the machine action took place, but there's no way to release a button repeatedly, so the symptom became "the bit got stuck on".

Customers have generally gotten a lot better about installing good Ethernet networks. This is largely because now I/O runs on the network, and you can't just ignore a poor installation that makes the HMI flaky every once in a while.

PanelView 5000 terminals (the very new ones, not PV+) have, I've been told, a true I/O object so that they can run very fast pushbutton actions that cannot be subject to this sort of infrequent communication failure.

What you are observing is actually normal, even for new PanelViews. It's pretty much a design flaw of the PanelView comms in my opinion. The only way to prevent it is to use the ONS as mentioned before, or monitor the comms with the HMI. If the comms fail, unlatch all pushbutton bits.

The second option is slightly less foolproof but much easier to implement than to add all of those ONS bits in your code...