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.

So, no, we're not actually taking a rest - we're looking at what REST the acronym means from a practical perspective. But perhaps after reading this, if you're looking to connect to a RESTful API, you can give your mind a rest knowing you have a path forward.

I know the first time I ever heard the term, I had no idea what it meant or how to approach it. Maybe you've been told a certain data source has a REST API for accessing it, but you're not sure where to get started leveraging that API with your control system.

This post will provide a practical explanation of what REST is, how it can be useful to you and how you can take advantage of data provided by RESTful APIs or web services in your operations.

If you have been following our blog for a while or have been exploring IoT platforms available in the market, you may know that the Google Cloud Platform combined with the Google IoT Core is a frequently used combination in the industry. Google has recently announced that it will be shutting down the Google IoT Core. In doing so, Google is forcing many of its Cloud Platform users to switch platforms.

In this blog post, we will review detailed information about the alternatives to the Google Cloud Platform that are available for use with all of the IoT capable products we provide, and how the change works.

Modbus is one of the most widely used protocols around the world, implemented as the communications protocol by many different vendors for integration with other systems. If you're reading this, you likely have at least one Modbus device (whether it's a PLC, RTU or other device) being used in your industrial process and need to integrate data from that process.

In this video blog, I'll show you how to get started using our Modbus TCP Ethernet driver and it's flexible settings to connect and gather real-time process data from pretty much any Modbus Ethernet capable device for HMI, SCADA, MES and other client applications.

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.

Allen-Bradley's Logix family of PLCs and PACs is one of the most popular controllers across many automated industries. If you're reading this, you likely have at least one Logix controller being used in your industrial process and need to integrate data from that process.

In this video blog, I'll show you how to get started using our ControlLogix Ethernet driver to connect and gather real-time process data from Logix controllers for HMI, SCADA, MES and other client applications.

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.

The Google Cloud Platform (GCP) is Google’s cloud solution that brings all of Google’s cloud computing services together. Google’s own services, such as Google Search and YouTube, run on the GCP, but end users can also use their cloud services.

Google Cloud Platform, for the Internet of Things (IoT) area, offers their “Cloud IoT Core” services, which provide the functionalities to connect large quantities of devices via an integrated MQTT broker. In this blog post, we will show the necessary steps for connecting this Cloud IoT Core to the different data interfaces supported by OPC Router.