Validating a DAQmx terminal after casting from a string

[eaolson]

(I originally asked this in the Multifunction DAQ forum, but realized it's more appropriate here, since this is a software question.)

I need to cast from a string to a DAQmx terminal, and then set that terminal as the source for a external trigger.  I would like to verify that the terminal actually exists and that an error was not made.  I can't find any way of determining if a specified terminal actually exists on a given device.  Even setting a non-existent terminal as the trigger source for a task doesn't seem to throw an error.  Nor can I find a way to get a list of all the available terminals on a given device to see if the specified terminal is in the list.  I'm using LabVIEW 7.1.1.

Any suggestions?

[Christian Mergl]

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

[chrisger]

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!

[Christian Mergl]

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..") 

[chrisger]

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!!

[eaolson]

My guess is that you mean something like in the attached VI?  That will return the list of available physical channels (e.g. Dev1/ao0) for a device, but not the terminals (e.g. /Dev1/PFI0).

[eaolson]

---

@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.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!!

---

I observe the same behavior in 8.0 with DAQmx 8.0.1.  Perhaps the compiler is sees that the property node outputs aren't connected to anything so it disregards it at compile time?  Still, it seems very dangerous to me that DAQmx Start Trigger can take an invalid terminal name but not return an error.  It's just a wrapper to a Trigger property node itself. 

The same thing happens if a terminal constant is used instead of a string. 

[Jesse_O]

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

[chrisger]

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.