CRC VI

[rrojas]

All,

I was wondering if an attempt had been made to make a CRC VI? It's looking like I've got to write a CRC algorithm but was hoping a VI already existed. I realize the algorithm will depend on the polynomial, so it may be too much to hope for an all-around general CRC.

Anyway, for what it's worth, the polynomial I'm working with is:

x^16 + x^15 + x^2 + 1

Thanks in advance for any help of direction you may offer.

[Barrie]

All,

I was wondering if an attempt had been made to make a CRC VI? It's looking like I've got to write a CRC algorithm but was hoping a VI already existed. I realize the algorithm will depend on the polynomial, so it may be too much to hope for an all-around general CRC.

Anyway, for what it's worth, the polynomial I'm working with is:

x^16 + x^15 + x^2 + 1

Thanks in advance for any help of direction you may offer.

3046[/snapback]

From what I've found, you're pretty much on your own. Some time ago, I was under the mistaken impression that CRC meant just one algorithm but I have learned that it is very much dependent on what you are interfacing to and what algorithm the manufacturer has chosen for "his" CRC.

Various methods can generate CRC values of 16 bits or 32 bits, some operate bitwise, using a shift register, while others operate bytewise. An then of course, there is the polynomial, as you mentioned. I suspect the decision is based on CPU intensity and programming/math skills.

I think that you would be better of to just write it, rather than trying to modify an existing VI, unless some kind soul has exactly what you need. Also, sadly, expect to write another VI when you encounter this need from another machine.

Cheers!

Barrie

[rrojas]

That's what I was afraid of. I appreciate the reply.

[Louis Manfredi]

Hi Rojas:

I think I got a CRC routine kicking around somewheres-- give me a day to look for it before you waste the time duplicating the work.

Best Regards, Lou

[Michael Aivaliotis]

Here are two examples I scoured from the internet...

Download File:post-2-1103178246.vi

Download File:post-2-1103178263.vi

[Louis Manfredi]

Here's yet another CRC routine. Seems to give different outputs from the ones Michael found. But it might be of some use.

I extracted it from a more complex set of comm. vi's that include byte stuffing for eight bit data transmission, multiport near-simultaneous message transmission, & a variety of other features unrelated to the question at hand.

Best Regards & good luck, Louis

Download File:post-1144-1103205210.vi

[rrojas]

Thanks a lot, guys. I will check these VIs out!

[tetrarch]

Here's an "all-round general" VI for CRC calculation. The polynomial needs to be translated from equation form into numeric representation - one bit per power of X. In your case:

x^16 + x^15 + x^2 + 1

so that's something like 1 1000 0000 0000 0101 in binary (or 18005 hex).

