alertGet function hangs indefinitely

emaddocks · Post by **emaddocks** » Wed Jul 16, 2025 8:09 am

Hi,

We are using the alertGet function and 99.9% of the time it works as expected however on rare occasions it hangs indefinitely and never returns with an error code. We have to clear the alarm that is causing the alertGet function to hang and restart our vision to fix it and continue to process other alarms.

We seem to only see this occur on some internal DPEs and not consistently. Some of the DPEs we have seen it occur on are:

_ReduManager_2.Status.Reason

_Event.License.RemainingTime

_MemoryCheck_2.FreeKB

So it looks to be on int and uint DPEs rather than bools. When these alarms typically occur they do not cause the alertGet function to hang.

Just wondering if anyone else has ever seen this behaviour occur before and if so, has it been patched in a newer version of WinCC OA?

We are running WinCC OA 3.18 Patch 24 on RHEL 8.8.

Cheers
Eric

leoknipp · Post by **leoknipp** » Fri Jul 18, 2025 4:29 pm

In WinCC OA internally only DPE IDs are used. Therefore, it should not make a difference if you are using an internal or a project specific DPE at the alertGet() function.
When using this function you must exactly specify the time and count parameter for the alert where you want to read information.
What is the purpose of using alertGet() in your application?
Which attributes for the _alert_hdl config are read with this function?
How are you retreiving the information for the time and count parameter before calling alertGet()?

Best Regards
Leopold Knipp
Senior Support Specialist

emaddocks · Post by **emaddocks** » Wed Jul 23, 2025 2:14 am

Hi Leopold,

We are using it to get the acknowledgeable (_alert_hdl.._ackable) value of the partner alert. eg:

Code: Select all

alertGet(tPartner, iPartnerIndex, sDpe + ":_alert_hdl.._ackable", bPartnerAcknowledgeable);

where:

tPartner is the _alert_hdl.._partner value of the alert being processed

iPartnerIndex is the _alert_hdl.._partn_idx of the alert being processed

sDpe is the DPE of the alert being processed

An example of these three values when the alertGet function hangs is:

Code: Select all

["alertGet called"][2025.07.22 14:16:09.075000000][1]["MTDIST:_ReduManager.Status.Reason:_alert_hdl.._ackable"]

The tPartner and iPartnerIndex values are being returned from a dpQueryConnectSingle with the following SQL query:

Code: Select all

"SELECT ALERT '_alert_hdl.._system_time',"+
                       "'_alert_hdl.._value',"+
                       "'_alert_hdl.._ack_time',"+
                       "'_alert_hdl.._direction',"+
                       "'_alert_hdl.._class',"+
                       "'_alert_hdl.._sum',"+
                       "'_alert_hdl.._dp_list',"+
                       "'_alert_hdl.._filtered',"+
                       "'_alert_hdl.._filter_threshold',"+
                       "'_alert_hdl.._summed_alerts_count',"+
                       "'_alert_hdl.._came_time',"+
                       "'_alert_hdl.._panel',"+
                       "'_alert_hdl.._ackable',"+
                       "'_alert_hdl.._ack_user',"+
                       "'_alert_hdl.._gone_time',"+
                       "'_alert_hdl.._comment',"+
                       "'_alert_hdl.._add_value_1',"+
                       "'_alert_hdl.._add_value_2',"+
                       "'_alert_hdl.._partner',"+
                       "'_alert_hdl.._partn_idx'" +
         "FROM '{*}' " +
         "REMOTE ALL";

Do you think there is something wrong with the way we using the alertGet function? I would have thought that the function would return an error code rather than hang indefinitely if we were using it wrong.

Cheers
Eric

leoknipp · Post by **leoknipp** » Wed Jul 23, 2025 1:30 pm

If you are using a dpQueryConnectSingle like the mentioned one you will get all the alert information in the first call.
Then you will have data for the reference alert already in memory.
If there is a CAME alert, there will be no partner alert. Normally when a GONE alert is triggered also the CAME alert is updated and you should the information in the work function for the dpQueryConnectSingle.
Are you sure that you must use alertGet() to get the required information?

Best Regards
Leopold Knipp
Senior Support Specialist

emaddocks · Post by **emaddocks** » Thu Jul 24, 2025 2:01 am

Thanks Leopold,

We'll look into a work around that doesn't require the use of the alertGet() function. It seems to me that there is a bug within the alertGet() function as it should return an error, not hang indefinitely when called.

Cheers
Eric

leoknipp · Post by **leoknipp** » Wed Aug 06, 2025 4:44 pm

I have tested it with different alerts and a script which does a dpQuery() and alertGet() in a 5 second interval.
In my tests I cannot reproduce the problem that the alertGet() does not return.

The DP element _ReduManager_2.Status.Reason has a discrete alert handling where the alert class "_information" is used for all alert ranges.
This alert class is defined to have only came alerts and the came alers are not acknowledgeable. There will be no GONE alerts returned for a query for the current alerts. Only in historical queries you will find the GONE alerts.

Before using alertGet() you must check if the _partner_time is unequal to 0. Also it is important to use the correct partner index (count parameter) at the alertGet() function.
Doing an alertGet() to read information for the partner alert does not make sense for a CAME alert when there is no partner alert.

Best Regards
Leopold Knipp
Senior Support Specialist

Bugs / Problems