06-27-2016 08:36 AM
Hi,
I want a program that can grab and save an image and trigger the camera at the same time , as i found two examples here ( https://www.ptgrey.com/kb/10714) one to grab and save and the other to trigger the camera , i wanted to know if there is a possiblity to mix those two programs
you will find attached the two examples and the program where i tried to mix both programs
Any suggestion or idears will be appreciated
Thanks a lot for helping me
06-27-2016 09:00 AM
I've done a fair amount of IMAQdx work, but have never used Trigger Mode. What I've done is set up the camera to run at a certain frame rate (typically 30fps), and let the camera hardware "auto-trigger" itself (of course, I need to start it, which I do, giving me an "uncertainty" of the exact time of 33 msec, one frame period).
In some cases, we have an external event that we want to capture (and that can be considered a "trigger"). What we do is start the camera recording images in a (suitably-large) image buffer, and when the trigger comes along (in a separate, parallel loop), we start code that pulls images out of the buffer and saves them to an AVI file. This allows us to not only capture events starting from a trigger, but to save images that precede the trigger.
For this to work, we created multiple parallel loops, many operating in Producer/Consumer mode. For example, we created a Fixed-Length Queue to serve as the Pre-Event buffer, using Lossy Enqueues to fill it. When the Camera was in the "idle" state, the Image (technically, the Image Buffer) was enqueued. When the Trigger occurred, we switched States (I don't recall what we called it). The Pre-Queue buffer got passed to the "Create/Write AVI File" loop which saved all of the Pre-Event images. Meanwhile, the Camera was filling up a Per-Event Queue. Once the Pre-Events were enqueued, the AVI Loop started processing the Per-Event Queue, up to the number of post-event Images were desired. It also used those post-Event images to restart/rebuilt the Pre-Event Queue. I know, it sounds complicated, but once you think about what you want to do with the Images and when you want to do it, it just becomes a matter of keeping track of Who's On First.
To summarize, we run this as several independent loops running as State Machines, with the loops forming a Producer/Consumer Design where the Producer is the Camera saving its Image (buffer)s in one or more Queues and the Consumer is a State Machine that knows how to process those Queues. I don't remember how we tell the Consumer to start, i.e. how we take it out of its Init (or Ignore) State -- maybe a Notifier?
Bob Schor