Software Toolbox Technical Blog

In a prior blog post regarding redundancy, we learned how critical it is to plan for redundancy in the Industrial Automation space. We covered how the TOP Server Media-Level Redundancy Plug-In  facilitates duplicate or backup systems used to maintain reliable communications with the critical components in your environment which in turn minimizes data loss and increases the availability of your critical industrial data.

Tags, nodes, points, items, symbols – in our industry, we often see these terms thrown around, but in most instances, we’re all talking about the same thing. From the TOP Server OPC Server's perspective, we refer to them as tags. A tag is an OPC Server software application’s representation of a device address to use for communication. This is how your HMI, SCADA, MES, historian, or other client application is able to consume data. If you’re a TOP Server user, you know that you are required to configure tags to get data from your device, but did you know there are multiple options of how to accomplish this?

Have you ever wondered why certain features in TOP Server work the way you experience them, or how something might work in certain scenarios?  Well this blog post tries to answer a few of those type of questions!

Anyone that has used TOP Server before has had to make edits to the configuration. While TOP Server allows changes to many settings while actively collecting and serving data, and makes it simple, there are things to consider to avoid disrupting operations. TOP Server has certain restrictions in place when making configuration changes, and while potentially frustrating, these are for your benefit and security. For example, perhaps you have tried to make a certain change, but observed that the setting immediately changes back and “doesn’t stick”. Or maybe you’ve logged onto your machine and were unable to make any configuration changes at all. Why is that?

The engineering definition of redundancy is “the inclusion of extra components which are not strictly necessary to functioning, in case of failure in other components.” In the Industrial Automation space, redundancy is critical. Not planning for redundancy can easily result in vulnerability to financial losses due to unexpected downtime. There are multiple types of redundancy in the industry. In this blog, we will be covering “Media-Level Redundancy”.

It's common for members of the Software Toolbox Technical Team to encounter instances where users need to configure thousands of static tags for the devices in their TOP Server projects. We have even supported implementations with over a million tags.

In such situations, it would be inefficient to manually add each individual tag to TOP Server. There are several better alternatives for adding large quantities of static tags to a TOP Server project: Automation Tag Generation (ATG), Bulk Tag Creation, and/or CSV Import/Export.

Continuing our Tech Support Corner blog series, this post covers what methods you have available to mass create large quantities of static TOP Server tags and how to use them for greater efficiency.

The DNP3 protocol is commonly used in water/wastewater and other utilities related industries. It's common for RTUs used in these industries to support both DNP3 and Modbus (and possibly other communications protocols). DNP3 has many features compared to Modbus (and other more traditional protocols) that make it desirable for such remote telemetry applications including buffered event history and unsolicited (or Report-By-Exception).

But if you're new to working with DNP3 (it's common for users in such industries to be quite familiar with Modbus but not so familiar with the quirks of DNP3), it's important to understand how differently it behaves with respect to polling frequency, polling composition and considerations when configuring the DNP3 outstation/device itself.

Continuing our Tech Support Corner blog series, this post discusses what drives the polling behavior for DNP3 drivers in TOP Server and how the configuration on the device itself can impact what data is returned when a poll is issued.

With Modbus having been around since 1979, I’m sure you have had some interaction with it or at least awareness of it if you work in the automation industry. Our TOP Server is very widely used for its Modbus TCP/IP Ethernet Driver and variety of Modbus serial drivers to enable users to connect to any Modbus devices that they have in the field. For that common use case, the device is the Modbus Server, and the TOP Server is the Modbus Client.

But what if you needed to configure TOP Server to be the Modbus TCP/IP Server (i.e. the “device”)? That is the purpose of this next post in our continuing Tech Support Corner blog series – to discuss and tell you how you can configure TOP Server to act as a Modbus server device, which is a common need for systems where either a device or other software application can only act as a Modbus Client and you have other systems that need connectivity to that Modbus client.

A common misconception about TOP Server as an OPC server is that TOP Server will poll your device/devices automatically with no OPC client connected. So, when you are getting started with TOP Server, it is good to have an accurate understanding of how interactions occur between each node of a basic OPC architecture— client-server and server-device— to ensure that the configuration meets your needs and can be scalable to more demanding projects.

Continuing our Tech Support Corner blog series, in this blog post, we will discuss some basics of the interactions between an OPC client and server, including different types of reads and the expected behavior that you'll see as a result of those interactions.