DAQmx Device data type, local variable VS "Value" property

[Dennis_Knutson]

Of course the control is written to. That's the whole point. It's written to by the calling VI. What would you call it if a control is written and read at the same time?

[mzu]

---

Dennis Knutson wrote:
Of course the control is written to. That's the whole point. It's written to by the calling VI. What would you call it if a control is written and read at the same time?

---

 

Dennis, I beg to differ. The subVI.vi is called by a regular subVI node, therefore All the control values of the subVI.vi are set before it starts execution. There are no open references to this control outside of the subVI.vi.

Just to be sure we are talking about same VIs I list their snipplets here:

 

I am talking about "physical channels" control from the subVI.vi (leftmost one)

Please, let me know what you think. 

Message Edited by mzu on 11-25-2009 02:35 PM

Message Edited by mzu on 11-25-2009 02:36 PM

Message Edited by mzu on 11-25-2009 02:40 PM

[Broken_Arrow]

Snippets won't work to demonstrate this effect, because the Snippet makes nodes strict. Wiring a ref to a strict node does work, as evidenced in my prior post.

[mzu]

My apologies, I corrected the original post

Message Edited by mzu on 11-25-2009 02:41 PM

[Broken_Arrow]

That's my VI. Dennis and the OP have not referred to my VI to my knowledge.

[mzu]

Same situation with the original one:

 

Unless I misunderstood what Dennis was going to say, I do not see any race condition here

Message Edited by mzu on 11-25-2009 02:47 PM

Message Edited by mzu on 11-25-2009 02:48 PM

[Broken_Arrow]

---

mzu wrote:

Same situation with the original one:

 

Unless I misunderstood what Dennis was going to say, I do not see any race condition here

Message Edited by mzu on 11-25-2009 02:47 PM

Message Edited by mzu on 11-25-2009 02:48 PM

---

Wha? The Local and the Node will race it out, won't they?

[mzu]

I do not think so, they both read, there is nobody writing the control in question.

And if you put it into the sequence, the behavior does not change.:

I am leaving aside the question of style 

Message Edited by mzu on 11-25-2009 02:56 PM

[Broken_Arrow]

Yep, that's what I did to prove the DAQ item was not updating properly. We have two issues here (already stated), improper programming and (despite that) a static property node that doesn't seem to work even if you force the issue.

I still believe the original VI was a classic race condition, but ironically, it has proved to not be the culprit in the property node not working.

[mzu]

Agreed on the 2 issues.

The essential thing for the race condition is that one thread changes the value the other tries to read/change it. My references are:

wikipedia 

Definition 1 

http://java.sun.com/developer/Books/performance2/chap3.pdf

and 2 NI examples: 

http://zone.ni.com/devzone/cda/tut/p/id/7590 

http://zone.ni.com/devzone/cda/tut/p/id/7517 (the very bottom). 

However this is not the case with either original or your VI.

On the contrary, I think, that explicitly serializing the subvi and getting the same result - is the proof that the race condition is not there.

Only race condition I can possibly think of is some bug on the LabVIEW side. I remember an excellent post by Aristos Queue on lavag.org where

he told how the controls/indicators retain up to 5 different copies of the data. Pure speculation,  but may be because of some race condition inside

the LabVIEW itself we get the wrong (say previous or default) data. The way to prove that would be to launch LabVIEW in single threaded mode,

but I can no longer find this option for 8.6 and for 2009. Anybody has 7.1 to check?