No guarantees that this works (I put it together a while ago for a quick data check, and didn't need it to conform exactly to the CRC standards), but it should give you a starting point. Search for "CRC polynomial" and you should be able to get more information about how things are calculated.

PS. Many CRC implementations also have a starting value (often 0xFFFF for 16-bit, or 0xFFFFFFFF for 32-bit) and a final XOR value (again, 0xFFFF is common).

Download File:post-607-1103278851.vi

[rrojas]

Here's yet another CRC routine.  Seems to give different outputs from the ones Michael found.  But it might be of some use.

I extracted it from a more complex set of comm. vi's that include byte stuffing for eight bit data transmission, multiport near-simultaneous message transmission, & a variety of other features unrelated to the question at hand.

Best Regards & good luck, Louis

3058[/snapback]

Could you describe what's going on in the block diagram for me?

[Louis Manfredi]

Could you describe what's going on in the block diagram for me?

3087[/snapback]

Hi Rrojas:

As I said in the comment on the front panel, I translated this routine from a C routine written for the equipment I was talking to and ---Mea Culpa--- The rest of the story is that when I made the translation I understood the algorithm only partially, and documented it even less. (The routine was a small part of the project, it works, so I moved on to other issues which were more troublesome.)

As I understand it, the lookup table is equivalent to some of the calculations which appear in the classical methods, but takes less time. There was a time when that was an issue, and I suppose if you are running a really fast comm. channel, it might still be an issue. I seem to recall that the reference my colleauge got the routine from described how to change the lookup table to match different types of CRCs. I'll see if I have a copy of the reference anywhere-- might be Monday before I get a chance to look. If I can't find the reference I'm sure the colleauge who wrote the C code has a copy & I've been meaning to get in touch with him anyhow, so I'll check with him if need be.

Just goes to show, there's no such thing as a self documenting programming language, is there?

Best regards, Lou

[David Boyd]

Well, I was going to tack on a VI that I first wrote around 1998 (and have re-written over the years for differing instruments which implement CRC's in their protocols- Siemens ELAN, Tescom, etc.)

But there are already a number of other candidates submitted, so you should be well on your way.

Here's a link full of interesting reading - it suggests that the more common implementations of the CRC-CCITT algorithm out there (including one I wrote) are in fact erroneous. Sort of a moot point, since the devices I'm talking to use a compatible algorithm, but worth looking at nonetheless:

Discussion of CRC-CCITT

Best regards,

Dave

Edit:

Since I downloaded the other VIs, and found they differ from each other and from the most recent copy I have, I decided to post mine too. All I know about my own version is:

- it works with the Tescom ER3000's implementation of CRC-CCITT (whoo-hoo!)

- it faithfully matches the 'Bad_CRC' example given in the above link (which seems to be in common use);

- it's semi-documented.

Download File:post-195-1103327346.vi

[Louis Manfredi]

Hi Rrojas:

Hi Rrojas:

I'll see if I have a copy of the reference anywhere-- might be Monday before I get a chance to look. 

3094[/snapback]

Here's the promised link, As I thought, the lookup table method is motivated by efficiency- see section 9 of the following reference:

ftp://ftp.rocksoft.com/papers/crc_v3.txt (too make things clear, thats crc-underscore-v3.txt)

Hope this helps, & Best Regards, Louis

[rrojas]

Hi Rrojas:

As I said in the comment on the front panel, I translated this routine from a C routine written for the equipment I was talking to and ---Mea Culpa---   The rest of the story is that when I made the translation I understood the algorithm only partially, and documented it even less.  (The routine was a small part of the project, it works, so I moved on to other issues which were more troublesome.)

As I understand it, the lookup table is equivalent to some of the calculations which appear in the classical methods, but takes less time.  There was a time when that was an issue, and I suppose if you are running a really fast comm. channel, it might still be an issue.  I seem to recall that the reference my colleauge got the routine from described how to change the lookup table to match different types of CRCs.  I'll see if I have a copy of the reference anywhere-- might be Monday before I get a chance to look.  If I can't find the reference I'm sure the colleauge who wrote the C code has a copy & I've been meaning to get in touch with him anyhow, so I'll check with him if need be.

Just goes to show, there's no such thing as a self documenting programming language, is there?

Best regards, Lou

3094[/snapback]

Much thanks. Yeah, the problem I was having was trying to match the CRC the VI was giving to a CRC generator written in C by a co-worker. There were complications stemming from the fact that his algorithm was assuming 16-bit words as opposed to the VI's byte-based cycles. Plus, he was running his code on a big-endian processor whereas I was running his code on my PC (little-endian) so there was byte-order switching going on that the VI didn't have to deal with.

I finally got the VI to output the same CRC the C code was giving after figuring out what the VI was doing.

Thanks for all the help and example VIs, though. Very useful. :thumbup:

[ConawayNY]

I was looking for CRC stuff myself recently. Go to NI, developer section and do a search for CRC. I found between 5 and 8 algorithms / implementations (some may be repeats) as well as a RTF file that explains the whole bit shifting process and (possibly) how it is simplified in SW using a byte wide lookup table. search read enjoy

[Rolf Kalbermatter]

I was looking for CRC stuff myself recently. Go to NI, developer section and do a search for CRC. I found  between 5 and 8 algorithms / implementations (some may be repeats) as well as a RTF file that explains the whole bit shifting process and (possibly) how it is simplified in SW using a byte wide lookup table. search read enjoy

4403[/snapback]

Possibly one more CRC algorithme is in the lvzip package in the OpenG Toolkit. It is used to calculate a 16 bit CCITT CRC for the implementation of the Mac Binary format. Not sure about the correctness in terms of CRC theory of this but it seems to do, what the Mac Binary format requires, whatever that is. Other CRC algorithmes might be found on the Info-LabVIEW archives http://www.info-labview.org/the-archives

Rolf Kalbermatter

[Rolf Kalbermatter]

Much thanks. Yeah, the problem I was having was trying to match the CRC the VI was giving to a CRC generator written in C by a co-worker. There were complications stemming from the fact that his algorithm was assuming 16-bit words as opposed to the VI's byte-based cycles. Plus, he was running his code on a big-endian processor whereas I was running his code on my PC (little-endian) so there was byte-order switching going on that the VI didn't have to deal with.

I finally got the VI to output the same CRC the C code was giving after figuring out what the VI was doing.

Thanks for all the help and example VIs, though. Very useful.   :thumbup:

3114[/snapback]

If the C code has Endianess problems in itself I wouldn't trust it at all. It would indicate that the code was developed rather in trial and error methods, than by clearly understanding what the algorithme should do.

Rolf Kalbermatter

[m3nth]

I know this post is old and I don't have time to look at the other files posted. Just wanted to say though that I implemented the standard CRC32 routine in LabVIEW awhile ago, which is the one used in WinZIP type archivers (if you open up the CRC column for the files in the options menu). It is also used in tcp/ip networking I believe... it may be the CCITT flavor but I can't remember, just that it was THE CRC standard that everything used. I don't have the file available at the moment but wanted to post that if you'd like a copy of my code you can message me.

[Rolf Kalbermatter]

The newest LVZIP package on OpenG, which is to be released shortly does contain the CRC32 algorithme and makes it available as a user accessible function. It's implementation is in the underlying shared library and is used to calculate the CRC for the generated ZIP files.

Currently it already works for Windows and Linux86 and we are waiting for a compilation of the shared library for Mac OS X, which should be done shortly, at which time the package will be officially released.

LabVIEW for Windows and Linux users familiar with sourceforge can get the current CVS version from LVZIP @ sourceforge in the "source"directory to check it out.

Rolf Kalbermatter