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.
Timely notifications about abnormal conditions in your process are vital to minimizing downtime and the costs associated with it. Automating the process based on the condition of specific process variables gets you the information you need for making decisions as quickly as possible.
The following short video blog demonstrates step-by-step how easy it is to use the Cogent DataHub to establish a connection to an OPC data source and then define various flexible conditions for triggering email and/or SMS text notifications based on values collected from that OPC server.
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.
I’m excited about the recent release of the OPC Data Client development toolkit – and you should be too if you’re an active developer of custom OPC Client software applications. This post is highly technical, but hopefully our developer readers will find it useful.
We’ve been working with the OPC software interoperability standards since 1996, and it’s easy to forget that others who are new to this space often find the whole discussion around the OPC standard and all the different standards confusing.
