Running delay when the program becomes more complex(DAQ Sequence, 3rd party CCD imaging)

[Tomas_E]

I am using two DAQ cards NI6229 and NI6703, generating some multiple channels sequences(scale of 10kS/s, 2s length, 4 AOs, 8 DOs), some static voltages(8AOs), and acquire some analog voltage from AI (1 channel).  At the same time, the program is controlling a CCD camera(Andor) for imaging. Also, there are some imaging processes in run-time(have to). 

When the program is first not very complex, everything works fine. But when I make the program more complex like adding one more line of code, while running the program in the release executable file(.exe), the program got some huge delays(like stuck about 10s), and the reason is that the CCD camera cannot catch the triggering signal from the DAQ card(but with oscilloscope, the trigger is there fine.)  However, when the program is running in debug mode, although the response of the program to user interface is slower, but the CCD never misses the triggering signal and return the images. Of course for some practical reason we cannot run the program in debug mode.

One thing to point out is while this missing triggering happens, the program is calling a function relative to AO and AI hardware(read a voltage and output a voltage). If this function is disabled, everything is fine.

This miss-triggering caused running delay has nothing to do with whatever code I add to the program's complexity. It looks like sort of combination problem associated with the CVI platform, CCD camera(together with its C based functions libraries), DAQ cards, memory handing, CPU resources handling...etc.

Is there any one has similar experience and good solution?

Thanks

[menchar]

The release mode should run faster, if debug executable is succeeding then that sounds like there's some sort of delay needed for the system to work, and the slower debug executable enables it.

You could do a release executable but insert delays in between the major sections of your logic to see if you can discover where the time sensitivity is.  Where is the 10 second hangup accuring - when you're waiting for video to become available?  On the face of it, it would seem like the I/O calls are managing to block the video acquisition. 

NI-DAQ used to have a deadlock vulnerability but they fixed this as I recall.  I was trying to do analog output on an acquisition board, and if I called into NI-DAQ at just the wrong moment when an acquisition was occuring with a second thread, it would deadlock.

Is your application single threaded?

Menchar

[Tomas_E]

Yes there is a delay(timer). I found that the AO function is mainly the cause of the disrupt. The 6229 multiple card is the main card and there is large buffer allocated for the mixed signals sequence. the old 6703 only serve some unimportant DC output. But at this point, there are ten AO DC output commands to the 6703 conitnuously, and they are tested to be the main reason causing the delay. (Because 6703 is static voltage output card, so we use these ten commands to generate a 10 points waveform, maybe this is not a good idea).

There are no special thread configuration so I assume it is single thread process.

Thanks anyway.