IMAQ Double Trigger Issue

[JesseD]

Hello Dallin,

We were not able to locate a camera link version of the CV-M4. However, we do have another test we would like you to try. Instead of using external hardware to generate the trigger signal, we would like to have you test this by using the IMAQ board to generate the pulse.

The example you have been using can be modified by adding the IMAQ Generate Pulse VI in 2 locations: once right before the IMAQ Configure Trigger and once right after the while loop. The first is to start the pulse. Configure it to generate the pulse on the same external trigger line you use to trigger the acquisition. You will also need to specify "Immediate" for the signal and the pulse parameters. The second instance is to stop the trigger (you only have to pass the Pulse ID and the "Stop" mode). The attached image illustrates the inputs needed (it is not the entire diagram, therefore it is missing most of the example program and a few connections).

With the parameters shown, my IMAQ board triggered once per second (500ms pulse width) as expected. Let me know if you continue to see the double trigger issue.

Best Regards,

Jesse D.
Applications Engineering
National Instruments

[PTI@PCI]

Hi Jesse,

I inserted the changes as requested. It appears that the modified example with the IMAQ Generate Pulse.vi also triggers once per second (that is, only on a LO>HI transition), matching your results. However, when this modification is removed, the example resumes acquiring images on both LO>HI and HI>LO transitions (double-triggering).

I also compiled and ran both examples (with an without the Generate Pulse.vi) on my second computer (with Labview 7.0/IMAQ 3.1.1). I observed the same results as on my lab computer.

Thank you for your continued attention to this issue.

Best Regards,

Dallin

[JesseD]

Hello Dallin,

If generating the signal from the IMAQ board removes the "double trigger" issue, then I would expect that the external trigger is the culprit. Would it be possible for you to add a simple debounce circuit to the trigger to see if the behavior improves? This KB discusses one potential way to debounce a digital signal.

Best Regards,

Jesse D.
Applications Engineering
National Instruments

[PTI@PCI]

Greetings Jesse,

I thought we already ascertained that the "bounce issue" was not the source of the problem. A "bouncing" input implies that I am using some sort of mechanical switch or other noisy switching method. This is not the case. I am using a square wave generator (the output of an astable mode 555 timer circuit) and I can assure you that the trigger signal being supplied to the IMAQ board is absolutely clean. Please review the oscilloscope image I sent on 4/28 showing a typical trigger signal.

Lets consider the facts so far:

1) All trigger signals are free of noise/bounce.
2) Image acquisition occurs on both the rising edge and the falling edge of each trigger signal.
3) A single image acquisition occurs if the pulse width of the trigger signal is less than 5ms.
4) A single image acquisition occurs when generating an internal trigger signal via the 1428 board.
5) Changing the state of the Trigger Polarity input on the IMAQ Configure Trigger.vi has no effect.
6) This problem has been reproduced on two different computers and three different 1428 boards.
7) This problem occurs using IMAQ version 2.6.1, version 3.0, or version 3.1.1.
😎 This problem occurs using Labview version 7.0 or version 7.1.

Please review this issue carefully and supply me with a solution. My project time grows shorter and I must have a fix or I must build a one-shot board to patch the problem, which hardly seems that this should be necessary to do.

Thank you for continued efforts.

Best regards,

Dallin

[PTI@PCI]

Hi Jesse,

While double checking a few things on my last post, I found that the "double trigger" problem now occurs only when the trigger pulse is greater than 40ms in width, a ten-fold increase from before. This must been because I upgraded to IMAQ 3.1.1 and/or Labview 7.1 (my previous measurements were taken when IMAQ 2.6.1 was installed).

However, this still doesn't help me since the customer's host machine sends a pulse based off a proximity sensor target. This sensor turns ON the input when the leading edge of the product is in position under the camera. Due to the size/location of the proximity targets, the pulse may stay on variably between 60-100ms before turning off.

Since time is running short, I think I will just go ahead and build an interface board to condition the signals before introducing them to the 1428 board.

In any case, I would still consider this issue unresolved since the IMAQ/1428 system does not operate as expected, primarily due to the fact that the Trigger Polarity input in the IMAQ Configure Trigger.vi appears inoperable when using an external trigger. That is to say, changing the logic state of this VI's input has no effect on image acquisition. But then again, it seems to work fine when using an internally-generated trigger.

Thanks for your help.

Best regards,

Dallin

[JesseD]

Hello Dallin,

As you noted, the key appears to be in the trigger signal somewhere. When the trigger is generated from the IMAQ board, it works as expected. However, with the trigger signal from the function generator you are using, a buffer is acquired on both rising and falling edges. Something with the trigger from the function generator is most likely the cause of the problem. As I mentioned before, triggers are used very often with this IMAQ board and driver. The polarity function has been thoroughly tested as well.

A couple suggestions for alternatives to building the one-shot board that you might be interested in trying out:

1) Input the trigger on external trigger line 0 and use the IMAQ Trigger Route VI to route line 0 to line 1. Then configure the acquisition to trigger off of line 1 (instead of directly off of 0).

2) Generate the pulse from the IMAQ board as you did in your testing (use line 1), but use External Trigger 0 as the signal source (instead of immediate). You would also want to set the mode to Rearmed Pulse rather than Pulse Train. This way, when a trigger is received on line 0, the IMAQ board will generate a pulse on line 1 that could be used as the trigger source for the acquisition.

If you are still interested in troubleshooting the main issue, could you send a screen shot of the trigger pulse zoomed in to display only the rising or falling edge (micro-second or even nano-second level)? This way we could calculate rise time of the pulse.

Best Regards,

Jesse D.
Applications Engineering
National Instruments

[PTI@PCI]

Hello Jesse,

Nanoseconds? This comment made me wonder so I decided to try an experiment. Like I had done before, I directly wired External Trigger 1 to External Trigger 0 and used the IMAQ Trigger Drive.vi to output a 100ms pulse once every 3 seconds. The system works as expected with one image acquired according to the Trigger Polarity setting.

Then I made only one change, I inserted an opto-isolator (with a rise time of ~150µs and a fall time of ~5µs, as seen on my oscilloscope) between the Ext Trig 1 and Ext Trig 0. Interestingly, when I ran my VI with the Trigger Polarity set to FALSE, the ol' double-trigger problem appears. When Trigger Polarity is set to TRUE, only one image is acquired. As a side note, the 555 timer circuit I used had about a 250µs rise/fall time.

It seems I had no idea how extremely sensitive the 1428 is to ON/OFF state changes. I think it best at this point to request NI's minimum requirements, and other important characteristics, of the trigger signal that the 1428 board requires. Particularly, what is the minimum rise/fall time specified for the DIO lines on this device? I can find no information on this in the PCI-1428 manuals or on the website.

Thanks for your help.

Dallin

[JesseD]

Hello Dallin,

Sorry for the delay in the post. I have been working with our developers here at NI to try to reproduce and further investigate the issue you are seeing.

I have been able to reproduce the issue using a signal with a 1µs rise/fall time (linear ramp). I also measured the rise/fall time of the signal produced by the 1428 at about 25ns.

This is the extent of the information I have at this point in time. However, we are actively looking into this issue further for you. Please let me know if you have any other findings, questions, or concerns.

Best Regards,

Jesse D.
Applications Engineering
National Instruments