Software Toolbox Technical Blog

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.

So you just installed a Software Toolbox product and have run into a problem and you have exhausted all the normal troubleshooting steps – what do you do now?

The next step should be to give our support team a call, or shoot us an email. Whether you call or email, the moment you reach out to us a support ticket will be created and your support history is recorded in its entirety in our CRM system for future reference.

This blog post will cover how easy it is to access your current and historical cases with the Software Toolbox support team.