If you're familiar with OmniServer, you likely already know how OmniServer is commonly used to retrieve information from devices that use ‘non-standard’ protocols to communicate such as weight scales, barcode readers, and printers either over serial connections or Ethernet connections.

However, with the advent of USB connectivity, many such devices that would have traditionally been a serial/COM device now physically connect to a machine via USB, instead.

Continuing our "OmniServer Did You Know?" blog series, we will cover how OmniServer can easily connect to USB or serial-to-Ethernet devices that are mapped virtually as Serial/COM devices.

The New Year is a time of renewal, new projects, new challenges, and for some of you, new roles, or new people on your teams.

In this blog post, we provide a quick reference to resources from the past year that should be helpful to you and your colleagues.  If you aren't already subscribed to our blog, we encourage you to . We publish new content about once a week, sometimes more often, and you can control when you are notified about new content.

When working with non-standard protocols based on protocol documentation from a device vendor, there will always be some expected amount of testing, trial-and-error and troubleshooting in order to fine tune communications with a device.

Continuing our "OmniServer Did You Know?" blog series, this blog post focuses on how to use the built-in Item Values window in the OmniServer diagnostic tools and the included OPC Test Client to test communications using OmniServer.

With any communication server for collecting process data, there has to be a reliable mechanism built-in for dealing with error responses from the underlying devices.  This is true even for OmniServer as a user-configurable communication server.

Continuing our "OmniServer Did You Know?" blog series, this blog post focuses on how to use error messages and notification items in an OmniServer protocol to properly handle error responses or conditions received from your non-standard process devices.

As part of our continuous improvement process at Software Toolbox, OmniServer is updated several times a year to add additional useful features and tools, and to resolve any known issues.

In this video blog, I will cover updates and enhancements available in OmniServer V3.1.0.5 to help you with usability, performance and troubleshooting while connecting to all of your non-standard devices.

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.