Skip to content
  • There are no suggestions because the search field is empty.

What Is the Difference Between Subscription and Synchronous Reads in OPC DA (Classic)?

When developing a custom OPC DA client, learn the important considerations that can significantly improve the performance of your application

Introduction

There are 3 ways an OPC DA client can read data from an OPC Server

    • Synchronous Device Reads
    • Asynchronous Device Reads
    • Subscription reads

This article only focuses on Synchronous and Subscription reads due to the impact they can have. The goal of this article is to help you:

    • Understand the difference between Synchronous (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.

What is the difference between Synchronous and Subscription Reads?

Synchronous Reads

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 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 light of anything you know about your OPC server's design.
    • If an OPC server is multi-threaded (i.e. like the TOP server and OmniServer 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. Most OPC servers will try to optimize within a single Synch read transaction when the # of items is > 1.

    Subscription Reads

    In a subscription read, the OPC client 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 Rockwell (Allen-Bradley) PLCs, this is similar to the concept of unsolicited 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".

    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.

    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 if you use sensible subscription rates! In fact, if you did Synchronous reads driven by a timer in a custom 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 Client 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.

    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.

    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 its protocol is generally slow to begin with.
      • 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.

    Ideal solutions for Synchronous Reads:

      As with all things, there are also situations that we want to explicitly call out NOT to do - those are:

      When NOT to use Sync communications:

        • When you intend to read/write to Tags on a frequent basis, i.e. every "xx" msec, or "xx" seconds etc.
          Do not do Sync communications in conjunction with a timer in a custom application
        • When many OPC clients will be communicating simultaneously and polling items at some interval. The slower your PLC network, the more important this becomes in multi-client to single server applications.

      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 OPC client development, you should be in a better position to plan your OPC system.

      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.