Check if trigger happened without wait()

[ngblume]

Hello,

quick questions from the digitalTriggeredCapture perspective…
I am used to being able to check, if a trigger occured, without being stuck until the trigger occured.
Sofar the wait() fujnction seems to be blocking with no option for timeout…

Is there another function, that just allows me to check, if the trigger occured, maybe even after calling stop on a maybe triggered capture?
That way I can just discard the capture, if no trigger occured, or proceed with adding analyzer, etc. if the trigger occured as expected…

Thanks !

Cheers
Niels Göran

[BitBob]

Suggest this post may answer your question:

Detect Saleae Run State For Failed Trigger

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 pen…

… but as far as I know, the status hasn’t changed since then.

[simon1]

I’ll support/repeat the request for an ‘abort’ method, what would be nice if ‘wait()’ could accept a ‘timeout=Xms’ parameter and then return a success/failure value - maybe just an empty capture object.

I guess it is (also) possible for user interaction on the GUI to cancel a capture, but that’s not helpful when you are attempting automation of 1000’s of cycles.

I recently had an overnight run stall waiting for a trigger…

[timreyes]

@simon1 Thanks for your vote on this, and sorry this isn’t yet possible via our Automation API (our software doesn’t support this natively yet either).

I went ahead and added a comment for you in the idea post below so we can track your need for this to be implemented.

Automation API - Set a timeout when looking for trigger - Logic 2 - Ideas and...

[BitBob]

Another possible work around:

import time
   : 
with manager.start_capture(...) as capture:
   time.sleep(timeout)
   capture.stop()

Instead of using capture.wait(), and I suggest setting a timeout value as long as (or longer than):

• DigitalTriggerCaptureMode: after_trigger_seconds
  (plus longest time to wait for a trigger event)
• ManualCaptureMode: trim_data_seconds
• TimedCaptureMode: duration_seconds

Note: I think this method makes the most sense to use with DigitalTriggerCaptureMode as the other capture_mode options already have a stop condition based on time vs. depending on a trigger event that may not occur.

Also, this method uses host-based timing, so you may want to add a little extra margin in the timeout value to avoid clipping anything at the end of a capture (in case the PC timing isn’t fully sync’d with the Logic).

[simon1]

Work around is OK, but it would be nice to know whether the trigger occurred, ie something within the ‘capture’ object that would confirm?

[BitBob]

@simon1

it would be nice to know whether the trigger occurred, ie something within the ‘capture’ object that would confirm?

I agree, but it doesn’t look like the current API provides such a trigger status indication. However, the *.sal capture file is in zip format, so you could parse the meta.json file embedded within.

After a quick look, the captureProgress property includes a processedInterval.begin, processedInterval.end and/or a triggerProgress that might be used to infer if a capture file triggered or not. E.g., if triggerProgress value is significantly less than processedInterval.end and/or if the processedInterval.end - processedInterval.begin time difference is close to the timeout specified in the sleep() function, then maybe you can infer a trigger was missed? Maybe Saleae can comment on a more robust criteria to detect triggered capture files vs. trying to reverse engineer it?