Software Toolbox Technical Blog

Those of you who are aware of OmniServer will already know that it is primarily used to retrieve information from devices that use 'non-standard' protocols to communicate, such as weigh scales, barcode readers, and printers. An HMI, SCADA, MES, Historian, database, and more, could then read that data from OmniServer, making it a powerful, universal, data acquisition tool.

Some of these 'non-standard' device protocols require what we call "special handling". For most protocols, if you've used OmniServer, data that is sent or received is "what you see is what you get" type data. An ASCII "A" is transmitted or received and interpreted as an ASCII "A". But what if your device is expecting something else as part of its special handling in its communication protocol? Or what if you wanted to interpret the data differently from the device to meet new business standards or existing requirements?

OmniServer is capable of handling advanced protocols where the devices send special characters/bytes that need to be handled in a specific way. In this blog, we will explain how to use a feature called "translations" in OmniServer with certain protocols that require special handling.

Unlike off-the-shelf OPC servers and drivers that talk to specific devices or protocols and no others, OmniServer can be configured to talk to virtually any device or combination of serial, USB, or Ethernet connected devices with some outliers based on the complexity of the protocol. OmniServer helps you bring data that would otherwise be inaccessible into your process and business systems, helping you make more effective decisions. In our experience there are still many software applications that do not have open interfaces such as OPC for data input. This is particularly common in quality control and test stand applications. Operators use a digital device to capture a measurement, and then have to type that into their test stand or QC software. This slows testing rates and can be error prone. There is a better way. 

In today's business landscape, the exchange and storage of data plays a pivotal role in ensuring efficient and robust operations. Whether operating in sectors like Pharmaceuticals, Manufacturing, Power, or related industries, the exchange of data between services and applications has become standard practice, often an imperative. Consequently, many organizations leverage resources such as databases and historians to archive their invaluable data. However, there are instances where the need for simpler storage methods or direct interchange of data via Webservices is required to maximize application interoperability. Unfortunately, this solution area is often one filled with custom software applications. In this blog, we'll show you how to eliminate custom code and build sustainable solutions.

In a prior blog post regarding redundancy, we learned how critical it is to plan for redundancy in the Industrial Automation space. We covered how the TOP Server Media-Level Redundancy Plug-In  facilitates duplicate or backup systems used to maintain reliable communications with the critical components in your environment which in turn minimizes data loss and increases the availability of your critical industrial data.

The engineering definition of redundancy is “the inclusion of extra components which are not strictly necessary to functioning, in case of failure in other components.” In the Industrial Automation space, redundancy is critical. Not planning for redundancy can easily result in vulnerability to financial losses due to unexpected downtime. There are multiple types of redundancy in the industry. In this blog, we will be covering “Media-Level Redundancy”.

If you are reading this post, chances are you have configured your TOP Server project and are communicating with your devices successfully. Perhaps, you also have a client application successfully writing and/or reading to or from TOP Server. Did you know all TOP Server drivers provide several different Scan Modes for controlling how client requests affect the polling frequency for your configured devices? In fact, these Scan Modes apply to all client connection types including OPC UA, OPC DA and AVEVA SuiteLink.

Continuing our Tech Support Corner blog series, this short post will discuss the five Scan Mode options available in the TOP Server Device Properties. Each Scan Mode serves a different purpose depending on your specific scenario. We will explain each mode, giving you a better understanding of which mode is best for your situation. Correctly setting the Scan Mode to match the capabilities of your device will help to provide optimal performance for your automation system.

If you are reading this post, chances are that you are somewhat familiar with TOP Server as well as how to configure it to communicate with various devices. Perhaps, you are also familiar with how to configure different settings, OPC UA endpoint settings, Licensing, Stop and Start the Service, and, if you are a developer, you might be familiar with the development resources that TOP Server offers such as the Remote Config REST API and the OPC.NET interface.

However, during our daily interaction with end-users, we often find that there is a misconception of what the TOP Server application is composed of and how each component contributes to delivering the product that you interact with daily.

Continuing our Tech Support Corner blog series, this short post will discuss the various components of TOP Server and clarify how each component contributes to the macro process that allows the application to deliver communication between your process devices and your various IT/OT systems.