Software Toolbox Technical Blog

In recent years, many of our users have let us know they are adopting the latest Siemens technology, particularly S7-1500 controllers.  And, with that adoption of those controllers, users have been asking for connectivity via the symbolic optimized block addressing.  So we added a Siemens Plus Suite to enable connectivity to new and legacy Siemens devices.

This post focuses specifically on the general steps required to integrate S7-1500 controllers by connecting to their embedded OPC UA server using TOP Server for AVEVA.  

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.

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 the wide range of devices that use Modbus for their communication protocol, you'll find many different interpretations, terminology and labels with respect to how to access different types of data in those devices.  Sometimes a device manual might only refer to the supported Modbus function codes and the range of offsets available for those function codes.

In this blog post, I will step through the specifics of Modbus function codes and how they pertain to addressing, and how they affect what addresses to use in TOP Server for Wonderware applications.

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.

I'm sure you've all at least had some interaction with Modbus, working in the automation industry.  It's one of the most widely used protocols (if not the most widely used) in the world.  Which is both its blessing and its curse, to some extent.

Given how long Modbus has been around and in use as an "open" protocol (starting in 1979), there have been many different interpretations of Modbus throughout the years.  And with those different Modbus interpretations, much confusion about the different terminology for accessing data.

In this blog post, I will step through the basics of Modbus addressing including how offsets come into play, and how they affect what addresses to use in TOP Server for AVEVA applications.

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.