IMAQ Double Trigger Issue

[PTI@PCI]

I am currently developing a program to acquire images via the external trigger on my 1428 board. While examining the various "triggering" example VIs, I have noticed that that Labview/IMAQ does not seem to react as expected to incoming trigger signals.

Here is what I am seeing: On my test-bench setup, I have a photo sensor connected to deliver a TTL level signal to External Trigger 0 on the 1428 board. When I run the LL Triggered Ring without Timeout.vi with the Trigger Action set to Trigger each buffer, the system acquires an image on both the leading and trailing edges of the trigger. In other words, I get an image acquisition when I block the sensor beam, and a second image acquisition when I unblock the sensor beam. My oscilloscope has verified that all incoming trigger transitions are clean single LO>HI or HI>LO events.

My assumption is that if I set the Trigger Polarity in the IMAQ Configure Trigger to TRUE, I should expect that the system will acquire one image only when the TTL level jumps from LOW to HIGH, and ignore the opposite transition (HIGH to LOW). I have examined and manipulated various settings within this VI and see no way to prevent this "double-triggering".

Question: How do I configure, for example, the LL Triggered Ring without Timeout.vi so that the system acquires only ONE image on an external trigger event, according to the actual Trigger Polarity setting?

Thanks in advance for any advice/help you can provide.

Dallin

Hardware/Software:
Labview 7.0/IMAQ 2.6.1/IMAQ PCI-1428/JAI CV-M7+CL/PCI-DIO-96/Pentium 4 HT/XP-Pro SP2

[JesseD]

Hello Dallin,

I have worked with triggering the 1428 in the past, and not ran into the situation you are describing. Typically, the behavior you are experiencing is due to a "bouncing" trigger signal. However, since you said it looks clean on a scope, this is probably not the case. Is there any way you can send me a screenshot of the low-to-high and high-to-low transitions you see on the scope?

The only other difference I can think of is that you are using NI-IMAQ 2.6.1. I have used both NI-IMAQ 3.0 and 3.1 and not seen the behavior you are seeing. IMAQ 3.0 introduced a new underlying architecture for acquisition, but I'm not sure if the trigger handling changed. Trigger handling did change in 3.1 to add support for new hardware (VI was renamed to "IMAQ Configure Trigger2" and changed the Boolean for polarity to an enumerated list). Both of these versions support LabVIEW 7.0. I would recommend upgrading to the latest version, even if this doesn't resolve this particular issue. Is there a reason you are still using the 2.6.1 version (note that IMAQ 3.1 does not support LabVIEW 7.0RT)?

Let me know, and I can continue to investigate the issue for you.

Best Regards,

Jesse D.
Applications Engineering
National Instruments

[PTI@PCI]

Greetings Jesse,

First, thank you for responding to my post. It is much appreciated.

Attached is an image of a 40ms signal pulse generated using an astable 555 timer circuit. As you can see, it is a very clean transition. but as I stated previously, I get an image acquisition on both the leading and trailing edges of this pulse. I have noted that if the pulse width is less than ~4ms, there is no "double-trigger" event. It seems that the system completely ignores the Trigger Polarity setting and no matter what I do I cannot get a single acquisition (other than building a one-shot board with a <4ms output).

I have upgraded to 3.0 and still see the same effect. Do you think it is because I have two 1428 boards (2 cameras) installed and am trying to acquire one image from each camera on a single trigger being sent to both boards via the External Trigger 0 signal line?

Thanks

Dallin

[PTI@PCI]

Also, while searching the discussion board further, I found a person who had a similar problem:

http://forums.ni.com/ni/board/message?board.id=200&message.id=392&requireLogin=False

[JesseD]

Hello Dallin,

When you upgraded, did you install 3.0.0 or 3.0.1? After some research, it appears that 3.0.1 may have fixed some triggering issues.

In general, it would be best to have you upgrade to 3.1.1, unless you are using LabVIEW 7.0 RT (then stick with 3.0.1).

Also, can you try running the LL Trig Ring example (the one that uses timeouts)? After looking at the code for the other example, I discovered why your trigger works with a 4ms or less pulse width. Basically, the acquisition loop has a 5ms polling period. If two buffers are acquired within the 5ms, only the most recent of the two are extracted. In your case, both rising and falling edges are probably triggering, but the code only extracts the second one.

If that example behaves the same way, can you send me your camera file? I noticed that NI does not have an existing camera file for you camera. Did you create the file, or obtain it from another source? Before you send it, make sure all of your settings are current in MAX and save them. This will update the camera file to your current config.

Best Regards,

Jesse D.
Applications Engineering
National Instruments

[PTI@PCI]

Greetings Jesse,

Thank you for your continued help.

I did upgrade all the way up to Version 3.1.1., but found that I still had the same "double-trigger" problem. However, I have since reverted back to 2.6.1 because the later versions of IMAQ caused five of my previously written programs to cease to function properly on my lab computer. They worked perfectly fine in IMAQ 2.6.1, but I had a list of errors popping-up in 3.1.1. Unfortunately I don't have the time to go over all these programs and re-write them into an operating state for 3.1.1. These are not small programs, some total up to 12Mb of VI files and uses an extensive amount of IMAQ VIs that were apparently changed/modified.

