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

[EEsRULEtheWORLD]

Message Edited by EEsRULEtheWORLD on 11-17-2009 05:10 PM

[maksya]

Dear Dennis Knutson,

I will not comment your opinion about misunderstanding of dataflow in LV. Such talks make no sense.

However, could you please answer me the following question. There are two VIs in the attachment - no logic, no structures... only wires and LabVIEW features (property node, subVIs). There are no race condition. This is the most simple example I have made to depict the problem 😃

Please open only VI.vi, enter something into the Input String control and run the VI. Now, the question 😃 Output String is empty... Why? You can run VI.vi to be blue in the face but the indicator will be empty.

Now, please open the FP of the subVI.vi. Enter something into the Input String control and run the VI.vi. Output String is empty.. Once again run the VI.vi and voila 😃 the value of Input String will be passed to the Output String. Why does the Output String is updated only if subVI.vi's FP is opened?

Regards,

Max

[Dennis_Knutson]

I don't know how to make it much clearer. You are violating basic dataflow - what LabVIEW is built around. You simply cannot depend on the property being read after the control is updated.

[maksya]

And if I use String data type instead of DAQmx Device then the value is clearly passed (see the attach for this message).. I "cannot depend on the property being read after the control is updated."... but in case of String data type I can! Is it so? Looks strange.. Could you explain what magic do LabVIEW build around in case of String and DAQmx Device data types? 😃

P.S.: What is the purpose of property nodes if I can't bind their values with updates of controls and indicators?.. very strange. I have developed a tool for automatic editing of VI's documentation. It is based on property nodes and methods. It works properly and I can set new values to controls in that tool and they are properly reflected in property nodes of these controls...

[Dennis_Knutson]

You can make use of property nodes as long as you pay attention to dataflow - execution order. If you don't connect wires, you have no dataflow. You are doing 'illegal' programming.

[Broken_Arrow]

Nothing magical about it. Use real data flow by using references. See attached. Run it a few times while changing values.

[maksya]

Dennis Knutson, thank you for your comments. Such investigation is very valuable for me.

Two examples from my posts have identical "connections". The only difference is that the first uses DAQmx Device data type for subVI contol (DAQmx Device Name) and the second - String. What is the difference in usage of these two data types? Why does the similar dataflow crash if I use DAQmx Device data type?

[Broken_Arrow]

---

Dennis Knutson wrote:
I don't know how to make it much clearer. You are violating basic dataflow - what LabVIEW is built around. You simply cannot depend on the property being read after the control is updated.

---

Dennis,

True. But in this case, even when you force the issue with sequence frames, the DAQ item does not update, whereas the string item does. This is likely the OP's complaint, and it is a little strange. However, using a reference wired to the node works fine.

I'd like to make wired more bold than that. Use wires people. USE WIRES !

[mzu]

The stepwise reproduction of the buggy behaviour maksya is talking about.

1. restart LabVIEW

2. open VI.vi (without opening the FP of the Subvi.vi).

3. Type anyhting into physical channels, be it a valid thing or not.

4. Run your VI.

5. Observe nothing appears on "physical channels 2" indicator.

6. Do it couple times, changing the value at #3 with the same result

then, open subVI vi front panel.

7. Now, launch VI.VI.

8. Observe the value from "physical channels" propagate to "physical channels 2"

9. Now, change the value of the "physical channels"

10. Run VI.vi

11. Observe how "physical channels 2" did not change to reflect the changed value of "physical channels"

12. Now change the value of the "physical channels" to something completely else.

13. Run VI.vi

14. Observe how "physical channels 2" changed, but now reflects previous value (the one you entered at #9).

Obviously, ## 5,11 and 14 are disturbing and is indication of the same bug as maksya is talking about.

The bug is reproducible with 8.6, 2009, 2009x64.

Putting the things in the subvi.vi into a sequence structure does not alleviate the bug.

On a side note,

  While you should not use value property (the way it is used) for the sake of preserving dataflow, the behaviour demonstrated has nothing to do with the dataflow,

because the indicator being read is not being written to. IMHO, it is a clear bug inside LabVIEW.

I believe, that was the main point maksya was trying to make.

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

[mzu]

---

Dennis Knutson wrote: 
Your VIs make no sense and you show a lack of understanding of LabVIEW and dataflow. You have a classic race condition. Somehow you think that the local variable and proerty node will show what you are writing to the control. That is not the case. The read of the local and property node can happen before the write to the control. Using either a local or property node in this example is just nonsensical.

---

Dennis, please, elaborate on that. in the subvi we only read and do not write to the control. While the way it is done somehow violates the dataflow, but there is no race condition. Or have I misunderstood you?

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