For the last little while my postings have been pretty detailed, even though from a specification point of view the commentary was quite high level.    I think demonstrates the point I was trying to make, that the specifications ARE very low level and detailed.  The decision on whether or not to use OPC does not lie in the specifications, rather its best found in case studies, user experience and training courses conducted by those who know, use and develop OPC

After reviewing the overview posts one question I don’t think I answered is one I get asked a lot. Is OPC really plug and play?  Well, in terms of interoperability, I’d say yes OPC is almost there.   What does the term ‘plug and play’ mean?  Generally, it means when you install a component, it slides in with other pieces of the architecture seamlessly, without the need for a lot of configuration.   With the increased focus on interoperability, OPC Certification, Interoperability events and vendor commitment OPC is getting closer to true plug-and-play.  That is if you connect a trusted OPC client to an OPC server from a reputable OPC vendor, you would not expect to have any interoperability issues. 

However, does any technology mean you no longer need to consider connectivity issues or architecture design?   Can any specification cover all the features users want?  Back in the days of Yore, before the Microsoft-oply and Proprietary Dinosaurs roamed the industrial automation landscape, getting applications from different vendors to communicate was a significant problem.  An old adage I’ve heard repeatedly that I must agree with is ‘Connectivity issues get 1% of the budget and are 99% of the headaches’.    Sometimes I think that even with the wide spread adoption of OPC, that adage hasn’t really changed much.   Although OPC solves the issues of proprietary interfacing, many system implementers think ‘We don’t need to spend time or money on system integration, we’ll just use OPC’.  Yes, OPC solves the question of which interface to use and does reduce implementation time and costs.   But what about the issues associated with functionality, through put, guaranteed data delivery, network interoperability, communication disruption and recovery, maintainability and the countless other considerations associated with system connectivity?  

I think a much better saying to live by is ‘Plan and Play’.  Regardless of what technology you are using, you need to be working with a trusted vendor who understands your requirements and has the products and services to meet your needs.   OPC has done amazing things with leveling the playing field for system interoperability.  However, no protocol, technology or product can remove the planning and understanding needed in creating industrial strength connections between different systems.  So use OPC plug-and-play technology from a vendor you trust, and plan your implementation and get out and play.

This is the final posting on the DA Specification overview.  When I started this series, I warned you that most of the specification is geared towards what is needed to actually sit down and develop an OPC Server, and less on the how and why of using OPC.   Hopefully I was able to shed some light on those things over the last few postings.

4.5 CLIENT SIDE INTERFACES     Page 130

Blogger Note:  In terms of Compliance, there was no test for OPC clients.   The original thinking was OPC clients could implement as much or little of the specifications as they needed.   The onus was on the OPC Server to handle poorly behaving clients, and the specification only outlines the interfaces OPC Clients need to implement in order to properly handle callbacks and shutdowns  This lead to many interoperability problems.
The revamped OPC Certification process now places more requirements on OPC client development.  These include attending OPC Interoperability sessions and testing against a standardized test client the OPC Analyzer, before a client can be Certifified.

4.5.1 IOPCDataCallback     Page 130

This interface allows an OPC client to access the asynchronous functionality of an OPC server.  Only very simple or limited functionality clients would not support callbacks.  In order to be considered properly behaved, an OPC client must implement all methods on the interface.

OPC clients must also follow standard COM programming rules when dealing with memory management.   A poorly written OPC client can make it appear that an OPC server is ‘leaking’ memory.

4.5.1.1 IOPCDataCallback::OnDataChange     Page 131

Needed to access exception based data changes and Refreshs.  A client should expect to receive callbacks when the value or quality changes on an active item in an active group, but no faster than the set update rate.  Of course callbacks will also occur shortly after a Refresh request.

4.5.1.2 IOPCDataCallback::OnReadComplete 134

Called upon the completion of a Async Read.

4.5.1.3 IOPCDataCallback::OnWriteComplete     Page 136

Called upon the completion of a Async Write.�
�
Blogger Note:  A successful write does not necessarily mean the value was actually accepted by the underlying system, just that is was successful as far as the OPC server can determine.   Robust clients will perform a follow up read to ensure the write was not rejected at a lower level.

