Software Toolbox Technical Blog

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.

Welcome to our most popular blog post of the year! This post is our 6th annual sharing of references to learning resources including new whitepapers, our ever hot Tech Support Corner, a new AVEVA Users Corner, and new technology releases that users have told us were the most helpful to them over the course of the last year.

2022 accelerated transformations as industry worldwide continued to adapt to succeed in the face of ongoing challenges in supply chain, inflation, labor shortages, and exploding customer demand.  Each year we publish this blog post to help you learn, grow, and support empowering you to improve your business.

If you use OPC UA, you are likely at least somewhat familiar with OPC UA certificates. OPC UA client and server applications typically have Application Instance Certificates to provide application-level security. They are used for establishing a secure connection using Asymmetric Cryptography.

OPC UA certificates include a digital signature by the generator of the certificate. This digital signature can be self-signed or can be signed by a Certificate Authority (CA). Both types of certificates provide the same level of security and can be used in Asymmetric Cryptography. The major difference between CA signed and self-signed certificates in an OPC UA installation is the effort required to deploy and maintain the certificates. The choice of when to use a CA issued certificate versus a self-signed certificate depends on the installation and site requirements.

Many of our products leverage the OPC UA Configuration tool from the OPC Foundation to create and trust certificates and certificate authorities (CA). This tool actually installs with our OPC Data Client toolkit but is also available from the OPC Foundation. But how do we navigate this tool and the use of OPC UA certificates as a whole?

In this blog post, we will cover both methods of UA certificate signing, as well as the tool mentioned above for easily managing UA certificates for your OPC UA applications.

As you may be aware, Wireshark is an incredibly useful freeware tool for capturing network traffic on a computer. Our support engineers find it to be invaluable for troubleshooting Ethernet communications issues, as it provides visibility into more than just the protocol data packets, including handshaking calls and responses.

Wireshark also provides options for specifying capture filters (for defining a smaller subset of data to be captured that you're interested in) or you can capture all traffic and apply a display filter to narrow down the traffic that is visible.

Continuing our Tech Support Corner blog series, this blog post covers how to go even further using Wireshark by defining scripted custom Wireshark captures for specific use cases, which is helpful for capturing infrequent issues without wasting a lot of unnecessary hard drive space.

Do you find yourself in need of troubleshooting a TCP connection, but your IT department has everything locked down, so you're unable to install third-party Troubleshooting tools without permission? An often overlooked but effective tool for troubleshooting TCP socket connections is PowerShell.

Continuing our Tech Support Corner blog series, this blog post covers how to use PowerShell to effectively determine what issues you may be having with a problematic TCP Ethernet connection.

2021 furthered the transformations of 2020 as industry worldwide continued to adapt to succeed in the face of new challenges such as supply chain, a growing labor shortage, and exploding customer demand.  

This post is our 5th annual sharing of references to learning resources and new technology releases that users have told us were the most helpful to them over the course of the last year.

Continuing our Exploring OPC UA blog series, we're still going into the specifics of OPC UA security configuration in key Software Toolbox solutions that are OPC UA capable.

In this ninth post of the series, we will focus on OPC Router, focusing on stepping through what the settings are in OPC Router and how to get connected both for your OPC UA clients and servers.