Software Toolbox Technical Blog

Our  is designed to help professionals that are new to the industrial automation space whether at the start of their careers, or moving into the operations technology (OT) world from an IT or other background.

One of the common challenges in Industrial Integration is communications between different brands or manufacturers’ control devices (PLC, DCS, Drives, RTUs, smart sensors).  While most control devices have methods of communication, and some industry standards have helped, they don’t all communicate using the same methods or protocols, and even if they both have the same serial or Ethernet wiring the difference in communication protocols prevents them from passing information.  It’s the same problem you have if someone calls you on the phone, but doesn’t speak the same language.

While, as humans, we may be able to overcome a difference in dialect, machine communication has to be precise and exact.  Small differences in addressing or data formatting can be enough variation to create communications failure. So how do people overcome this challenge?

l ask you to remember back to  where took the information we pulled from a device’s protocol document () and created a custom protocol in OmniServer.  As you’ll recall, our protocol has now been designed.

But how do you go about testing the protocol and proving that it works? This final post in the series takes you through the steps of getting connected and actually troubleshooting your OmniServer protocol.

So remember in  where you just have a protocol document from the manufacturer for a device you need to integrate with your control system?  And for this new device, there is no existing, off-the-shelf connectivity driver or server available.

And remember asking yourself, “How do I connect to this non-standard device?”  With custom software development being very expensive and time-consuming, we discussed a better way using .

This post, the second of three, goes beyond the protocol details we gathered from the document in  to provide the basics on how to actually use those details to build a working protocol in OmniServer without custom code for a fast, affordable solution with industry-standard client interfaces including as OPC DA and UA.

We’ve been working with the OPC software interoperability standards since 1996, and it’s easy to forget that others who are new to this space often find the whole discussion around the OPC standard and all the different standards confusing. 

So you've been tasked with bringing data from a new device (maybe a weigh scale or barcode scanner or RFID system) into your HMI/SCADA system.  But you just have a protocol document from the manufacturer.  And for this new device, there is no existing, off-the-shelf connectivity driver or server available.

So what now? Do you contact a custom software development house?  That gets very expensive and time-consuming very quickly.

This post, the first of three, goes through what to look for in that protocol document from the manufacturer to know how to begin using OmniServer to integrate your device without requiring custom code in a fast, affordable manner that provides industry-standard client interfaces such as OPC DA and UA.

Does your data logging software force you to define the location where you're logging your data ahead of time?  Wouldn’t it be nice if your logging software could evaluate your data and make a decision on where the data should be logged?

In this first of two posts in a series on dynamic SQL logging, I'll show you how the OPC Data Logger can easily be configured to switch between SQL Tables at runtime, reducing any post-log sorting you have to do in SQL and saving you time and effort in the process.

In the automation and control world you need to know about problems immediately.  If problems are not recognized early enough, they can cause unexpected downtime, damage to machinery or environmental impacts.  In other words, these problems can cost you a lot of money.

Fortunately, these days most of us have 24/7 access to email or texting through their laptops and smart phones which has made receiving alarms in a timely fashion much easier than in the past.

In this third post of our “I Can Do That?” blog series, we’ll cover how to get alerts to problems ASAP and also share some specific use cases for email/SMS notifications using Cogent DataHub.

Do you need to log specific process data to a database or text file based on some predefined variable or condition? We typically refer to this concept as "conditional" or "condition-based" logging.  It sounds simple enough but without a plan, it can be a tricky task to implement.

In this post, I'll introduce you to the considerations involved with conditional data logging and cover how OPC Data Logger can easily be set up to log data based on a variety of conditions without a lot of headaches.