LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Start DAQmx task without specifying physical channels

Solved!
Go to solution

I want to create an application for the DAQmx driver, that will allow a user to specify the number of input channels and the number of output channels they want to use.

 

They're allowed to specify the number of channels in the range 0-4 & 0-2 respectively, 0 meaning that they don't want to collect any input/output. 

 

It works fine if both numbers are nonzero. However, if I try to start a task without specifying any physical channels (in the case of "0"), I run into an error.

 

I could use case structures to eliminate all input/output task instructions, but that would make the code impossible to maintain. Maybe there's a way of specifying a dummy channel, but I couldn't find it.

 

So what's the best way around this problem?

0 Kudos
Message 1 of 9
(2,799 Views)

I say that you should put any of the code that causes an error when there are zero channels inside a case structure.  That would be the zero case  In the default case, (which would handle all numbers besides 0, there you have the code.)

 

You almost have it with the code you've shown, you just need to move around those functions that error out.

0 Kudos
Message 2 of 9
(2,786 Views)

 


@RavensFan wrote:

I say that you should put any of the code that causes an error when there are zero channels inside a case structure.  That would be the zero case  In the default case, (which would handle all numbers besides 0, there you have the code.)

 

You almost have it with the code you've shown, you just need to move around those functions that error out.


That would require putting a case structure around almost every single block. Are there any other ways to do it?

0 Kudos
Message 3 of 9
(2,782 Views)

No.  What is wrong with using the case structure?

 

In the screenshot you showed, it is as easy as moving the code you have into the case structure you already have.

0 Kudos
Message 4 of 9
(2,779 Views)

Mostly because it needs to integrate into a larger application, and using case structures in every instance would make the code very hard to maintain.

0 Kudos
Message 5 of 9
(2,771 Views)

Your app wants to seamlessly support 0 or more channels in a task.  But DAQmx doesn't support tasks with 0 channels.  So you'll have to do some coding to handle this exception condition.  No way around it.

 

You have some choices on exactly where and how to handle it, but the fundamental need is a simple consequence of wanting a behavior that's different from what DAQmx provides natively.

 

I would prefer an approach that encloses task operations in a case structure. I'd drive the case structure from the result of feeding the task refnum into the "Not a Refnum" function from on the comparison palette.   

 

An alternate approach is to go ahead and attempt the task operations, but then deal with errors after the fact.  I don't tend to like this approach when it can be avoided because there isn't always a clean 1:1 mapping between the condition you can anticipate and the error code that gets generated.  Better to *avoid* the error than to trigger it and count on a perfectly appropriate response.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 9
(2,751 Views)
Solution
Accepted by topic author Hamilton67

Hello Hamilton,

I looked at you screenshots and am not 100% sure if your way of implementing it is the easiest to achieve what you are trying to. As I don't know what your requirements/goals are I can of course be completely wrong with this feeling.

 

Some ideas:

  • Use only one Channel Control on the Front Panel. Otherwise you need to check that your user uses the "first" controls. Think of: He/She selects "2" as number of inputs, but selects channels in "Signal 1" and "Signal 3" instead of "Signal 0" and "Signal 1".
  • Inside one Channel Control, multiple physical channels can be defined:
    LabVIEW_2019-05-20_09-55-03.png
    There is even a dialog which helps picking the correct channels when you don't want to type them in:
    2019-05-20_09-55-14.pngLabVIEW_2019-05-20_09-55-31.png

  • Then, you don't need any for loop of case structure to open all channels your user defined, no matter if it is just one or 50:
    LabVIEW_2019-05-20_09-58-59.png

  • Only having zero channels selected this will fail, so you should check that beforehand, e.g. like:
    LabVIEW_2019-05-20_10-00-33.png
    (Or typecast into a string, or compare with to "Empty String/Path?")
  • However, you said this shall integrate into a bigger application. In such a case I'd pack all DAQmx code into e.g. an Action Engine/Functional Global Variable ("FGV") that keeps track of its own state internally.

Ingo – LabVIEW 2013, 2014, 2015, 2016, 2017, 2018, NXG 2.0, 2.1, 3.0
CLADMSD
0 Kudos
Message 7 of 9
(2,737 Views)

@Kevin_Price wrote:

An alternate approach is to go ahead and attempt the task operations, but then deal with errors after the fact. I don't tend to like this approach when it can be avoided because there isn't always a clean 1:1 mapping between the condition you can anticipate and the error code that gets generated.  Better to *avoid* the error than to trigger it and count on a perfectly appropriate response.


Maybe helpful: The approach to check first is often called "Look Before You Leap" (LBYL), the other one is "Easier to Ask for Foregiveness than Permission" (EAFP).

Which one is better is a discussion between programmers half a century old now...

EAFP will add additional "exit points" to you VIs that are basically invisible. A bit like "goto" statements, just worse. However, for good LBYL you have to write really defensive code and might still forget to heck for something. I believe the best approach is a mix from both: I validate my user's inputs extensively using LBYL, and rely on more EAFP internally.


Ingo – LabVIEW 2013, 2014, 2015, 2016, 2017, 2018, NXG 2.0, 2.1, 3.0
CLADMSD
0 Kudos
Message 8 of 9
(2,731 Views)

That's certainly far more scalable than I had in mind! Thanks very much!

0 Kudos
Message 9 of 9
(2,665 Views)