Split U32 to Bits

[therealkilkenny]

Hi All,

I'm not really understanding the whole business with bits and int's etc so you'll have to bear with me. I tried to understand other posts but to no avail.

I have a U32 being returned from a dll. The first 2 bits are reserved, the next bit is measurement taken (yes/no)?, the next bit is distance measured (yes/no)?, the next 12 bits is the amplitude measurement, and the next 16 is the distance measurement. I have tried to do something and i've attached it. I'm getting the right values but i don't think its very efficient (and i need it to be) and i can't seperate out bits 3 and 4. I want a 0/1 for bit 3, a 0/1 for bit 4, a number for bits 5-16, and another number for bits 17-32. The value in is is a real one.

Any help greatly appreciated.

Phil

[johnsold]

Phil,

The boolean functions can be used with numeric inputs. AND and logical shift along with Split Number (Numeric >> Data Manipulation) will do the job.

Lynn

[Been bitten by LabVIEW]

I couldn't look at your VI as I am running only 7.0, but unless LabVIEW 8.4 has bitwise operators implemented, what I have attached should be about as fast as you can get unless you take my subVI (GetBits.vi) and expand it directly into the main VI (Extract Bits.vi).  It uses 3 integer subtractions and 2 bit shifts.

If you really want to go faster, you should consider a different language like C or complain to National Instruments to add such features.  However, using a bitwise and would not allow for a generic function.  But if speed is what you are after then that is irrelevant.  Under the hood, I'm not sure if LabVIEW is really geared for high speed processing using low speed computers anyway.  If that is what you want, go to C/C++.


Adrian

[Been bitten by LabVIEW]

Oops, forgot to attach the file.


Adrian

[RavensFan]

Here is a screen shot of Lynn's code.  If I had my preference, I would use the method going into Amplitude and Distance indicators, as opposed to the method going into the Amplitude2 and Distance2 indicators.  I wouldn't do any of the original code as shown in the top with the string conversion, data formatting manipulation.

Message Edited by Ravens Fan on 10-03-2007 04:47 PM

[Been bitten by LabVIEW]

Looks like the and/ors are polymorphs.  Good to know.

Those icons in the top right are not familiar to me.  They new in 8.x?


Adrian

[therealkilkenny]

Hi All,

Thanks for that. Just out of interest and in terms of figuring out which is the fastest method of executing it i've attached a vi comparing the three methods. The fastest seems to be the Amplitude and Distance method, narrowly followed by Amlitude2 and Distance2, closely followed by Adrians method. I've attached the Vi - it's 8.2 - sorry Adrian. Perhaps i have unfairly given one method an advantage.

Let me know what you think,

Phil

[Been bitten by LabVIEW]

Hey, benchmarks don't lie. (Though I can't see them since I'm stuck right now with 7.0. *snif*).

I'm new to labVIEW so I'm still working out how things work in it.  What I used was a generic solution which is undoubtly a slower one.


Adrian

[rolfk]

---

Been bitten by LabVIEW wrote: I couldn't look at your VI as I am running only 7.0, but unless LabVIEW 8.4 has bitwise operators implemented, what I have attached should be about as fast as you can get unless you take my subVI (GetBits.vi) and expand it directly into the main VI (Extract Bits.vi).  It uses 3 integer subtractions and 2 bit shifts. If you really want to go faster, you should consider a different language like C or complain to National Instruments to add such features.  However, using a bitwise and would not allow for a generic function.  But if speed is what you are after then that is irrelevant.  Under the hood, I'm not sure if LabVIEW is really geared for high speed processing using low speed computers anyway.  If that is what you want, go to C/C++.

---

No need to complain. Boolean logic is there and at least as good as C and even more versatile. Maybe that C++ offers some more esoteric bit operators but I'm not sure I want to know them.

If you really want to do high speed bit crunching then yes LabVIEW is not the best tool to use. Dealing with bit operations requires a very specific knowledge of the problem, is always a tricky business independant of the environment you use and that all contrasts strongly with the ease of use of LabVIEW in other areas. And with LabVIEW not creating highly optimized machine code, it will always be slower than when you do the same in C and set the compiler to maximum machine code optimization (crossing the fingers that the C compiler does not create buggy optimizations).

But that has to be weighted with the much easier realtime debugging capabilities of LabVIEW that can make developing bit operations still easier than doing the same in C(++) with 100rds of iterations through {recompile, build, start, debug, (crash), edit} cycles.

[rolfk]

---

@therealkilkenny wrote:
Hi All,

Thanks for that. Just out of interest and in terms of figuring out which is the fastest method of executing it i've attached a vi comparing the three methods. The fastest seems to be the Amplitude and Distance method, narrowly followed by Amlitude2 and Distance2, closely followed by Adrians method. I've attached the Vi - it's 8.2 - sorry Adrian. Perhaps i have unfairly given one method an advantage.

Let me know what you think,

Phil

---

I think your benchmarkings are fairly accurate. The polymorphic use of AND and OR on numbers is supposedly about as fast as you can get without using esoteric machine code optimization that LabVIEW does not and IMHO should not even attempt to do. Bit operations are definitely not the main use area of LabVIEW and optimizing that is a theoretical problem of its own. I rather would see the LabVIEW programmers spend their time on more productive areas than that.

PS: The VIs you attached are really 8.5 format.

Rolf Kalbermatter

Message Edited by rolfk on 10-04-2007 09:00 AM