Labview data fast data transfer

[Kevin_Price]

In the 1-Ctr version, you configured your pulse width counter differently (and wrongly) compared to the full code.  You need implicit timing and don't need the triggering.  Counter input tasks aren't allowed to configure a regular Start Trigger, they can only use the Arm Start Trigger.  But I don't think you need it.  You'll be implicitly timed by the pulse generating counter which *is* triggered.

(BTW, I didn't catch this before but the counter output task that *does* use an Arm Start Trigger would be allowed use the regular Start Trigger.  Just FYI for future reference.)

Attached are just a few simple mods I did to your top-level main program "Imaging.vi".  More could be done, but here's what I changed:

1. added the "commit" before the main loop for all the tasks.  See msg #17.  (There's a chance this doesn't help and might hurt for the output tasks, I've only ever used it for input tasks before where I know it helps.)
2. changed error wire connections among task starts and stops to allow more parallelism where ok and enforce sequencing where needed.  See msg #19.
3. allowed the loop to terminate on error and added a dialog and indicator to inform you of about any errors

-Kevin P 

[vasylko]

Kevin,

I have tried to put the commit action before the main loop. Apparently, my USB board doesn't like it. It gives an error 201025: Possible reason(s):

Non-buffered hardware-timed operations are not supported for this device and Channel Type.

Set the Buffer Size to greater than 0, do not configure Sample Clock timing, or set Sample Timing Type to On Demand.

I have looked up on internet and it is suggested to put the Write daq before the Start task, but I can't go this way in my program, right?

Thanks for the error wire changes

[Kevin_Price]

Let's keep trying on the task commit.

I looked up this KB article on that error.  I have 2 suggestions for you:

1. Make sure that the GUI control 'Input points' that's used to size all the task buffers has a good value in it.  The default value is 0 when you first open the vi.
2. If you still get the error, try calling DAQmx Write with your AO data *before* you commit the AO task.  I got hints from the KB article that USB boards need extra care as far as prefeeding AO data before starting the task.  It may help to prefeed before the "commit" since "commit" does the majority of the work leading up to "start".   (And that's also why a "committed" task can stop & restart faster inside the loop.) 

  It should be fine to put the DAQmx Write before your main loop since all the data is defined before the main loop.

-Kevin P

[vasylko]

Ok, I will try both and keep the "commit" action. 

Another thing is saving data. When I need to save the vectors with intensities not only display them, the program execution time grows by roughly 50-70% for each cycle. 

My idea was either to stop image updating while saving data or to make images in the program itself without saving the data (IMAQ, etc.)

What do you think about it?

Thank you

[Kevin_Price]

No, that'd be solving the wrong problem.

As has been suggested multiple times in the thread, the *most important* thing you should do to improve your loop cycling time is to move *all* processing, gui updates, and file writing into another independent loop.   Put all the data coming out of your DAQmx Read calls into a queue, and let the other loop dequeue all the data and do all the processing work.

This frees up your DAQ loop to cycle back to the next iteration while the processing proceeds in parallel.

-Kevin P