LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
manu.NET

Graphical SET/GET BIT ...

Status: New

Hello,

 

It should be nice to have graphical tools toGET or SET a bit in an integer. (I8 , U8, I16, U16 ... ) 

 

Today it is possible to Set / Get bits with "Bitwise operators and, or ..." integer to boolean array, boolean array to integer ...

But i think this is a "C like programming way"Smiley Sad, not a LabVIEW graphical way.Smiley Wink

 

It should be interresting to GET the value of a bit using something like ...

  • A special unbundle
  • A tools like an index array

It should be interresting to SET the value of a bit using something like ...

  • A special bundle
  • A tools like a replace array subset

It should also be interresting to get / set a bit of an integer in a "Inplace structure"

 

I think this idea could clarify the way to access Bits in Labview ... and clarify the readability of a block diagrams.Smiley Surprised

In place of using integer masks, integer to boolean array, and , or, XOR ... the set bit / get bit could be more userfriendly.

 

I think that this idea could also be usefull in LabVIEW FPGA.

 

Manu.net

 

 

Manu.net
6 Comments
Mr.Mike
NI Employee (retired)

What about a  VI to get or set bits?  You could make a poly VI for getting and a poly VI for getting: just pass the index or indicies of the bits (as an array) you want to get or set.  You can do it in a bunch of relatively simple VIs.  The only problem is the fact that there are 8 types 2 operations can be done on.  If you allow arrays of indicies, then there are twice as many again.  That results in 32 VIs.

 

So, yes it could be done with a new node, but I really think it'd be a lot easier with two poly VIs with a number of pretty simple VIs.  Maybe someone who reads this will put it together and put it on the developer community?

-- Mike
manu.NET
Active Participant

Hello Mr. Mike,

 

I know very well how to create subvis, polymorphic subvis ... etc ...

 

The aim of my idea is to give to all LabVIEW users (not only me) a way to create userfriendly set/get graphical tools.

 

I thought that LabVIEW/Ideas was done for this ! 

 

Most ideas published can be solved by a user development ... my idea is only here to make LabVIEW better.

 

Manu.net

Manu.net
crossrulz
Knight of NI

I too had to make my own subVI for this.  I am willing to bet that NI can make a much more efficient primitive than any subVI we can make.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Mr.Mike
NI Employee (retired)

@manu.NET wrote:
 

The aim of my idea is to give to all LabVIEW users (not only me) a way to create userfriendly set/get graphical tools.

 

I thought that LabVIEW/Ideas was done for this ! 

 


To the first: that's why I suggested it be put on the developer community
To the second: Yes, the LabVIEW Idea Exchange is for submitting your ideas, but not all of the submitted ideas can be implemented.  In cases where they can be solved more easily with other means, we'll probably suggest that, unless of course the idea gets overwhelming support from other members of the NI community (into the hundreds of kudos)

@crossrulz wrote:
I am willing to bet that NI can make a much more efficient primitive than any subVI we can make

Yes, NI can probably make a more efficient primitive than any sub VI.  Much more efficient?  I doubt it.  Setting a bit is a few basic operations which (I'm pretty sure) get compiled down directly to machine instructions (shift, and, or, xor).  Getting a bit is the same.  Clearing the bit should be the same.  If you inline it, it'll be really fast.  I wouldn't be surprised if it were as fast as using a primitive.

 

Creating a new primitive is actually a bit expensive for NI (it involves someone to write the code, some one to review the code, someone to document it, and someone to run tests on it), so we're hesitant to add primitives where the result can be performed with existing code.  Additionally, we've been trying hard to keep the commonly used palettes from growing.

 

 

- Mike

-- Mike
Mr.Mike
NI Employee (retired)

So, I've got this implemented just not documented.  Right now I can run about 300,000,000 to 900,000,000 SETs or GETs per second (averaging around 400,000,000) for all integral types except 64 bit.  For I64 and U64I can only get about 12,000,000 per second.

 

Right now I've got two poly VIs: Read Bit and Change Bit.  I also made two more: Set Bit (make the bit true) and Clear Bit (make it false).  Clear Bit isn't any faster, but Set Bit is about 2% faster.  Since it's such a small increase, I don't think I'll include them because the library is already full enough with 17 Change and 17 Read VIs.

 

I'll try and post it on the NI dev community later today or Monday.  Hopefully this should provide a good, common soution to the resolve this request on the idea exchange since I'm not optomistic NI choosing to implement this.

 

(Just FYI: all these numbers are informal tests under loose condiitons.  YMMV)

Bits.png

-- Mike
Mr.Mike
NI Employee (retired)

I've posted my library on the NI Developer Community.

 

Check it out.  See if you can make it go faster.

 

(Oh, and the problem with the 64 bit sets and gets was that I forgot to mark those as inline...so they get the same 300-900M sets per second).

-- Mike