LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Need help with this VI

Solved!
Go to solution

I have this VI which calculates CRC for SPI communication. Someone provided a formula node to calculate CRC. The system has been upgrade so now the formula node is my choke point. I need to convert this to a VI so it will run faster. Can anyone help with this?

 

I have tried a few different things but none of them give me the correct answer.

 

Tim
GHSP
0 Kudos
Message 1 of 11
(3,433 Views)
Solution
Accepted by aeastet

Here.  There are probably some optimizations available, but here's both a literal translation of the logic and a slight tweak to give you a starting point to explore benchmarking with different bit-manipulation functions.

 

 

-Kevin P

 

u8_crc.png

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 11
(3,399 Views)

With code very similar to Kevin's I found that the speed is dependent on the size of the message. For small messages the formula node is faster. With messages of 255 elements the native code is almost 10 times faster. With messages longer than 255 elements the formula node hangs. (Loop counters i and j are U8).

 

Lynn

0 Kudos
Message 3 of 11
(3,392 Views)

THe messages should be around 85 so I think we are good for now.

Tim
GHSP
0 Kudos
Message 4 of 11
(3,390 Views)

@Kevin_Price wrote:

Here.  There are probably some optimizations available, but here's both a literal translation of the logic and a slight tweak to give you a starting point to explore benchmarking with different bit-manipulation functions.

 

 

-Kevin P

 

u8_crc.png


Thank you very much for the help.

Tim
GHSP
0 Kudos
Message 5 of 11
(3,389 Views)

At a message length of 85 I find the native LV code about 3 times faster than the formula node.

 

Lynn

 

Speed test.png

Message 6 of 11
(3,360 Views)

That is good to know. My time to complete my generate command, write, read, check for error and store data is about 5 msec. and I would like to have a little time left. Right now witht eh CRC turned on witht he formula node I am seeing prcess times of around 8-10 msec. This will help greatly. I am sure that I will have to still find more places to get the extra loop process time I need, but this was my biggest problem.

Tim
GHSP
0 Kudos
Message 7 of 11
(3,354 Views)

Turn that inner loop into a lookup table (array constant) since there are only 256 possible values.

Message 8 of 11
(3,336 Views)

I'll second Darin.K 's suggestion to use a U8 array constant as a lookup table.

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 9 of 11
(3,308 Views)

The LUT version runs in less than half the time of the nested for loop version for 85 element message and four times faster for 255 elements.

 

Lynn

0 Kudos
Message 10 of 11
(3,285 Views)