Error -200088: Configuring DAQmx channels using subVIs instead of DAQassistant

[hinamdar]

Operating system = Windows Enterprise 7

Software environment = LabVIEW 2015 Base Development version

I made a subVI comprising 

1. DAQmx Create Task.vi

2. DAQmx Create Virtual Channel.vi

3. DAQmx Property Node

4. DAQmx Start Task

Then I made a MWE to test whether this subVI works. Both these VIs are attached with this question. 

The subVI is reentrant with preallocation, with debugging allowed.

I put probes in the source VI and the subVI. I observe:

1. Task name is read in the source VI, but inside the subVI, the probe readout is an empty string.

2. Physical channel addresses are read in the source VI, but inside the subVI, the probe readout is an empty string array.

3. Channel names are read in the source VI, but inside the subVI, the probe readout is an empty array. 

4. Since the task name is an empty string, the probe readout for the refnum after the Create Task.vi is "unnamed_task<>"

5. I suspect this causes errors in the Create Virtual Channel.vi, Property Node, and the Start Task.vi. 

6. The final error readout is -200088: "Task specified is invalid or does not exist."

Does anyone know why data written to the subVI is not actually passed to the subVI? Strangely enough, sometimes, this data is passed for the first run, but not for any subsequent runs. 

Note: If you run the MWE, there is a subVI in the MWE to configure the CompactDAQ device being used to read measurements. 

[Blokk]

I do not understand lots of things why you do it in that way. You have a "DAQmx Flatten Channel String.vi" with input of "globale virtuelle Kanäle". You do not connect anything to this terminal in your top level VI, then this Flatten.vi output is connected to the "DAQmx Create Task.vi" which task out is connected to the DAQmx Create Virtual Channel.vi.

Just delete that first 2 VIs ("Flatten" and "Create Task"), and see if it will work. You only need the "Create Virtual Channel.vi" with the "physikalische Kanäle" input.

I see other strange things in your code what I do not understand:

1. Why do you use integer values for those parameter inputs? You just make your life harder. Also, you input wrong values at certain points, like you set value of "-40" for the thermocouple type input. This is wrong I think. Just use the normal parameter inputs, like "J" or "K". Same applies for the other inputs. You can make array of these parameters too!
2. Your test VI is not OK. You initialize HW, but you do not close the resources when your VI stops execution. You need to close HW resources, otherwise you might get problem at the next init attempt!
3. There is a missing subVI you did not attach. What does it do?

I put there the snippets of your VIs, so others can also help who does not have LV on their phone/PC:

top level VI:

subVI which was attached:

[hinamdar]

Hello Blokk,

Thank you for your observations.

I developed this subVI to use in our research group. Since this needs to be a very generalized version to make it useful to as many people as possible, I included inputs that I do not use as well. Therefore, I maintained the „globale virtuelle Kanäle“ input wire as well.

1. The integer values for parameter inputs are because it is easier to wire in a numeric array. I changed that to a ring array now. The thermocouple type input was wrong—you are correct and I changed it.

2. The test VI does not include „End/Close Task“ because I use it only for troubleshooting. I manually end tasks and unreserve the chassis.

3. The missing subVI was for to configure the CompactDAQ device being used to read measurements (as I said in my post).

I found out that I needed to do two changes to make the subVI work:

1. Since I do not always use all input terminals in the „Create Virtual Channel“ VI, the indexing of the for loop using the input arrays gives rise to problems. The array with the lowest size is used to index the for loop. If the thermocouple channels all had internal cold junction compensation, the cold junction compensation value or channel input arrays were empty. This gave 0 iterations of the for loop. I had to include a Case Structure inside the for loop and stop indexing on the optional input arrays.

2. The „Create Task“ VI gives a Refnum output which is wired to the „Create Virtual Channel“ VI. As you see, I wired this Refnum input as a tunnel without indexing into the for loop. I had to change this to a shift register. I put probes on the Refnum wire and observed that tunnelling made the Refnum wire probe readout to be an empty string whereas with a shift register, the probe readout was the name assigned to the task. I do not understand why this is so, but I know that this approach works.