Software Toolbox Technical Blog

Integrating specialized hardware into your control system shouldn't require a computer science degree or a massive budget for custom software development. Yet, many plants struggle with a "Zoo of Automation Hardware:" a collection of non-standard devices like barcode scanners, weigh scales, and sensors that simply don’t speak Modbus or Ethernet/IP.

As technical consultants at Software Toolbox, we are often approached by users who need to expose data from a software application they have written, or are writing, to communicate from systems they own to a client, HMI/SCADA, or historian. And, in many cases, there are dozens of applications at different sites that the data needs to reach. The question we are then presented with is, “how can I accomplish this quickly and efficiently while staying within budget?” 

Our hope is to answer this question and share from our experience with OPC since 1996, what our users have told us are the common reasons why they chose to use a commercial OPC server toolkit, and to help readers determine what factors to consider for their specific situation and circumstances.

In a previous blog post, we covered the basics of commercial OPC client development toolkits, with a dive into the benefits of using one, while here in part 2, our focus is on OPC server development toolkits. If you read our blog on OPC client toolkits, you will likely notice a clear overlap in the benefits you gain from using both types of commercial OPC toolkits.

Sometimes we are approached by users and integrators with very specific business demands, and an off-the-shelf OPC client solution isn't always the answer to their problems. As they explore the fully customizable development toolkits on the market, they are often concerned that their OPC expertise is inadequate for writing their own OPC client application. How should states and client objects be handled? When would an OPC group need to be created and have items added? What about timeouts, keep-alive intervals and more? Isn't PubSub (as in OPC UA PubSub) a deli sandwich from a popular grocery store called Publix in the US region we live in? Look – we hear you – and its problems like this that Software Toolbox has been solving since 1996. Let's start by saying this up front – you do NOT need to be an OPC expert or understand the internal complexities of OPC connectivity. Our OPC client development toolkit handles all of that and so much more for you. Let's learn more. 

JSON (JavaScript Object Notation) is a file format that has become fairly common in the industrial automation industry for storing data or information (including such things as configuration files). But also as one of the most common data formats used by RESTful APIs and web services, which are commonly used for providing a range of useful information including energy prices and weather data.

Sometimes, of course, depending on the application, some or all components of JSON packet might be variable or dynamic in nature, which can make it difficult for off-the-shelf industrial software solutions to properly parse the information from those packets.

In this post, I will cover step-by-step how to leverage the scripting capabilities of the OPC Router to access and parse JSON packets either from a JSON file saved to a specific file directory or from a RESTful web service after which that data can be used with any of the other connectors that OPC Router supports. For this example, we log the data to a SQL database.

A common misconception about TOP Server as an OPC server is that TOP Server will poll your device/devices automatically with no OPC client connected. So, when you are getting started with TOP Server, it is good to have an accurate understanding of how interactions occur between each node of a basic OPC architecture— client-server and server-device— to ensure that the configuration meets your needs and can be scalable to more demanding projects.

Continuing our Tech Support Corner blog series, in this blog post, we will discuss some basics of the interactions between an OPC client and server, including different types of reads and the expected behavior that you'll see as a result of those interactions.

So, no, we're not actually taking a rest - we're looking at what REST the acronym means from a practical perspective. But perhaps after reading this, if you're looking to connect to a RESTful API, you can give your mind a rest knowing you have a path forward.

I know the first time I ever heard the term, I had no idea what it meant or how to approach it. Maybe you've been told a certain data source has a REST API for accessing it, but you're not sure where to get started leveraging that API with your control system.

This post will provide a practical explanation of what REST is, how it can be useful to you and how you can take advantage of data provided by RESTful APIs or web services in your operations.

It's pretty common these days for companies to use Microsoft Teams™ for internal communications within and between departments and maybe even between IT and OT segments in an organization. This has become more and more important with increasing remote office scenarios, enabling vital collaboration between key members of an organization.

But what if you could also have real-time updates from your process and other systems in the same fashion? Rather than a colleague messaging you about an urgent matter, what if your actual processes and even business systems could message you via Teams with actionable information (possibly a line is down, or a tank level is approaching maximum level)?

In this blog post, we'll cover the steps necessary to use OPC Router to integrate your variety of systems with Teams so that you can have real-time updates and make important decisions about your business more quickly.

If you have been following our blog for a while or have been exploring IoT platforms available in the market, you may know that the Google Cloud Platform combined with the Google IoT Core is a frequently used combination in the industry. Google has recently announced that it will be shutting down the Google IoT Core. In doing so, Google is forcing many of its Cloud Platform users to switch platforms.

In this blog post, we will review detailed information about the alternatives to the Google Cloud Platform that are available for use with all of the IoT capable products we provide, and how the change works.