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.
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.
It is common for companies to use databases for long-term storage of their critical information. In our experience, we also see machine setup information, short term operational data and much more besides traditional historical data put into shop floor databases in the operations technology or “OT” world.
Over on the business side or the “IT” world, everything somehow ends up in a database: Production plans, forecasts, orders, it’s all there. Increasing business demands and IT/OT convergence are driving more real-time integration between these databases and control systems.
This blog discusses some of the key reasons users like yourself need this information and then shows how the DataHub can help move this data from a database to your control systems via OPC DA, OPC UA, Modbus and other interfaces or protocols that are common in the automation layer.
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.
