Calculating the CRC32 of a File with LabVIEW

[DGardner]

Overview

This example demonstrates how to calculate the CRC32 value of a file.

Description

A short LabVIEW routine to calculate the CRC32 value on one (or more) files. Uses the same algorithm as WinZip and Microsoft's CRC305 application. Written entirely in LabVIEW, this routine calculates a 32-bit CRC value of an entire file (text or binary). This image is an example of how you can use this function as a subVI to calculate the CRC32 of a single file.

If a number of files are to be calculated together, use a shift register to feedback the CRC value into the CRC buffer control.

Requirements

LabVIEW 2012 (or compatible).

Steps to Implement or Execute Code

1. Download the appropriate MECC CRC32 VI.
   
2. Insert the VI onto the block diagram of a calling VI.
3. Connect the FilePath and CRC32Value terminals.
4. Run the program.

Additional Information or References:

---

**This document has been updated to meet the current required format for the NI Code Exchange.**

[BetaCommunityCo]

Perfect

Just what I was looking for! Thank You

[SimonH]

This VI is not only very well written but also perfect for calculating CRC values for PNG data chunks!

[CTRInsurgent]

It's not working right for me. Try CRCing "IEND", the final PNG chunk code. I keep getting 0xFFFFFFF0 when it should be 0xAE426082. Same result if I store it in a file or feed it directly from a byte array. http://www.lammertbies.nl/comm/info/crc-calculation.html gets the right result.  One problem is that the CRC buffer should probably be initialized to 0xFFFFFFFF and there are a couple oddities in the lookup code, like it ANDs against the wrong operands. Is this supposed to be the IEEE CRC-32? It looks like the right polynomial but the implementation doesn't seem to be consistent with the standard. I uploaded a correction at http://decibel.ni.com/content/docs/DOC-8411

[samapico]

Don't know what you're doing wrong, but this works fine for me. IEND returns the expected CRC, and all the files I tried as input returned the same CRC as WinRAR.

[CTRInsurgent]

Are you sure you tested the 7.1 Version? It's been so long I don't remember the specifics. I just downloaded and tested it again, and it's still broken.

[samapico]

Hmmm, I tested the 8.0 version. I didn't realize your bug fix concerned the 7.1 vi particularly... Nevermind

[RyanCheng]

Thank you for your kindly share!

It's really helpful!

[test_man]

Works as expected. Very useful VI. Thanks for your work and time.

[Nina006]

Oh, thank you very much!!! It works great!

[Optimystic]

 This was the perfect tool. Thank you!

[dnoble79]

This is very useful set of VIs which I have been using for a while now, but recently I found that I get a different CRC value when, for example, I CRC the string "abc" vs cascading the CRC of "a", then "b", then "c".

To fix this I found I had to XOR the CRCBuffer input with 0xFFFFFFFF (or just invert it using NOT) and set its default value to 0 (instead of 0xFFFFFFFF). After doing this I get the same CRC value for both cases in my example.

I also note that if you read a file with "Convert EOL" turned on (as shown in the snippet above), then this might give a different CRC than that generated by other applications.

[vgpascual]

This is a great VI! However, how do you know what are the values (True/False) of Ref In and Ref Out?