Which OPC server is best?

I figured this did not actually pertain to FSQL or FPMI so I would post this in the general questions area.

I know there are more than two but the two I do know of, Matricon and KepServer are OPC servers. I was wondering who was using which server and what the benefits are of one over the other?

Also this more pertains to the folks at Inductive Automation, In kepserver if you are using the OPC quick client and you watch the status. Even though in the status window of the OPC server you can see when a device becomes unavailable, sometime it takes time before the status goes from GOOD to BAD. Which item is FSQL watching? Is it the flag that comes up and says Device not repsonding or is it the status which would similarly be used in the Quick CLient?

I’d say Matrikon, but of course as an employee I’m more than a bit biased :slight_smile:

Seriously though. As with any product ‘which is better’ is in the eyes of the user, and what their criteria is.
In terms of OPC, both companies are diligent in keeping their OPC servers up to Compliance with the OPC Foundation criteria. As well, both companies have a lot of history and experience dealing with industrial automation.

Since the OPC side of things is standardized their not much room for improvement any company can really do there. Much like ODBC is standard, what makes any of MySQL, Oracle or MS SQL a ‘better’ product? The answer lies with other features, such as usability, configuration or added functionality. For some users, the vendor’s experience and expertise and their ability to provide support, training and robust, quality products are important factors.
Features like DA, HDA or A&E support, browsing, configurable address space, customized scaling, etc may be important for one user and not to another. Auto configuration, flexible communication options or communication redundancy offer different advantages depending on whether the end device is a PLC, DCS, historian or remote RTU. The feature set the of end device the OPC server supports is just as important as the OPC side of things. At the end of the day, it’s subjective based on what you value as ‘better’. Both companies offer a range of free product downloads. I’d suggest taking some for a test drive.

On your other question, of course the folks at Inductive Automation have the final answer, but I can make a couple of comments.
Every OPC server supports the GetStatus call. It’s a very light weight call that returns information on the state of the OPC server, current time, vendor info etc. Many OPC clients will call this interface at a high frequency to use as a ‘heartbeat’ (DA 3.0 introduced a ‘real’ heartbeat interface). Many OPC clients will use the result of this call to determine if an OPC server is alive.
This is different from the OPC Quality of individual items. Many OPC clients will tie their error handling to the OPC item quality, since it is possible for an underlying device to go offline, but the OPC server is still functioning. The update rate of the OPC item Quality is the update rate of the Group (which is often much slower than the GetStatus call rate). Also an OPC client may attempt to retry a connection or wait for multiple items to report a Bad Quality before declaring the underlying system or server dead.

Hope you find some of that rambling helpful.

Eric - thanks for your input. I welcome your argument as to what makes Matrikon the better OPC server.

For the purposes of this post, you can probably expect users to be referring to OPC-DA as requested through FactorySQL (sorry - get’s back to my frustration with the usefulness of our product and HDA). For the record, I’m interested in hearing what you have to say on a different level.

Compliance and standardization are big ones. They’re the main reason that I generally throw out “Kepware” and “Matrikon” by name, but exclude the “little guys”, when a customer asks.

Configuration, communication options, and error reporting are also very relevant.

I would say that, although difficult to quantify, your caching and read/write aggregation algorithms are incredibly important as the system scales.

I welcome more info from Eric, Kepware, or other OPC Server vendors on the topic.

And just to clarify on how the status monitoring works in our products- Eric’s right on the mark. GetStatus is used to monitor the OPC server (the DA3 heartbeat that he mentioned will be making its way in soon), and for the actual data the quality is used.

FactorySQL doesn’t have any idea about how the devices are laid out, it only knows about tags, the “quality” of the tag (reported by the OPC server along with the value), and whether or not the OPC server is functioning, as determined by the GetStatus call. As to why there would be a delay, that’s simply the amount of time the OPC server is taking before it decides to notify FSQL that the quality is bad. There are some technicalities that could be mentioned, like that this notification is constrained by the update rate of the group, but usually FactorySQL groups are running at a quick enough rate that this isn’t the source of the delay (on the order of 300ms->1sec for the OPC subscriptions). You may look at how the server is configure to re-attempt communications, or specified timeout values.

Hope this helps clarify a bit, and thanks to Eric for his informative post. I fully agree with the need to evaluate the servers for yourself, because like he said there is a wide range of features and ‘approaches’ available. However, like Nathan pointed out, there are a lot of half-way/fly by night servers out there, so taking a good look at the company and their dedication to interop testing and the like is an important part of evaluating the server. I can say that I’ve personally had lot of good experiences working with both Kepware and Matrikon.

Regards,

I have been on the Kepserver web site and there are some questions that I have the maybe Eric or someone or possibly both could clear up.

  1. It said on the knowledge base that windows has a default of 2024 threads per process. Is this all versions of windows or just server versions?

  2. What exactly is considered a process? I ask because it also said that each subscribed groups constitutes 2 or 3 threads. But it only vaguely mentions tags, so does more tags in a group mean it takes more threads and more processes?

  3. It said depending on how the client connects upto the server that the actual amount of available groups could be 900 if it uses 2 threads or 600 if it uses 3 threads. So is a group considered each individual tag or if you have a folder in Kepserver that has 20 tags in it that would consititute one group.

  4. Then it said to ask client software maker how many groups it adds to the server.

