This is the tobey statement that I was referring to. tobey does have more than one agenda and I don’t quite understand some of it, but I was referring to the fast scan as being less than optimum for typical use of that scan feature. If the Scan mode honored the Fast option selection, then the user can decide how to use Scan. It is very difficult to communicate successfully in this one-way forum medium (without immediate feed-back to confirm understanding) and that is why these posts can get frustrating at times for all of us.

Provided we also shift the trigger position left, this makes sense and so I will look into this.
That statement caught me off guard. Now I think I understand what you were considering and that I was missing. It sounds like you are saying that in Fast Post, a portion of the left half of the display could be blank and I hadn’t considered that. I guess we have come to the cross-roads of user capability versus complex functionality. I would quickly realize that when Fast Post leaves the left side of the screen blank, then I would just use the trigger position to slide the whole display to the left as required. A user with less knowledge base might consider the blank screen area as a problem or bug. It sounds like you are considering sliding the trigger position to the left of the screen to protect the less qualified user and that certainly has it merit. Explaining this situation in the User Guide would be another option.

This does come at the added expense of complexity however in that we need additional controls for T/Div (if you really want to change the time domain), V/Div, Trigger Pos and Vert Pos related to reference. We would also need to consider cursors (V1, V2, T1, T2 and Trigger Pos) as these can apply to only one set of domain parameters. Still I think there may be ways to solve all of these issues if there is consensus that this adds real value to real problems…
More important perhaps is that we should not change the default behavior in such a way that typical usage is obscured and this is where I struggle to see where you want to go with “retaining XML parameters”… Don’t think for a second however that I do not appreciate the ideas however challenging they may be.
Maybe I can improve my communication here. My examples referred to a common time domain which has the T/Div the same so I don’t see a need to make the time bases independent. I may have indicated that in an earlier post but have since decided that it is unnecessary complexity.
As far as default program behavior is concerned we could never change the REF waveform before, so keeping the V/Div fixed to the loaded XML parameter is not a change in behavior of the Ref waveform. The Ref waveform following the T/Div would in fact be an advantage such that both waveforms could be stretched simultaneously for closer examination for differences.
As you have indicated, cursors for the Ref waveform would not be necessary for a common T/Div.
Vertical position offset is most useful whereas horizontal offset provides little if any advantage.
In summary, my suggestion is that we only need 3 changes; to preserve the XML V/Div of the Ref waveform to correct for the comparison of large signals and small signals, to keep the Ref waveform vertical offset disconnected from the primary waveform vertical offset so that the two waveforms can be separated in the vertical plane, and to isolate the Ref waveform from Gnd Pos changes to ensure that vertical separation can be maintained.