Is it possible to create local variables for color boxes?

[stubbsy90]

Hi all,

I am using color boxes to represent multicolored LEDs and really need to be able to create local variables for them when using them in state machines? When I do this it does not work. All help is much appreciated. 

Cheers 

[Michael_78]

Hi,

I have just tried using local variables with colour boxes, and it works OK.  Remember you cannot create a local variable from a block diagram constant. If you are having problems, post some code so we can have a look.

Good luck,

Michael.

[aeastet]

Why are you not just using a boolean indicator and changing it's color?

[Michael_78]

Because you only get two colours?

[aeastet]

You can change the color of a boolean indicator using the property node very easily.

[Michael_78]

Yes, but you can write to the terminal of a colour box indicator directly, without using a property node. Updating indicators using property nodes is generally considered 'not good' practice and should be avoided where possible.  Either way, I think the question of local variables with the colour box is still unanswered as they would still be required to update the property node.  Of course, it may be better to avoid locals altogether, but without seeing the code it is difficult to comment.

[smercurio_fc]

You have some misconceptions:

---

@RiversDaddy wrote:

Updating indicators using property nodes is generally considered 'not good' practice and should be avoided where possible. 

---

Says who? There are advantages and disadvantages, and the method is "appropriate" depending on the situation. Using a property node gets you the advantage of providing error I/O that you can use to eliminate race conditions. Using property nodes gives you the disadvantage that it makes a thread swap to the user interface thread, so updating by means of a property node is slower than a local variable. This does not mean that property nodes should be avoided, since I would hazard to say that in the vast majority of cases that slowdown is probably inconsequential. Do I have metrics for this? No, just observation from a lot of years of programming in LabVIEW.

---

Either way, I think the question of local variables with the colour box is still unanswered as they would still be required to update the property node. 

---

What do the local variables have to do with using the property node?

---

Of course, it may be better to avoid locals altogether, but without seeing the code it is difficult to comment.

---

This is highly debatable in general. I for one, have no problems using local variables, but that's because I know how to use them, and I know how to identify and avoid race conditions. Local variabls are simply abused/misused by newbies. That does not mean that it is "better to avoid locals alltogether". If for one, would never advocate this.

[Ray.R]

Since it is a State Machine, why not use shift registers and wire the color you want to them in one state and display them in another.

You can use the color box without the property node or the use of Locals.

If you dislike the wires at the top (or bottom) then a single wire for a cluster will do the trick.

[Michael_78]

Smercurio,

Please don't quote me incorrectly.

I did not say it is best to avoid property nodes, i said it is generally better to avoid updating value of an indicator with a property node where possible!   The method is "appropriate" depending on the situation, but can we take a guess that in this situation it is probably not the best method?

I did not say "better to avoid locals altogether" I said "may be better to avoid locals altogether". Well, it may be in this case, or it may not. I don't know. Do you, without seeing the code?

Do you have any answer to the original question?

Michael.

[Ray.R]

---

RiversDaddy wrote:

I did not say "better to avoid locals altogether" I said "may be better to avoid locals altogether". Well, it may be in this case, or it may not. I don't know. Do you, without seeing the code?

---

Michael,

I support you.  Let's not use Locals...  😉

Let's upset Sheldon.  😄