As far as I know, the WaitCapture API is a blocking call, and won’t return until the capture has met the criteria defined in the wait() API documentation:
- TimedCaptureMode, this will wait for the capture duration to complete
- DigitalTriggerCaptureMode, this will wait for the digital trigger to be found and the capture to complete
So, you might need a separate thread to detect DUT failure and restart the DUT instead?
Otherwise, I’ll defer to Saleae to comment on how to clean-up or cancel a pending wait() that has not returned, since according to the Automation API:
stop() and wait() should never both be used for a single capture.
Your use case may not be supported in the current version of the API, as I don’t believe there is a non-blocking method to check if a trigger has happened, or if a capture is still waiting (or running).
Maybe a feature request to add a waiting() method that returns true or false based on whether the capture was started, but not completed? Include an optional timeout parameter to ‘wait’ for a time interval before returning, and either return when the capture completes (or not started), or after the timeout value is reached? Default timeout=0: checks capture status and returns immediately to indicate if capture is waiting (true), or not (false)?
Then, you could poll the waiting() API, and implement your own timeout/restart of the DUT based on how long you’ve been waiting (??)
Note: for a more generalized API – maybe waiting() should be running() to handle the ManualCaptureMode, too (which doesn’t support wait() like the other two capture modes)?