LV 8.21: strange behavior with DAQ tasks, parallel running VI's and shift registers

[KlausS]

Hello,

I have made a VI using DAQmx vi's. The VI uses shift registers to store DAQ tasks and other (internal) information. I have implemented  several modes of operation (enum control with a case structure) like 'init', 'read AD', 'config AD' etc. If I use this multi mode VI in a single main VI everything work as expected. I have attached a jpg that shows one example where the DAQ VI is called from 2 parallel running while loops. One loop aquires the data (LOOP 1) while the other loop configures the aquisition task (LOOP 2). If I implement the same thing by putting LOOP2 in a different VI that runs seperately from the first VI I get an error message (200428):

Possible reason(s):
Measurements: Value passed to the Task/Channels In control is invalid.
The value must refer to a valid task or valid virtual channels.
Task Name: EasyDAQ_AD

Of course, the second VI is started manually after the 1. VI has passed the initialization part. The error message is triggered from the 1. VI that executes the DAQ task. From my understanding of the LV execution system this seems like a bug to me. Does anyone have an idea what could go wrong here?

klaus

[Kevin_Price]

1. In general, this kind of technique is something I've been using successfully for years.  (Ben recently wrote up a very nice treatment of these "Action Engines" as a "Community Nugget.")  So I don't start by expecting this to be a bug in the LV execution system.

2. Your description of the problem sounds almost backwards.  You say you manually start the 2nd vi ("Config AD") *after* running the 1st vi ("Read AD").  Seems like you'd need to do the Config 1st and then do the Read, right?   I kinda suspect you actually did it in the right order, but described it wrong.

3. The next likely scenario is that the Config failed, but you didn't trap the error and were unaware of it.  Then it makes sense that the Read would also fail.

4. A couple issues I regularly deal with in these DAQ Action Engines is internal error handling.  I often keep a shift register inside to store errors generated inside the Action Engine.  But it can get a little tricky doing sensible things with both the internal error and any other error being wired in as input.

I said all that so I can say this: if you have complex nested case statements, or lots of different action cases to handle, double check that the task wire makes it from all the way from left shift register to right.  Sometimes they get lost if they go through a case statement, the output tunnel is set to "use default if unwired", and 1 or more of the cases don't wire the output.

-Kevin P.

[KlausS]

Thank you Kevin for your ideas!

I have also used this approach for several projects and never had a problem with it. In this particular case the 'config AD' action has to be called at least once after the 'init' action since this action creates the task id for the 'read AD' action. As the single VI test (figure in my initial post) shows there is no problem calling the 'config AD' action in between 'read AD' actions. THe problem only shows up when I use the 'config AD' action from a separate VI. I've attached screen shots from the 2 actions relevant here

[Kevin_Price]

One more thought along the lines of generic troubleshooting...

Your first screenshot showed successful runs with 2 parallel loops in 1 main vi.  What if you were to select on loop and choose from the menu "Edit-->Create sub-vi"?  Does it fail when calling it from the newly created sub-vi when you automatically create it directly from working code?

-Kevin P.