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.

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.