PDA

View Full Version : Trigger & Timing Issue LabView / DMx 51BU02



Sheepyhollow
April 20, 2014, 23:19:20
Hello there,

I have another trigger vs. Labview issue and couldn't yet find relevant information within the other related posts. Obviously my understanding of capturing, triggering and how the image buffers work is poor.

Cam is a DMx 51BU02.

My programm runs in cycles and I need a reference image (not time critical) and an externally triggered image (very time ciritcal) in each cycle. The programm basically looks like this:

initialise: open device (live = yes), set trigger "off" (is this necessary?)
start loop/cycle


Reference Image with IC grab image (based on memory snap method) without trigger
Set DeviceTrigger = TRUE
start hardware event which subsequently fires the trigger after 0-300ms (the delay is externally set, trigger pulse length is 50 ms)
use IC grab image (memory snap method) to read out triggered image
Set DeviceTrigger = TRUE
Process images, GOTO 1 (next cycle)


Now the weird thing is that random cycles fail due to a memory snap timeout. Some work as they should, some don't. This is independent of the timeout setting, i.e. it's not too slow anywhere before - there simply is no picture to be snapped in step 4 - as if the camera did not react upon the trigger. Sometimes it works for 20 cycles or so, then I get timeouts, it recovers for 5 cycles, timeout... - it is as random as can be.

Triggering is working fine otherwise in a broad range of frequencies, the pulse is quite a good rectangle, the external timing is precise (┬Ácontroller), we are measurably far off the timeout timescale.

I strongly suspect the reference image (step 1) as the show-stopper in combination with the trigger on/off procedure*. But why?


How do livestream and buffer relate? The Labview "setExternalTrigger.vi" puts LiveStart = True (if it's been TRUE before) but the DeviceTrigger description says "If the trigger is enabled, the video capture device will not send images if no trigger event occurs." So "sending images" is not equal to live stream? Send where? I am a confused...

Shedding light on this would be very appreciated :)


*I can not use the trigger for step 1 as the trigger signal is "hardwired" to another event and I can not change the electronics easily (it's a workaround i shall try to pursue, though)

UPDATE: See reply to this post.

One other question: Does the trigger react on rising or falling edge? In addition to the issue described above, I have some cycles where the image appears to be 50ms "late" (according to the filmed process). Those cycles are also random but not visibly connected to the failing ones. But 50ms is exactly my pulse length...

Thanks for reading this far ;)

UPDATE: I found a threat (11 years old..., however) where Stefan is stating that the trigger/MemorySnap-Method is a bad combination and recommends using the "ImageAvailable"-Event. I shall try this. But nevertheless - the option that there is no image availble would not help - I need my triggered picture ;)

Stefan Geissler
April 22, 2014, 15:09:01
Hello

First of all, trigger and MemorSnapImage combination is not recommended, because MemorySnapImage waits for the next complete image. If the trigger occurs, before MemorySnapImage has started, then you will miss one image.

Therefore, use the ImageAvailable event, which is fired, when a new image is provided and the LiveCaptureContinuous property was set to true before.

However, the timeout can be caused by a frame drop too. Therefore,you may use a lower frame rate or the Processor Idle State Manager. (http://www.theimagingsource.com/en_US/support/downloads/) Maybe this solves your problem.


How do livestream and buffer relate?
StartLive() starts the camera. That means, the sensor is prepared, the software is prepared. If the camera does not run triggered, it triggers itself internally. So you will receive a continuous stream of images. If the camera runs triggers, the trigger pulse must come from outside. (These are the simple words, there are some more differences in the sensor between free running and triggered.)


Does the trigger react on rising or falling edge?
This depends on the "trigger polarity" property. Default is rising edge, as far as I know.

Sheepyhollow
April 24, 2014, 14:06:03
UPDATE

I changed my electronics so that step 1 is now achieved with the same trigger. Additionally, the trigger pulse is shortened to 1-2 ms.

No effect - I still get the random timeouts. The pulse is definitely arriving at the camera, I see it on the oscillosscope.

How is it possible that trigger pulse and MemorySnapImage are out of sync?

How time dependent is the MemorySnapImage method? I thought it just fetches whatever image is in the (last) buffer, no matter how old it is? Or does the method have to be "active" *while* (i.e. before) trigger and exposure happen?

:confused:

Stefan Geissler
April 24, 2014, 15:30:45
How is it possible that trigger pulse and MemorySnapImage are out of sync?

I already wrote, that trigger and MemorySnapImage is no good combination. You do not know, when MemorySnapImage is called. If it is called too late, then you wont receive an image. Therefore, I suggested to use the ImageAvailable event.

Also it can happen, the image data transfer being interrupted and the frame is dropped. Then you also will receive a time out.


How time dependent is the MemorySnapImage method? I thought it just fetches whatever image is in the (last) buffer, no matter how old it is? Or does the method have to be "active" *while* (i.e. before) trigger and exposure happen?

No, it fetches the next incoming images.

Maybe another approach without MemorySnapImage:
You set the .LiveCaptureContinuous property of IC Imaging Control to true. Then every incoming image will be saved into the ring buffer automatically. You can monitor the ICImagingControl.ImageBuffers.CurrentIndex property. If it changed, a new image was provided.

You can access the image then as either ICImagingControl.ImageActiveBuffer or ICImagingControl.ImageBuffers[ICImagingControl.ImageBuffers.CurrentIndex]

You may refer to
http://www.imagingcontrol.com/en_US/support/documentation/activex/prop_descICImagingControl_LiveCaptureContinuous.ht m
http://www.imagingcontrol.com/en_US/support/documentation/activex/prop_descICImagingControl_ImageActiveBuffer.htm
http://www.imagingcontrol.com/en_US/support/documentation/activex/prop_descImageBuffers_CurrentIndex.htm

Sheepyhollow
April 29, 2014, 10:37:22
I already wrote, that trigger and MemorySnapImage is no good combination.

Yes - I fear, my second post and your answer were out of sync, too :)

I was finally able to solve all issues - by not relating on the snap method (this hint was crucial!).

I am not using ImageAvailable because event processing is somewhat tricky in LabView and I did not fully understand how to implement this into my vi structure. But I rely on the trigger being fired and I managed to set the strict timeframe in a way that there always will be an image in the buffer. It's perfect now - no dropouts and beautiful images!

Your hints to Livemode etc. were very helpful, too. Now I understand the combination of settings that finally worked better.


Should there be updates in the future, I'd suggest to put things a bit clearer in the help files. It's all there, actually, but if I search for the optimum trigger-strategy, the relevant steps might be harder to find. Especially the combination with LiveCaptureContinuous. Time-consistent triggering is a common requirement.

Thanks, Stefan! I'm all happy now :)