Created attachment 498 [details] options/settings PV version: 0.5.0-git-0adee2d and (0.4.1 on Win) Selected device: Demo device Pulseview settings -> Trace View Option Show time zero at the trigger works mainly when you open settigns menu and untick/tick checkbox. findings: 1. when trigger "arrives" after running the capture, time marker "0" is not positioned at the trigger point 2. every next time the that capture is rerun with this settings. time marker is placed a bit more to the right (looking from the point of trigger timestamp) partial solutions: 2. in void View::capture_state_updated(int state) initialize variable ruler_shift_ = 0; 1. need to check for reasons a bit more Need to understand why we are calculating: ruler_shift_ = -(position + (-ruler_shift_));
Created attachment 499 [details] 1_capture
Created attachment 500 [details] 2_capture
By commenting out view.cpp:615 // When enabled, the first trigger for this segment is used as the zero position GlobalSettings settings; bool trigger_is_zero_time = settings.value(GlobalSettings::Key_View_TriggerIsZeroTime).toBool(); if (trigger_is_zero_time && (triggers.size() > 0)) set_zero_position(triggers.front()); It works for me (current setup, demo device). Any suggestion how to check more cases? SHORT DESCRIPTION of proposed solution: 2. initialize ruler_shift_ on capture start 1. change its value on settings change OR trigger arrival (NOT on capture frame arrival)
https://github.com/sigrokproject/pulseview/pull/12
(In reply to stegu13 from comment #4) > https://github.com/sigrokproject/pulseview/pull/12 Is the fix (WORKSFORME) available in a Windows executable? It isn't in the Nightly Build.
No, not in current version/nightly. It was not merged yet. Currently as a branch/pull request on github.com: - https://github.com/luftek/pulseview/tree/timestamp_zero_on_trigger - https://github.com/sigrokproject/pulseview/pull/12
This was fixed via a different implementation in fe68068b2f8f3ae69b762636e91de91e8996aa11, thanks a lot!
Thank you and thanks abraxa.
(In reply to Uwe Hermann from comment #7) > This was fixed via a different implementation in > fe68068b2f8f3ae69b762636e91de91e8996aa11, thanks a lot! Works like a charm, thanks!