Software Toolbox Technical Blog

Most AVEVA™ users are already familiar with the native connectivity options they have for interfacing with different systems. AVEVA users have turned to OmniServer for many years to integrate non-PLC devices such as barcode scanners, weigh scales, vibration monitors, RFID readers and more, all without custom code.

Those users of AVEVA InTouch have traditionally connected to OmniServer directly via its native SuiteLink interface. AVEVA's OI Gateway provides those users the additional option of connecting to OPC UA data sources, for easier and more secure remote connections to such data sources.

In this video blog post, we will cover the basic steps to connect AVEVA InTouch to OmniServer via OPC UA, expanding non-PLC device connectivity options for AVEVA users.

As someone who has worked with non-standard device connectivity using OmniServer for over 16 years, I consider myself well-versed in some of the more obscure nuances of certain protocols that a user might need to implement and how to do so in OmniServer.  It's very common for non-standard device protocols to simply be some combination of ASCII alpha-numeric characters with some special characters mixed in for starting messages, terminating messages or as delimiters.

Many OmniServer users may not be aware, though, that there are certain ASCII characters that are used in OmniServer protocol messages that have special meaning. So when you come across a device protocol that requires those characters to be sent or receive as-is (namely backslashes, curly braces and square brackets), there is some special handling required when configuring your OmniServer protocol .

Returning and expanding our "Did You Know" OmniServer blog post series, I'll cover the usage of some common special syntax characters for OmniServer protocol messages and how to, when needed, escape their special status in the message so they can be treated as their original ASCII equivalent instead.

AVEVA™ users already have a wide range of connectivity options for interfacing with different systems. For many years, OmniServer has been expanding that connectivity to include non-standard, non-PLC type devices that don't have an existing off-the-shelf communications driver. Users of AVEVA System Platform have traditionally connected to OmniServer via either the native SuiteLink interface or OPC DA Classic. AVEVA's OI Gateway provides those users the additional option of connecting to OPC UA data sources, for easier and more secure remote connections to such data sources.

In this blog post, we will cover the basic steps to connect AVEVA System Platform to OmniServer via OPC UA, expanding non-standard device connectivity options for AVEVA users.

For users that have never worked with OmniServer, it can be intimidating thinking about how to take information out of a device manual or protocol document and convert that into an OmniServer protocol for your device. OmniServer makes this significantly easier, though, than alternatives such as custom code, especially once you're familiar with how OmniServer works and how to get started.

Continuing our Tech Support Corner blog series, this blog post covers six tips I know should help any relatively new users be successful getting OmniServer connected to your non-standard devices as quickly as possible.

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.

But a common challenge is configuring an OmniServer but not having a real device physically available to test against. However, with a little extra configuration and a second PC with OmniServer installed, you can create a "device" version of the same protocol to test against.

Reviving our "OmniServer Did You Know?" blog series, I will cover how a second OmniServer can be configured to act as a test device for troubleshooting your protocol when a physical device isn't available.

Software Toolbox has a long-standing history of offering supplemental solutions that fit right in with AVEVA™ (formerly Wonderware®) projects. Many of you will be familiar with our TOP Server for AVEVA™ that offers a variety of device connectivity options, and a variety of client interface options like SuiteLink, OPC DA, and OPC UA.

SuiteLink is a communications protocol that runs over TCP/IP at the application layer, created by Wonderware to replace/succeed FastDDE, in the mid-1990's. Unlike OPC DA, SuiteLink doesn’t rely on COM or DCOM technology, making SuiteLink a common choice for remote connectivity to Software Toolbox solutions.

Continuing our Tech Support Corner blog series, this post shares best practices and procedures to follow when attempting to troubleshoot a SuiteLink connection, specifically when it comes to using SuiteLink clients with TOP Server. While this post specifically uses TOP Server as the SuiteLink server, the same techniques and concepts also apply to OmniServer, which also has a SuiteLink client Interface and is commonly used with AVEVA solutions.

Updates are made to Omniserver several times a year, adding useful features and tools, as well as resolving any known issues as part of our continuous improvement process.

In this post, I will cover updates and enhancements available in OmniServer V3.2.0.12 that increase the usability of OmniServer with respect to migrating and saving configurations, monitoring statistics and keeping current with Microsoft technologies.

As you may be aware, OmniServer is updated several times a year to add additional useful features and tools, and to resolve any known issues as part of our continuous improvement process.

In this post, I will cover updates and enhancements available in OmniServer V3.2.0.11 that enhance the usability of OmniServer Professional Edition for email alerts and reports and also an update that makes it easier to run OmniServer as a Windows service.