08-27-2014 05:36 PM
Hi all,
I'm running a cameral link frame grabber card PCIe-1433, with an I/O extension board.
LabVIEW 2013, Vision Development Module 2013, Windows 7
In LabVIEW, I'm using 'IMAQ Generate Pulse3 VI ' to generate pulses.
In the current iteration I'm generating up to 3 pulses, and the client would like more.
According to the help file, "The NI 1427, NI 1429, NI 1433, and NI 1435 can generate a maximum of 3 pulses".
Is there another way to generate TTL pulses on the I/O extension board lines, that doesn't have this limitation?
Thanks,
Jeff
08-28-2014 04:49 PM
Hi DMJeff,
The documentation for that function is as you say. This is a limitation of the hardware that you have. That being said, you can probably generate more pulses using one of our digital I/O cards.
08-28-2014 05:00 PM
Hi Paolo,
Thank you for the confirmation.
I'm inferring from your reply that this limitation still exists in the 2014 version of LabVIEW/Vision, and that there is no other VI tool available that does not have this limitation.
We chose the I/O Extension board to facilitate and triggering of digital events while recording video.
The timing of the digital event, as it relates to each frame of the video, is critical to the application.
If we were to use an alternate DAQ card, driven from the same LabVIEW application, would there be any potential delays, or other indeterminate timing, of signals sent out the DAQ in relation to video coming in on the 1433?
Also, the client is considering adding input flags that the DAQ would monitor, would there be delays or other indeterminate timing on digital or analog inputs as it relates to the video?
Thanks,
Jeff
08-28-2014 08:38 PM
08-29-2014 01:34 PM
Hi,
Thank you for the thoughts.
We are collecting video (280 fps) of a test subject, with the PCIe-1433 frame grabber card and a Point Grey camera.
At random time intervals we provide a random stimulus to the subject, maybe light, maybe sound, maybe air motion.
Each of these stimuli is attached to a separe TTL output pin on the I/O extension board.
The critical measurement is the elapsed time from the stimulus firing until the subject reacts to that stimulus.
As it is currently set up, I can provide a stimulus (perhaps 0.1 seconds in duration) three times.
The stimulus is a simple, single pulse, square wave. That is, turn on this pin, for this duration, and then turn off.
When I get to the fourth stimulus, the VI fails due to the 3 pulse limitation.
I can live with that limitation, as the timing of the stimuli and the duration of the video seem to be okay with the limit of 3.
Now I want to modify the routine, so that I'm using a user adjusted PWM signal from the I/O extension board to adjust the brightness of the flash of light.
If I use the 'IMAQ Generate Pulse3 VI' to generate the PWM pulse train, then I lose one of my triggered stimuli.
Since I have 3 different lights to control, that would use up all 3 pulses, and I wouldn't have any pulses left for stimuli.
It is critical, however, that I record when the stimulus actually fired, so I can time the test subjects reaction.
Can I get this tight coupling/timing if I use a second DAQ card instead of the I/O etension card?
Thanks,
Jeff
08-29-2014 01:58 PM
09-02-2014 01:39 PM
HI,
Thanks for the idea, I'll look into it.
In my VI, I'm using a 'rearmed pulse' to give me a single 0.1 second rising edge pulse.
I had assumed since it was a 'rearmed pulse' that the VI would 'stop' when it was done, apparently that isn't the case.
Based on the help field, I'm guessing that as soon as I call the VI with 'stop', that the pulse will end (return to low value), regardless of the pulse duration I set up when I started the pulse.
Is that true? Or will it complete the execution of the current 0.1 second pulse before recognizing the stop command?
Thanks,
Jeff
09-02-2014 02:16 PM
09-03-2014 01:41 PM
Hi,
Thanks again for the input as I work through the issues, it has been very helpful.
I don't think that I'll need to coordination between cards that RTSI provides.
As far as I can tell, using the RTSI would necessitate using the DAQMx to drive it, and still have the 3 pulse limit.
Whether that is actually the case or not, probably isn't critical to the question.
The most important timing is from the software trigger to the actual pulse.
If I have a second DAQ card, not connected to the frame grabber, and I sense an input or trigger an output, in the LabVIEW, as long as there isn't a significant delay from the electrical DAQ connection to the LabVIEW, then we're good. I need to know when the event happened (within 0.5 mSec), as I'm capturing video frames.
Have you utilized a separate DAQ card at the same time as the frame grabber, without linking them?
Thanks,
Jeff
09-04-2014 04:56 PM
Hi DMJeff,
If the two cards are not linked then it will be software timed. If that is OK with you then a reaction time of 0.5 msec from the input or trigger might not be reached as that is a frequency of 2000Hz, which is not achievable using software timing. For more precise timing, hardware timing would be the method of choice.