Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

The NI 1427, NI 1429, NI 1433, and NI 1435 can generate a maximum of 3 pulses.

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

 

 

0 Kudos
Message 1 of 12
(5,631 Views)

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.

Paolo F.
National Instruments
Applications Engineer
0 Kudos
Message 2 of 12
(5,604 Views)

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

 

0 Kudos
Message 3 of 12
(5,603 Views)
Maybe you could clarify your exact pulse requirements better. There are 3 pulse resources on this hardware that can act independently. Each one can generate a single pulse or a continuous pulse train that will continue forever. Do you need more than 3 I/O lines to pulse independently and simultaneously?

As far as synchronizing with a DAQ card, you can use the RTSI connector and export/import signals between the two cards. This would allow you to synchronize between the two cards.
0 Kudos
Message 4 of 12
(5,593 Views)

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

 

 

0 Kudos
Message 5 of 12
(5,576 Views)
Do your stimuli overlap? As long as you "stop" each pulse after it is done you can re-use the resource. Thus you can have up to three _simultaneous_ stimuli but as many as you want over time.

As far as synchronizing things with a DAQ card, take a look at what signals you can export from each over RTSI. I am confident you can find a way to make that work if you wanted it to.
Message 6 of 12
(5,573 Views)

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

 

0 Kudos
Message 7 of 12
(5,532 Views)
I am fairly certain it unconditionally stops when called.
0 Kudos
Message 8 of 12
(5,526 Views)

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

0 Kudos
Message 9 of 12
(5,508 Views)

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.

Paolo F.
National Instruments
Applications Engineer
0 Kudos
Message 10 of 12
(5,488 Views)