kbaker wrote:
Should I use the WriteRegister right after the StartAcquision.vi, or right before the StartAcquision.VI? I have always been a little confused on exactly when I should be changing the camera parameters, the start acquistion VI, the configure acquistion VI, and the register for events for the frame done event. Can someone give me any information on the right order I should call the VIs?
"Configure Acquisition" sets up our driver and the camera to be ready to acquire. It is at this point internal buffers are allocated and we determine how we will interpret the image coming from the camera (pixel format, etc). At this point any features of the driver or camera that would invalidate any assumptions about the acquisition should not be written to. The driver will ensure you cannot modify these settings through the attribute mechanisms, but if you write directly to the registers it would be up to you. This is essentially equivalent to "arming" the acquisition.
"Start Acquisition" really just hits the "start bit" on the camera and is designed to be as fast as possible. It is at this point the camera is free to start sending images at any time. You can start/stop the acquisition multiple times without re-configuring if you do not change any configuration parameters as described above.
Where you do your register writes would depend on what type of feature it is. If it is some sort of trigger configuration you likely want it before Start because you don't want the camera to be using a different trigger setting when we start it. Since it is unlikely that this trigger setting would be affected or be locked down by Configure Acquisition, it can likely be done at any point after opening the camera, although you likely want to be careful with how you order it with respect to attribute operations that touch similar registers because all the feature and register invalidation that the XML file uses to describe how modifying one feature may affect another one will not be taken into account.
Also, I would be hesitant to recommend using the Frame Done event if you are immediately going to then do a Get Image on that buffer number. LabVIEW's event mechanism has various limitations that usually don't mix well for most imaging applications. If you are waiting for an image, it is usually much better to simply block in the Get Image VI.
kbaker wrote:
I don't understand why I am getting significantly different times when reading out the images after the level high trigger is completed? I am using a labview ms timer before and after reading out the image to determine how long it takes to read out each image. It is my understanding that it should take about 8 ms everytime (because camera's acquisition frame rate is 120fps) to read each image at full resolution, so why is it sometimes ~100ms and others it is ~1ms? It seems that the first image read out time is always about 8ms when my trigger pulse duration is much longer than 8ms (e.g. 100ms), but the remaining read out times are only a few ms (e.g. 1,2,3ms), but can be as large as 100ms too? Although when I set the trigger pulse less than 8ms it seems that on average the readout time is about 8ms, but sometimes it too can only read a few ms instead of about 8ms? My main concern is that when I am reading very short times (e.g. ~1ms) I am not actually reading the last image, but rather the one that was acquired before since it is much shorter than the camera's acquisition frame rate. Also my other concern is that when my exposure time is longer than 8ms (e.g. 20ms) that my camera is not exposing the image for the entire time the trigger pulse is high, since the readout time is not even close to the camera's frame rate (e.g. 1,2,3 ms instead of 8ms)?
How are you doing your Get Image call? Are you asking for a specific buffer number or are you asking for the "next" image. Next image means to take the currently last acquired buffer number (acquired, not actually retrieved by the user) and add 1 to it. It is more used for the case where you always want the latest image without repeating images. It is usually not good to combine this with triggered cases where you want to retrieve every image. You can get odd timing effects because depending on when you start waiting for the image, the time you wait may be different depending on whether one has recently arrived or not.
kbaker wrote:
Do you think it would save me any time to use the stream hold parameters until after I am done acquiring my images? Or at the very least if I use this camera parameter I will ensure that the time between each image is about 8ms, because it won't depend on what my windows OS is doing at the exact time I request to read the image? Then after I am done with my sequence of images I can read them out indivdually with the get image VI.
The stream hold feature on the AVT/Prosilica camera is different from buffering it within the driver. You would only want to use this if you didn't have the network bandwidth for the camera (or usually more than one camera) to send their images instantaneously. You probably want to buffer it within the driver. You can either do a continuous acquisition and request buffers by buffer number or you can do a non-continuous (sequence) acquisition that is of a fixed number of images. The transfer is likely not the reason why you are seeing inconsistent frame times, it is likely due to not requesting specific buffer numbers.
It may be good if you could include a simple screenshot of your acquisition structure so we could get a better idea of what your code is currently trying to do.
kbaker wrote:
Anyone have any idea how long does it takes to update the camera gain? Before I always took a few images or waited some time before taking the next image to ensure that the gain settings were changed on the camera.
This is camera-specific. When you write a camera attribute, we will block that call until the camera says it has completed. Some cameras guarantee that any images *acquired* after that point in time will have that new setting. The important thing to recognize is that there is a fair level of buffering between the sensor, camera internals, and the driver and so unless you are controlling the triggering or stopping/starting the camera in between, we have limited visibility as to when that setting takes effect.
Hope these answers help,
Eric
