AVI Write only saving first frame to file

[biomedoly]

I am designing a VI to capture AVI movies for single-molecule biology experiments. I have created a state machine with three states: standby, activate camera, and record. The idea is that the user will configure the frame parameters and initiate a grab. During the grab, the user may wish to record what is being observed to an AVI. The user should be able to stop the recording (close the AVI) and return back to observation or configuration. All of it works well EXCEPT for the fact that in the record state, only the first frame is written to the AVI file. This is despite the fact that the loop which should write the frames iterates just fine (I used an indicator to be sure). Additionally, I can see the image grab just fine on screen during the Write loop, but the frames are not being saved continually to the AVI file. No errors are thrown off, and the VI can cycle through the states repeatedly as desired without exiting the VI.... I can exit the Record state, re-enter with a different file name and it too will consist of only the first frame it grabs.

 

I have designed the AVI Write loop based on several other VIs and snippets that I have found as examples and which generally work as prescribed. Yet for some reason the AVI Write loop in my VI will only write out the very first frame. I am baffled as to why this is happening.

 

I am using the AVI Write from the AVI1.llb in order to work around the 2GB file size limit with AVI2 Write. We require raw uncompressed U8(grayscale) images at high frame rate (>=60fps) and long times (60 mins), so we go beyond 2GB file size easily and often.

 

I have attached snippets of the Record and Active Camera states, and I would appreciate any help towards resolving this issue. Thank you!

[infinitenothing]

Since you are storing the data uncompressed, maybe you can just write 2D arrays to disk using Write to Binary File

[ensegre]

Without entering into your code, which maybe only suffers from a bug in AVI1.llb (which I never recall to have needed, my customers who shoot at such speeds as to produce TB of videos can't write it as avi in the first place), usually I use a different logical structure, with: ringbuffer, producer-consumer loop, and IMAQdx grabbing driven by the FrameDone dynamical event. The latter I would never have discovered myself, I just found it on the IMAQdx example wich used to come with Labview, and upon which I have since them based an uncountable number of grab-from-usb/firewire/gige camera snippets plus trigger/logging/lighting/messaging/whatever which I've been asked. See if the attached sample is of any help to you. Not much of a state machine, but should cover your functionality. I'm not on windows now, so I hope I'm passing you a functioning version of it.

HaveYouEverSeen.vi

[biomedoly]

Since you are storing the data uncompressed, maybe you can just write 2D arrays to disk using Write to Binary File

I have seen that as a potential solution, and if I cannot get the issue with the AVI Write figured out I am planning to go that route as a last resort. 

 

Without entering into your code, which maybe only suffers from a bug in AVI1.llb (which I never recall to have needed, my customers who shoot at such speeds as to produce TB of videos can't write it as avi in the first place), usually I use a different logical structure, with: ringbuffer, producer-consumer loop, and IMAQdx grabbing driven by the FrameDone dynamical event. The latter I would never have discovered myself, I just found it on the IMAQdx example wich used to come with Labview, and upon which I have since them based an uncountable number of grab-from-usb/firewire/gige camera snippets plus trigger/logging/lighting/messaging/whatever which I've been asked. See if the attached sample is of any help to you. Not much of a state machine, but should cover your functionality. I'm not on windows now, so I hope I'm passing you a functioning version of it.

Thanks, I'll look into the VI you've provided and see what I can figure out. It seems that a producer-consumer loop is very popular for high-speed image grabs, though I decided to try something different for our situation. We're more mid-speed (~60fps), with uncompressed and medium image size (640x480), so I don't think write-to-disk times would cause problems with skipped frames. Nonetheless, if a p-c loop can get things working as desired, I'll happily run with it.