Software Toolbox Technical Blog

As technical consultants at Software Toolbox, we are often approached by users who need to expose data from a software application they have written, or are writing, to communicate from systems they own to a client, HMI/SCADA, or historian. And, in many cases, there are dozens of applications at different sites that the data needs to reach. The question we are then presented with is, “how can I accomplish this quickly and efficiently while staying within budget?” 

Continuing our OPC Development Toolkits blog series, our hope is to answer this question and share from our experience with OPC since 1996, what our users have told us are the common reasons why they chose to use a commercial OPC server toolkit, and to help readers determine what factors to consider for their specific situation and circumstances.

In the first part of this series, we covered the basics of commercial OPC client development toolkits, with a dive into the benefits of using one, while here in part 2, our focus is on OPC server development toolkits. If you read our blog on OPC client toolkits, you will likely notice a clear overlap in the benefits you gain from using both types of commercial OPC toolkits.

As someone who has worked with non-standard device connectivity using OmniServer for over 10 years, I sometimes take for granted the knowledge that I have gained over that time.  If you're anything like me, once you figure out the data you need from your device's protocol document, you just want to get your protocol knocked out as quickly as possible so you can start communicating.

In this post, I'm going to cover 4 key tips that I've learned over the years when working in OmniServer to build a protocol that you may not have realized and that could add convenience and save you a lot of time, which is time you can be spending on other important tasks.