Thanks again to all on this forum.

Martin,

Some of your questions you’ll have to pose to Kepware directly, but I’ll answer what I can:

I assume with some certainty that KepServerEX is always exactly one process.

A think by the term “group” they are talking about client subscription groups. There is a reason that in FactorySQL groups are called “groups” - that is what OPC calls a collection of tags subscribed at the same rate. So, you are in direct control over the number of FactorySQL groups. SQLTags scan classes are also each a group, I believe.

Hope this helps,

Some in-depth questions! Since you mentioned my name I give it a go, and the Inductive Automation guys can tell me when I’m out in left field.

  1. It said on the knowledge base that windows has a default of 2024 threads per process. Is this all versions of windows or just server versions?
  • I would say all versions, but it probably doesn’t matter a whole lot, since most software applications will hit another wall, like stack size, before maxing out the thread count.
  1. What exactly is considered a process? I ask because it also said that each subscribed groups constitutes 2 or 3 threads. But it only vaguely mentions tags, so does more tags in a group mean it takes more threads and more processes?
  • A process would be any instance of a computer program that is being executed. i.e. the OPC Server executable would be one process. I can’t speak to Kepware’s programming specifically, but typically more tags/items would not mean more threads. An OPC Group is a collection of tags/items with the same update rate. Since the OPC server needs to keep track of groups I could see having one or more threads per group. However, even though the OPC specifications are standard, each software vendor is allowed to deal with things ‘under the hood’ as they see fit. For example, the threading design MatrikonOPC
    servers use is not tied to the number of groups or items a client configures.
  1. It said depending on how the client connects up to the server that the actual amount of available groups could be 900 if it uses 2 threads or 600 if it uses 3 threads. So is a group considered each individual tag or if you have a folder in Kepserver that has 20 tags in it that would constitute one group.
  • An OPC Group is a collection of OPC items/tags that all have the same update rate. Since the OPC client is in charge of creating groups, it is possible to create a single item per group, but that would defeat the whole purpose, which is to optimize tag management. From my experience, most OPC clients will create somewhere between 1-10 groups. 50-100 groups would be considered a ‘big’ client, and those would typically be an aggregating server. Of course OPC clients are allowed to create any number of groups, but generally the number is well below the hundreds range. It’s important to remember that the OPC client has to keep track of its groups too, so good OPC client/server vendors will try an optimize resources.
  1. Then it said to ask client software maker how many groups it adds to the server.
  • Usually it is obvious from the interface how many groups a client is adding to a server, but sometimes an application will optimize the number of groups actually being created on the server. If in doubt, ask your vendor.

We have some customers using our MatrikonOPC servers with a few hundred of groups, dozens of client connections, and/or tens of thousands of OPC items configured, and I have yet to hear of someone being thread limited. (Memory or process cycles are usually more of a concern in really large systems.) It’s also important to remember that the limit is concurrent threads. Using thread pooling or killing off/reclaiming completed threads would be used in products that make heavy use of thread spawning. Do you have a particular architecture in mind or are you just trying to get a feel for what is possible?

Eric, thanks for all the informative replies. The reason I ask such questions is actually multi part. One part is for the knowledge being as I have no real formal training on this type of application. Another part is due to understanding design considerations. And the big part right now is due to a problem that recently arose and I am hoping to be able to recreate. The problem dealt with ASCII string that I have in the data stream. In my project that I am designing, with a lot of great assistance from the team at IA and some of the really smart people on this forum, I have a group of historical items which is recorded to an SQL table. In this is the said ASCII strings. On a recent run, before our server went south and had to be reinstalled, while running all 9 connected machines, one machine the ASCII string would not update. All the other data was being updated but for some reason not any of the ASCII. This is the second time that this has happened. And it does not follow any specific pattern. The last time it was the machine we refer to as #52, the most recent time it was machine #2. However both times before I was able to get into the actual server where the software is installed something happened that shut down all processes. In the first case it was the log file in SQL and in the second the witness program detected a problem of some sort and caused the IT dept to conceed that the server needed rebooted. When they did it crapped out. So neither time was I able to get on the server and run any of the diagnostics to find out what could be causing the problem. I want to know that as this system grows and becomes fully implimented that this is not going to be a major problem that comes back and bites me in the behind. Ole man Murphy and I are great friends. So I guess another reason for all these questions is for some C.Y.A. I just want to know that I making the best choices possible.

Graybox OPC Server Toolkit lets the programmer to create robust and highly effective OPC Servers within the shortest possible time. This toolkit eliminates the necessity of implementing all of the numerous OPC interfaces and COM programming. Graybox OPC Server Toolkit supports OPC Common 1.00, OPC Data Access 1.00, OPC Data Access 2.05a, OPC Data Access 3.00 (not available in Graybox OPC Server Toolkit 2.x versions). Graybox OPC Server Toolkit is fully compatible with Windows NT4/2000/XP/2003. Windows 95/98/Me operating systems are not longer supported (starting from version 2.0).

Eric - I have no problem with you pushing your OPC Server here. Our software should work well with whatever OPC package. In my experience, Matrikon and Kepware both work really well. I love to hear about features and implementation details that distinguish your product. I have experienced performance hits and browsing issues with RSLinx on large systems.