Software Toolbox Technical Blog

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.

It's important for any enterprise to have actionable data in the timeliest fashion for making decisions. Minimizing downtime and increasing performance are important to the profitability of any company and knowledge at the point of action is key.

To that end, automating notifications or reports based on the latest process data from your various systems can ensure you're never in the dark when it comes to your processes.

In this post, I will cover step-by-step how to easily automate email notifications and reports for OPC and data sources with the OPC Router for giving you and other decision makers the knowledge you need to make informed decision as quickly as possible.

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.

OPC Router provides connectivity to a wide range of data sources including ERP systems such as SAP, a variety of relational and other databases, conversion of file data including CSV, XML, JSON and others, IIoT systems including REST and SOAP web services and MQTT brokers and more. It's often necessary for OPC UA client applications (such as HMIs, SCADAs and other software clients) to need access to such data sources. OPC Router also supports acting as an OPC UA server.

In this blog post, we will cover the basic steps to map such non-OPC UA data sources supported by OPC Router to OPC UA nodes/items for access by external OPC UA clients.

Our team often gets questions about the extent to which our products can be used. It’s important to differentiate between technical versus practical limits when discussing what is and is not possible.

Continuing our Tech Support Corner blog series, I will be providing some insights into how many channels, devices, and tags it is technically possible to set up in TOP Server while also highlighting some practical rules of thumb to observe to ensure the best performance.

If you're a TOP Server user, you're likely accustomed to connecting to a device configured in TOP Server that is sending real-time data through one of its many available drivers. But did you know you can setup devices in a "Simulated" mode for a variety of client testing purposes when a live device isn't available?

Continuing our Tech Support Corner blog series, this post covers how the "Simulated" device property works, why you might implement it into your testing and a brief walkthrough on connecting a variety of client applications to a simulated device in TOP Server.

Cogent DataHub® is a gateway that enables a wide range of connectivity interfaces for different data sources such as OPC UA, OPC DA, ODBC, DDE and so much more.  Included in those available interfaces is the ability to act as both an MQTT client and broker even including Sparkplug B support for enabling MQTT integration with many other types of systems that don't natively support MQTT.

A key facet of the MQTT specification that can sometimes be complex for our users and cause issues with compatibility between DataHub and other MQTT clients and brokers is how to handle the formatting of MQTT messages. As you may or may not know, while MQTT does specify how to construct a message header for routing by an MQTT broker, it does NOT specify the actual message content. This tends to be a challenge when MQTT clients from different developers need to work together, since they need to be using the same format for the message content.

In this video blog, I'll show you how to use DataHub V10's Advanced MQTT Parser capability to specify flexible formats that will work with virtually any other vendor's MQTT clients and brokers.