Software Toolbox Technical Blog

MQTT continues to grow in popularity and implementation within the industrial automation community. For those who are still new and learning about this protocol, MQTT is a light-weight transfer protocol built around a publish/subscribe architecture. In simple terms, MQTT can be compared to a mail envelope, providing structure and a common appearance with a supported delivery system, while the actual content of that envelope can vary widely.

Because of the ambiguity of message content, implementations of MQTT can be utilized for various needs across segments in our industry, though the varying message content presents its own issues that are outside the scope of this article. There are multiple solutions for providing structure and standards around the message content that we will discuss in future posts.

This blog will primarily focus on the reliability of message delivery based on the concept of Quality of Service (QoS). We will be utilizing the Cogent DataHub to showcase these options, as it can act as both the MQTT Broker & Client. It is important to note that this information can be applied to various MQTT implementations, including other Software Toolbox product offerings with MQTT, such as OPC Router or the TOP Server MQTT client driver.

Whether you're running a production system in manufacturing, oil and gas, building automation, or energy, safety and uptime are of the utmost importance, especially with cybersecurity attacks increasing in frequency and complexity.

That’s why when running an application with widespread user access, managing user permissions and configurations is so important, and you need a solution that is as security centric as you are. In this blog post, we delve into how to manage user groups and permissions inside the TOP Server’s User Manager and Security Policies Plug-In to ensure a robust and secure gateway to your TOP Server Configuration.

Applications tend to have a lot of moving parts. Here at Software Toolbox, we know that understanding these parts is important whether you are new to an application or a seasoned veteran who wants a more robust understanding for the sake of troubleshooting and optimization. Because of this, part of our job is to help you recognize and understand the components of our products to maximize your ROI when using our solutions.

In this blog post, we'll provide an overview of the different components of OPC Data Logger, an effective solution for reliable, event-driven logging of data from OPC server data sources (both OPC UA and OPC DA) to SQL and ODBC databases (including Microsoft Azure SQL) or text and CSV files. We'll cover the wizard-based interface used for Configuration, the difference between the Service and Runtime, and the Notification functionality so you can understand the purpose of each component and how to configure them to meet your logging needs.

In today's business landscape, the exchange and storage of data plays a pivotal role in ensuring efficient and robust operations. Whether operating in sectors like Pharmaceuticals, Manufacturing, Power, or related industries, the exchange of data between services and applications has become standard practice, often an imperative. Consequently, many organizations leverage resources such as databases and historians to archive their invaluable data. However, there are instances where the need for simpler storage methods or direct interchange of data via Webservices is required to maximize application interoperability. Unfortunately, this solution area is often one filled with custom software applications. In this blog, we'll show you how to eliminate custom code and build sustainable solutions.

Your operations visibility relies on real-time data from machinery, systems, and field devices. When there are communications issues resulting in loss of or inaccurate data, addressing issues promptly is critical. Whether it's stale, poor quality, or missing data in your SCADA or HMI application, a well-defined troubleshooting procedure is a must. Like all our products, the TOP Server OPC Server offers an arsenal of tools to inform you about what is happening and streamline your troubleshooting process, summarized in our previous blog post, Minimize Downtime with TOP Server Troubleshooting Tools.

In this post, we'll take a deep dive into some of those tools, with an emphasis on the device connection side of TOP Server, teaching you a step-by-step process to pinpoint communication issues at their source. While this specific example uses the Modbus Ethernet Driver and an OPC DA Client connection, the same principles can be applied when troubleshooting various other scenarios.

The GE Ethernet 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 GE Ethernet controller being used in your industrial process and need to integrate data from that process.

The TOP Server GE Ethernet driver supports data access from devices using the GE SRTP Ethernet Protocol, including Series 90-30, Series 90-70, Horner OCS (Horner's Operator Control Stations), PACSystems RX3i and RX7i, and the VersaMax Family, as well as an expanded range of GE PLCs through the open device model selection within the driver.

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

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.