Byte Status message to user friendly cluster

[VinnyAstro]

Hi!

I would like to have an opinion from more experienced Labview-users on my solution to interpret a U8 status message received from a deviced (through a CAN message frame) to something more readeable by a user.

The byte is composed as followed (bit 0 to7):

Index found | Boot | N/A | Ctrl mode 1/2/3 (3bits, see below) | Failsafe | Error (from message frame)

Ctrl mode: 000=Power Off | 001=Mode1 | 100=Standby | 101=Vel Mode | 110=Acc Mode | 111=Torque Mode (Cases 010 and 011 unused)

What do you think of my way of dealing with it? I've benchmarked it 3 to 4µs to execute (tested 10000 times) Is there a way to improve it?

 

Thanks!

Vinny.

[crossrulz · Accepted solution]

I'm sure somebody will pick apart my benchmark, but I find it best to avoid using the Number To Boolean Array and instead use AND and Logical Shift to mask the bits you want and then shift over (or use Not Equal To Zero for the Booleans).

[VinnyAstro]

Wait, so there is a factor 100 between the 2 versions? Or am I misreading the 1.288633[s](?) vs 10.0955[ms](?)

[AeroSoul]

Tested his code and you are reading it right. The factor is somewhere between 80 - 100.

[VinnyAstro]

Yep, tested it too (10 million iterations) ^^

I technically don't need this calculation to run at 20ns (my typical coms rate will be around 10Hz 😂) but it's good to know for future projects !

Thanks!

[crossrulz]

I actually do enough unpacking of bits that I made this little malleable VI.  You just gave me an excuse to look at it a little closer to add Boolean support and handle enums better.  I have not benchmarked it.  I suspect it will be a little slower than my previous solution, but should still be faster than using the Number To Boolean Array.  The real goal with this guy was readability.

[billko]

I had no idea that was so expensive.  Do you think the Boolean Array to Number function was expensive, too?

[crossrulz]

---

@billko wrote:

I had no idea that was so expensive.  Do you think the Boolean Array to Number function was expensive, too?

---

My thought is not as expensive.  The part that makes Number To Boolean Array so expensive is the allocation of the array.  But I generally try to avoid arrays when dealing with packed data.

[mcduff]

---

@crossrulz wrote:

---

@billko wrote:

I had no idea that was so expensive.  Do you think the Boolean Array to Number function was expensive, too?

---

My thought is not as expensive.  The part that makes Number To Boolean Array so expensive is the allocation of the array.  But I generally try to avoid arrays when dealing with packed data.

---

Besides that allocation, the multiple delete from Arrays are expensive. If you remove them and use explicit indexing, you can get a factor of 2 improvement. No where near the boolean operations directly on the numbers, but better to not use delete from array unless absolutely necessary.

Edit: Removing the typecast and using array to cluster also helps. 19s to 8s to 1s. Still not as good but much closer.

EDIT #2: Get rid of array to cluster and bundle directly, now under 1 s, ~0.8. Still not as good, but better.

[billko]

Normally I use some variation of the "Number-to-Boolean" code above because I have a hard time envisioning bitwise operations and I can more easily visualize "physically" breaking out the bits and capturing them in a cluster.  I'll probably still do that where the bottleneck will always be the human, but I have time-critical stuff coming up where this information will be invaluable.