07-05-2013 07:02 AM - edited 07-05-2013 07:05 AM
We want a USB camera to start acquisition when a TTL edge is detected by our NI PCI 6013 card (WinXP), with minimal time delay (<0.1 ms).
It works fine, but too slow and unpredictable. CCD acquisition occurs at a 1.5 KHz rate, by calling a DLL inside labview, which is working fine. We do not miss a single pulse once we start calling the DLL in the for-loop, USB + camera + labview are fast enough. The problem seems to be the unpredictable time delay between detecting the edge and calling the DLL. The current program is attached.
Right now, a dummy voltage measurement is performed, triggered on the falling TTL edge. Of course, the voltage measurement itself costs time unfortunately. I am looking for a smarter way of progamming, such that execution proceeds directly after TTL edge recognition. Any ideas?
Background:
1.5 kHz laser system, which gives electric triggers to the CCD controller and chopper. Part of the laserlight is modulated by an optical chopper, which gives a TTL signal to communicate the current state: blocking or open. We want to start acquisition with a known chopper state.
07-05-2013 07:19 AM
With Windows, you can't be deterministic at all. It will be totally unpredictable when an action will happen.
Many cameras have trigger inputs. If yours does, you really should use that so that the software doesn't get in the way.
07-05-2013 07:37 AM
I realize windows does not behave real time, but it is also not totally unpredictable. This is proven by the fact that we can indeed call the CCD from labview 1500 times per second succesfully. So speed is good inside the for-loop, we just need to start it at the right time.
What I am looking for is more "raw" programming with the TTL edge recognition, i.e. a direct software action in Labview when the 6301 detects the edge. Do you know about that? We can characterize the quality of the solution when it is implemented.
(NB, as written in the opening post, the camera trigger is already used.)
07-05-2013 08:56 AM
I realise the "multifunction DAQ":board might be less applicable then the Labview board, so I reposted it there. (link)