Continuing with the OPC overview, after a brief interlude for some Halloween candy and a nasty cold that slowed me down quite a bit (even after multiple doses of Buckley’s and Extra Strong Fisherman’s Friends)

4.4 OPCGROUP OBJECT     Page.53

Blogger Note:  The Group Object is the real workhorse of the specification.  It describes the various data access methods, and a server has to implement pretty much all of them.

4.4.1 General Properties     Page 54

The OPCGroup has certain general properties and behaviors which affect the operation of the Interfaces and Methods.

4.4.1.1 Name     Page 54

As we mentioned in the Server section, Groups need a name that is unique to the client and OPC clients are allowed to change the name of a group.  Although the specification states that group names are case sensitive (i.e. my_group and MY_GROUP are two different groups), you will run into OPC clients that force a case in order to avoid any confusion.

4.4.1.2 Cached data     Page 54

Restates that the specification uses the terms CACHE and DEVICE as abstract concepts. The specifications do not dictate the implementation details, but in general CACHE is expected to be ‘fast’ and DEVICE is expected to be slower but less ‘stale’.

4.4.1.3 Active     Page 54

All groups have an active flag, which is separate from the item active flag.  These flags are designed to clients/servers to optimize speed and resources.  The implementation behavior of how the state of these flags affects the behavior of various interfaces is well defined. However the specification does not dictate how or when these flags are used.   Some OPC clients may allow users to toggle these flags at any time.  Others might only programmatically control the group active state, such as during a server start up.

4.4.1.4 Update Rate     Page 55

The client can specify an ‘update rate’ for each group. This determines the time between when the exception limit is checked. If the exception limit is exceeded, the CACHE is updated. The server should make a ‘best effort’ to keep the data fresh. This also affects the maximum rate at which notifications will be sent to the client’s callback. The server should never send data to a client at a rate faster than the client requests.

It’s important to remember that the update rate is a contract between the OPC client and server.  It is not necessarily related to the servers underlying processing rate.  Two clients may be accessing the same item at different update rates, or multiple items in a group might have different Item Sampling rates (more on Sampling later)

4.4.1.5 Time Zone (TimeBias)     Page 55

It’s possible the OPC client and server are in different timezones.   For various reasons it was not prudent to have to add timezone information overhead to all data transactions. Instead, the OPCGroup provides a place to store a time zone that can be set and read by the client. The default value for this is the time zone of the host computer. The OPCServer will not make use of this value. It is there only for the convenience of the client.

4.4.1.6 Percent Deadband     Page 56

Deadband only applies to analog values, and is based on a set percentage of the item range (EU High – EU Low).  The PercentDeadband can be set when AddGroup is called, allowing the same PercentDeadband to be used for all items within that particular group. However, with OPC DA 3.0, it is allowable to set the PercentDeadband on a per item basis. This means that each item can potentially override the PercentDeadband set for the group it resides within.

4.4.1.7 ClientHandle     Page 56

Returned on  callbacks so client can match the data with the right group.

4.4.1.8 Reading and Writing Data     Page 56

There are basically six ways to get data into a client.

• Synchronous Read (from cache or device)
• Asynchronous Read (from device)
• Subscriptions (exception based) which can also be triggered by Refresh.
• ItemIO Read (from cache or device as determined by “staleness” of cache data)
• Synchronous ReadMaxAge (from cache or device as determined by “staleness” of cache data)
• Asynchronous ReadMaxAge (from cache or device as determined by “staleness” of cache data)

The last three are new with DA 3.0

There are five ways to write data out:

• Synchronous Write
• Asynchronous Write
• ItemIO WriteVQT
• Synchronous WriteVQT
• Asynchronous WriteVQT
Again, the last three are new with DA 3.0

4.4.2 IOPCItemMgt     Page 58

Allows a client to add, remove and control the behavior of items is a group.
Blogger Note:  The majority of the following sections of the spec go into mind numbing details on result codes, parameter types, pointers, arrays and such stuff.  For most of these sections I’ll just point out any interesting details..

4.4.2.1 IOPCItemMgt::AddItems     Page 58

It is acceptable to add the same item to the group more than once.  Note that if an Advise is active, the client will begin receiving callbacks for active items. This can occur very quickly, perhaps even before the client has time to process the returned results. The client must be designed to deal with this.

4.4.2.2 IOPCItemMgt::ValidateItems     Page 60

Let’s clients validate items without actually having to read data.

4.4.2.3 IOPCItemMgt::RemoveItems     Page 62

Indicates whether or not the client is interested in a particular item.  It does not affect the address space of the server or physical device. The client should insure that no further references are made to deleted items.

4.4.2.4 IOPCItemMgt::SetActiveState     Page 63

Activating items which were previously inactive must result in a callback at the next UpdateRate period

4.4.2.5 IOPCItemMgt::SetClientHandles     Page 64

In general, it is expected that clients will set the client handle when the item is added and not change it later.

4.4.2.6 IOPCItemMgt::SetDatatypes     Page 65

In general, it is expected that clients will set the requested data type when the item is added and not change it later.

4.4.2.7 IOPCItemMgt::CreateEnumerator     Page 66

The client must release the returned interface pointer when it is done with it.

4.4.3 IOPCGroupStateMgt     Page 67

Allows the client to manage the overall state of the group. Primarily deals with changes to the update rate and active state of the group.

4.4.3.1 IOPCGroupStateMgt::GetState     Page 67

This function is typically called to obtain the current state values prior to calling SetState, and is also useful for debugging.

4.4.3.2 IOPCGroupStateMgt::SetState     Page 69

Sets group information like update rate, time bias, deadband and active state.

4.4.3.3 IOPCGroupStateMgt::SetName     Page 71

Changes a groups name.

4.4.3.4 IOPCGroupStateMgt::CloneGroup     Page 72

Creates a copy of a group with a new name and handles.  It is completely independent from the group it was cloned from, so clients would need create new connections just like any other group.

4.4.4 IOPCGroupStateMgt2     Page 74

4.4.4.1 IOPCGroupStateMgt2::SetKeepAlive     Page 74

4.4.4.2 IOPCGroupStateMgt2::GetKeepAlive     Page 76

New to DA 3.0 and is an extension of the DA 2.0 GroupStateMgt interface.  The purpose of this interface is to set/get the keep-alive time for a subscription. When a subscription has a non-zero keep-alive time, the server will insure that the client receives a callback on the subscription minimally at the rate indicated by the keep-alive time, even when there are no new events to report. By providing callbacks at a minimum known frequency, the client can be assured of the health of the server and subscription without resorting to pinging the server with calls to GetStatus().

Another lengthy post, but hopefully informative too.   There is still a lot of stuff to cover regarding the different reads and writes, but I’ve sure your coffee mug is empty by now so we’ll leave that until next post.

I’d like to close with a note on Buckley’s.  You got to admire a product with the tagline “It Tastes Awful.  And It Works”   Their product motto is:   “When it comes to being sick, there are two kinds of people in this world. Those who want comfort, and those who want to get better. We make medicine for the second kind.”

Sometimes in life you got to put up with a little bit of pain to get the results you are looking for.  It’s a good perspective to remember next time your implementing a tricky OPC architecture  (or fighting a tenacious cold)