CRC-CCITT

[Toro]

I have all ready search the db and several CRC16 info files and VI's I have try the VI's but there seem to be for the CRC16 only and not for the CRC-CCITT that uses polinomial X^16 + X^12 + X^5 + 1.
I have try to make a vi that will do this using the CRC16 vi's as sample guide to make the CRC-CCITT but I get the wrong answer. I am having difficulty understanding how to translate the polinomial to a graphical working of the CRC-CCITT.

[shoneill]

Hi,

I just had the very same problem myself. Turns out that my C code description which I tried to translate into LabVIEW was simply wrong.

This VI doesn`t use polynomials, but it DOES calculate the CCIT CRC16.

Hope it helps.

Shane.

[Toro]

Thanks for your respond.
I downloaded your vi and try it.
I am a bit confuse I try and enter ASCII hex 1 FF 6 285D and give me an aswear of 1EC9. I know the answer for this should be B3AB from a excell file that generates CRC16-CCITT.
Should this answers be the same or there are going to be a different do to the type of programs creating the CRC16-CCITT value.

[shoneill]

I can`t test the Excel file as the functions "hex2dec" and "dec2hex" arent included.

Looking at the CRC code, you`re computing a different number. It`s logical that the results are different, as the code is also different.

As to which "CRC16-CCITT" is correct, I don`t know, but I`ve been trying to get an instrument working which demands a "CRC16-CCITT" Checksum, and it works only with my version.

There seem to be hundreds of opinions as to what`s correct.....

Shane.

Shane.

[waldemar.hersacher]

Hi Shane and Toro,

I started implementing some CRC VIs and collected some of them during discussions here which people send me as they have found some of them.

During this there seems to be a problem with the CCITT-CRC16 algorithm. I currently do not have any access to the original document from CCITT so cannot tell which will be the right VI. I have two versions all stating to implement CCITT-CRC16 but they have different pre- and post conditions. All of them use a lookup table and I dont know which polynom they implement.

Toro:
I have downloded your VI but I'm missing a subVI named bitshift. Your VI initializes two local variables but there is no dependency that this will happen before the execution of the while loop.


Shane:
I have compared your VI to one I have and it will give the same result. Your solution is the solution which represents a hardware implementation. You are clocking in each bit in two stages (outer loop for each byte inner loop for each bit of the byte) and making the exor operation. The constant (0x1021) are the coefficients of the polynom. The U16 shift registers are representing a 16 bit wide HW shift register. The solution I have works with a lookup table. The difference will be the time the VIs will run yours have to go 8*n times, mine only n times through the exoring operation.

Send a email to buero@hersacher.de if you are interested in the VIs I have.

Do you have any problems if I will distribute your VI together with the collection I already have?

Waldemar

[Toro]

Waldemar.
I sended you an e-mail explaining what I need to achive. I try to use another CRC16-CCITT that I found in the LabView search library. Since I was not getting the same answear that I thoug I should get I try to modified. The VI I found does said the polynomial used to come up with it. I know there are two types of polynomial usage hardware and software. I think there is were I am confuse I think I may be expecting the same result from a different usage. When I saw Shane's VI I notice my confusion. I have been trying to do both usages in one, I think! But should both usages come out with the same aswear?.Note: the bit shift was from another CRC16 that I got from the search in LabView.

[waldemar.hersacher]

Toro,

I do this support at home but have some of the information in the office.

From another track someone was talking to a Knick 73 instrument. From the documentation I see it uses a CRC CCITT-X.25 builded with the following conditions:
Precondition is set to 0.
Polynom is x^16+x^12+x^5+1
Postcondition is not inverting

From your mail I see you need:
Precondition is set to 0xFFFF
Polynom is x^16+x^12+x^5+1
Postcondition is inverting

Since the VI from Shane and the one which works with the Knick instrument calculate the same CRC it has the right polynom. Modify the VI in the following manner:
There is a constant labeled CRC16 which goes to the shift register of the outer loop. This is the precon
dition. Change this to 0xFFFF.
The other side is the CRC. Insert a boolean invert before the branch to the indicator and type cast.

Another optimization you can do is to move the Build array which is located in the outer loop before the outer loop and use a tunnel with indexing disabled. I don't know if the optimizer of LabVIEW will see that the array is constant with each iteration of the outer for loop. This is even another variant part in CRC calulation. This array hold the power of 2 numbers in decreasing order. You can also do this in increasing order.

For your understanding:
CRC is not a byte stream it is a bit stream calculation. Mathematically is does not operate on bytes it operates on bits. Therefore you have to define which bit of a byte you have to process first.

I think the modified VI will calculate the right CRC.

Thanks to my ISR providing a web interface to my mailbox so I can reach it from the office.

Waldemar

[shoneill]

Hi Waldemar,

The thing with the Knick instrument seems to be in the same direction as my application. I`m communicating with a WTW conductivity meter.

The problem was a code snippet which was deliverd with the meter showing how to calculate the CRC. As far as I can see, this code was quite simply wrong (see my original post).

I had quite a lot of trouble finding the correct CRC procedure. I tried ModBUS CRC routines, other routines which gave the same result as that listed by WTW, until finally I found an old version of CCITT X.25 protocol in some language I wasn`t familiar with (but could read).

I`m glad to hear it`s working for others too (I thought I was going insane trying to get it to work).
If you want to add it to your collection I see no reason why not. I tried a little to understand the mathematics behind it, and found a few good sources, but it`s been too long since I did that kind of thing. This must be how it feels getting old......

Thanks for your help again, and for the reassurance that the version works. Regarding the implementation of my routine, it was re-written several times trying to find the problem (which didn`t lie with my code). There are certainly more efficient methods, but my messages to check are max 65 bytes, and only 3Hz frequency. Performance isn`t exactly an issue....

Shane

[Dr._Imad]

Attached is my version of the CRC 16 (not the CCITT). It works correctly on an instrument with a modus bus link

[waldemar.hersacher]

Hi Shane,

I expanded your VI to have all variations doing CRC calculation. This took me about two and a half hours and I found that your VI and two other which where sended to me do the same calculation and all say they do a CCITT X.25 CRC calculation.

The one I implemented from a book about networking uses the same polynom but does all the other things in a different way. Precondition, postcondition, bit order for input, bitorder of the CRC. This one was stated to be CCITT CRC calculation (not explicitly mentioning X.25).

Now I though I have a universal CRC Calculator was happy at 23:15 and saw the reply from Dr. Imad. Modbus must do something different, I cannot calculate the s
ame CRC with the CCITT VI. At this time I didn't start analyzing his VI against yours. Maybe I will have time next week to do it.

Waldemar