How to avoid repeated start/stop task?

[fomine]

Hello,
6229/62289, DAQmx 8.3 LV 8.2 WinXP.
I need to implement a sub-vi that will output 16 bits at a specified clock. I am looking at C:\Program Files\National Instruments\LabVIEW 8.2\examples\DAQmx\Synchronization\Multi-Function.llb\Multi-Function-Synch Dig Read Write With Counter.vi example as the basis for the sub-vi.
(I will not need the loop as I need to output only 16 bits at a time, so perhaps I will need to switch to FiniteSamples mode)
I will use Counter to generate required clock (100kHz in the examples below) and use it as a timer for DO.
The problem is that I will need to call this sub-vi millions of times, and I don't want to create/destroy the counter and DO tasks every time.
In fact, I benchmarked it, and it comes out that 1000-cycle of this sub-vi takes 51sec!!! (vs. theoretical limit of 0.16msec - 1000times x 16 bits / 100kHz) for clock of 100kHz
This is outrageous overhead. Start/stop task (+memory on shift registers to store the task) is way better at 11 seconds, but still a long way from theoretical (and highly desirable!) target.
Removing start/stop tasks cuts down the time to 0.4 seconds - quite acceptable, but 200288 error pops up when trying to write the second set of 16-bit data.
What do you guys think whould be the best implementation for such task?
On the side note, what happens to Finite Sample task cofigured (DAQ Timing) to output 16 samples, once writing 16 bits (DAQ Write.vi) is complete?

Looking forward to your answers!

Evgeny

[Dennis_Knutson]

It seems you already know that the culprit is the multiple calls to Start/Stop Task. Instead of placing these in your subVI, move them to the main. You should call Start Task once when the main starts and then call Stop Task when the main finishes.

[fomine]

The problem is there are many "mains" that call this sub-vi.
I have tried to start task only on the first call of the sub-vi (First instance?->Case[True=Create+start task, pass it to shift register; False=Pass-through the task from shift register])
But this way I get -200288, and I don't know how to make it work. Please help!
I have attached the file for your convenience. SDIO- NI - the sub-vi I'm trying to create, !SDIO- NI to run it in the loop.

[fomine]

Here is the sub-vi it will be looking for...

[Dennis_Knutson]

I don't understand at all what you mean by multiple mains. You have a single top level main VI called !SDIO NI1 that calls a subVI with the DAQmx code. You can move the DAQmx initialization (including the Start Task) to this. It would be doen outside the for loop.

Maybe you don't have a good concept of a LabVIEW program. You have a single top level VI that can contain subVIS nested as deeply as you wish. Typically, you pass values from a top level VI to a subVI through the subVI's connector pane. In your case, you would pass the task and error in (and any parameters you wish to set). The subVI then passes data back to the calling VI through the same connector pane. Yuo would pass back the task and error out (and any data returned).

[fomine]

I mean the following: What you see as !SDIO is just a benchmark test. I did not include all (or any) of my top-level VIs.
In real life I will have Main1.vi, Main2.vi, Main3.vi etc. Some of them will be run at all times, some - manually on and off, some - by the schedule.
All of them will call SDIO sub-vi asyncronously. I have no way of predicting which of the MainN.vi will call SDIO sub -vu first.
I have no mean to predict which one will be the last. I know however that if I don't make the sub-vi re-entrant, I don't have to care about possible collisions. Mains will queue for the sub.(Apparently, I cannot make simultaneous DO on the same lines)
I hope it clarifies my situation.
P.S. If I know how to use memory on the shift registers, I think it is safe to say that I know at least something about LV.


Message Edited by fomine on 02-14-2008 12:12 AM

Message Edited by fomine on 02-14-2008 12:15 AM

[Dennis_Knutson]

Making the subVI reentrant will do nothing to avoid collisions of setting the hardware. If you call the SDIO from multiple top level VIs, you will get a conflict because the hardware driver itself will not allow it. You can only have a single task for the same resource.

[fomine]

That is exactly what I said.
I will not make it re-netrant, thus I will have no problems with collisions.
They will execute SDIO sub-vi one by one. I have no problem with it.
The problem is how to avoit create-destroy, or start-stop task....
Thanks!

[Dennis_Knutson]

You don't understand what I said. Whether it is reentrant or not, I believe collisions can occur.

You either put the initialization in one main that sychronizes the hardware access or not. If the time it takes to start/stop tasks is a problem, your only solution is to not do it so often.

[fomine]

No, it will not.
It's not the point here anyway, I have no problems with collisions, the question is how to avoid repetative start-stop?