Is it possible to generate a software frame trigger that functions as a gate trigger. This can be a toggle of sorts, but an external line trigger is present, and I want to control the number of lines aquired in a frame using a software trigger. The iLinescan interface is not available for the specific camera I want to use, so is there perhaps another method of doing this via code? A toggle on / toggle off is acceptable too, so send a command to start the acquisition, and one to stop the acquisition, irregardless of the number of lines currently aquired in the frame. If no stop command arrives, the max number of lines in a frame should be sent.
1 Like
Hi C,
thanks for the question.
Actually the answer is depending on the used camera / grabber combination and most of the time it is more like a workaround than an official feature. To solve this you want to have a look into your camera or grabber (depending on the interface) configuration and check out how you are able to achieve a gated frame trigger. This feature will be affected by an input and if you are lucky it is possible to select the polarity of this input by software…
…
toggle this feature and check if the camera starts sending frames. Should work at least with the Linea GigE, Spyder GigE series. I never used this feature with CL-Cameras so I am not sure how this works out for framegrabbers but in theory this should work just the same.
Give me a call if you need some more hints.
Regards,
Theo
Ps.: I am not really sure if this is a programming question as long as you know how to setup your camera / grabber using CVB. 
It could be that there perhaps was some interface like iLinescan that I overlooked. I assumed (correctly it turns out) that using the right camera configuration that this would be possible. By setting the configuration you are stuck using a software trigger exclusively.
Let me rephrase a bit then, say I want to interrupt a frame during acquisition, but not discard the partial frame, and I want to do this using a software input, how would I do this?
Hi @CvK
That is indeed more tricky than it sounds… First off: You are right in that the ILineScan would have offered a mechanism for what you want to achieve (you’d be able to specify a callback of type pLSBLOCKCALLBACK, and if that callback - implemented by you - returns FALSE the currently running LSGrab will terminate even if the end of the frame has not been reached. At the moment the pLSBLOCKCALLBACK is invoked, the image buffer has already been updated, therefore you’d be able to interrupt the running acquisition and still “see” the data that has been acquired (technically speaking in line scan acquisition via ILineScan all the grabber driver’s buffers are concatenated into one image). The interruption granularity is limited by the number (and therefore size) of the acquisition blocks.
Unfortunately, the ILineScan interface has only been implemented on very few grabber drivers and is considered deprecated (i.e. even on grabber drivers where it is implemented we usually advise against using it).
What you could try - if the hardware you are using offers that feature - is a variable length acquisition (sometimes also called start/stop trigger mode). In that mode a hardware trigger is being used for defining the number of lines to be acquired (either by providing a start trigger spike and a stop trigger spike or by providing an active level during which acquisition is running). In this scenario you define your image height big enough to cover the largest number of lines you expect the images to have. Then you configure the grabber for variable length (or start/stop trigger) acquisition and make sure the trigger signals are correctly set up.
This is also where variable length acquisition differs from what you’d like to do because typically grabbers - as far as I made their acquaintance - usually expect a hardware trigger for variable length acquisition (I guess the logic behind this goes along the lines that software triggers are usually not as precise as hardware triggers). So when opting for this approach you’ll either need to use an I/O board or wire one of the grabber’s digital I/Os that you can control (if such a thing is available) to the relevant trigger input…