As you requested, I ran the LL Trig Ring example, but I had to modify it so the program can sit in a continuous loop waiting to acquire images on Ext Trig 0. I did this by setting the timeout period to 9 billion (I really fail to see the usefulness of a program that quits operation after a few seconds just because it didn't get a trigger signal). In any case, I still get the double-trigger problem in this example too.

As requested, attached is the camera file for my JAI CV-M7+CL cameras. You are correct, I wrote the file manally using an old CV-M4 camera file as a template, and upgrading to the CV-M7 using the commands listed in JAI's Operation Manual. If you think this is the source of the problem, then by all means, please look it over and let me know.

NOTE: I added the .txt extension to the end of the file because NI-board said it was an invalid extension.

I just can't figure out why all the examples and my own VIs all give me a double-trigger. Any help you can give is very much appreciated [by my customers too].

Thanks,

Dallin

[JesseD]

Hello Dallin,

Are you able to successfully run a continuous, non-triggered acquisition (such as a Grab in MAX)? What frame rate do you get?

You mentioned that a 40ms pulse causes the double-trigger, but a 4ms pulse does not. Have you tried any other values than these? For instance, have you tried a 100ms pulse?

I also noticed that the default/current mode in your camera file is continuous. Have you tried asynchronous reset mode? What behavior does it exhibit?

Sorry for all the questions.

Best Regards,

Jesse D.
Applications Engineering
National Instruments

[PTI@PCI]

Hello Jesse,

No problem with the questions, if it helps to get to the bottom of this issue, ask away!

Yes, I can run continuous non-triggered acquisitions with no problems. MAX indicates that the frame rate is 24pfs.

I've tried various pulses all the way up to 1sec. It appears that any pulse greater than 4ms causes the system to exhibit the "double trigger" problem.

Oops... The file I gave you was copied out of my laptop computer, not my lab computer. They are the same but the one I gave you was setup from another job. The setting I am using is Asynchronous with Trigger Mode set to Edge Pre-select. I've tried various combinations of other settings in this file, but the problem still exists.

Today I wondered if my lab computer only had this issue, so I dug out a brand new Dell 3.2Ghz computer from our stock, installed a new 1428 board, Labview 7.0 Runtime, and IMAQ 3.1.1., then compiled the LL Triggered Ring without Timeout.vi and ran it on the new computer with a new camera set to Asynchronous reset mode. While triggering External Trigger 0 input with a 1000ms ON and 1000ms OFF pulse period (using a clean square wave generator), I got the same "double-trigger" problem.

Since I now have two computers that exhibit the same problem, it occurs to me that perhaps the underlying IMAQ.DLL is simply ignoring the trigpol parameter input and acquires a new image regardless if the trigger polarity is transitioning from OFF>ON or ON>OFF. Just what is the Trigger Polarity input on the IMAQ Configure Trigger supposed to do? But then again, I might be completely missing something in the setup/configuration and my brain hasn't stumbled across it yet.

I know I can work around this problem it with a one-shot board that takes a trigger input at whatever length and outputs a 3ms trigger pulse to the 1428 board. But I really would like to avoid doing this if possible so I don't have to explain to the customer what that "little one-shot board" is for.

Thanks again for your attention and assistance.

Dallin Katt
Design/Applications Engineer
Raton Services, Inc.

[JesseD]

Hello Dallin,

We are going to try to reproduce the behavior you are seeing. Unfortunately, we do not have a CV-M7+CL to test with. However, we may be able to obtain a CV-M4+CL, which is very similar to the M7.

Triggering each buffer is a highly used feature on the 1428 (and other IMAQ boards). The behavior you are seeing is not expected. Let me know if you have any other information that may be useful for our testing.

Best Regards,

Jesse D.
Applications Engineering
National Instruments

[PTI@PCI]

I don't have much more to add, but if it helps, here is an actual movie showing the problem first hand (hopefully the NI board system will accept it).

Let me first describe the test-bench setup. I bread-boarded a 556 timer IC circuit with two square wave outputs. One output drives a modified calculator to act like an event counter (I needed something to change from one image to the next). The second output (which has a 1sec ON and 1 sec OFF period) is connected to the External Trigger 0 input to the 1428 board. Both outputs operate independently of each other.

The movie starts showing a nearly-unmodified LL Trigger Ring without Timerout.vi file, a vi file straight out of the Example Browser. The next scene shows the front panel with the External Trigger input flashing ON and OFF. As can be clearly seen, the image is updated on both rising edge and trailing edge events. Even though I set the Trigger Polarity parameter to TRUE, apparently to trigger on a rising edge event, images are acquired on all transitions. I see the same occurance on both computers in my lab.

I really would like the system to acquire an image only on a rising edge of a trigger event, and to ignore trailing edge events. One would assume the Trigger Polarity parameter is the control to do this. Or

I will await the results of your investigation. If you cannot gain access to a CV-M7 camera, let me know. I can send one of ours to you if necessary.

Thanks for your help,

Dallin K
RSI, Inc


Note: The movie uses MPEG-4 (XVID) codec. You can download this codec from here if you need it: Fourcc.org