Is there a way via the API to detect when the Saleae is still capturing data/waiting for trigger?
I’ve been using Capture.wait() to detect when a measurement has finished without any issue so far, but have come across an instance where due to a DUT failure, a trigger never occurs and so the Saleae just runs and runs whilst my software waits potentially infinitely for a return from the method.
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:
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)?
@davidpcl1977 Unfortunately, I don’t think our Automation API supports this use case at the moment.
I like @BitBob 's idea for adding a proper timeout parameter. This would be helpful as a feature in the GUI as well (i.e. timeout a triggered capture after x amount of time without a trigger detected). I’ll bring this up with our team here, though it’s likely we won’t be able to implement such a feature in the near term. I’ll provide an update if we can think of a workaround as well.
Thanks @BitBob and @timreyes for your comments. I’ve managed to get around this by calculating an expected runtime of a measurement then using the ‘capture.stop()’ method, and so far this has worked without issue.
Some sort of status byte would be a nice feature to have - I do a lot of work with Keysight scopes and they usually have a *STB? SCPI command that allows you to get a snapshot of what state the scope is in.