Software Toolbox Technical Blog

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 . 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.

So remember in  where you just have a protocol document from the manufacturer for a device you need to integrate with your control system?  And for this new device, there is no existing, off-the-shelf connectivity driver or server available.

And remember asking yourself, “How do I connect to this non-standard device?”  With custom software development being very expensive and time-consuming, we discussed a better way using .

This post, the second of three, goes beyond the protocol details we gathered from the document in  to provide the basics on how to actually use those details to build a working protocol in OmniServer without custom code for a fast, affordable solution with industry-standard client interfaces including as OPC DA and UA.

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.

In this edition of OPC Talk with Win and Marc, we’re going to address some common questions we get about redundancy involving OPC software.  If you’re new to the industrial automation space and want to learn more about redundancy in automation in general, visit our Demystifying Redundancy in Automation blog post.