4.5.1.4 IOPCDataCallback::OnCancelComplete     Page 138

Called upon the completion of a Cancel request.

4.5.2 IOPCShutdown     Page 139

Good OPC clients will implement this interface, as it is the only way for an OPC server to cleanly notify the OPC client that it is shutting down.  Of course if the client supports connections to multiple servers, it would support interfaces for each server instance.

4.5.2.1 IOPCShutdown::ShutdownRequest     Page 139

Servers use this method to tell clients of impending shutdown, and allow them to perform clean up actions such as unadvising callbacks, etc.

5 INSTALLATION ISSUES     Page 140

The specification does not mandate any form of installation program, interface or installation type functionality.   However there are key registry settings and files required by Certified OPC products during installation.

5.1 COMPONENT CATEGORIES     Page 140

Outlines the Microsoft Component Category ids required by DA 3.0 servers.   These where introduced with OPC DA 2.0 to improve server discovery.   DA 1.0 installations required clients to perform time consuming remote registry scans, or worse require users to manually update the server machine registry.

5.2 REGISTRY ENTRIES FOR CUSTOM INTERFACE     Page 140

Required registry keys for any OPC server.

5.3 REGISTRY ENTRIES FOR THE PROXY/STUB DLL     Page 141

The proxy/stub DLL is used for marshalling interfaces to LOCAL or REMOTE servers. It is generated directly from the OPC Foundation supplied code and should be the same for every OPC Server.   Prebuilt and tested proxy/stubs are provided at the OPC Foundation Web site making it unnecessary for vendors to rebuild this DLL.

6 DESCRIPTION OF DATA TYPES, PARAMETERS AND STRUCTURES     Page 142

6.1 ITEM DEFINITION     Page 142

The ItemID is the fully qualified definition of a data item in the server, commonly referred to as the WHAT. No other information is required to identify the data item for the client to be able to read/write values.

Blogger Note:  ItemIDs are unspecified by the OPC Foundation.   Servers can use pretty much any format or naming convention they want.  This is both a majority flexibility feature, and an interoperability headache.   The open format allows servers to offer very powerful data access features by simply having a well documented naming convention.   On the other hand OPC clients need to be able to handle many formats, and make no assumptions on naming conventions like name length, acceptable characters or delimiters, or even that the ItemID is in any way related to the browse structure a server may expose.

6.2 ACCESSPATH     Page 143

The AccessPath is intended as a way for the client to provide to the server a suggested data path (e.g. a particular modem or network interface). It indicates HOW to get the data.

The ITEM ID provides all of the information needed to locate and process a data item. The Access Path is an optional piece of information that can be provided by the client. Its use is highly server specific but it is intended to allow the client to provide a ‘recommendation’ to the server regarding how to get to the data.

Blogger Note:  This was a good idea that resulted in many interoperability problems.  Since it was an optional feature neither clients or servers could rely on the AccessPath to provide information.   Most well written clients/servers use it as a convenient way to pass information, but will rely on the ItemID or other configuration to ensure essential data is transferred.

6.3 BLOB     Page 144

Essentially a binary ‘scratch pad’ that allows clients and servers to exchange unstructured binary information.
Blogger Note:  Another good idea that suffered from interoperability problems.

6.4 TIME STAMPS     Page 144

Time stamps are in the form of a FILETIME as this is more compact than other available standard time structures. Time stamps are always in UTC since this form is always increasing and is unambiguous. Time stamps should reflect the best estimate of the most recent time at which the corresponding value was known to be accurate. If this is not provided by the device itself then it should be provided by the server.

Blogger Note:  The most common complaint with OPC timestamps is that there is no standardized way of clients to determine if a timestamp is supplied by the underlying device, the OPC server or even an aggregating OPC server.   OPC UA addresses this problem by supplying two timestamps a SERVER and SOURCE timestamp.

6.5 VARIANT DATA TYPES FOR OPC DATA ITEMS     Page 145

Outlines how VARIANT data types are handled with Win95, NT 4.0 and Automation interfaces.  It also points out that under IEEE rules, NAN values are allowed and must be handled by clients and servers.

6.6 CONSTANTS     Page 146

