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.

The DNP3 protocol is commonly used in water/wastewater and other utilities related industries. It's common for RTUs used in these industries to support both DNP3 and Modbus (and possibly other communications protocols). DNP3 has many features compared to Modbus (and other more traditional protocols) that make it desirable for such remote telemetry applications including buffered event history and unsolicited (or Report-By-Exception).

But if you're new to working with DNP3 (it's common for users in such industries to be quite familiar with Modbus but not so familiar with the quirks of DNP3), it's important to understand how differently it behaves with respect to polling frequency, polling composition and considerations when configuring the DNP3 outstation/device itself.

Continuing our Tech Support Corner blog series, this post discusses what drives the polling behavior for DNP3 drivers in TOP Server and how the configuration on the device itself can impact what data is returned when a poll is issued.

With Modbus having been around since 1979, I’m sure you have had some interaction with it or at least awareness of it if you work in the automation industry. Our TOP Server is very widely used for its Modbus TCP/IP Ethernet Driver and variety of Modbus serial drivers to enable users to connect to any Modbus devices that they have in the field. For that common use case, the device is the Modbus Server, and the TOP Server is the Modbus Client.

But what if you needed to configure TOP Server to be the Modbus TCP/IP Server (i.e. the “device”)? That is the purpose of this next post in our continuing Tech Support Corner blog series – to discuss and tell you how you can configure TOP Server to act as a Modbus server device, which is a common need for systems where either a device or other software application can only act as a Modbus Client and you have other systems that need connectivity to that Modbus client.

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.

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.