Software Toolbox Technical Blog

In this first installment of our 2024 Environmental Sustainability Blog Series, we’re going to piggyback on last year’s Waste Reduction blog post, and take things a step farther – how can you incorporate aspects of a circular economy to positively impact your work environment? In this blog post we’ll discuss what a circular economy is, the impact circular economies have on the environment, and how software that leverages OPC Standards and the automation industry can play a pivotal role in fostering its success.

Those of you who are aware of OmniServer will already know that it is primarily used to retrieve information from devices that use 'non-standard' protocols to communicate, such as weigh scales, barcode readers, and printers. An HMI, SCADA, MES, Historian, database, and more, could then read that data from OmniServer, making it a powerful, universal, data acquisition tool.

Some of these 'non-standard' device protocols require what we call "special handling". For most protocols, if you've used OmniServer, data that is sent or received is "what you see is what you get" type data. An ASCII "A" is transmitted or received and interpreted as an ASCII "A". But what if your device is expecting something else as part of its special handling in its communication protocol? Or what if you wanted to interpret the data differently from the device to meet new business standards or existing requirements?

OmniServer is capable of handling advanced protocols where the devices send special characters/bytes that need to be handled in a specific way. In this blog, we will explain how to use a feature called "translations" in OmniServer with certain protocols that require special handling.

Unlike off-the-shelf OPC servers and drivers that talk to specific devices or protocols and no others, OmniServer can be configured to talk to virtually any device or combination of serial, USB, or Ethernet connected devices with some outliers based on the complexity of the protocol. OmniServer helps you bring data that would otherwise be inaccessible into your process and business systems, helping you make more effective decisions. In our experience there are still many software applications that do not have open interfaces such as OPC for data input. This is particularly common in quality control and test stand applications. Operators use a digital device to capture a measurement, and then have to type that into their test stand or QC software. This slows testing rates and can be error prone. There is a better way. 

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.

Here at Software Toolbox, we strive to be the “One Responsible Partner” for our clients - a motto we see as soon as we enter the door every morning. That extends beyond just our amazing sales and support teams. It also means being the One Responsible Partner for our Earth.

With Earth Day coming up, our team has decided to take this month to focus on the different ways our products help users achieve their own environmental sustainability goals and the conservation of natural resources in general. In this first blog post, we will take a look at how OmniServer helped a food and beverage user improve efficiency and reduce waste in a “sweet” way.

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.

Most AVEVA™ users are already familiar with the native connectivity options they have for interfacing with different systems. AVEVA users have turned to OmniServer for many years to integrate non-PLC devices such as barcode scanners, weigh scales, vibration monitors, RFID readers and more, all without custom code.

Those users of AVEVA InTouch have traditionally connected to OmniServer directly via its native SuiteLink interface. AVEVA's OI Gateway provides those users the additional option of connecting to OPC UA data sources, for easier and more secure remote connections to such data sources.

In this video blog post, we will cover the basic steps to connect AVEVA InTouch to OmniServer via OPC UA, expanding non-PLC device connectivity options for AVEVA users.