Software Toolbox Technical Blog

If you’ve been following our blog series on custom error detection, you’ll remember that OmniServer provides a large number of pre-defined Error Detection Codes (EDC) for use in different protocols for non-standard device communication.  And, again, it’s not uncommon to find an EDC from a vendor that is not pre-defined due to some specialized handling by the device manufacturer.

As we covered in our previous posts on creating a custom checksum and LRC, OmniServer gives you the ability to build custom EDCs in an OmniServer protocol to handle these situations.  This post, the final of three on custom Error Detection Codes, covers the basics steps to creating a custom CRC (Cyclic Redundancy Check) in an OmniServer protocol.

You may be aware that OmniServer provides a wide variety of pre-defined Error Detection Codes (EDC, also known as CRC, LRC and Checksums) for use in protocols for non-standard device communication.  However, it’s not uncommon to find an EDC that isn’t pre-defined due to some specialized handling by the device manufacturer.

To handle such situations, OmniServer provides the ability to build your own custom EDCs in an OmniServer protocol.  This post, the second of three on custom Error Detection Codes, will cover the basics of creating a custom LRC (Longitudinal Redundancy Check) in OmniServer.

If you’ve worked with OmniServer to connect your non-standard devices in the past, you may be aware of the large number of pre-defined Error Detection Codes (EDC, also known as CRC, LRC and Checksums) available.  However, as is the nature of custom protocols out there, it’s not uncommon to find an EDC that isn’t pre-defined due to some specialized handling by the device manufacturer.

To that end, OmniServer provides the flexibility to define your own custom EDCs in an OmniServer protocol.  This post, the first of three on custom Error Detection Codes, will cover the basics of creating a simple custom checksum in OmniServer.

When you live in a remote region that is one of the most arid places on earth, you import your raw materials, and you’re making millions of hectoliters of beer a year, you have to make the most of all the resources you have and leverage what is in abundance in your location.  Namibia Breweries Ltd. (NBL) has a long history of success in a tough environment at their Windhoek site. They have received numerous awards for their innovative approaches to meeting their information system needs.

In this blog post, we’ll share their look into how they use off-the-shelf software and their teams' intellectual know-how and creativity to empower their manufacturing success.  If you read the stories in Automation World or Pro Food World you learned about how Andre Engelbrecht, manager of industrial control systems at NBL, and his teammates Annemarie Kruger, Rolando du Pisani and others unlocked data sources and built a digital smart manufacturing platform across the entire facility.  In this article, we’re going to share the rest of the story of NBL’s integration points, problems solved, and how they leveraged Software Toolbox’s full value proposition as part of their team effort.

Software Toolbox has worked with integrators, users, OEMS and distributors of Wonderware Software products since 1997.  At a Schneider Electric Software conference in 2017, they met a hardware supplier new to the Wonderware user community, , also known as TPI.  It turns out TPI is not new to the vibration monitoring space, though, and has a long history of providing handheld test and measurement equipment. In this video blog...

Our latest release of the OPC Data Client development toolkit provides some exciting new features for leveraging powerful OPC UA technology features including OPC UA complex data support.

In this post, we will cover some of the key reasons the OPC Data Client 2018.1 is an easy, effective method for bringing the power of OPC UA to your custom client applications.

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.

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?