Software Toolbox Technical Blog

---

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.

---

This is Part 10 of our “25 Things to Consider when Choosing an OPC Tunnel” series.  Are there ways to connect a Windows system to a non-Windows system with the Tunnel solution?

Since OPC was designed around DCOM, a Windows only technology, you simply do not find OPC Data Access Servers that are supported in a non-Windows environment.  Nonetheless, it's not unusual for control systems to have both Windows and non-Windows machines that need to share information.

This blog post will discuss how it can be possible to link Windows and non-Windows systems in your control systems.

---

In this blog, we will cover the built-in startup and testing features included in the TOP Server including a video link to see these tools in action.

These tools include a sample OPC client that can help with quickly testing connectivity to your devices, as well as device-to-server level and server-to-client level communication diagnostics. The user interface displays important informational messages, as well as communication warnings and errors. Also available is extensive and easy to navigate help documentation.

We’ll briefly discuss each of these tools and take a look at a video which walks us through the use of each of these tools and points us to further troubleshooting resources at Software Toolbox.

---

This is Part 9 of our “25 Things to Consider when Choosing an OPC Tunnel” series.  Will a tunneler support redundant tunnel paths?

Redundancy is typically a more complex topic than it might sound especially if your automation control architecture is extensive and has multiple layers.  Redundancy has different meanings to different people for different applications.

This blog post will outline reasons why it's important for an OPC tunneling solution to support redundant paths for applications where it is essential minimize the risks of failure when transferring your control data and what questions to ask.

---

Have you ever been in a situation where you were working with both Wonderware and some other client (HMI, SCADA, other) and needed to share data?  Perhaps your company acquired another company or assets and a non-Wonderware HMI/SCADA came as part of the assets.  Or perhaps your company merged with another and now your Wonderware system is expected to play nicely with some other system.  Your options for sharing data largely depend on what software interfaces this "other system" supports.

In this blog post, I'll discuss how to share your Wonderware ArchestrA or InTouch data via OPC UA for situations where you're working with an OPC UA capable client application that needs access to process data in your Wonderware system.

---

This is Part 8 of our “25 Things to Consider when Choosing an OPC Tunnel” series.  What flexibility is there in how ports are configured?

Depending on your level of knowledge regarding OPC tunneling solutions, you may or may not be aware of how a tunneler uses TCP ports for transferring data between machines.  Your IT department likely gives you plenty of trouble whenever you mention needing to open a TCP port.  And with good reason - cyber attacks frequently exploit commonly used TCP ports.

This blog post will outline three top reasons why it's important for an OPC tunneling solution to support fully configurable TCP ports for transferring your data.

---

This is Part 7 of our “25 Things to Consider when Choosing an OPC Tunnel” series.  How does the OPC tunneling solution work in a mixed Windows OS environment.

If you have ever used DCOM between two different varieties of Windows operating system (Windows 7 and Windows XP, for instance) you already know how painful it can be to configure DCOM.  DCOM configuration is never a walk in the park but the frustration multiplies when the operating system isn't the same on both machines.

This blog post will outline one of the easiest methods to avoid the problems of configuring DCOM when the operating systems do not match.

---

If you’re reading this blog, you likely need a way to collect data from some random device in your process – something like a barcode reader or a weigh scale or an RFID system or some other device.  These are the types of device that don’t typically yield favorable results when you type “OPC Server for xyz” into a Google search.

In this blog post, I'll discuss the device manufacturer documentation that is typically provided for such devices and what some of the key information is you'll be looking for - including examples of how a good protocol document will present such information.