Software Toolbox Technical Blog

As someone who has worked with non-standard device connectivity using OmniServer for almost 18 years, I've encounter most of the subtle nuances of certain protocols that a user might need to implement and how to do so in OmniServer. One such nuance (which is true even with "standard" protocols such as Modbus) is that it's not uncommon for device vendors to implement their communication protocols with variable or parameter values that use a unique byte order compared to ordering by the first byte received to the last byte received (also referred to Most Significant Byte to Least Significant Byte, Big Endian or Motorola Byte Order).

You may not be aware that OmniServer has several flexible ways to manipulate the ordering of bytes parsed into Items to be shared with client applications to ensure that the correct and expected value is always displayed in your HMI, SCADA, historian, MES or other client applications.

Returning and expanding our "Did You Know" OmniServer blog post series, I'll cover what byte ordering settings are available in OmniServer, when you might need to use them and how.

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.

In recent years, many of our users have let us know they are adopting the latest Siemens technology, particularly S7-1500 controllers.  And, with that adoption of those controllers, users have been asking for connectivity via the symbolic optimized block addressing.  So we added a Siemens Plus Suite to enable connectivity to new and legacy Siemens devices.

This post focuses specifically on the general steps required to integrate S7-1500 controllers by connecting to their embedded OPC UA server using TOP Server for AVEVA.  

If you’ve been following our blog series on custom error detection, you’ll remember that OmniServer provides a large number of pre-defined Error Detection Codes (EDC) for use in different protocols for non-standard device communication.  And, again, it’s not uncommon to find an EDC from a vendor that is not pre-defined due to some specialized handling by the device manufacturer.

As we covered in our previous posts on creating a custom checksum and LRC, OmniServer gives you the ability to build custom EDCs in an OmniServer protocol to handle these situations.  This post, the final of three on custom Error Detection Codes, covers the basics steps to creating a custom CRC (Cyclic Redundancy Check) in an OmniServer protocol.

You may be aware that OmniServer provides a wide variety of pre-defined Error Detection Codes (EDC, also known as CRC, LRC and Checksums) for use in protocols for non-standard device communication.  However, it’s not uncommon to find an EDC that isn’t pre-defined due to some specialized handling by the device manufacturer.

To handle such situations, OmniServer provides the ability to build your own custom EDCs in an OmniServer protocol.  This post, the second of three on custom Error Detection Codes, will cover the basics of creating a custom LRC (Longitudinal Redundancy Check) in OmniServer.

If you’ve worked with OmniServer to connect your non-standard devices in the past, you may be aware of the large number of pre-defined Error Detection Codes (EDC, also known as CRC, LRC and Checksums) available.  However, as is the nature of custom protocols out there, it’s not uncommon to find an EDC that isn’t pre-defined due to some specialized handling by the device manufacturer.

To that end, OmniServer provides the flexibility to define your own custom EDCs in an OmniServer protocol.  This post, the first of three on custom Error Detection Codes, will cover the basics of creating a simple custom checksum in OmniServer.

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.