6.6.1 OPCHANDLE     Page 146

OPCHANDLEs are used in conjunction with both groups and items within groups. The purpose of handles in OPC is to allow faster access to various objects by both the client and the server.

6.6.1.1 Group Handles     Page 146

6.6.1.2 Item Handles     Page 146

Describe specifics on how servers handle the handles.

6.7 STRUCTURES AND MASKS     Page 147

6.7.1 OPCITEMSTATE     Page 147

6.7.2 OPCITEMDEF     Page 148

6.7.3 OPCITEMRESULT     Page 150

6.7.4 OPCITEMATTRIBUTES     Page 151

6.7.5 OPCSERVERSTATUS     Page 153

Gory details on specific structures and masks used within the OPC specification. 

6.7.6 Access Rights     Page 154

This represents the server’s ability to access a single OPC data item in terms of readable and writeable.  Client applications should use this information only as something to be viewed by the user. Attempts by the user to read or write a value should always be passed by the client program to the server regardless of the access rights that were returned when the item was added.

6.7.7 OPCITEMPROPERTY     Page 156

6.7.8 OPCITEMPROPERTIES     Page 157

Describe specifics on OPC Item Properties.

Blogger Note:  Yet another powerful feature that suffered interoperability woes.  Item properties could supply important information, but suffered from less than performant access calls.  DA 3.0 aliviated this somewhat by adding property information to the browse interface.   Again this issue has been dealt with in OPC UA.

6.7.9 OPCBROWSEELEMENT     Page 158

6.7.10 OPCITEMVQT     Page 159

New structures to handle new DA 3.0 functionality.

6.8 OPC QUALITY FLAGS     Page 160

These flags represent the quality state for a item’s data value. This is a simplified version of the Fieldbus Data Quality Specification. The intent of the design was to make easy for both servers and client applications to determine how much functionality they needed to implement.

Blogger Note:  Although there are some rarely used Quality codes, for the most part the GOOD, BAD and UNCERTAIN codes and associated sub states are fairly well used and predicable. In general, most of these states have migrated to OPC UA.

7 SUMMARY OF OPC ERROR CODES     Page 164

The OPC specification attempts to minimize the number of unique errors by identifying 32 common generic problems and defining error codes that can be reused in many contexts. An OPC server should only return those OPC errors that are listed for the various methods in this specification or are standard Microsoft errors.

8 APPENDIX A – OPCERROR.H     Page 167

9 APPENDIX B – DATA ACCESS IDL SPECIFICATION     Page 173

Nothing says ‘gearhead’ like a document that includes header or IDL files in the documentation.  If you don’t know what a header or IDL file is, then your not missing anything unless your job is to produce a working OPC server.

Whew!  Got to admit, when I decided to recap a 190 page specification from a high level, decision maker’s point of view, I didn’t think it would take six lengthy postings.   It just goes to show that standardized interoperability is not child’s play.   There are many key aspects to consider and many more factors to consider when choosing an OPC vendor you can trust to know what they are doing.  No wonder pundits say system interoperability is 10% of the budget and 90% of the heartache.

I hope that a few of you out there got some good information from this exercise, then it was worth the effort.  I know that taking forcing myself to take a renewed, close look at the specification was a helpful reminder of what OPC is and does.  If you are sitting there wondering; Should I use OPC?   Is joining the OPC Foundation important?  Or Do I trust my OPC vendor? I hope I’ve helped you answer your question.

I would still like to do something on a ‘layman’s comments on OPC UA’ but the shear size of the specifications would preclude such a detailed commenting as I did for OPC DA 3.00.  The next few posts will be more topical, since even as we approach the slower holiday season, there are things happening in the security, vulnerability disclosure and other arenas that are worth commenting on.  Tune in.

Continuing on with the overview.   This should be Part V of VI as we are getting to the end.  Even a high level technical overview takes some time.   Think what it takes to develop a solid, industrial strength product, even with a well defined standard!  

4.4.5 IOPCSyncIO     Page 77

The synchronous read/write function, often referred to as a Demand Read or Write.  These operations run to completion.  Depending on the type of underlying device and details of the implementation (e.g. which threading model is used) synchronous actions could take a long time to complete or may also prevent any other operations from being performed on the server by any other clients.

