This article has been inspired by an e-mail conversation we have recently had with a customer. He had written a piece of code "from the scratch" that connected to his OPC Data Access server, and was able to obtain the data he needed to store in a database. He therefore had doubts about the value and usefulness of a library such as QuickOPC; it appeared to him that the task of writing an OPC client is quite easy.
During the course of a discussion, we have identified quite a lot of points that his code was lacking. Here are some questions we have asked:
It turns out the the above mentioned issues are just a fraction of what an OPC client must do properly in order to be OPC compliant, and at the same time robust and reliable. When you use QuickOPC, all of it is taken care of automatically. For example, when an error occurs that causes a disconnection from the server, you will receive an ItemChanged event notification, and after a configurable delay, QuickOPC will reconnect again and will restore the original state of the connection (OPC groups and OPC items inside the server). There is no way you can develop a code for all of this in several days, let alone to be prepared for idiosyncracies of some non-compliant OPC servers, and unexpected traps and pitfalls of the OPC specifications. The OPC client code in QuickOPC is a result of more than ten years of development, and extensive testing and resolving all possible, common and rare, situations.
But of course, decision between "develop your own" vs. "use a proven toolkit" is in your hands...