time lapse image sequence

[mjd]

I am collecting a series of time lapse images (1 image per sec) that is triggered by a TTL pulse. This is possible using IMAQ List/Copy routines using a single buffer and repeated calls to Copy every ~1 sec to retrieve each image ; the images are then saved to an AVI file. I'm sure there are better ways to do this but this works.

For the timing, which only needs to be approximate, I sample the A-D board 72,000 times (takes about 1 sec) check if the DiG 0 line has gone high and if so, start image collection for 5 min, once every sec.

The problem is that I would like to have access to about 60 of the "pre-triggered" images, i.e. 1 minute of image data BEFORE the trigger TTL pulse. The routine will run for 5-6 hours before the trigger fires and then images will be collected for about 5 min. So, I'd like to collect the image data from min -1 to min 4. I have followed the various threads partially related to this and followed the advice in them (mostly from Bruce) to use the high-level SEQUENCE vi as a template.

The problem with this, is if I put 60 images into the HL sequence vi, I can only sample for the TTL pulse once every MINUTE. I need to sample it once every SECOND. If I deconstruct the HL sequence vi I can find no place in it to sample my A-D board every second.

Does anyone have a solution?

Mike

[BruceAmmons]

Mike,

The big question is how long the TTL pulse lasts.  If it stays on long enough to poll it several times a second, you shouldn't have any problems.

I would try the following:

Create an image buffer that will hold 5 minutes of images at one per second.  This will be circular buffer, and you will have to manage the indexing.  You will either have to increment the index (with wrapping) every time you copy an image, or you can rotate the array of images every time.

Acquire the images in a continuous buffered loop that will hold a few seconds.  Several times a second, poll your trigger and check the acquisition buffer status.  If the trigger is on, start a counter to acquire 4 more minutes of images.  If a new image is ready, copy it to the circular buffer.  You only want to copy images with an index that is a multiple of your frame rate.

This may sound fairly complicated, but it isn't that bad.  It is just a while loop with a couple of cases in it.

If your trigger pulse is very brief, you will need to find a way to register the pulse.

Bruce

[mjd]

---

@mjd wrote:
I am collecting a series of time lapse images (1 image per sec) that is triggered by a TTL pulse. This is possible using IMAQ List/Copy routines using a single buffer and repeated calls to Copy every ~1 sec to retrieve each image ; the images are then saved to an AVI file. I'm sure there are better ways to do this but this works.

For the timing, which only needs to be approximate, I sample the A-D board 72,000 times (takes about 1 sec) check if the DiG 0 line has gone high and if so, start image collection for 5 min, once every sec.

The problem is that I would like to have access to about 60 of the "pre-triggered" images, i.e. 1 minute of image data BEFORE the trigger TTL pulse. The routine will run for 5-6 hours before the trigger fires and then images will be collected for about 5 min. So, I'd like to collect the image data from min -1 to min 4. I have followed the various threads partially related to this and followed the advice in them (mostly from Bruce) to use the high-level SEQUENCE vi as a template.

The problem with this, is if I put 60 images into the HL sequence vi, I can only sample for the TTL pulse once every MINUTE. I need to sample it once every SECOND. If I deconstruct the HL sequence vi I can find no place in it to sample my A-D board every second.

Does anyone have a solution?

Mike

---

Bruce, thanks very much for the suggestion. The TTL trigger pulse lasts from 2-10 secs, so detecting it should not be a problem if I am able to sample that digitial line at least 1/sec. I will attempt to follow your advice; if you can suggest an example vi to get me started, that would help. It seems like I've been through all sorts of combinations of the low and high level vi's, using start, copy, get, buffer commands or snap commands, etc. without success, trying something similar to what you suggested, although not exactly. No longer how I try to delay image acquistion (e.g. 1/sec), with copying the new image into an indexed image array to store it temporarily, every time I do an image acquition the entire image array gets updated. The only example routine that doesn't overwrite all the images immediately is HL SEQUENCE, but that example has the A-D sampling limitation I mentioned previously.

Mike

[BruceAmmons]

I wrote a quick example of the image acquisition part.  While writing it, I remembered you can use the Skip Count to skip frames.  By setting the Skip Count to 29, you will get every 30th frame, which should be once per second.  This simplified my idea and eliminated the second buffer.  If you are using firewire, you will need the more complex solution since I don't think firewire has the Skip Count available.

This example loops every 200 msec, so you should be able to check your trigger every time through the loop and respond accordingly.

This example has not been tested at all, so don't be surprised if there is a bug or two.

Bruce

[mjd]

Thanks for the jump start; I really appreciate it. I will work on it and let you know. I am using both types of cameras but use the standard one, with PCI 1409 for this application.

Mike

[mjd]

Bruce, your method works fine. There is a problem I still need to work out with the final stack of images being out of order, but the basic method works well. I think the sequence problem has to do with how many times the program has looped through the image buffer by the time the TTL trigger pulse arrives. I'm sure I can get this figured out with a little testing.

Thanks again; I was at a real impasse and there seemed to be no examples in the documentation or example vis of doing anything like this.

Mike

[BruceAmmons]

I put a piece at the end that reorders the image array so that the oldest image is first, and the newest image is last.  It may need a little work, but it should be really close to the correct order.

Bruce

[mjd]

I kept that part of the code as you had written it, but the sequence still ended up being mixed up, with the post-trigger image sequence being at various places in the image stack, depending (I think) on how much time had elapsed from the inititation of the program until the TTL trigger arrived and/or the buffer index when the TTL pulse arrived. I'll figure it out with a bit more experimentation.

Thanks,

Mike