Boolean logic : Enabling & Disabling Bit

[dangeross]

I just put in the loop for testing and will remove it once I'm done hacking on it. It seems that LabVIEW doesn't care about labels so I used duplicate names because I was lazy I will probably change to Set 0 & Clear 0. Either Set or Clear will have to take precedence when working with an input byte that is to be modified so I just chose Set for now, but depending on the application Clear could be made to take precedence. What are the pink Clear Bits and Set Bits blocks and the yellow blocks immediately to the right of them. Coming from the PLC word I am used to User Defined Function blocks being able to take a large number of connections and still being easy to connect to. Schneider Electric even has a C Code function block toolkit that I used back in the day to write a 32bit fixed point square root function for a i386EX based controller that would take 2ms for every floating point multiply and more for divides and other operations.

[dangeross]

I am thinking of have just a 8 bit version and then using Flatten To String Function and Join Numbers to make 16, 32, and 64 bit versions as need. I took a quick look at the Malleable vi type and the way to use them for this doesn't jump out at me.

[altenbach]

Having duplicate labels is an extremely bad habit. If you want them to show the same text on the front panel, use the caption instead. The name on the diagram should be unique, you could use Sbit# and Cbit#, for example. Once you have duplicate labels and need to use local variables, things get confusing fast if more than one terminal has the same label.

These are just clusters. Instead of clear/set, you could implement a "toggle" if that is a more useful functions. Would be quite simple.

A malleable VI will adapt to the integer type you wire to it (this happens at edit time and the correct code is used, depending on what's wired and how the type specialization is implemented)

Here's my earlier VI. (as I said, you should use arrays instead of clusters, of course!)

[dangeross]

As I said the duplicate labels were just being lazy while I hack on this. I don't think the cluster approach will work for me I need to be able to wire the boolean controls to other parts of the vi. This is probably what I need for my use now. I haven't connected any switch inputs but you can get an idea of the intended usage the numeric inputs and outputs would also normal come from and go to inputs and outputs of some external devices.

[altenbach]

You reverted back to posting in LabVIEW 2024 and I cannot look at your VIs.

In the meantime, here's a simple demo that calls a VIM that supports:

1. all integer types
2. modes: set/clear/toggle
3. an array of bit positions.

Seems more scalable than herding all these cats boolean terminals.

[dangeross]

I keep forgetting to saving back to a previous version, I do the same thing in AutoCad. The vim has me a little confused.

The subtraction block should result should always be 0 if  x = y then x - y = 0 and the increment block x result will always be 1 if x = 0. The Voodoo of LabView For Loops running without any value of N took a minute to figure out the auto-indexing with an array input behavior. I think I am stuck dealing with a Clowder since I need to be able to wire the different boolean terminals from different parts of the vi using the subvi.

[altenbach]

---

@dangeross wrote:

The subtraction block should result should always be 0

---

Of course it does! For a vim we need to make sure the zero is in the correct datatype, i.e. same as the input. (we could of course just use a U8 zero and have it coerce as needed).

---

@dangeross wrote:

I think I am stuck dealing with a Clowder since I need to be able to wire the different boolean terminals from different parts of the vi using the subvi.

---

No, you are not! It is just not scalable with 8 scalar boolean terminals. What will you do if you need 32 booleans in the future? You could easily create an array of indices from your scattered booleans to be used as input to my VI.

[altenbach]

---

@dangeross wrote:

I keep forgetting to saving back to a previous version,

---

While I still think you are complicating things with your approach, here are some quick comments:

In your set byte subVI, you should change the output configuration of array to number to U8.

In your clear subVI, I can think of code with much less duplication:

[dangeross]

I'll have to take a look at using an array to input to your VI. I am very new to LabVIEW and think I just passed the 4 hour mark today.

[dangeross]

Part of my problem is that I started out in programming watching my Father hand write machine code for a RCA 1802 and then starting myself programming Zilog Z8 microprocessors in Assembly. I naturally think of AND, OR, etc as single bit operations so I don't immediately think of the Polymorphic nature of LabVIEWs logic functions.