Symptoms
After updating Impact Acquire to version 2.32.0 or greater while a version smaller than 2.32.0 was running before a client application no longer terminates. When attaching a debugger it can be seen that the function mvIMPACT::acquire::FunctionInterface::imageRequestWaitFor never returns.
Cause
The default value of the property mvIMPACT::acquire::BasicDeviceSettings::imageRequestTimeout_ms has been changed according to the following table:
| Impact Acquire version | Default value of the 'ImageRequestTimeout_ms' property |
|---|---|
| < 2.32.0 (May 8, 2019) | 2000 ms |
| >= 2.32.0 | infinite |
This was done as in the past the timeout caused by this property was a always a great source of confusion because effectively there are 2 timeouts affecting the overall behavior of the acquisition engine as explained here: Timeouts
This change however has potential effects on applications not dealing with abort conditions properly. Applications not cleaning up e.g. by calling mvIMPACT::acquire::FunctionInterface::imageRequestReset AND calling mvIMPACT::acquire::FunctionInterface::imageRequestWaitFor with an infinite timeout AND not explicitly setting the value of the mvIMPACT::acquire::BasicDeviceSettings::imageRequestTimeout_ms property might suffer from this change as now by default a buffer never times out. So in an application where e.g. triggered images are no longer arriving (because the trigger signal has already been switched off) now the application might wait forever when shutting down while previously the application did shut down eventually after some time.
Resolution
The affected application can be changed
Several things can be done to overcome potential problems. All the guidelines presented here should be followed in any case and not just because of the problem described here!
- Always make sure no more buffers are active when shutting down the application
- If the application still actively waits for buffers with an infinite timeout but no more buffers are delivered by the device call mvIMPACT::acquire::FunctionInterface::imageRequestReset from a separate thread to unblock the mvIMPACT::acquire::FunctionInterface::imageRequestWaitFor function
- Do NOT call mvIMPACT::acquire::FunctionInterface::imageRequestWaitFor with an infinite timeout but with a reasonable timeout interval of e.g. 200 ms and call it in a loop. Whenever no new buffer became ready simply call it again. This way the capture thread stays responsive and can be terminated in a worst case after one full timeout interval has elapsed even without the need to call mvIMPACT::acquire::FunctionInterface::imageRequestReset in parallel
- Do NOT rely on default values, but explicitly set the value of mvIMPACT::acquire::BasicDeviceSettings::imageRequestTimeout_ms if desired (if all the previous guidelines have been followed there should hardly be a reason for this one)
The affected application can not be changed
If the affected application can not be modified the previous behavior can still be restored if a setting is loaded by the application(from a file or (on Windows®) from the Registry). When this is the case simply edit the mvIMPACT::acquire::BasicDeviceSettings::imageRequestTimeout_ms parameter by removing the default flag and/or the actual value of the property:
Setting in a file
In the setting XML file locate the property:
<Property name="ImageRequestTimeout_ms" default="1" position="16" flags="7" size="1" formatString="%d ms" valType="1"> <Value index="0" val="2000 ms"></Value> </Property>
You can change it e.g.by removing the default flag like this to restore the previous behavior:
<Property name="ImageRequestTimeout_ms" default="0" position="16" flags="7" size="1" formatString="%d ms" valType="1"> <Value index="0" val="2000 ms"></Value> </Property>
Setting within the Windows® Registry
