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?
The OPC UA specification is an evolution on the original OPC Classic specifications that has been designed by the OPC Foundation to supplement, but not render obsolete the existing OPC standards such as DA, HDA, & A&E. OPC UA is designed to make enterprise-level integration easier, while ensuring compatibility and interoperability with existing OPC DA, HDA, and A&E servers and clients. OPC expert Marc Holbach gives a seminar on all of the details below.
Software Toolbox has been involved with Industrial Automation communications for over 20 years now and some of us for even longer. When you've done something for such a long time you can forget that many people in this industry or IT don’t know as much about the topic as they would like.
To help share the collective knowledge we've gained throughout the years, we're starting a series of articles on why protocols matter for getting the most out of your projects.
This introductory blog post to the series will discuss my insights starting out in this industry as an Applications Consultant at Software Toolbox with respect to just how important the actual communications protocol and understanding of its strengths and weaknesses can be to the success of a project.
