Software Toolbox Technical Blog

As someone who has worked with non-standard device connectivity using OmniServer for over 16 years, I consider myself well-versed in some of the more obscure nuances of certain protocols that a user might need to implement and how to do so in OmniServer.  It's very common for non-standard device protocols to simply be some combination of ASCII alpha-numeric characters with some special characters mixed in for starting messages, terminating messages or as delimiters.

Many OmniServer users may not be aware, though, that there are certain ASCII characters that are used in OmniServer protocol messages that have special meaning. So when you come across a device protocol that requires those characters to be sent or receive as-is (namely backslashes, curly braces and square brackets), there is some special handling required when configuring your OmniServer protocol .

Returning and expanding our "Did You Know" OmniServer blog post series, I'll cover the usage of some common special syntax characters for OmniServer protocol messages and how to, when needed, escape their special status in the message so they can be treated as their original ASCII equivalent instead.

For users that have never worked with OmniServer, it can be intimidating thinking about how to take information out of a device manual or protocol document and convert that into an OmniServer protocol for your device. OmniServer makes this significantly easier, though, than alternatives such as custom code, especially once you're familiar with how OmniServer works and how to get started.

Continuing our Tech Support Corner blog series, this blog post covers six tips I know should help any relatively new users be successful getting OmniServer connected to your non-standard devices as quickly as possible.

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.