GE Quickpanel+ IC775CSS12 Freezes when logging an alarm

Hello,

I was testing the alarms from the PLC to the QP+ by toggling on/off the shared variables in the PLC code while cross-checking the alarm display on the QP+ (I have around 172 alarms), everything was fine until the last 6 alarms. When I toggled either of the last 6 alarms, the QP+ got frozen. Cycling power helped put back the QP+ in service but it froze again when I did the same.

This did not happen with alarms above the last 6 ones. Could this be an overflow issue somewhere in the QP+ or in the alarm object itself ? I tried to increase the storage memory but it didn't help.

Does anyone has any suggestions ? Thanks.

To check if it is an overflow issue, delete one of the earlier alarms and see if it then only crashes on the last five alarms. 166 alarms is a strange number to be an upper limit on the total number of alarms.

Tried your suggestion but the problem persists. It seems that View Runtime crashes and I can't talk to the QP using Machine Edition (9.5 SIM9) after the incident (QP windows is ok). The shared variables used are ranged from %M2300 to %M2765. The bits that crash ViewRuntime are from %M2757.

Upgraded to SIM12 but ViewRuntime still crashes everytime I turn the bits on.

What is the expected response of the QP to the alarms that cause it to freeze? Do they trigger scripts that could be stuck in a loop? Don't overlook the possibility that other variables could be assigned to the same %M address.

Upgraded PME to SIM12 and the QP+ to Build24 but the issue wasn't gone. Then I changed the variables to different addresses it was OK no more frozen Runtime. The affected bits were %M2757 to %M2761.
Not sure if it was a variable conflict somewhere, checked both PLC and QP but couldn't find anything suspicious. If something was assigned to the same %M, I should be able to see it in the PLC code via the "References" tab.

If a specific range of %M memory causes the HMI to freeze up when any of the values are true but causes no problems when they are all false, it is hard to imagine anything other than a problem within the specific application being the cause.
Now that you have changed the addresses of the alarms, go back into the PLC program and toggle on the %M2757 - %M2761 bits to see if they still make the QP freeze. If you can't find the problem in the QP, you may have to take steps in the PLC program to make sure someone else doesn't use those bits later.
I would also create a simple View runtime application that does nothing more than display the values of those addresses. If you can demonstrate the a true state in any of those bits causes a QP lockup regardless of the View runtime application running on the QP, you should start a case with tech support.
If your company permits, post a copy of your project file here. I'll take a look to see if I can spot anything. I don't have a QP to test it on so I won't be able to duplicate your situation.

If something was assigned to the same %M, I should be able to see it in the PLC code via the "References" tab.

Click to expand...

Instead of that, sort the variables in your project by address. Then you can scroll through the variable list and locate all cases of multiple variables assigned to the same PLC address in the range that is causing the View runtime lockup. I expect the reason for the lockup will be found in the QP target rather than in the PLC target.

Thanks for your suggestions Steve. Unfortunately I'm not allowed to share the project file in public per the company policies, but thanks anyway for the enthusiasm.

Those bits only crashed View Runtime when they were assigned to log to the alarm display object (by setting the "discrete" property from "no alarms" to "when on"), after I turned them off to "no alarms" they did not cause the problem anymore. Toggling on/off the bits with Runtime running without assigning them to alarm display object also didn't stop the program.

I will create a simple View runtime app and see if the bits would cause the same issue to the program or not.

From post #1 I got the impression that simply toggling the PLC variable from off to on froze the HMI. After reading post #8 I'm not sure when the problem shows up.
When you change the property of the HMI variable from "No Alarm" to "When off" you need to download the HMI target. Does the freezeup happen after you perform the download or does the HMI not accept the download after erasing the old runtime? What does the feedback zone screen show you during the download process? Does Runtime start on the QP and then refuse to accept and touch or click actions?

The problem showed up when I toggled the bits %M2757 to %M2761 in the PLC to generate alarms to the QP View Runtime alarm display object. The purpose was to see if the alarm display object could log the alarms in. The QP did not freeze but only View Runtime stop responding. Sorry for the confusion.