Software Toolbox Technical Blog

When working with Modbus communication, understanding the key concept of function codes is essential for ensuring efficient and accurate data exchange. Sometimes a device manual might only refer to the supported Modbus function codes and the range of offsets available for those function codes. A solid understanding of function codes is critical in achieving optimized performance and resolving potential communication issues.

After reading this blog, you'll know how you can leverage TOP Server’s Modbus driver to automatically handle the appropriate function codes for your application – while also taking advantage of its flexibility and other advanced features – to enhance performance, ensure compatibility with your devices, and reduce troubleshooting time.

When working with Modbus devices and TOP Server, one critical factor that can significantly influence communication efficiency is the concept of block sizes. Optimizing block sizes for your application ensures smooth data transfer between your Modbus device and TOP Server, improving overall system performance.

In this blog, we’ll talk about what Modbus block sizes are, why they matter, and how to configure them effectively in TOP Server for the best results. We’ll also cover what happens when a block request includes non-contiguous addresses or undefined memory, causing potential issues with valid data. Additionally, it is important to note that other drivers/protocols may utilize block sizes as well, so these concepts could apply to other protocols beyond just Modbus.

Welcome to the kickoff post of our Data Storage Deep Dive blog series! In this series, we will explore the crucial role of data storage solutions and Historians in industrial automation. Over the coming weeks, we’ll be looking into how solutions delivered by Software Toolbox can be utilized with Historians, helping you make the most of your industrial data.

Welcome to the kickoff of Software Toolbox’s Summer of IoT blog series! Over the next few blog posts, we’ll discuss how our products can play a role in the exciting world of Internet of Things (IoT), but more importantly, how they can be used to further your success in Industry 4.0 and Digital Transformation initiatives. The IoT landscape has grown exponentially over the past decade, transforming industries by connecting devices, systems, and people in unprecedented ways. IoT is reshaping how we interact with technology. At Software Toolbox, we recognize the power of IoT and are committed to providing solutions that facilitate this technological revolution.

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.