I am working with a Linea and acquiring long images in the Frame Burst Active mode.
I am facing a technical difficulty: when I get the successive frames generated when the trigger is active, I don’t know if a frame is the last one. Well, in general it will be incomplete and I can just test the number of lines received, but if the last buffer is full by coincidence, that won’t work.
Is there a reliable way to know that the frame is the last ?
Personal note:
It could well be impossible for the driver to tell that a frame is the last, if the trigger goes low a little after the driver has seen a full frame. But then the next frame should be issued with a heigh of zero line.
Say frames are 1000 lines high (0-999, then 1000-1999…) and the trigger occurs bewteen lines 999 and 1000 but a little too late, after the first frame has been confirmed. Then the next frame shoud be empty (because the trigger went down before line 1000), but a frame should be generated anyway to let the user know that acquisition of this image is over.
this is more or less a hardware-question. This forum is dedicated to all questions regarding and not all our products (as e.g. Cameras, Framegrabber or 3rd Party Software). Questions regarding those other products please forward to our support department using the hotline or support e-mail address.
Regarding you question I would suggest that you use the counter of the camera and increase it with every falling edge of you gate. The counter value can be written into the metadata of the image. This way you will always know which images are belonging to one gate cycle.
How to readout the values with CVB would be another question .
Most of your questions are regarding CVB so I think this was the right procedure and we are happy that you are using our forum for your questions. Furhermore I hope that you are setisfied with the support you already got here.
However, the right procedure for hardware related questions is still to contact us through our hotline or e-mail address. Another reason for this is that we need delicate data like your real name, customer number, order number etc. as our no-cost support service only regards products which are sold by Stemmer.
As your local support department is in holiday you are welcome to use our german hotline system ( +49 89 80902-200 | support@stemmer-imaging.de)
Not yet. I need to find out how to configure the counter to count the pulses, then to store this value in the metadata (if not implicit), then to read back the metadata from the frame.
Anyway, I am not sure that this is useful at all. If the trigger goes low between two frames, I guess that no empty frame will be emitted and I will not know that I received the last frame of the image. I’ll have to wait for the first frame of the next image to know, which can be minutes later. This is not what I want.
I am trying to use the FrameBurstActive mode. Assume the frame size is 1000 lines.
If the trigger goes up for 4321 lines, I will receive 5 frames, the last of which holds 321 lines. So I know it is the last one for this capture.
But if the trigger goes up for 5000 lines, I will receive 5 full frames and be unsure that the fifth is the last one.
And I cannot wait until the next capture to know.
A timeout is not a solution because in this application the next capture can arrive quickly as well, you never know. Testing the trigger while getting the frames is also not the solution because the frames are queued and received asynchronously.
Only the camera knows that the trigger has gone down and there are no more lines to be acquired, it has to somehow communicate this to the application.
of course you are correct here. You would have to wait for the next frame, poll the input status or the current value of the counter. In my opinion the metadata are the most reliable way to distinguish between two different burst acquisitions.
However, I think I found exaclty what you are looking for. I do not think that this is a UseCase the Dalsa thought about but it should work:
Use Timer1 with a short duration (~1) and start the timer with the falling edge of your gate trigger.
This way there will be always a Timer1End Signal when your gate is falling.
Select one of the outputs and use “Pulse on: End of Timer 1”.
Now you are able to register an GigE Vision Event on the selected output and this enables you to get a callback in your software as soon as the gate signal is falling.
I made a little test myself today and it seems to work pretty well but in the current state I can not tell how reliable this is.
Let us know if you need any help to setup the callback.
Sorry, but no. The fetching of the frame is asynchronous with the real-time events, such as the trigger signal. There is no temporal relation between the event that will be raised and the completion of the G2Wait call that delivers the buffer.
So I can be warned that the trigger was lowered, but I won’t know after which frame.
The trigger information MUST be attached to the buffer.
I am sorry I was not clear enough. Mostly the solution consits of a combination of two features:
This way you always will know which images are belonging together but as you mentioned before this will not be enough as you would always have to wait for the next gate cycle.
Adding the following, however, will give you the exact moment of each falling gate. In combination you should be able to distingish between two different gate cycles.
If you need help setting this up please contact us via phone or e-mail. If necessary we can have a remote session regarding this.
The callback might very well be called when another, earlier frame is being processed. Because the processing of the frames is delayed due to latencies.
Then you still don’t know if the frame is the last or not.
Transmission of the frames starts while the first line of the camera is acquired. The frame will be finished and completely transferred to the ringbuffer of your system shortly after the event occures.
If you have processed a full frame (in your case the second) and the gate end event occured during processing check for a pending frame (see G2GetGrabStatus(...)). If there is a frame already delivered call ‘G2Wait(…)’ and check the metadata of this image.
Possibly you will have to implement a very short delay to be sure that the last image is delivered before checking for pending frames.
I have already asked Dalsa what the camera is doing in this special situation. As long we are waiting for a better solution you will have to live with this workaround.
and not all our products (as e.g. Cameras, Framegrabber or 3rd Party Software). Questions regarding those other products please forward to our support department using the hotline or support e-mail address.
.
+49 89 80902-200 | 
