Problems grabbing images from camera memory (Mikrotron EoSens mini GigE)

[MichaelAivaliotis]

I already started a support ticket with NI (Reference#7256780). However I want to post this out on the forums in case someone else has a solution. I'm running a tight timeline so every little bit helps.

I'm using this GigE camera from Mikrotron (also available under the Fastec brand). It has on-board memory which allows it to acquire images at insane frame rates if you reduce your ROI. I'm using the latest and greatest version of IMAQdx (3.4) and LabVIEW 2009. I've attached the camera datasheet and the GenIcam reference manual for it.

The camera has a quirky startup process. Out of the box you cannot do a snap or a grab because there are no images in memory. IMAQ returns an "Attribute value is out of range" error. This is because one of the attribute ranges depends on the number of images in memory. Since this value is effectively 0, it causes another attribute (StreamEndNumber) to have a maximum of -1. I've figured out a workaround by performing an attribute command called "RecordStart" then "RecordStop". This populates the internal memory. Now you can use the normal LabVIEW snap and grab VIs to get Live images.

However, getting Live images is not good enough. This only helps if you want to align or setup your camera. In normal operation you want to trigger the images into memory then stream the images from memory to the PC after the fact. In order to do this you have to set an attribute on the camera called AcquisitionSource=Memory instead of AcquisitionSource=Live. This is where the problem lies. According to the documentation, you have to execute an AcquisitionStart attribute command and then specify the image frame number. Once you've iterated through all your frames then you execute an AcquisitionStop attribute command. This is if you want to grab a single frame at a time. There is another mode called "streaming" which is faster since you can specify a range of images but I'd be happy to get either of these modes working.

The issue is that when the camera is in Live mode, I can grab the images using the snap and grab VIs. But this does not work in Memory mode.

[MichaelAivaliotis]

If anyone cares and wants to help, I have an update. It turns out that I probably need to issue the AcquisitionStart attribute command in order to initiate any data transfer from the camera memory to the PC. The problem now is that this attribute is not visible in MAX. Not sure why. I looked at the XML file for the camera and the AcquisitionStart attribute command is defined in there, what would cause MAX to block showing it? This means I can't even use it in LabVIEW. Issuing this command causes an "Attribute could not be written" error. So it definitely doesn't like it.

[BlueCheese]

Hi Michael,

I've heard of this camera but have not used one personally. Sorry to hear you are having issues with it. The Attribute Out Of Range issue seems like it would be easy to fix in the XML file to make sure the attributes stay valid at all times. Perhaps you might be able to ask Mikrotron about it.

The reason you don't see the AcquisitionStart command is because we block direct access to it (and AcquisitionStop). This is because these control the flow of data from the camera and must be synchronized with managing the network ports and everything else. If you could write this directly you could start the camera before the driver is ready or stop it while the driver is expecting data still. However, IMAQdx's Start/Stop on the Low-level palette basically just wrap these attributes from the camera's perspective. You should be able to just Start/Stop IMAQdx to get this functionality. Note that this is different from the Configure/Unconfigure.

It sounds from the manual provided that you were on the right track if you simply use IMAQdx Start/Stop in place of the commands (use the Low-Level Grab/Sequence examples as a start). When the AcqusitionSource is set to Memory it seems like it does the continuous streaming instead of a single frame. I'm not sure I understand what the relationship is between the single frame index selector and the start/stop indices and how you change which one you want to be active...

Lastly, since you know how many frames it acquired, if you are able to fit all of them into your host memory at once (<hint> Vision Acquisition 2009 has 64-bit support....), you likely will want to use a Sequence rather than a Grab. This will ensure that the camera can stream them to the PC at the full rate of the GigE connection and the images won't be overwritten even if you process them slower than they arrive.

Let me know if you still run into issues after trying the Start/Stop. I can't understand the manual fully enough to give you an exact sequence of operations you'll need to record and playback data, but I haven't seen anything that would indicate to me it should be a problem.

Eric

[PhilCFastec]

This post appears to be a bit old, but in case you are still having problems:

You've correctly figured out that the camera is capable of very high speed recording.  Much much faster than the ability of the ethernet to capture.  Live mode is used strictly to set up the camera (or to mimic a standard low spped camera operation).  [Record Start] and [Record Stop] are used to actually perform an actual recording sequence.  Once camera memory fills, you can go back and play the images by setting [AcquisitionSource] from Live -> Memory

Furthermore, this camera has many advanced features and special modes, including the ability to record in multiple sequences.  Many of these features are best utilized using the standard standalone control software.  If using Imaq or any other generic GigE vision interface, you life is made much easier if you make sure the parameter [RecordMode] is set to "continuous recording" (not "single recording").

In "continuous" a [RecordStart] command initiates a recording and the camera will record images into it's internal memory continuously, when memory is filled (there's typically 2GB, 4GB or 8GB of memory depending on the camera model/options) it overwrites only the oldes data in a rung buffer fashion.  The camera can be adjusted to pre and post-trigger by changing the parameter [RecordTrailer] to start, just set this to 0 which tells the camera to stop immediately and NOT continue recording post-trigger frames when you send the [RecordStop] command.

This may all sound like a lot of extra work compared to a typical camera, however, it's all due to the fact that as you noticed, this camera is capable ot capturing very high speed video at many thousands of frames/second so you must control the camera reocrd mode into internal memory and then stream it back when the recording is complete (viewing live data while recording is also possible by grabbing once the [REcordStop] command was sent).

Phil Christensen

Fastec Imaging

Applications Engineer

[MichaelAivaliotis]

Yes, this is a very old post! I managed to solve all my problems and got a kick-ass application written that uses the camera. The Mikrotron camera is great and the German tech support staff went out of their way with firmware updates to support me.

The biggest issue I had was streaming data from the camera after it was recorded. The data transfer was prone to errors. I had to develop an algorithm in LabVIEW that basically went through the data packets and reassembled it on the PC side correctly after it was retrieved. Long story, but it was frustrating at the time. Also, the ethernet speed and packet size is important to make the transfer work correctly. A big issue with GigE.

Thanks for creating a great camera product.

You can read the case study about the project here.

[JuJae91]

Hi Michael,

obviously I've still the same problem by streaming the images from camera memory to my host PC.

I'm using a Mikrotron Eosens Cube 7 camera and Labview 2016.

I would be really happy, if you could give me some more details how you finnaly did this or a brief solution of that problem.

Many thanks in advance for your efforts!

Kind regards from Germany,

Julian