4.4.5.1 IOPCSyncIO::Read     Page 77

Reads the value, quality and timestamp from either the CACHE or DEVICE.  Expected behavior is that a CACHE read should be completed very quickly (within milliseconds), where a DEVICE read may take a very long time (many seconds or more).   For this reason Clients are expected to use CACHE reads in most cases. DEVICE reads are intended for ‘special’ circumstances such as diagnostics.

4.4.5.2 IOPCSyncIO::Write     Page 80

Writes values (and only the value) to one or more items in a group. The function runs to completion. The values are written to the DEVICE. That is, the function should not return until it verifies that the device has actually accepted (or rejected) the data.

4.4.6 IOPCSyncIO2     Page 82

Shiny and new with DA 3.0.   The purpose of this interface is to provide a group level method for writing timestamp and quality information into servers that support this functionality. In addition, the ability to Read from a group based on a “MaxAge” is provided. This interface differs from the IOPCItemIO interface in that it is group based as opposed to server based.

4.4.6.1 IOPCSyncIO2::ReadMaxAge     Page 82

Like the SyncIO function, but is only from CACHE.  The MaxAge parameter gives the acceptable “staleness” for each item. The server will calculate the number of milliseconds between “now” and the timestamp on each item. For each item that has not been updated within the last MaxAge milliseconds, the item must be obtained from the underlying device.

4.4.6.2 IOPCSyncIO2::WriteVQT     Page 85

A long awaited feature.   Writes one or more values, qualities and timestamps for the items specified.  Like SyncIO::Write except that Quality and Timestamp may be written. If a client attempts to write VQ, VT, or VQT it should expect that the server will write them all or none at all.

4.4.7 IOPCAsyncIO2     Page 87

These allow a client to perform asynchronous read and write operations to a server. The operations are ‘queued’ and the function will return immediately so that the client can continue to run. Each operation is treated as a ‘transaction’ and has an associated ID.  Asynchronous operations are generally the preferred method of exchanging data.

4.4.7.1 IOPCAsyncIO2::Read     Page 88

Reads the value, quality and timestamp from the DEVICE.

Blogger Note:  In earlier versions of the DA spec, there was an asynchronous read from CACHE, but it gave no performance benefits over a synchronous read from cache (and in some implementations was actually slower!).

4.4.7.2 IOPCAsyncIO2::Write     Page 91

Asynchronous version of the Write, so it writes the value only.

4.4.7.3 IOPCAsyncIO2::Refresh2     Page 94

This operation Force a callback for all active items in the group (whether they have changed or not).  Functionally it is also similar to what could be achieved by doing a READ of all of the active items in a group.

4.4.7.4 IOPCAsyncIO2::Cancel2     Page 96

Cancels any outstanding transactions.  Good clients will do this before shutting down.

4.4.7.5 IOPCAsyncIO2::SetEnable     Page 97

4.4.7.6 IOPCAsyncIO2::GetEnable     Page 98

These set/get the callbacks.   The purpose of the functions is to allow a Connection to be established to an active group without necessarily enabling the OnDataChange notifications. An example might be a client doing an occasional Refresh from cache.

4.4.8 IOPCAsyncIO3     Page 99

Another new interface with DA 3.0  The purpose of this interface is to provide a group level method for asynchronously writing timestamp and quality information into servers that support this functionality.

4.4.8.1 IOPCAsyncIO3::ReadMaxAge     Page 99

4.4.8.2 IOPCAsyncIO3::WriteVQT     Page 102

Asynch versions of ReadMaxAge and WriteVQT.   Again asynchronous operations are usually preferred.

4.4.8.3 IOPCAsyncIO3:: RefreshMaxAge     Page 104

Much like the Refresh functionality, except the MaxAge value will determine where the data is obtained. There will be only one MaxAge value, which will determine the MaxAge for all active items in the group. This means some of the values may be obtained from cache while others could be obtained from the device depending on the “freshness” of the data in the cache.

4.4.9 IOPCItemDeadbandMgt     Page 106

