Software Toolbox Technical Blog

In a nutshell, OmniServer's purpose is to retrieve information from devices that use ‘non-standard’ protocols to communicate such as weight scales, barcode readers, and printers.

Sometimes with some protocols, simply sending one message to a device, or doing nothing but simply transferring data to a client isn't enough. There are some more complex protocols where you will need to send a series of messages to the instrument, or respond to an event coming in from the device or to handle a sequence of handshaking messages. This is where "chained messages" come into play in an OmniServer protocol.

In this second post of a follow-up to our "OmniServer Did You Know?" blog series, we will cover how to chain multiple OmniServer command/request messages together in a protocol to flexibly handle such complex protocols.

As you probably know, OmniServer is used to retrieve information from devices that use ‘non-standard’ protocols to communicate such as weight scales, barcode readers, and printers.

In some situations, device protocols need to be designed to where the client application (HMI, SCADA or other), and not OmniServer, is in complete control of the polling. But before you send out the next message, how do you know if the device is still connected?

In this first post of a follow-up to our "OmniServer Did You Know?" blog series, we will cover how to create what is known as a heartbeat message to confirm your device is "listening" before sending the next message.

OmniServer's connectivity and data parsing capabilities are only part of how OmniServer helps with integrating non-standard devices with Wonderware.  How does the device data actually make it into Wonderware?

In this video blog, part of a series on connecting Wonderware to OmniServer, I'll show you how to make a basic SuiteLink connection from Wonderware Historian to OmniServer for historizing process data from all of your "other" devices where there isn't a standard, off-the-shelf driver - all without the cost and effort of having to write a custom driver.

OmniServer's connectivity and data parsing capabilities are its primary job; however, they are only the part of how OmniServer helps with integrating non-standard devices with Wonderware.  How does the device data actually make it into Wonderware?

In this video blog, part of a series on connecting Wonderware to OmniServer, I'll show you how to make a basic SuiteLink connection from Wonderware InTouch to OmniServer for integrating process data from all of your "other" devices that don't have a standard, off-the-shelf driver - and all without the expense and headaches of having to write custom code.

While OmniServer's core connectivity and data parsing abilities are its primary function, they are only the first step to integrating non-standard devices with Wonderware.  How does that device data then make it up into Wonderware?

In this video blog, part of a series on connecting Wonderware to OmniServer, I'll show you how to make a basic SuiteLink connection from Wonderware System Platform to OmniServer for integrating process data from all of your "other" devices that don't have a standard, off-the-shelf driver - all without the expense and headaches of having to write custom code.

OmniServer's core connectivity and data parsing abilities are only part of the equation when integrating non-standard devices with Wonderware.  How does that device data then make it up into Wonderware?

In this video blog, part of a series on connecting Wonderware to OmniServer, I'll show you how to make a basic OPC DA connection from Wonderware System Platform to OmniServer for integrating process data from all of your "other" devices that don't have a standard, off-the-shelf driver - all without having to write custom code.

OmniServer Wedges are included with OmniServer Professional Edition.  Wedges are built-in components providing additional useful capabilities that expand the functionality of OmniServer beyond its core connectivity and data parsing abilities for non-standard devices.

The OmniServer Database Wedge allows you to log your device data to any ODBC-compliant database, including SQL, with a highly configurable format and flexible conditions.  And this ability is built into OmniServer, eliminating the need for separate external components or applications.

In this video blog, I'll show you how to get started using the OmniServer Database Wedge to easily log process data based on specified conditions, making it possible to monitor trends in your process and easily report on your process data or troubleshoot any issues that are discovered.

If you’ve been following our blog series on custom error detection, you’ll remember that OmniServer provides a large number of pre-defined Error Detection Codes (EDC) for use in different protocols for non-standard device communication.  And, again, it’s not uncommon to find an EDC from a vendor that is not pre-defined due to some specialized handling by the device manufacturer.

As we covered in our previous posts on creating a custom checksum and LRC, OmniServer gives you the ability to build custom EDCs in an OmniServer protocol to handle these situations.  This post, the final of three on custom Error Detection Codes, covers the basics steps to creating a custom CRC (Cyclic Redundancy Check) in an OmniServer protocol.