Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

12-02-2016 12:44 PM

Options

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

GHSP

Solved! Go to Solution.

Solution

Accepted by topic author aeastet

12-02-2016 01:27 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

12-02-2016 01:35 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

12-02-2016 01:38 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

Tim

GHSP

GHSP

12-02-2016 01:38 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

@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

Thank you very much for the help.

Tim

GHSP

GHSP

12-02-2016 01:59 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

Lynn

12-02-2016 02:04 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

GHSP

12-02-2016 02:32 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

12-02-2016 04:53 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

-Kevin P

12-02-2016 08:45 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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