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.
Refresher on What an EDC Is
So just to quickly recap, as I explained in our first post in this series, an Error Detection Code (EDC) is an algorithm that, when applied to a sequence of characters in a message or data packet, returns a number that can be used by another process to check the validity of the data stream.
EDC is a blanket term for an entire class of such error detecting algorithms including checksums, LRCs and CRCs, among others.
- Checksums calculate an EDC based upon the sum of a data stream.
- LRCs (Longitudinal Redundancy Check - also referred to as BCC, or Block Check Character) usually use an XOR-type algorithm on the data stream.
- CRCs (Cyclic Redundancy Check) apply another type of algorithm to the data stream and will always include some form of polynomial used in the calculation.
Doesn't OmniServer Already Have Error Detection Codes?
As we discussed previously, while OmniServer comes with 19 pre-defined EDCs that cover the most common EDCs you might see a device manufacturer using, it’s not uncommon for a manufacturer to have implemented some EDC in their devices that is not pre-defined in OmniServer.
The Error Detection Code builder in OmniServer makes it possible to define your own new EDC for a protocol, allowing you to successfully communicate with that manufacturer’s device without needing to pay the typically expensive cost to build a custom server just to handle the EDC.
How can I define custom EDCs in OmniServer?
As we discussed in the last post, the first step to defining an EDC is finding a description of the code or calculation required from the manufacturer. Such information can typically be found in a protocol document of some sort from the device’s manufacturer. Click here for our post on evaluating protocol documentation.
Last time, we looked at a basic checksum. For today’s example, our manufacturer’s protocol document states this:
“The check code calculated from the first character after the header character up to and including the End-of-Text character. Beginning with the value of 0xAAh, each byte is XORed with the previous result, after the number "1" is added to each byte before it is XORed. The final result is then ANDed with 0x55h, and the number is appended to the data stream in one byte.”
Looking at this description, we know we need to use an LRC (which uses the XOR algorithm) and, since one byte at a time is used in the calculation and there is only one byte being appended to the data stream, we can determine it should be an 8-bit LRC.
Looking at the variety of OmniServer's pre-built EDCs, we do have a couple of 8-bit LRCs available. However, none of the pre-defined LRCs use a bias, initial value, and a routine to AND the result - all of which are required by this device manufacturer. As such, it will be necessary to create our own LRC using the Error Detection Code builder.
With the deciphered information from the device manufacturer, you have all that’s needed to go into an OmniServer protocol and build a custom LRC to handle the above calculation. For a detailed how-to on building the custom LRC 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 the rest of this series on designing custom EDCs in OmniServer and also other useful posts on addressing industrial automation challenges.
