genicam / harvesters

Image Acquisition Library for GenICam-based Machine Vision System
Apache License 2.0
501 stars 86 forks source link

How to set value of ChunkModeActive #337

Closed Lichtschwertpiratin closed 1 year ago

Lichtschwertpiratin commented 2 years ago

Dear developers,

When trying to run with ia.fetch() as buffer: as shown in your example code [1], I receive the error RuntimeException: Invalid layout of buffer attached to chunk parser! : RuntimeException thrown (file 'ChunkAdapterGEV.cpp', line 99), just as described in your FAQs [2]. There, you recommend to set ChunkModeActive to "off" as a workaround. Unfortunately, I cannot find an explanation on how to do this, i.e. an exemplary piece of code where the value of ChunkModeActive is changed correspondingly.

I'd appreciate if you could help me there! Thanks!

[1] https://github.com/genicam/harvesters#harvester-on-ipython [2] https://github-wiki-see.page/m/genicam/harvesters/wiki/FAQ

kazunarikudo commented 2 years ago

Hi, you can achieve it by the following line:

ia.remote_device.node_map.ChunkModeActive.value = False

By the way, which version of Harvester are you using now? You can check the value by executing the following command:

$ pip list

There you will find a line for harvesters and its version. Regards, Kazunari.

Lichtschwertpiratin commented 2 years ago

Hi, thank you for the quick response!

Unfortunately, the code line results in an error message telling me that the node does not exist:

  File "C:\Users\sli_user\anaconda3\lib\site-packages\genicam\genapi.py", line 2080, in __getattr__
    return self.get_node(attribute)

  File "C:\Users\sli_user\anaconda3\lib\site-packages\genicam\genapi.py", line 2032, in get_node
    return _genapi.NodeMap_get_node(self, key)

LogicalErrorException: Node not existing

By the way, this does not happen with similar looking commands like ia.remote_device.node_map.PixelFormat.value = 'Mono8' from the example code. My Harvester version is 1.3.6 and my Python version is 3.8.5

kazunarikudo commented 2 years ago

the node does not exist

Maybe you should ask DaHeng if the camera support toggling chunk data. Perhaps the device may not support it.

By the way, could you show me the whole traceback message where you get the following message, please?

RuntimeException: Invalid layout of buffer attached to chunk parser! : RuntimeException thrown (file 'ChunkAdapterGEV.cpp', line 99)
Lichtschwertpiratin commented 2 years ago

The camera is not by DaHeng but SVS Vistek, but yes, I can ask their support.

The full traceback message is:

Traceback (most recent call last):

  File "C:\Users\sli_user\anaconda3\lib\site-packages\genicam\genapi.py", line 2080, in __getattr__
    return self.get_node(attribute)

  File "C:\Users\sli_user\anaconda3\lib\site-packages\genicam\genapi.py", line 2032, in get_node
    return _genapi.NodeMap_get_node(self, key)

LogicalErrorException: Node not existing

The above exception was the direct cause of the following exception:

Traceback (most recent call last):

  File "E:\NewCamera\SVS-Vistek-Control.py", line 40, in <module>
    ia.remote_device.node_map.ChunkModeActive.value = False

  File "C:\Users\sli_user\anaconda3\lib\site-packages\genicam\genapi.py", line 2084, in __getattr__
    raise AttributeError from e

AttributeError
kazunarikudo commented 2 years ago

Hi, thank you for the update. However, the traceback you pasted above is not the one I asked. I need a traceback when you get the following message:

RuntimeException: Invalid layout of buffer attached to chunk parser! : RuntimeException thrown (file 'ChunkAdapterGEV.cpp', line 99)
Lichtschwertpiratin commented 2 years ago

Oh, sorry, my mistake. There it is:

Traceback (most recent call last):

  File "E:\NewCamera\SVS-Vistek-Control.py", line 44, in <module>
    with ia.fetch() as buffer:

  File "C:\Users\sli_user\anaconda3\lib\site-packages\harvesters\core.py", line 2312, in fetch
    buffer = self._finalize_fetching_process(raw_buffer, is_raw)

  File "C:\Users\sli_user\anaconda3\lib\site-packages\harvesters\core.py", line 2245, in _finalize_fetching_process
    self._update_chunk_data(buffer=raw_buffer)

  File "C:\Users\sli_user\anaconda3\lib\site-packages\harvesters\core.py", line 2128, in _update_chunk_data
    self._chunk_adapter.attach_buffer(buffer.raw_buffer[:size])

  File "C:\Users\sli_user\anaconda3\lib\site-packages\genicam\genapi.py", line 2963, in attach_buffer
    self._adapter.attach_buffer(self._buffer, statistics)

  File "C:\Users\sli_user\anaconda3\lib\site-packages\genicam\genapi.py", line 3102, in attach_buffer
    return _genapi._ChunkAdapterGEV_attach_buffer(self, pBuffer, pAttachStatistics)

RuntimeException: Invalid layout of buffer attached to chunk parser! : RuntimeException thrown (file 'ChunkAdapterGEV.cpp', line 99)
Lichtschwertpiratin commented 2 years ago

Hello again,

Maybe you should ask DaHeng if the camera support toggling chunk data. Perhaps the device may not support it.

I received an answer from the camera developer: It seems that the camera does not support chunk data.

Do you know if there is anything else (apart from setting the chunk mode) that I could do to fix the error?

Thank you!

jcormier commented 1 year ago

Our camera also doesn't support Chunk transfers. And ia.remote.node_map.ChunkModeActive does not exist. Sticking with harvesters 1.3.2 until we can figure this out.

Note: Moving this post to here since it fits more than issue #360

