11-12-2009 01:54 AM - edited 11-12-2009 01:56 AM
Hi, dear ALL
I am faced with a problem. Could you help me to explain the LV behaviorin such a case -
In the attach you can find 3 VIs:
2 subVIs and main VI. SubVI daq operates with DAQm Device data type and outputs two parameters - using local variable and using property node "Value". SubVI str is similar, but operates with String data type.
All outputs work properly except devNameProp[] =( This output operates with property node "Value" of DAQmx Device data type.
Some notes:
1. If only main VI is opened then devNameProp[] has empty string elements.
2. If we open daq subVI, then devNameProp[] is filled with unexpected string elements.
3. If we enable Highlight Execution option in the daq subVI then devNameProp[] is filled with correct string elements.
Thanx in advance,
Max
Message Edited by maksya on 11-12-2009 01:55 AM
11-12-2009 03:02 AM - edited 11-12-2009 03:11 AM
Hi maksya,
what are you doing in your sub vis?
- Why do you use locals/property nodes instead of wiring the terminals? This is just a big race condition: "when HIGHLIGHT is enabled..."
- Why do you have a "VISA Configure Serial Port" in both subvis without connecting anything to it?
- What output do you expect when feeding the input of both subvis with just "numbers" ("1" to "5")? They should just give back those inputs...
- What are "unexpected string elements"? What are expected ones?
Have you attended the free online courses to understand the dataflow principle of LabView?
11-12-2009 03:38 AM
> what are you doing in your sub vis?
just demonstrating strange behavior of "Value" property for DAQmx Device data type..
> - Why do you use locals/property nodes instead of wiring the terminals? This is just a big race condition: "when HIGHLIGHT is enabled..."
I use them to show the problem. You are right, I can wire terminals directly, so the problem will be workarounded. But this not a solution of the problem. Additionally, where is a race condition in my VI's? Data from the input passes to the output in four paths:
- String to DAQmx Device (via local variable)
- String to DAQmx Device (via property "Value")
- String to String (via local variable)
- String to String (via property "Value")
All paths except the second work properly.
> - Why do you have a "VISA Configure Serial Port" in both subvis without connecting anything to it?
Just a rudiment 😃 This "bug" doesn't affect the main code.
> - What output do you expect when feeding the input of both subvis with just "numbers" ("1" to "5")? They should just give back those inputs...
Exactly! Give back inputs! But devNameProp[] do not! That is the problem. String constants "1" to "5" are only for example.
> - What are "unexpected string elements"? What are expected ones?
Expected ones are ["1", "2", "3", "4", "5"] on all four outputs, and "unexpected" are ["","","","",""] or ["5","5","5","5","5"].
> Have you attended the free online courses to understand the dataflow principle of LabView?
Thanx for advice, but I do understand the dataflow 😃 The only problem I wish to discuss here is "why property node "Value" doesn't work correctly with DAQmx data type".
Regards,
Max
11-12-2009 05:05 PM
Hi, Max.
In reading through your original post, it seems as if you want to display the Device Names using the DevNames Property. This property is found in the DAQmx System Property Node (Measurement I/O»DAQmx»DAQmx Advanced»DAQmx Constants and Property Nodes»DAQmx System Property Node). The following screenshot is an example of how exactly to utilize DAQmx property nodes to display the Device Names as well as Product Type of the specific Device Name:
Is this the information that you needed? Let me know if you have any more questions, or if I had perhaps misinterpretted the question.
I hope you're having a great day!
11-13-2009 12:37 AM - edited 11-13-2009 12:40 AM
Hi, Sara.
Thank you very much for your answer! This is helpful information. And also thanks for your wish 😃
Unfortunately, that is not complete solution.. I will shortly describe the task itself.
I have a DAQmx Device control on the FP:
I want to get the current value of "dev" control ("Dev1" in example). And I want to use a property node to get this value and use it on the Block Diagram. Seems that property node "Value" is not suitable for my needs =(
Could you suggest any solution?
Best regards,
Max
11-16-2009 11:07 AM
Hi, Max.
I opened the DAQ.vi that you had posted in your original post that utilizes the Value Property Node to display the value of the dev control. This VI successfully displays Dev1 in the DevNameProp indicator. When I change the dev control to Dev3, for instance, this change is reflected in the DevNameProp indicator. Is this not working for you?
11-16-2009 01:55 PM
maksya wrote:Hi, Sara.
Thank you very much for your answer! This is helpful information. And also thanks for your wish 😃
Unfortunately, that is not complete solution.. I will shortly describe the task itself.
I have a DAQmx Device control on the FP:
![]()
I want to get the current value of "dev" control ("Dev1" in example). And I want to use a property node to get this value and use it on the Block Diagram. Seems that property node "Value" is not suitable for my needs =(
Could you suggest any solution?
Best regards,
Max
Message Edited by maksya on 11-13-2009 12:40 AM
The problem with getting the response you want to your question is the statement: I want to get the current value of "dev" control. The value of the dev control is Dev1.
11-17-2009 02:14 PM
Dear, Sara
That's right. If daq.vi is executed as a standalone VI then Value Property Node returns the real value of the dev control - Dev1, Dev3 in your examples.
And now, try to call daq.vi as a subVI. You can use my main.vi in the attachment. Open only main.vi (daq.vi shall be closed). Execute main.vi and you will see that devNameProp[] array is empty!! devNameProp[] collects output devNameProp of daq.vi. But it is empty! That is the problem 😃
Regards,
Max
11-17-2009 02:26 PM
Sorry, but I didn't understand your solution.. dev is Dev1 only in an example 😃 And I want to get any value of dev control via "Value" property node. So, what is your suggestion?
Regards,
Max
11-17-2009 04:49 PM