From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

Chunk data support in latest NI-IMAQdx

Solved!
Go to solution

Vision Acquisition Software, March 2010 edition, came with a nice new feature. Chunk data support for GigE Vision cameras, in IMAQdx 3.6. This is a feature I have been waiting for for some time, so I gave it a try with my Basler Runner camera. I'm putting in some remarks/questions:

 

  • I could not find any documentation for the new feature. Is there anything out there? Document, help file, example?
  • I set the "Chunk Mode Active" attribute through MAX. However, the enum attribute "Chunk Selector" is empty and enum values are filled up only after Chunk Mode is switched on and the camera is re-found by MAX. But MAX won't let you save the "Chunk Mode Active" attribute unless "Chunk Selector" is set to a valid value - it pops up the "Attribute out of range" error. To come out of this endless circle, I had to manually edit the ICD file and set "Chunk Mode Active". That being done, I could now set "Chunk Selector" to e.g. "Timestamp" through MAX and thus activate the timestamp chunk.
  • In an image acquisition loop in LabVIEW, I looked at the custom data attached to the IMAQ Image coming out of IMAQdx Get Image. There were only two keys there, "IMAQdxActualHeight" and "IMAQdxLostPackets". No timestamp. So I went back to MAX and turned "Chunk Mode Active" off. After rerunning the acquisition loop, now the timestamp chunk was actually among the custom data - the two keys "IMAQdxTimestampHigh" and "IMAQdxTimestampLow". It's a bit weird that the chunk data is available only when the "Chunk Mode Active" is set to OFF... Nevertheless, the data contained in the keys "IMAQdxTimestampHigh" and "IMAQdxTimestampLow" are perfectly OK, just the image timestamps I always wished to have.
  • Having experienced the weird behavior of "Chunk Mode Active" attribute, I turned the attribute back on and tried setting the second new attribute "Chunk Data Decoding Enabled". In this case, I got a lot of new keys in the custom data of the image. Among them, also "IMAQdxChunkData_CameraAttributes::ChunkData::ChunkTimestamp". Which seemed to be what I needed. Anyway, after converting to U64 type, this key gives me values I don't exactly understand. They are somehow related to the actual timestamp, but I'm not able to decode the relationship.

To sum up, it looks like the new feature is there and providing results. But many things seem to not be working "as expected", forcing me to use really nasty workarounds. Or maybe I'm doing something wrong. Which I cannot find out when there's no documentation.

So, could anyone clarify things a little bit?

View my profile on LinkedIn
0 Kudos
Message 1 of 9
(7,145 Views)
Solution
Accepted by Vladimir_Drzik

Hi Vladimir,

 

Sorry you had to find out the hard way that the documentation is a little "lacking" for this new feature. Hopefully this will be rectified in the next version...

 

I'll try to explain how things work and answer your questions along the way 🙂

 

Chunk Data must be implemented and enabled in two places: the camera and in the driver.

 

How it is enabled on the camera is (right now) very vendor specific. Some vendors might enable it by default, most require it to be enabled manually. I'm not sure if I've seen the issue you are seeing with the "Chunk Selector" feature on the Basler camera. The way it should work is that after enabling "Chunk Mode Active", you would then toggle the "Chunk Selector" through each available value and enable or disable that feature to be included in the chunk data the camera sends. You shouldn't need to edit the ICD file directly... If you just toggle the Chunk Mode Active to "true", move "Chunk Selector" to a valid value, and then click save, does it not work?

 

After enabling the various chunk data elements you want on the camera, you would then go into IMAQdx's "Chunk Data Decoding Enabled" attribute and set it true. This will cause IMAQdx to decode chunk data that is present from the camera and put it into the Custom Data in the Vision image. This is what you are seeing when you see any custom data with the key starting with "IMAQdxChunkData_". The name that follows is the name of the chunk data element (they are specified in the XML like attributes, so they live in the attribute namespace).

 

