Software Toolbox Technical Blog

Have you ever been confused on the difference between Modbus offsets and addresses? I’m sure you may have configured different Modbus devices from different manufacturers who follow different documentation standards, especially for memory mapping. As we all know, that can certainly increase implementation time. In this blog post, we are going to dive into how offsets and addresses compare and differ to hopefully provide a better understanding, cutting down that configuration time when using TOP Server. Before we start comparing offsets and addressing, let’s first get an understanding of what both are.

In the world of industrial automation and control systems, communication protocols play a crucial role in ensuring seamless data exchange between devices. Modbus started as a protocol used in Modicon, now Schneider Electric, PLCs in the 1970’s. It was adopted across the industry for its clarity and simplicity. With any protocol, including and especially with Modbus, there are areas where the parties to the communication, the client and server, can interpret the bit stream of data differently once exchanged because the Modbus protocol specification does not speak to those interpretations.

We all love it when things go according to plan, but realistically that’s not always the case. Inconsistent device documentation and confusing protocol specs can make custom protocol implementation for devices that don't use standard communications protocols daunting, and although OmniServer is significantly easier than custom code solutions, there are still a lot of details to attend to!

So, what happens when things aren’t working as you hoped? With OmniServer, our users rave about its simple but powerful diagnostics tools and how they make troubleshooting communication issues a breeze. In this blog post, we will examine the five diagnostics tools available within OmniServer: the Logger, Item Values, I/O Monitor, Poll Statistics and Offline Devices. Our own technical team uses these same diagnostics when we are helping you during or after implementation.

If you’ve worked with OmniServer before, you’re probably familiar with its pivotal role in extracting data from devices that use a 'non-standard' communication protocol. These devices encompass a range of equipment, such as weight scales, barcode readers, and printers, connected via either serial or Ethernet interfaces. OmniServer helps you bring data that would otherwise be inaccessible into your process and business systems, helping you make more effective decisions. OmniServer does all this at a lower cost and greater reliability than traditional custom solutions.

In this blog, we will be exploring the components that make up the OmniServer Configuration and explain what they do and how each component can be used for successful communication to your device. The main OmniServer Configuration Window is broken up into two sections: Configuration and Diagnostics. Our focus for this post is the Configuration portion and digging into Devices, Protocols, Topics and Clients.