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.
What exactly is an EDC Again?
Since it may have been awhile since you read the first and second post in this series, I’ll recap what an Error Detection Code even is. Error Detection Codes (EDC) are algorithms that get applied to a sequence of characters in a message to or from a device and returns a value that can be used by another device or software solution to check the validity of the data stream. This is to ensure there was no interference with the message, whether simply electrical “noise” on the line or actual malicious interference.
EDC is an overarching term referring to an entire class of error detecting algorithms including checksums, LRCs and CRCs, amongst others.
- Checksums are calculated based upon the sum of a data stream.
- LRCs (Longitudinal Redundancy Check - also referred to as BCCs, or Block Check Character) are calculated using an XOR-type algorithm on the data stream.
- CRCs (Cyclic Redundancy Check) are calculated using another type of algorithm on the data stream and always include some form of polynomial used in the calculation.
You Mentioned Pre-Defined Error Detection Codes?
As I mentioned earlier, even though OmniServer does come with 19 pre-defined EDCs that cover most common EDCs you will see from a device manufacturer’s protocol, it’s not uncommon for a manufacturer to have implemented some EDC in their devices that is not covered already in OmniServer.
That’s where the Error Detection Code builder in OmniServer comes in. Rather than having to throw in the towel, it allows you to define your own new EDC for that protocol based on the details of the required calculation from the protocol document, allowing you to successfully communicate with that manufacturer’s device without needing to start looking at the expensive cost to build a custom server just to handle that EDC.
What do I need to define custom EDCs in OmniServer?
As I’ve discussed in our previous EDC posts, the first step to defining any EDC (even a pre-defined one) is finding a description of the code or calculation required from the manufacturer. That information should pretty much always be available somewhere in a protocol document from the device’s manufacturer. Click here for our post on evaluating protocol documentation
Previously, we’ve looked at a basic checksum and an LRC. For today’s example, our manufacturer’s protocol document states this:
“The check code is a Cyclic-Redundancy check utilizing a polynomial of x^16+x^15+x^12+x^7+x^5+x^2+1 (90A5). Starting with an initial seed of 0xFFFFh, all bytes that appear in the data stream are included in this check with the exception of any control characters (ASCII 0 through ASCII 31). The final result is represented by an eight-bit byte appended to the end of the file.”
Looking at this description, we know we need to use a CRC calculation, and since the initial seed value of the polynomial is 2 bytes (i.e. 16-bits), we know it needs to be a CRC 16-bit.
Looking at the variety of OmniServer's pre-built EDCs, we do have a number of 16-bit CRCs available. However, none of the pre-defined CRCs use the proper polynomial and initial seed value or exclude control characters. That being the case, it will be necessary to create our own using the Error Detection Code builder.
With all of this information, you have all that’s needed to go into an OmniServer protocol and build a custom CRC to handle the above calculation. For a detailed how-to on building the custom CRC in the above example and then using it in a protocol, click here.
As with other aspects of custom protocols, there can be a lot of variability regarding the type of error detection a device manufacturer has decided to implement, if any, including how they document the calculations required. For that reason, don’t forget that we do offer complimentary protocol reviews to help you determine compatibility of your protocol (including EDCs) with OmniServer and professional services when you just don’t have the time and you’d prefer us to just handle the protocol and EDCs for you.
Don’t forget to subscribe to our blog so you don’t miss our other useful posts on addressing industrial automation challenges using OmniServer and other solutions.
