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.
I'm declining this due to lack of community support.
This would be a useful feature to recover from a unreposive code module. Particularly useful, if the code module communicates with the firmware inside the DUT which could become unresponsive due to unforeseen erronous conditions.
This option should be optiional. It should be configurable with different timeout values. Once set and configured, then TestStand shall stop executing the code module, return from it and generate an error.
This would require abnormally terminating the thread which could leave the process in a bad state. It's better to handle things like this at the code module level where you can more gracefully timeout or abort rather than forcing the thread to terminate. Forcing a thread to terminate is bad because you don't know what code it's in the middle of executing. It could be in the middle of modifying some shared data and could end up leaving such data in an inconsistent state.
I'm declining this due to lack of community support.