Hello,
I’ve noticed that in Logic 2.x (currently using 2.3.11) the time of the trigger is not 0 but whatever time has passed since the start of the listening phase. I personally would prefer to have the trigger at time 0, everything before the trigger as negative time relative to the trigger and everything after the trigger as positive time relative to the trigger, similar to the behavior in Logic 1.x.
What I find a bit irritating how Logic 1.x shows the negative timeline though is the time increments before the trigger. They are positive relative to the last bigger step, in the screenshot for example “+10 µs”, “+20 µs”, etc relative to “-0 s : 0 ms : 100 µs”. I would prefer to have the timeline before the trigger to be “right aligned”. This would make the “+ 10 µs” in the screen shot “-90 µs”, “+20 µs” would be “-80 µs”, etc. I think you get the point. For everthing after the trigger the “left aligned” view is fine.
If you don’t want to change the default settings please make this configurable in the options.
In addition, I would like to show only the data after the trigger, i.e. set the value for “Trim pre-trigger data” to 0. Currently there seems to be a minimum value of 10 ms.
@cg1 Thanks for the feedback with that! We have this on the backlog right now to set the last trigger to be time zero. Here is where we have logged it for now:
I also see what you mean regarding counting backwards (negative) going left from the trigger, and counting forwards (positive) going right from the trigger. I don’t exactly know what we have planned for this, but I’ll mention this to our software team and add a note about it to the ideas forum above. Thanks again for the feature idea!
I was wondering if the feature with trimming pre-trigger data is also on the roadmap? I am only interested in data, that is recorded after my trigger but in the current Logic2 version you are still limited to a 10 ms trim. That is quite a lot of file size overhead if you sample at a high rates and want to do it automatically with the python sdk.
Thanks for writing in! I’m not exactly sure why we forced the minimum remaining pre-trigger time to 10ms. I do know we increased it from zero seconds back in 2020.
We’ll test it for issues with the limit reduced to 1us, would that help solve your issue?
Second, you can manually trim the capture in the UI through several ways, including right-clicking the “T” at the top of the trigger and selecting Delete Data > Before Trigger. This is not available in the API though. We do have plans to dramatically expand the API to include more functionality, but it’s going to be a while before we can get back to it.
I discovered the manual trim data feature, and that is good! However, I need to use this with the python api, and as you said, it is not available there.
Additionally, if I use a value smaller then 10ms in the api call, it will return the complete measurement. It would be good to have an error raised here, or have it documented.
The reason for me to trim the data is, that the data I am interested in is only short compared to the 10ms in front. This produces a lot of unnecessary data on my disk as I will record multiple measurements.
I would love to see the feature with trimming to zero seconds or at least 1 us/ms coming back.
@christian Thanks for describing your requirements! We’ve lowered the limit to 1us in an internal test build, and so far, we haven’t run into any issues with it. We’ll run some more tests before we commit it to the official build.
For your request to add this feature to our Python Automation API, I completely agree. We’re keeping track of “post-capture” automation feature requests in the forum post below. I’ve added your request as a comment so we can remember it.
