Example Code

Calculating the CRC32 of a File with LabVIEW

Code and Documents

Attachment

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.

 

SingleFileSubVICall.png

 

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

 

MultiplefileSubVIcall.png

 

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:

 

Calculating the CRC32 of a File with LabVIEW FP.png

 

Calculating the CRC32 of a File with LabVIEW sn.png


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

Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.

Comments
BetaCommunityCo
Member
Member
on

Perfect

Just what I was looking for! Thank You

SimonH
NI Employee (retired)
on

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

CTRInsurgent
Member
Member
on

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
Member
Member
on

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
Member
Member
on

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
Member
Member
on

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

RyanCheng
Member
Member
on

Thank you for your kindly share!

It's really helpful!

test_man
Active Participant
Active Participant
on

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

Thanks.
CVI 2010
LabVIEW 2011 SP1
Vision Builder AI 2011 SP1
Nina006
Member
Member
on

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

Optimystic
Member
Member
on

 This was the perfect tool. Thank you!

dnoble79
Member
Member
on

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
Member
Member
on

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