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.
So you've been tasked with bringing data from a new device (maybe a weigh scale or barcode scanner or RFID system) into your HMI/SCADA system. But you just have a protocol document from the manufacturer. And for this new device, there is no existing, off-the-shelf connectivity driver or server available.
So what now? Do you contact a custom software development house? That gets very expensive and time-consuming very quickly.
This post, the first of three, goes through what to look for in that protocol document from the manufacturer to know how to begin using OmniServer to integrate your device without requiring custom code in a fast, affordable manner that provides industry-standard client interfaces such as OPC DA and UA.