OS: windows 10
Harvester: 1.3.8
Genicam: 1.1.0
Python (Anaconda): 3.8.12
GenTL Producer: Critical Link
GenTL Viewer: 2.7.0
Camera: MityCAM-35MMFHDXS
In [5]: dir(ia.remote_device.node_map)
Out[5]: 
['AcquisitionControl',
 'AcquisitionFrameCount',
 'AcquisitionFramePeriod',
 'AcquisitionFrameRate',
 'AcquisitionMode',
 'AcquisitionStart',
 'AcquisitionStop',
 'AdcBlkClamp',
 'AdcCdsGain',
 'AdcSelection',
 'AdcVgaGain',
 'AmpGain',
 'BadPixelReplacementEnable',
 'BadPixelReplacementMap',
 'DeviceControl',
 'DeviceFirmwareVersion',
 'DeviceManufacturerInfo',
 'DeviceModelName',
 'DeviceReset',
 'DeviceSFNCVersionMajor',
 'DeviceSFNCVersionMinor',
 'DeviceSFNCVersionSubMinor',
 'DeviceSelect',
 'DeviceSerialNumber',
 'DeviceVendorName',
 'DeviceVersion',
 'DigitalIOControl',
 'ExecRead',
 'ExecWrite',
 'ExposureTime',
 'FpgaVersion',
 'FrameCountMax',
 'Fx3Version',
 'Height',
 'HeightMax',
 'ImageFormatControl',
 'LineMode',
 'LineSelector',
 'LineSource',
 'LineStatus',
 'Max10CtrlVersion',
 'Max10Version',
 'MinFramePeriod',
 'OffsetX',
 'OffsetY',
 'PayloadSize',
 'PixelFormat',
 'RegAddress',
 'RegValue',
 'Root',
 'SensorHeight',
 'SensorPeekPoke',
 'SensorWidth',
 'SoftwareBuildDate',
 'TestControl',
 'TestPattern',
 'TestPendingAck',
 'TransportLayerControl',
 'TriggerActivation',
 'TriggerMode',
 'TriggerSelector',
 'UserOutputSelector',
 'UserOutputValue',
 'VSkip',
 'Voltage',
 'VoltageSelect',
 'Width',
 'WidthMax',
...
jcormier commented 1 year ago

Note that according to SFNC 2.5 and SFNC 2.7 (the ones I've checked), ChunkModeActive is only a recommended (not mandatory) parameter.

jcormier commented 1 year ago

The following change fixes this issue. Found some misplaced whitespace which caused the "no way to check chunk availability" to be treated as if chunk support was available. I'll create a merge request though it'd be great if a 1.3.9 could be created as well, since I have additional issues with 1.4.0 (#368)

PS C:\Users\jcormier\Documents\harvesters> git diff -U4 
diff --git a/src/harvesters/core.py b/src/harvesters/core.py
index 6f35d90..7623ecc 100644
--- a/src/harvesters/core.py
+++ b/src/harvesters/core.py
@@ -2172,9 +2172,9 @@ class ImageAcquirer:
                 if _is_logging_buffer:
                     _logger.warning(
                         'no way to check chunk availability: {0}'.format(
                             _family_tree(buffer)))
-                    return
+                return
             else:
                 if _is_logging_buffer:
                     _logger.debug('contains chunk data: {0}'.format(
                         _family_tree(buffer)))
JeremyKeusters commented 1 year ago

Hi all,

I'm having the same issue with a Daheng Imaging camera model ME2P-900-13GC-P. I'm getting an Invalid layout of buffer attached to chunk parser! : RuntimeException thrown (file: 'ChunkAdapterGEV.cpp', line 99) error, while ia.remote_device.node_map.ChunkModeActive.value is already set to False.

I am using the experimental ARM64/AArch64 genicam package in combination with Harvesters 1.4.0. I can confirm that this issue is fixed by upgrading to 1.4.1, but this version was yanked.

@kazunarikudo : is there any ETA on when 1.4.2 will be released? It would be nice to have this critical bug fix in as soon as possible. @jcormier : thank you for spotting and fixing this issue, very much appreciated! 🙏

Thank you all again for your hard work on this project!

kazunarikudo commented 1 year ago

@JeremyKeusters Hi, thank you for trying out Harvester and I am sorry for having kept you waiting. I will try to release 1.4.2 in the following days. Regards, Kazunari.

kazunarikudo commented 1 year ago

@JeremyKeusters Hi again Jeremy, I have just prepared a trial branch for you:

https://github.com/genicam/harvesters/tree/draft/1.4.2-beta

Could you try that branch when you can and tell me if it does not break your application, please? If it works, then I will release it and upload the packages to PyPI. Thank you.

JeremyKeusters commented 1 year ago

Hi @kazunarikudo thanks for your quick replies and effort. I have tested this and it seems to solve the issue (just like 1.4.1 did), nothing else is broken on my side. Can I know out of interest why version 1.4.1 was actually yanked?

kazunarikudo commented 1 year ago

@JeremyKeusters Hi Jeremy, thanks for testing it. I appreciate that.

Can I know out of interest why version 1.4.1 was actually yanked?

Sure. I yanked that version due to a defect that I had introduced. I was going to introduce a feature that involves a dedicated thread and I set the feature enabled by default; this is failure number 1. In addition, the thread was not a daemon thread; this is failure number 2. These two failures made some applications hang up because the thread had kept running after the parent application was terminated. In version 1.4.2 I have disabled the feature by default and I have made the thread a daemon thread so that the thread can be terminated once the parent application is terminated.

JeremyKeusters commented 1 year ago

Thanks for the clarification @kazunarikudo . Looking forward to the release of version 1.4.2!