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 mv.impact.acquire.FunctionInterface.imageRequestWaitFor never returns.

Cause

The default value of the property mv.impact.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 mv.impact.acquire.FunctionInterface.imageRequestReset AND calling mv.impact.acquire.FunctionInterface.imageRequestWaitFor with an infinite timeout AND not explicitly setting the value of the mv.impact.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 mv.impact.acquire.FunctionInterface.imageRequestReset from a separate thread to unblock the mv.impact.acquire.FunctionInterface.imageRequestWaitFor function
Do NOT call mv.impact.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 mv.impact.acquire.FunctionInterface.imageRequestReset in parallel
Do NOT rely on default values, but explicitly set the value of mv.impact.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 mv.impact.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

ImageRequestTimeout_ms property in the Windows® Registry