Software Toolbox Technical Blog

As someone who has worked with non-standard device connectivity using OmniServer for over 10 years, I sometimes take for granted the knowledge that I have gained over that time.  If you're anything like me, once you figure out the data you need from your device's protocol document, you just want to get your protocol knocked out as quickly as possible so you can start communicating.

In this post, I'm going to cover 4 key tips that I've learned over the years when working in OmniServer to build a protocol that you may not have realized and that could add convenience and save you a lot of time, which is time you can be spending on other important tasks.

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.

The New Year is a time of renewal, new projects, new challenges, and for some of you, new roles, or new people on your teams.  The last year has been one where our team has grown and worked to deliver the relevant content you need to learn more about software for automation & control, how to use our products, and the type of problems we solve.

In this blog post, we’ll provide a quick review of some key items from the last year that can help you or your colleagues in the coming year.  If you aren’t already subscribed to our blog, we encourage you to subscribe using the form at the right . We publish new content at least once a week, sometimes more often, and you can control the frequency of when you are notified of new content.

Our  is designed to help professionals that are new to the industrial automation space whether at the start of their careers, or moving into the operations technology (OT) world from an IT or other background.

One of the common challenges in Industrial Integration is communications between different brands or manufacturers’ control devices (PLC, DCS, Drives, RTUs, smart sensors).  While most control devices have methods of communication, and some industry standards have helped, they don’t all communicate using the same methods or protocols, and even if they both have the same serial or Ethernet wiring the difference in communication protocols prevents them from passing information.  It’s the same problem you have if someone calls you on the phone, but doesn’t speak the same language.

While, as humans, we may be able to overcome a difference in dialect, machine communication has to be precise and exact.  Small differences in addressing or data formatting can be enough variation to create communications failure. So how do people overcome this challenge?

l ask you to remember back to  where took the information we pulled from a device’s protocol document () and created a custom protocol in OmniServer.  As you’ll recall, our protocol has now been designed.

But how do you go about testing the protocol and proving that it works? This final post in the series takes you through the steps of getting connected and actually troubleshooting your OmniServer protocol.

If you haven't received one of my emails or heard from a colleague about our latest TOP Server release, you may not have heard about the key new features in the TOP Server V6.4 release.

In this post, I'm going to go through the top 3 key features released in V6.4 in more detail and how they benefit you as a TOP Server user.

In this edition of OPC Talk with Win and Marc, we’re going to discuss when things go wrong and how do you know?  No matter what OPC software you’re using, there are many things that can happen that could cause system problems.  Most people would rather know about a problem before it ruins their day, week, month, or career, right?

The heart of any control system is the computers and servers that run your automation software.  For example, when PLCs talk to AC drives over Ethernet, the drives will shut down if they lose communications for more than a second, sometimes even milliseconds.  Drives shutdown = Line shutdown = Plant shutdown.  What IT calls a blip for plant operations can mean downtime, scrapped product and even your company’s reputation due to missed delivery deadlines.

Traditionally, server maintenance and upkeep is the role of IT.  However, when these systems go down, it affects operations (OT) with different pains than IT sees on the business side.  IT has systems to monitor their own assets, on the standards they need for the business, but they need the OT side to expand monitoring of their own systems and self-reliance in order for OT to meet operational needs, while bringing in IT as a resource.

This blog post will discuss how to get information about health of servers and PCs that runs the automation software OT users need without having to rely solely on IT.