Long awaited modifications to deadbanding.  This interface allows the PercentDeadband to be set for individual items within a group. Once set on an item it overrides the PercentDeadband set for the entire group. This provides a mechanism to set the PercentDeadband on a “noisy” item, which may reside in a group that doesn’t have the group PercentDeadband set. It also allows individual items to be fine tuned with respect to notifications based on an expected range of change.

4.4.9.1 IOPCItemDeadbandMgt::SetItemDeadband     Page 106

4.4.9.2 IOPCItemDeadbandMgt:: GetItemDeadband     Page 108

4.4.9.3 IOPCItemDeadbandMgt:: ClearItemDeadband     Page 110

Fairly self explanatory.  Functions used to deal with item level deadbanding.

4.4.10 IOPCItemSamplingMgt (optional)     Page 112

One of the very few optional interfaces.   It’s a very useful feature, and is kind of a poor man’s buffering.   This interface allows the client to manipulate the rate at which individual items within a group are obtained from the underlying device. It does not affect the group update rate of the callbacks for OnDataChange.  So for example if you have three items in a group with an update rate of 10 seconds, you would get a data callback every 10 seconds (even if the data is changing faster on the device).   With this interface you could set ItemSampling on one or more items.  Say you set one item in the group with a Sampling rate of 2 seconds and buffering enabled.  If that item updated 3 times during the 10 seconds, then on the callback multiple values get returned for that item.

Because the server may need to buffer an unknown amount of data, the server is allowed to determine the maximum amount of data buffered. The server should maintain the same size buffer for each item. If the server determines that its maximum buffer capacity has been reached, then it will begin to push out the older data, keeping the newest data in the buffer for each item.

4.4.10.1 IOPCItemSamplingMgt::SetItemSamplingRate     Page 113

4.4.10.2 IOPCItemSamplingMgt::GetItemSamplingRate     Page 116

4.4.10.3 IOPCItemSamplingMgt::ClearItemSamplingRate     Page 118

4.4.10.4 IOPCItemSamplingMgt::SetItemBufferEnable     Page 119

4.4.10.5 IOPCItemSamplingMgt::GetItemBufferEnable     Page 121

Functions to handle the ItemSampling stuff.

4.4.11 IConnectionPointContainer (on OPCGroup)     Page 123

4.4.11.1 IConnectionPointContainer::EnumConnectionPoints     Page 124

4.4.11.2 IConnectionPointContainer:: FindConnectionPoint     Page 125

These interfaces are improved versions of the DA 1.0 asynchronous handling routines.  OPC Compliant Servers, versions 2.0 and higher, are REQUIRED to support this interface.

4.4.12 IEnumOPCItemAttributes     Page 126

4.4.12.1 IEnumOPCItemAttributes::Next.     Page 126

4.4.12.2 IEnumOPCItemAttributes::Skip     Page 127

4.4.12.3 IEnumOPCItemAttributes::Reset     Page 128

4.4.12.4 IEnumOPCItemAttributes::Clone…129

These interfaces allow a client to find out the contents (items) of a group and the attributes of those items.

I had originally planned to wrap this up in five posts, but it’s getting too long.  I’ll finish off the installation issues, and client side stuff in one last post.  Stay tuned.

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)

Happy Halloween to one and all.   One of my favorite holidays (I can’t believe I missed Talk Like A Pirate Day this year!).  What’s not to love about dancing around bonfires, eating copious amounts of sweets and watching for fairies, demons, ghosts and the walking dead to appear?

The concept of Halloween is just so appealing.  You walk up to the door, and ask for something you will enjoy.  If they don’t give it to you, tradition says you are within your rights to soap their windows, or get creative with several rolls of toilet paper and their trees.  Wouldn’t it be great if those simple rules applied year round?   If for example you purchase an OPC product from a vendor that doesn’t comply with the standards, or gives you grief, then you get to egg em’!

Of course, if you buy your OPC products and architecture advice from a trusted vendor, you don’t have to worry about performing exorcisms or wearing garlic to get your OPC system running smoothly.  DCOM configuration can still be a demon sometimes (personally I think Microsoft has linked DCOM behavior to the waxing of the full moon), but then there’s always OPC Tunneller to slay that particular beast.

Gotta go and find a pillow case big enough to hold the sugar load.