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.

If you're familiar with OmniServer, you likely already know how OmniServer is commonly used to retrieve information from devices that use ‘non-standard’ protocols to communicate such as weight scales, barcode readers, and printers either over serial connections or Ethernet connections.

But a common challenge is configuring an OmniServer but not having a real device physically available to test against. However, with a little extra configuration and a second PC with OmniServer installed, you can create a "device" version of the same protocol to test against.

Reviving our "OmniServer Did You Know?" blog series, I will cover how a second OmniServer can be configured to act as a test device for troubleshooting your protocol when a physical device isn't available.

You may be aware that OmniServer is updated several times a year to add additional useful features and tools, and to resolve any known issues as part of our continuous improvement process.

In this post, I will cover updates and enhancements available in OmniServer V3.2.0.10 designed to make it easier to backup and/or move your project configurations between machines (whether during migrations or new installations of OmniServer).

As you may be aware, OmniServer is updated several times a year to add additional useful features and tools, and to resolve any known issues as part of our continuous improvement process.

In this post, I will cover updates and enhancements available in OmniServer V3.2.0.5 to help you with increased flexibility for implementing protocols and updates for OPC UA client connectivity for integrating all of your non-standard devices.

If you know nothing else about OmniServer, you probably know it is commonly used for accessing information from devices that use ‘non-standard’ protocols including such devices as weight scales, barcode readers, and printers either over serial connections or Ethernet connections.

From its beginnings 25 years ago, OmniServer was designed to save time and effort when integrating your "other" devices, especially when compared to the time, effort and cost of alternatives such as custom code.

In this blog post, we will step through the 5 most time-saving features of OmniServer's Visual Protocol Editor, including short demo videos of each feature, highlighting how they can help you save up to 40% more of your time and effort when configuring an OmniServer protocol to communicate to your other devices.

Those of you even somewhat familiar with OmniServer are likely aware that OmniServer is frequently used for accessing information from devices that use ‘non-standard’ protocols including such devices as weight scales, barcode readers, and printers either over serial connections or Ethernet connections.

Over the past several years, we've been working to evolve the OmniServer user experience with the goal of making it easier and more efficient to build a non-standard protocol/driver.

In this video blog post, we will step through the most powerful features of the new visual protocol editor for OmniServer, demonstrating the key enhancements to the user experience that will make integrating your non-standard devices easier and faster than ever.