e2v linescan camera

[LightWorker]

I am currently using an e2v UM2 gigE camera (4k) to capture an image. What I have noticed is that after the image has been received and displayed on my PC  there is still communication going on between the camera and PC. This seems to last for the same length of time it took to capture the image. If I attempt to acquire another image before this additional communication has finished I get an error message from the start acquisition vi. Once the additional communication has finished I can acquire another image with no problems.

My question is - what is this extra communication that continues after the image has been acquired and displayed? The fact that the duration of the extra communication is identical to the  image acquisition time is significant I think. Could the camera being sending out a second duplicate image?

In addition the stop acquisition vi gives an error which I clear before the next cycle of the loop is activated. I haven't got to the bottom of this yet.

[BlueCheese]

Hi LightWorker,

My best guess is that the camera is not handling the case properly when we stop and restart it in quick succession. Part of this might be complicated by the fact that IMAQdx does not attempt to change the camera's mode between a continuous and single-shot mode regardless of your acquisition type in IMAQdx. This is for historical reasons because the various modes had not fully been standardized for all use-cases. As a result, the camera is likely still in a continuous mode and thus after acquiring one image it is likely acquiring a second one when you begin your sequence again. Now, normally the Stop Acquisition should guarantee the camera has fully stopped, but some cameras might have "quirks" that they don't fully abort when they are in the middle of an image exposure. That is what i am guessing could be going on here. I'd suggest playing with some of the attributes on the camera and see if you can put it into a single-shot mode so it doesn't start acquiring a second image after the first. A better way might be to not configure/unconfigure the acquisition each time and trigger the camera via an I/O or software trigger each time you want to take an image. This would be more efficient than reconfiguring each time.

Eric

[LightWorker]

Hi Eric,

What you say kind of makes sense.  The fact that the stop acquisition vi generates an error may be indicative that the camera is not being stopped properly.

I am configuring / unconfiguring the camera once at the start / end of the vi but I don't repeat this for every iteration of the loop. I'm also setting the camera to single shot mode during the configuration. 

I will play around with the camera attributes to see if this helps. 

One  other observation - in MAX the snap command seems to work OK  but the grab command gives an unknown gigE error (0x BFF6902A)when stopped.

Thanks

Simon  

[LightWorker]

Hi Eric,

Clutching at straws now.

I am looking at the xml file for this camera in which there is a reference to acquisition mode.  Firstly there is no entry for single shot mode and secondly the value for continuous mode is set to 0. However in LabView 0 represents single shot mode - the mode that I want to work in - whilst 1 represents continuous mode. Could this mean that when I select single shot mode at configuration I could be inadvertently selecting continuous mode? Unfortunately I don't have another gigE line scan xml file to compare the Aviiva xml file with.

Regards

Simon 

[BlueCheese]

Hi Simon,

As I mentioned, IMAQdx's continuous vs sequence acquisition mode is currently completely disconnected from the camera's continuous vs one-shot modes. It is up to the user to configure the camera into a mode other than continuous. The enumeration values between the two thus do not matter.

Unfortunately I do not have a recent e2v firmware to reproduce the problem you are seeing. I'll try seeing if I can update and reproduce what you are seeing. Can you find out what firmware version your camera is using?

Eric

[LightWorker]

Hi Eric,

The firmware version is shown in the attachment.

Thanks

Simon

[LightWorker]

I have received this reply from e2v.

During a stop acquisition, NI sends a Stop commands than try to write "0" in the SCP0 (stream channel register) port : This is their way to abort. 

In the Camera, during the grab, this port can't be written : This means that during a big frame grab (as yours) the Camera send back "Access denied" when the NI soft tries to write "0" in SCP0. This should not disturbe the NI software but it does.

 If you have small images, the end grab is much more frequent then you have the chance to catch this write command when the grab is not active.

There is actually no way to make any change on the Camera (UM2) firmware in order to support this particularity of NI stop command.