Yes, it does.

The kit server defines various event categories, but among them, it is currently capable of generating those below.

Simple Events:

- Regular events each 1 second, each 10 seconds, and each 1 minute – they are generated automatically, no need to do anything extra.
- You can trigger that a simple event is generated by writing True (or any non-zero) to OPC-DA item SimulateEvents.SimpleEvent1.Generate ….. up to SimpleEvent9.

Tracking Events:

- You can trigger that a tracking event is generated by writing True to OPC-DA item SimulateEvents.TrackingEvent1.Generate ….. up to TrackingEvent9.

Condition Events:

- You can trigger those by writing to OPC-DA items under SimulateEvents.ConditionState1 ….. up to ConditionState9. Generating condition event notification is different, as you basically manipulate the condition state by writing True (or any non-zero) to items such as SimulateEvents.ConditionState1.Activate, SimulateEvents.ConditionState1.Acknowledge, and this in turns changes the state and send out the notification.

With the events that you can trigger trough OPC-DA, you also have the option to first set their other parameters (such as Message, AttributeValues) through writing by OPC-DA, and generate the event then. All this is meant for testing/demo purpose, and many examples provided make use of it (let me know if you cannot locate them or need more information).

Zbynek Zahradnik

From: R.
Sent: Thursday, September 15, 2011 10:22 PM
To: Zbynek Zahradnik
Subject: RE: Subscription filters

Yes, that is also a good point.

One other question- does the kitserver support filtering?

R.

And, if you wanted to determine the support for particular event type (such as Tracking) from application code, see bullet #2: call QueryEventCategories with AEEventTypes.Tracking, and if you receive an empty list of categories, then Tracking event type is not supported by the server.


Best regards,
<span style="font-family: "Arial","sans-serif"; color: #1f497d; font-size: 10pt">Zbynek Zahradnik

Yeah, I think that’s just a question of wording it differently.

<span style="font-family: "Arial","sans-serif"; color: #1f497d; font-size: 10pt">Zbynek Zahradnik

From: R.
Sent: Thursday, September 15, 2011 7:11 PM
To: Zbynek Zahradnik
Subject: RE: Subscription filters

Zbynek,

Thank you. I think that does help. Point 5 helps the most. I think what I found confusing is that TOP server help file states:
The Alarms & Events Plug-In also supports filtering categories, which differ by event type. The supported filtering categories are as follows:
Simple Events

Server Information Events: These are the same information events that appear in the OPC server event view.


Server Warning Events: These are the same warning events that appear in the OPC server event view.


Server Error Events: These are the same error events that appear in the OPC server event view.

Conditional Events

Level Conditions: Events generated by Level conditions (MULTI_LEVEL, HI_HI and so forth).


Rate of Change Conditions: Events generated by ROC conditions (ROC).


Deviation Conditions: Events generated by Deviation conditions (DEV).

This to me says that Tracking event filtering is not supported at all.

R.

R.,
I am not sure if I fully understand, so for start I will throw in some related pieces of information and hopefully that either helps or triggers further questions.

1. Per OPC spec, “a particular event category can include events of only one type”.

2. With QueryEventCategories, you can specify one or more event types. If you want to get categories for two or more types, you can use “logical OR” to combine the event types into one; or, there is a pre-defined constant AEEventTypes.All that combines all three event types, so if you use it you can obtain event categories for all types in one call.

3. If you want to determine for each event category which event type it generates, you will need to call QueryEventCategories three times, passing it Simple, Tracking and Condition in sequence. You will end up with three sets of categories, each for a particular event type. This may be the practice you are looking for?

4. When you create a subscription filter, you may – among other options – filter by event types, or event categories. If you specify event categories, then filtering by event types does not make much sense, because categories imply types (see #1). But a subscription filter with event types does make sense if NO categories are specified in the filter: In such case, events of ALL categories are returned (this may be missing from the documentation), so filtering by event type then becomes meaningful.

5. When the OPC server supports filtering by event types, it always support filtering by all of them (Simple, Tracking and Condition). It is possible that the server is not capable of generating certain event type at all (as is the case with Tracking events and TOP Server – that’s quite usual), but that does not invalidate this statement – the server makes the filtering and if you ask for an event type that does not get generated, you’ll receive no events of that type…

Best regards,
Zbynek Zahradnik

From: R.
Sent: Thursday, September 15, 2011 3:42 PM
To: Zbynek Zahradnik
Subject: Subscription filters

Zbynek,

I have [...] “best practices” question for you for A&E.

Let’s say I want to apply an event filter to my subscription. The TOP Server only supports “Simple” and “Condition” event filters. I have confirmed with Kepware that is you send it a filter type of ‘Tracking” no event notifications will be sent to the client. I have tested the QueryEventCategories method as a way to determine what categories are supported by the server and what I receive back from the TOP server is:
- Rate of Change alarms
- Deviation Alarms
- Level Alarms
- Runtime error events
- Runtime warning events
- Runtime information events

What would be the best way to then organize those returned values into the supported AEEVentTypes (Condition, noevent, simple, tracking). Do I just need to manually handle that in the code somehow? i.e. for the first three get applied as “condition” events and the rest as “simple”. But then the returned values will be different for each server, so how do I handle classifying them in a generalized way that can be dynamic without saying something like: if my dictionary value = “rate of change alarms” then use the AEEventType.condition filter?

Or, is there some way to query the supported filter interfaces in terms of the supported AEEventType members that I am missing in the help file?

I hope this question makes sense. Thanks in advance for your help.

R.