LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Property Node Works, Local Variable Does Not

From a Newbie...

 

I have a control panel for two power supplies. The control clusters on the control panel for each are duplicates and are saved as a typedef for the cluster. Of the several controls in the cluster, there is a DBL data type VOLTAGE selector control, a Boolean SET button (to set the selected voltage) and a Boolean ON/OFF button (to set output state on or off). When returning the instrument to the ON state, the driver requires the voltage setting to be read. But, if the user has inadvertently changed the VOLTAGE control without pressing SET, the supply will output the voltage on the control (which is wrong). To avoid this, I created a new control within the cluster - VOLTAGE SET, and it is this control the supply driver reads. I have an event structure that traps for the SET button press. It reads the VOLTAGE control and writes to the VOLTAGE SET control.

 

Now, my problem:

If I use a local variable for either power supply, unbundle to the VOLTAGE value, send that value to a Bundle By Name function with the item VOLTAGE SET, and write to another local variable, it only works with Highlight Execution. I separated the code into a sequence structure, adding timing delay (thinking it was a timing issue), with no result.

 

However, if I use a Property Node for each control, it works perfectly. As the Voltage Set control is hidden, it is not so convenient to create the nodes, and the solution seems to lack elegance. Additionally, I have only gotten so far as to test ONE power supply cluster and fear that the two clusters may conflict using nodes as the controls have the same name!

 

Questions:

Why does the local variable solution fail?

As the two power supplies clusters share the same typedef, will my fear of conflict be reality?

Is there a better solution to saving and reading a value?

 

Thanks,

J

 

0 Kudos
Message 1 of 13
(2,656 Views)

Instead of lenghty descriptions, show us your code instead!

 

Your symptoms are typical for race conditions, for example if a local variable is read before the desired value is written to its indicator or another local variable of it elsewhere. highlight execution changes the execution speed and can rearrange execution order, seemingly fixing the problem.

 

Yes, there will definitely be a better solution!

 

... but first, show us your VI.

0 Kudos
Message 2 of 13
(2,642 Views)

Can you share some code?  This is really sounding like a race condition issue.  And there might be ways to not even use the locals and property nodes.


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
0 Kudos
Message 3 of 13
(2,638 Views)

Sorry Folks, for the delay - I had other issues to deal with...

 

The VI named "...Does Not Work" has two supplies - neither work. They are configured differently, but what they have in common is the 'Voltage Set and Current Set' are in a cluster.

The VI named "...Only Supply 2 Works" has the voltage and current set indicators (value place-holders) placed separately (not in a cluster) on each supply cluster. Although they are identical, Supply Two works on my computer - Supply One only works in Highlight Execution mode.

 

In both VI's, all place-holder indicators are hidden - the cluster in "...Does Not Work" and the individual indicators in the one that half-works.

 

What is going on and what is the proper way to handle storing a value for use at a later time?

 

Thanks,

John

0 Kudos
Message 4 of 13
(2,578 Views)

I can't see the difference between your VI's they are too big.

 

But one question I have is why do you use the "Mouse Up" event for many of your boolean buttons rather than "Value Change"?

0 Kudos
Message 5 of 13
(2,569 Views)

Sorry for the complicated Vi. Attached is a stripped-down version with 3 approaches. The Local Variable model (Supply 1) does not work.

 

I use the Mouse-Up event to avoid inadvertent clicks. That way if the user mouses-down over the control and catches the mistake before they release the button, they can move the mouse off the control and no event is fired.

 

John

0 Kudos
Message 6 of 13
(2,557 Views)

jmltinc wrote:

I use the Mouse-Up event to avoid inadvertent clicks. That way if the user mouses-down over the control and catches the mistake before they release the button, they can move the mouse off the control and no event is fired.


You get the same benefit with a value change event of a "latch when released" boolean. If you press down, then move off the control, it will not trigger.

 

Just glancing at your code, why so convoluted???

0 Kudos
Message 7 of 13
(2,552 Views)

You get the same benefit with a value change event of a "latch when released" Boolean. If you press down, then move off the control, it will not trigger.

But that is not compatible with Local Variables... Correct?

 

why so convoluted???

If you mean the sequence structure, I was just trying to eliminate potential timing problems. If you mean the additional controls and the read/writes, I don't want to write to the driver from the control panel user control until they hit 'SET'. I am sure there is a better way. I am a Newbie...

 

John

0 Kudos
Message 8 of 13
(2,534 Views)

I would suggest using shift registers for your values. You can update values in the indicators as necessary. If you use the value change on the controls you can use the correct mechanical action and avoid the issues with the muose up events. Also, you can eliminate all (or most) of the property nodes and local variables you areu sing now.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 9 of 13
(2,520 Views)

@jmltinc wrote:

why so convoluted???

If you mean the sequence structure, I was just trying to eliminate potential timing problems. If you mean the additional controls and the read/writes, I don't want to write to the driver from the control panel user control until they hit 'SET'. I am sure there is a better way. I am a Newbie...


I was talking about how you bounce values in and out of value propery nodes, (or local variables) even if the terminal or wire value is right there. Compare the two code segments below (top: yours, bottom: equivalent alternative).

 

 

If you use a wire, there is no potential timing problem, because if forces execution order.

 

 

I would also combine the events (cluster: value changed), then compare the new and old to figure out what changed.

0 Kudos
Message 10 of 13
(2,501 Views)