Need method is_processing_completed or is_triggered in Logic2

1

Hello,

I use the method is_triggered / is_processing_complete in Logic1 to check if trigger event occurred in the TriggerModeCapture. It seems no similar method available in Logic2. The call sequence might be as following:

  • start capture
  • polling to check triggering status (e.g., the trigger event will be generated when DUT temperature reaches the threshold)
  • get the bus data for calculation.

What the suggestion on the implementation of automation script for this task with Logic2?

Thanks,
Carson

2

Are you using the wait() method, as per:
https://saleae.github.io/logic2-automation/automation.html#saleae.automation.Capture.wait

… assuming your using DigitalTriggerCaptureMode for the capture config?

See also this post about issues if the capture fails to trigger:

3

Thanks @BitBob ,

Based on the info you provided, we have done more experiments with Logic2. I think the test can be done as following:

  1. start data capture with parameters capture_channels, capture_duration, trigger_channel, trigger_type
  2. start a thread with a timeout parameter, in which will send capture.stop() after timeout
  3. start capture.wait(), waiting for for the digital trigger to be found and the capture to complete
  4. if no trigger occurred due to some failure case, the logic analyzer will keep running. the thread in step 2 will timeout, the command capture.stop() will stop logic analyzer capture session.
  5. if trigger occurred, capture.wait() exits, stop the thread in step 2, and continue for data calculation/analysis.

Ideally the capture.wait() should have a timeout parameter to avoid the endless running with a failure case.

what’s your advice for it?

4

I think someone from Saleae may have to give feedback, but the Automation API docs did say:

stop() and wait() should never both be used for a single capture.

… so, I think you should either use:

  • a DigitalTriggerCaptureMode and use wait() as long as the trigger is known/guaranteed, or
  • a TimedCaptureMode that is setup long enough to catch the desired trigger event,
    (and possibly ‘trim’ the capture after it’s completed)

Unfortunately, the wait() is a blocking call, and it doesn’t currently have a timeout option to exit if the desired trigger is never hit. However, I’m not sure what happens if you violate the above constraint and call stop() from another thread – but I don’t recommend it unless Saleae says otherwise.

Thus, as long as you have the storage and the trigger condition isn’t guaranteed, I think using a TimedCaptureMode for the equivalent timeout period should be close enough to your worst-case trigger event capture storage anyway.

Ultimately, I think adding a timeout parameter to wait() and/or adding a cancel() command or allowing a stop() command while wait() is pending would help. Of these options, I think the timeout is the preferred & cleanest choice as there is no need for a separate thread, and no race condition/risks of coherency issues between wait() vs. stop() (or cancel()) API calls.

5

Thanks for your comments.

Yes, I am expecting that Saleae team can add timeout for wait() in the future release.