Software Toolbox Technical Blog

OmniServer Plug-ins (or Wedges), which are included with OmniServer Professional Edition, are built-in components that provide powerful, supplemental capabilities that expand the functionality of OmniServer beyond its core connectivity and data parsing abilities for non-standard devices.

The OmniServer Email Plug-in / Wedge allows you to send your device data as an email message or text in a highly configurable format with configurable conditions.  And it provides this ability built into OmniServer, eliminating the need for separate external components.

In this video blog, I'll show you how to get started using the OmniServer Email Plug-in / Wedge to send timely email or text notifications to your key personnel based on specified conditions, allowing those individuals to quickly take the appropriate action to minimize any related loss or downtime that might occur. This includes configuring secure SSL or TLS encryption with a configurable port, as well as, a new test function for confirming email server settings work correctly.

The Message Queue Telemetry Transport (MQTT) standard is a lightweight publish/subscribe model communications protocol used widely for Industrial Internet of Things (IIoT) integration of edge devices across a wide variety of industries around the world.

In this video blog, I'll show you how to get started using our MQTT Client driver to interface to an MQTT broker or server (including devices acting as a broker or server) to integrate data from your IIoT data into Wonderware applications.

If you’ve worked with OmniServer to connect your non-standard devices in the past, you may be aware of the large number of pre-defined Error Detection Codes (EDC, also known as CRC, LRC and Checksums) available.  However, as is the nature of custom protocols out there, it’s not uncommon to find an EDC that isn’t pre-defined due to some specialized handling by the device manufacturer.

To that end, OmniServer provides the flexibility to define your own custom EDCs in an OmniServer protocol.  This post, the first of three on custom Error Detection Codes, will cover the basics of creating a simple custom checksum in OmniServer.

As someone who has worked with non-standard device connectivity using OmniServer for over 10 years, I sometimes take for granted the knowledge that I have gained over that time.  If you're anything like me, once you figure out the data you need from your device's protocol document, you just want to get your protocol knocked out as quickly as possible so you can start communicating.

In this post, I'm going to cover 4 key tips that I've learned over the years when working in OmniServer to build a protocol that you may not have realized and that could add convenience and save you a lot of time, which is time you can be spending on other important tasks.

Timely notifications about abnormal conditions in your process are vital to minimizing downtime and the costs associated with it.  Automating the process based on the condition of specific process variables gets you the information you need for making decisions as quickly as possible.

The following short video blog demonstrates step-by-step how easy it is to use the Cogent DataHub to establish a connection to an OPC data source and then define various flexible conditions for triggering email and/or SMS text notifications based on values collected from that OPC server.

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.