Now, the two custom data keys you were seeing called "IMAQdxTimestampHigh" and "IMAQdxTimestampLow" are actually NOT chunk data. They are data that is present in the standard image payload of a GigE camera. We have actually always returned those since the first version of IMAQdx with GigE Vision support. These should match up to the exact same values as what you get if you query the "IMAQdxChunkData_CameraAttributes::ChunkData::ChunkTimestamp" on a Basler camera. Interestingly though, as you found out already, when chunk data sending on the camera is enabled, these built-in timestamps will disappear. This is because in the 1.0x version of the GigE Vision spec, the packet format for chunk data did not have the same fields present in the data that the basic image payload has. The idea was that once you enabled chunk data, you had to get all those fields via chunk data. In the newer version of the GigE Vision spec (which is not yet implemented by IMAQdx and might not be on any cameras yet) there is a combined format that allows the usage of chunk data along with the standard image information (like timestamps, image height, etc) without needing them to be sent as explicit chunk data items. However, for all practical purposes, cameras should let you enable the exact same fields missing from the image payload and present them as chunk data instead.

 

Hope this helps explain some of the behavior,

Eric 

Message 2 of 9
(7,133 Views)

I am having difficulties similar to the post above. Can anyone help?

_______________________________________________________

 

I am trying to access a digital input to a Basler ACE camera using chunk data and LabVIEW but I am having little success.

 

I have been able to make the following settings to the camera (as per recommendation in the previous post):

 

Chunk Mode Active           True

Chunk Selector                 Line Status All

 

I have also tried to enable the IMAQdx driver to use the chunk data by setting ChunkDataDecodingEnabled to true. However, when I try to do this LabView returns the error “Attribute not supported by camera”. According to the Basler manual though, chunk data clearly is supported.

 

Can you make any suggestions on what might be going wrong? Is this a camera issue or a Labview isssue?

 

 

Many thanks

 

Tom

 

__________________________________

 

Other details:

 

Camera model                  Basler ACE AC640-100gm

Camera SN                      2103220

NIC model                        Intel

NIC driver                         Basler driver 1.4.2.49156

Software                          LabVIEW 2009

Software driver                 IMAQdx 3.7

 

0 Kudos
Message 3 of 9
(6,605 Views)

Hi Tom,

 

Can you try setting the "ChunkDataDecodingEnabled" attribute via the generic "ActiveAttribute" property rather than via the explicit property control for that item (or just enable it via MAX and save the camera file)? I believe there is an open CAR that that property node element for ChunkDataDecodingEnabled does not actually get handled properly although the underlying attribute does work.

 

Eric

0 Kudos
Message 4 of 9
(6,600 Views)

Eric,


Thanks for the response.

 

I might be wrong, but I don't think its possible to set the "ChunkDataDecodingEnabled" attribute using the generic "ActiveAttribute". I think the "ActiveAttribute" is only able to set camera settings (see attached file). The "ChunkDataDecodingEnabled" setting falls under the "AquisitionAttributes". Is there any other way to set this parameter if we think the underlying functionality does work?

 

I've attached a few screen shots of how the attributes are laid out as well as one from MAX.

 

Also, what is an "open CAR"? Is it like a convertible?

 

Thanks

 

Tom

Download All
0 Kudos
Message 5 of 9
(6,587 Views)

Hi Tom,

 

CAR=Corrective Action Request (a.k.a bug report). This means someone internally or externally already reported the issue and it is being tracked in our database.

 

There is functionally no difference between Camera Attributes and Acquisition Attributes besides the categories in their fully qualified names. The ActiveAttribute can set any attribute in the same fashion. You can either provide just the name "ChunkDataDecodingEnabled" or the fully qualified name with the entire category names. As I said before, you could also just go and change the default setting via MAX and save to your camera file (though you have to change the tree's filter to show All Attributes rather than the default of just Camera Attributes).

 

Eric

 

 

0 Kudos
Message 6 of 9
(6,577 Views)

That seems to have sorted it.

 

Many thanks.

 

Tom

0 Kudos
Message 7 of 9
(6,561 Views)

Hi Tom,

 

its a long shot but can you share your code as an example for getting the chunk data ?

0 Kudos
Message 8 of 9
(3,587 Views)

I will be glad too. Maybe someone can share your code as an example for getting the chunk data.

0 Kudos
Message 9 of 9
(2,583 Views)