08-04-2006 09:34 AM
08-07-2006 04:47 AM
Hi eaolson,
You can read out the information of the device using the property nodes located in "Measurement I/O>DAQmx>Advanced>Sytem Setup.
You only have to set "Device Names" for the system node, connect it to the device node and you can read out nearly any information.
So my idea was to compare the string with the existing terminals out of the information of the property nodes before doing the typecast.
Christian
08-07-2006 06:45 AM
hi there
i played around a bit and found a bug (see attachment). the DAQmx property node returns only an error when an indicator is connected!
08-07-2006 08:25 AM
Hi Chris,
I wouldn't say this is a bug!
I think if you wire a not existing terminal it takes somthing else for default (maybe onboard clock) and the error only appears,
if you try to read out the value, as you did it with your vi!
But the behaviour is quite interesting....
Christian
(last words of an chemist: "..and if we now bring this two substances together..")
08-07-2006 08:48 AM
hi there
no, this is a bug! let me explain a little bit more in detail:
1. you create a task
2. you connect a string (!) of a non-existing terminal to the trigger configuration vi for this task -> no error (would be fine if there'd be an error, but that's ok for me)
3. you read the value of the property Start.DigEdge.Src
up to here the behaviour of the app HAS TO BE exactly the same, no matter that there's an indicator connected to the property node or not! the visualisation of the properties value takes place AFTER the value has been read. the pure fact that the value of the property node is displaed should have no effect to the error cluster! but: the property node throws an error only then when there's an indicator connected. if you remove the indicator, the property node returns NO error, but the app does exactly the same thing.
just take the vi i posted, connect the SomeNonexistingTerminal-string to the trigger config vi, and visualize the error cluster directly after the property node. run the vi -> error code. remove the terminal indicator of the property node, and run again. then you'll see that the error vanishes, while you have changed nothing at all!!
08-07-2006 12:11 PM
08-07-2006 12:18 PM
@chrisger wrote:1. you create a task
2. you connect a string (!) of a non-existing terminal to the trigger configuration vi for this task -> no error (would be fine if there'd be an error, but that's ok for me)
3. you read the value of the property Start.DigEdge.Srcup to here the behaviour of the app HAS TO BE exactly the same, no matter that there's an indicator connected to the property node or not! the visualisation of the properties value takes place AFTER the value has been read. the pure fact that the value of the property node is displaed should have no effect to the error cluster! but: the property node throws an error only then when there's an indicator connected. if you remove the indicator, the property node returns NO error, but the app does exactly the same thing.
just take the vi i posted, connect the SomeNonexistingTerminal-string to the trigger config vi, and visualize the error cluster directly after the property node. run the vi -> error code. remove the terminal indicator of the property node, and run again. then you'll see that the error vanishes, while you have changed nothing at all!!
08-08-2006 01:13 PM
Hello,
During the initial creation of the task, your settings are not verified.
If you place a DAQmx start task (or manual verify the task), you will get an
error when using an invalid terminal name. If you look here at figure 9,
you will see the verify, reserve, commit structure that exists in either the
start task or the task control VI. I have attached below a picture of the
control task VI displaying the error when the indicator is disconnected.
Regards,
Jesse O.
Applications Engineering
National Instruments
08-09-2006 03:12 AM
hm, well, ok, i see..
but i think it's still very confusing that the behaviour INSIDE a property node depends wether an indicator(!) is connected or not.