Building on the progress made with developing custom axis limits, I've been working on implementing the waterfall feature (finally). There is now a checkbox on the controls panel that allows the user to toggle the waterfall feature on/off, and this will scale the left axis such that the displayed plot range is divided evenly between each of the displayed pvs--two pvs plotted should each take up half of the plot range. Toggling the feature on and off seems to work well but I haven't tested yet how well it behaves when the feature is on and the user goes to the EditPVDialog and specifies new custom axis ranges. I think I'd like this action to turn the waterfall off, but I'm not sure how it works now. But so far, so good
Added guard in StripToolPV before the updated display range is emitted. This prevents the application from crashing if the plotted pv's max and min are both equivalent and equal to zero, when this is the only pv plotted.
Made some changes to how the waterfall effect is created in StripToolSeries related to what values are used to create this effect. By default, the dataMin and dataMax values are used, but if they aren't appropriate (say if they are both equal to zero) and appropriate custom limits are defined, the custom limits are used instead. If the dataMin/Max and the customMin/Max are inappropriate, arbitrary values are used instead (this hasn't been tested yet). But, with this change, pvs that don't usually change values and are normally zero (such as dxp1607-B21-04:ma1.R0's reported value and WIG1405-01:ramp:status) should be displayed properly, with or without the waterfall applied.
Attempting to switch from NewXRFDetector branch back to master, where my StripTool stuff lives! I think!

Merge branch 'master' of https://github.com/acquaman/acquaman
Commiting changes made so that I can switch to NewXRFDetector branch! I'm noticing some very odd behavior with StripTool running now, that might be related to changes that I've made to StripToolSeries. Review these later!