Trend View Request

[RBPLC]

Make optional the ability to move the display tag of a trended element to either the left or right of the trend depending on which y-axis (1 or 2) that element is using.

[franji1]

Good as an "option", especially if you have a wide or multi-monitor setup.

[Controls Guy]

Also, normalize the grid times to round numbers instead of random.   Obviously there would be a limit to this based on the overall trend window width and the number of divisions selected, but at least attempt to keep the vertical lines on even increments.    Or possibly change the config dialog to time width per div and total number of divs/window or time per div and total window time (with non-int number of divs).

[franji1]

Also, normalize the grid times to round numbers instead of random.

We got it working.  The left edge and the right edge should be "correct" and "truncated", the internal tick marks "truncate" their display value (so may or may not be exact - we may need to look at that).

We basically did the following.  Based on the Time Interval, the nearest "truncated" time value for the LEFT EDGE truncate to the following and the right edge is then based on the Time Interval (you choose that; internal tick values will depend on number of tick marks configured and the chosen Time Interval)

(0, 10 seconds) - don't truncate (old way)
[10, 5 min) - truncate left edge to whole second
[5 min, 10 min) - truncate left edge to 10 second mark
[10 min, 30 min) - truncate left edge to 30 second mark
[30 min...) - truncate left edge to whole minute mark

[Controls Guy]

Awesome, thank you!   In the next point release?

[franji1]

Awesome, thank you!   In the next point release?

Yes.  2.10

We also tweaked the default number of major ticks on the time line.  Monitors are getting wider, so we bumped it from 8 to 9 (so 10 time sections), so 10 is much more divisible to whole numbers.  If you narrow the view, at some point only every-other major time tick is labeled (since the label text would over lap), hence why 8 was originally chosen based on the default size of a "normal" app window instead of 9 on a 1024 pixel wide monitor (oh, the minutiae).