|
Synchronous Vs Subscription Reads with the OPC ActiveX Data Control
When to use ReadVariable, ReadMultiVariables methods vs. using the Value_Changed event
Introduction
There are 3 ways the OPC ActiveX Data Control can read data from an OPC Server
- Synchronous Device Reads - i.e. ReadVariable, ReadMultiVariables methods
- Subscription reads - tied to visible form elements (i.e. text boxes, labels)
- Subscription reads - NOT tied to visible form elements (how subscription reads work)
This document will help you:
- Understand the difference between Synchronous (sync) and Subscription Reads
- Understand how the OPC data control works with an OPC Server using Sync and Subscription Reads
- Understand when to use Sync, or Subscription Reads
- Help you to better understand these concepts so you can plan your application development more effectively and efficiently, to prevent
unnecessary and expensive re-development and debugging time later.
For the OPC "purist" reader, we'll apologize in advance if we have simplified some ideas. There are many complex examples using
Sync and subscription reads and our examples will make simplifying assumptions in the spirit of communicating the base concept. If you have a complex application and want to discuss things not covered here
relative to this topic, our engineers are available on a phone/email consulting basis to aid in your application design process. If you want to skip right to our recommendations, you can.
What is the difference between Synchronous and Subscription Reads?
Synchronous Reads
|
Synchronous Reads Analogy:
Say for example you run a coffee shop and a customer asked for a cup of coffee and a chocolate bar. If you've ever been
in a coffee shop where there was a long wait for service, then you can relate to this analogy. Imagine you are the OPC server and the customer is the OPC client.
- Customer asks you for a cup of coffee and a chocolate bar.
- You go and make the coffee (if it has to brew, you stand there and wait).
- The customer stands at the counter and waits
- When the coffee is done you come back and give it to them and collect their money and give them the chocolate bar.
Do you see the "waits" in this analogy? Probably not the best use of both parties time.
|
|
We'll start with Synchronous Reads. In a Synchronous Device read, the OPC client directs the
OPC server to go read data from the device (i.e. the PLC). The OPC client will wait for the OPC server to return with the data. Unless it is running in a
multi-threaded fashion (which many clients do, including the OPC ActiveX data control), the OPC client can't do anything else while waiting. Even if the OPC client is multi-threaded, it can still be wasteful of
computing resources to have the client sit and wait.
Synchronous device reads do have value in that they are good to use if
- You only want to read an item one time based on operator input (i.e. they click a button) or some other event.
- You need to know the value NOW and do not want to continue to do anything else until you get the result.
There is a price for doing Synchronous Device reads
on the OPC server side and the price goes up as you have more OPC clients connected to the same OPC server.
- Each OPC Server's internal architecture is different so you should take our comments in lite of anything
you know about your OPC server's design.
- If an OPC server is multi-threaded (i.e. like the TOP server and INGEAR OPC servers), the impact of Sync
reads is mitigated by the muilti-threaded architecture. In the worst case, if an OPC server were totally
single threaded, a call to Sync read the device would prevent the OPC server from doing anything else until it is done.
- Consider that
- When an OPC server is told to do a Sync Read from Device of PLC Address R001 by Client A, it
will go do that read and hand over the data to Client A.
- If at the same time Clients B, C, and D are also requesting Sync Device Reads of PLC Address
R001 ( notice it's the same address! ), the OPC server will go out and read the same point 3 more times.
- In this scenario, the loading on the PLC network will linearly increase as you add OPC clients to
the system because of the duplicate requests.
- Because the OPC Server has no forewarning of what items the OPC client wants it cannot do any
blocking or optimizations outside of the block of items requested in a single Sync Read transaction.
- Sync Reads can contain > 1 item - in the OPC data control this is implemented with the
ReadMultiVariables method. Most OPC servers will try to optimize within a single Synch read transaction when the # of items is > 1.
Subscription Reads
|
Subscription Reads Analogy:
Say for example you run a coffee shop and a customer asked for a cup of coffee and a chocolate bar. If you've ever been
in a Starbuck's coffee you can relate to this analogy. Imagine you are the OPC server and the customer is the OPC client.
- Customer asks you for a cup of coffee and a chocolate bar.
You collect their money and give the customer chocolate bar
- The customer goes off to read the paper.
- You start the coffee
- While the coffee is brewing, you work on other tasks or help other customers
- When the coffee is done you get the coffee and make a "callback" to the customer to come pickup their coffee.
|
|
In a subscription read, the OPC client (i.e. the OPC ActiveX Data Control) tells the OPC server the names
of OPC items that it wants updates for and how often it wants updates and then the client returns to what it is doing. Whenever the OPC Server has new data to
report, it makes a "callback" to the OPC client and delivers the data. For those of you that use Allen-Bradley PLCs, this is similar to the concept of unsolicted messages - it is not 100% the same
because the OPC client does "subscribe" to the data points - so it's not like the callbacks from the OPC server to the OPC client are 100% "unsolicited".
The key is that the OPC client does not have to waste time
- Polling the OPC server for changed data
- Waiting for data to come back from a request
When the OPC server has data, it's there.
There are several advantages for the OPC server too in that
- The OPC server can look at all of the items that have been requested of it and group them together by
update rate, proximity of memory addresses, etc. to optimize how it polls the PLC to satisfy subscription requests.
- The OPC server can manage it's priorities to provide optimal performance versus being constantly told
what to do by the client, which is what happens with Sync reads.
Important Note: We are often asked the question "but won't putting these items on a subscription with an
update rate in ms bog down my computer network?" The answer is generally no. In fact, if you did Synchronous
reads driven by a timer in your VB application set in milliseconds, THEN you could bog down your computer
network with un-necessary traffic. With subscription reads, the only polling that goes on is on the PLC network
between the OPC server and the PLC -- the only time traffic gets generated between the OPC server and the OPC ActiveX data control is when the data change conditions are met. This is yet another reason that if you
need to have data polled in the PLC or field device at a fixed rate (i.e. 500ms), but you doubt the data will change
often, Subscription reads are the best use of overall computer, computer network, and PLC network resources.
Thought Provoking Question:
If 10 people came into your coffee shop requested a cup of coffee and chocolate bar... which method of
communication would you use to provide fastest service ? Sync or Subscription?
Answer:
You would want to use Subscription, and here's why... but lets put this into the OPC Server perspective and see
both Sync and Subscription side-by-side. Remember you as the person tending to the coffee shop are the OPC
server, and the customers are OPC clients requesting data. By the way, our coffee shop only serves one type of coffee to keep this example simple.
|
Subscription Reads
|
Synchronous Reads
|
- After taking the first customer order you would get a pot of coffee started large enough to serve 10 customers, just in case
they all want coffee.
- While waiting for the coffee, you would collect each customer's order and money and give them a chocolate bar.
- When the coffee is done, you'd go back get and get the coffee pot
- You'd make a callback to each customer and deliver their cup of coffee.
In this scenario, the customers can go sit and read the newspaper while they wait on their coffee and you are making maximum use of
your limited time resource.
This emphasizes the single trip to get the coffee, collecting one pot of coffee and then distributing it multiple times...in the OPC
server world, this would be like reading the PLC address R001 one time but sending the value to multiple OPC clients.
|
- First customer comes in and you take their order
- Make the coffee and give it to person #1
- Make the 2nd coffee and give it to person #2
- Repeat this process until everybody has their coffee
- Get a chocolate bar for person #1
- Get a chocolate bar for person #2
- Repeat this process until everybody has their chocolate bar
This emphasizes the point that multiple trips will be made for each person who made a request, and that no other requests are
handled until the the current request is complete.
In the OPC world this illustrates the worst case scenario in Sync reads where > 1 client is calling for data and the OPC server
is single threaded.
|
How OPC Data Control works with Sync and Subscription Reads
The OPC Data Control ActiveX is able to use both Sync and Subscription Reads.
Sync Device Reads are made when you invoke on of the following methods. For the OPC purists, this is a call to IOPCSyncIO::Read().
- ReadVariable method
- ReadMultiVariables method
Subscription Reads are setup when you connect an Object/Variable to an OPC item using either of the following
methods. For the OPC purist, we are setting up the items as Active on the Group and Item level and enabling callbacks.
- Programmatically (i.e. all through code)
- connectObject method
- connectName method
- From the OPC ActiveX Data Control's property page
- Connections tab (for visible objects)
- Events tab (for subscribing to items that you do not want to bind to visible objects)
Help on the specifics of these methods is provided both in the product help file that installs with the OPC ActiveX data control and in sample programs available for download on this website.
When Should You use Subscription Reads and When Should You use Sync Reads?
This section is merely to provide base recommendations for when you should consider using one method or
another. As with any situation, the advice given here may not suit your requirements, but please consider what you have read with your project requirements in mind. Consulation on specific project designs is available.
Ideal situations for Subscription Reads:
- When you want to poll OPC items on a frequent basis, i.e. every "xx" msec, or "xx" seconds etc. -
the subscription read method allows your client application to remain very responsive.
- When many OPC clients will be communicating simultaneously - the importance of using
subscription reads in this case grows as you add more clients -- it is even more important if the PLC network or it's protocol is generally slow to begin with.
Ideal solutions for Synchronous Reads:
- You need to read OPC Items on demand, and you only want to read the item a finite # of times - i.e. when a user clicks on a button.
- You want to read an OPC item and not take other steps until you are sure the read is done.
As with all things, there are also situations that we want to explicily call out NOT to do - those are:
Planning your application
Now that you are aware of the difference between Synchronous Reads and Subscription Reads as they relate to
OPC in general and to the OPC ActiveX Data Control, you should be in a better position to plan your OPC
system. As with any software development, experience with the ActiveX product along with knowledge as to how
the ActiveX works will help you to use the OPC Data Control ActiveX to it's best capabilities within your application.
We cannot emphasize enough the importance of thinking about your needs before you just start writing code. In
our years of experience, we have seen many times the added cost users have put on themselves by skipping the design phase of a project where application needs are considered.
Therefore, we strongly encourage you to use the dedicated OPC ActiveX Data Control website on which this
article is published and periodically check our support section for examples and lessons in effectively using the OPC ActiveX Data Control.
Dedicated website: http://www.opcactivex.com/
Support and Examples: http://www.opcactivex.com/Support/support.html
|
