Software Toolbox Technical Blog

What is the most important feature for any data logger to have? At the end of the day, we are trusting a data logger to take our data and store it.  Now whether that is for reporting, optimization, legal reasons, or simply to retain process data over some period of time in case it might be needed later, we expect the data to be logged without any losses.

This is particularly true in the industrial automation space, where the amount of data that is being logged is growing almost as exponentially as the speed at which the data is needed in order to have a business impact. As such, the prospect of losing data can very quickly result in lost jobs, thousands of dollars in lost production, and legal or financial penalties in case of an audit.

So how much do you trust your data logger to really be logging 100% of the data that it should be? In this blog post, I will address these concerns and highlight the ways OPC UA provides capabilities that software applications can leverage to provide peace of mind.

Does your data logging software force you to define the location where you're logging your data ahead of time?  Wouldn’t it be nice if your logging software could evaluate your data and make a decision on where the data should be logged?

In this first of two posts in a series on dynamic SQL logging, I'll show you how the OPC Data Logger can easily be configured to switch between SQL Tables at runtime, reducing any post-log sorting you have to do in SQL and saving you time and effort in the process.

Do you need to log specific process data to a database or text file based on some predefined variable or condition? We typically refer to this concept as "conditional" or "condition-based" logging.  It sounds simple enough but without a plan, it can be a tricky task to implement.

In this post, I'll introduce you to the considerations involved with conditional data logging and cover how OPC Data Logger can easily be set up to log data based on a variety of conditions without a lot of headaches.

Does your non-standard instrument connected to your COM1 serial port refuse to communicate without being told how? Do you need to tell the instrument what bank of memory to use before you can extract any data? Does the instrument require setup parameters before it will work? Do you not want to script this in your client application, and don’t want to expect a user to manually initialize a device before doing anything else?

With OmniServer, there is an auto-activated message flag that's exactly the feature you have been looking for when communicating with your non-standard devices and instrumentation.  This fifth post in our "OmniServer Did You Know?" blog series focuses on how to use OmniServer's setting for auto-activating a command protocol message to initialize communications with your device automatically on startup.

A common question I run into when talking to OmniServer users is "How can I gain more visibility into what is going on with my OmniServer."  After all, a primary concept for an OPC Server is to be invisible – to be a transparent converter between the protocol used by a device, and that used by your SCADA or HMI (i.e. OPC, Wonderware SuiteLink, etc.).

While there are a number of answers to how you can be more aware of what is going on with your system, this fourth post in our "OmniServer Did You Know?" blog series focuses on the importance of system tags, and specifically how they can be used in the OmniServer to query the health of the server as a whole, as well as individual device connections.

If you are familiar with the OmniServer, you probably already know that it can be used to retrieve information from devices that use ‘non-standard’ protocols to communicate – typically these are your weight scales, barcode readers, and printers.

However, did you know that the OmniServer can also retrieve data that are exposed via web services, or even websites?  Keep reading to find out you can "scrape" web sites or services to integrate useful information into your systems using OmniServer.

At its core, a communication protocol is just the ‘language’ that devices speak, right? Just a collection of rules that govern how components of a system are going to interact with each other, and what the capabilities of the system might look like.

In this post, I will discuss why you should bother learning anything about communication protocols in the first place. I will discuss the value of knowing what a communication standard is and why some people (myself included) commit so much time to learning them.

A key feature of any HMI package is the ability to not only show the current state of your control system, but to then store that information for historic purposes. But what good is historical data when you can’t easily access it? How can historical data result in process improvements, financial returns, or increases in efficiency if you’re not accessing it?