LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Disable property node is not been updated continuously

Solved!
Go to solution
Highlighted

Hello everybody.

 

I've set the disabled property node of my dialog boolean boxes and string controls to enable and disable in my code.

 

The main idea: I have 16 dialog boolean boxes and 16 string controls. I want to set every dialog boolean box and string control to be enabled only after the previous dialog boolean boxes and string controls had been set (for example, the dialog boolean box and string control number 3 will be enabled only after I've checked the dialog boolean box number 1 and 2. until then, the dialog boolean box and string control will be disabled and grayed).

 

I use the Disabled property node of the dialog boolean box and string control in order to do that.

 

My problem is that the dialog boolean box and string control is been changed to enable only when I stop the LabVIEW running and start it again. It doesn't update the property node to be enabled while the LabVIEW is running.

 

I want it to be updated continuously while the LabVIEW is running without needing to stop and start the continuous run every time.

 

 

Do you know how do I do that?

 

 

Thanks,

Reshef

0 Kudos
Message 1 of 6
(212 Views)
Solution
Accepted by topic author resheffink

First, put a wait function in that VI so that it isn't burning up your CPU.

 

The problem is you have a case of "localitis".  Why are you using local variables of your booleans to control the enable/disable rather than the wire coming from the boolean terminal itself?

 

Even despite all that, your VI worked okay for me once I deleted the missing subVI.

0 Kudos
Message 2 of 6
(190 Views)

What is the missing vi doing? Are you able to stop the vi with the Stop button or are you using the Abort button in the toolbar? It also worked for me when I delete the missing vi. I suspect that your real problem is that the program is getting stuck in the missing vi.

0 Kudos
Message 3 of 6
(177 Views)

Hi.

 

It's now working for me as well. I don't know why it didn't work before but everything works fine now.

 

Thanks anyway for all the help!!

0 Kudos
Message 4 of 6
(112 Views)

@resheffink wrote:

 

It's now working for me as well. I don't know why it didn't work before but everything works fine now.


Unless you fixed all the mentioned race conditions, i is NOT fine, because the problem can occur again at any time. Your code is not safe.

 

  • Get rid of all local variables, none are needed.
  • Building all controls into arrays would reduce the code to less than 10% of the current complexity. Don't do all these duplicate operations!
  • What does the subVI do?
  • Why do you need so many identical enum diagram constants? One each is sufficient. You can branch the wire.
  • Property nodes only need to be written if the input changes, and not with every iteration of the loop.

Can you describe in a few words how the code is supposed to behave?


LabVIEW Champion. It all comes together in GCentral GCentral
0 Kudos
Message 5 of 6
(92 Views)

Following my suggestions above, here's a simplified version for four items. You can easily expand it to any number of items by just increasing the arrays accordingly. No other change in code needed. This is called scalability! Notice that there is no longer any duplicate code or local variables!

 

See if this can give you some ideas. Good luck!

 

(As I said, further optimizations are required. For example the lower FOR loop only needs to execute whenever the boolean array changes, so place it inside a case structure. Not shown)

 

DisableUp.png


LabVIEW Champion. It all comes together in GCentral GCentral
0 Kudos
Message 6 of 6
(76 Views)