Programaticaly change boolian local variable

[The_Big_Lebowski]

Hello All,

I ran into something today I have never dealt with in Labview...

I downloaded an instrument driver for a power supply, and got that working OK (using VISA over USB communication).

The driver example program itself works fine, and is a quasi state machine.  It turns it on and off and adjusts voltage and current properly, as it should.

Next, I need to edit the .VI to add a time on-time off timer .VI to it.  I have written that simple little VI and it works properly as it should.

It is just a boolian on/off timer.  Comes on at 8:00AM every day, shuts off at Noon every day.

The problem I am having is the boolian variable called "Output(T:Enable)" which is located in the power supply example .VI is a pannel button, but it is called in several places as a local variable.

(again, I didn't write this part, and please no lectures about why you should never use a local variable...)

When you change the state of the panel button of  "Output(T:Enable)", the power supply turns on and off as it should.

The problem comes when I try to control this boolian value using my timer VI.  I have tried several things, and using debug, I cannot get the state of "Output(T:Enable)"  to change.

The value will ONLY change if the button is pressed on or off.

CAUTION:  The local variable condition shown also is a safety shut off in case of short or overload, so the name cannot be changed.

Is there any way I can trigger "Output(T:Enable)"  using "My Timer Output" but still make it shut down if there is a short?

This has me stumped... I have tried several different things, and just can't figure it out.  Any help would be appreciated.

Thanks!

The Dude

[M_Peeker · Accepted solution]

Hello Dude!

Not sure I understand the problem to it's full extent, but I'm guessing you want to fire off the event that the Output (T: Enable) controls? If you want to do that programatically, create a property node from the control and use the "value (signaling)" property. Writing to a local variable will not fire the event, although it will change the value on the front panel.

[James.M]

What M_Peeker said is probably your issue. If not, then you'll have to share the actual code because it might be a race condition somewhere with your local variables.

[The_Big_Lebowski]

Thank you M_Peeker and James!

Yes, the property node worked...  I need to read more about property nodes.  I do not often use them, but should start.  Very Handy.

Here is a sample test VI:

When the timer output is wired to the "Output(T:Enable)" value signal property node, it fires it, and if the alarm triggers, it changes the output to off.

oddly, the "Output(T:Enable)"  button no longer works...

However, if the alarm button is latched,  the "Output(T:Enable)" button light flickers which I believe is a race condition, but it does force the local variable "Output(T:Enable)"  to go off, which is what I wanted for safety and is required.

The indicator linked to the variable "PWS On" does not flicker, only the light on the "Output(T:Enable)" button.

I will now edit the driver .VI and test it thoroughly.

Thank you!

The Dude

[James.M]

---

@The_Big_Lebowski wrote: 

---

This is, to be blunt, a really bad example of how to test your button interface. It's just a whole bunch of race conditions running as fast as your CPU will let it.

"oddly, the "Output(T:Enable)"  button no longer works..."

You're writing from Timer to Output on every single iteration, so that's going to overwrite anything else that gets written to Output (or any user interaction iwth Output). This also means you'recontinuously triggering the event every single loop iteration.

However, if the alarm button is latched,  the "Output(T:Enable)" button light flickers which I believe is a race condition, but it does force the local variable "Output(T:Enable)"  to go off, which is what I wanted for safety and is required.

The indicator linked to the variable "PWS On" does not flicker, only the light on the "Output(T:Enable)" button.

Output flickers because you're writing the Timer value over anything each iteration, so it gets set to false within the case structure but gets set back to True as fast as the loop is iterating. The fact that you don't see PWS change is because the value will always be read from the Output local var on the top right before the one in the case structure gets set.

[The_Big_Lebowski]

James,

Agreed.

however, the fault event changes "Output (T:Enable) "  is changed the same way in the actual device driver VI.  How can I do this a better way?

(see my first picture where it is circled... "Output (T:Enable)"  local variable is changed the same way.

[James.M]

The way it is in your first image should be fine since it has to go to the next iteration where it handles the event that was triggered. I'm assuming that is the location where you check the value and set PWS. Event structures are great at forcing the developer to eliminate race conditions because it should be handling each value within its respective event. Gosh, I really like event structures. They really pull the code together.

[The_Big_Lebowski]

Well, that sort of worked... the "value signal" property node to turn on the variable... but...  I dont think it can be done properly without a major re-write of the device driver.

It turns the supply on and off, but being it is a USB device, it no longer reads out the voltage and current live from the device on the screen nor does it poll the status.

Heading for a more simplistic analog approach... a relay.  Already burned waaaay too much time messing with this.  Boss is getting angry.

Thanks for the help.