Trend View Feature Requests

[RBPLC]

It would be nice to have a pan feature in addition to the zoom feature for trend views. It would also be nice to have the time scale view properties available on the main trend window without having to go into options. 

[franji1]

It would be nice to have a pan feature in addition to the zoom feature for trend views.

I'm guessing you are wanting to pan back in time easily, but keep the view "live" (not historical mode).  We could possibly change the pan function to keep the "live" right edge fixed, but scale the time of the left edge, either based on the current view port time span, or even the span of the entire historical range (probably a combination of the two, e.g. scrolling of a 1 second window with 24 hours worth of data would be hard to NOT go into historical mode, so panning in this situation would increase the window time range from 1 second to 1/2/5? minutes, and the time value of the left edge, while maintaining the right edge "live" time).

It would also be nice to have the time scale view properties available on the main trend window without having to go into options.

We could add an edit control to let you set it (probably just minutes/seconds).

For now, the time scale scroll bar on the toolbar lets you set the set the time scale to specific detents.  If you need specific ranges (e.g. exactly 42 minutes or 42 seconds), the options dialog is modeless - just move it out of the way, and you can tweak it when needed for these ranges.

Not sure if this helps, but you can use Ctrl+Mouse Wheel to zoom in and out to a specific time/range wherever your mouse pointer is pointing (think Google Maps).

[Controls Guy]

Not sure if this helps, but you can use Ctrl+Mouse Wheel to zoom in and out to a specific time/range wherever your mouse pointer is pointing (think Google Maps).

Ooh, that is cool!    Wasn't aware of that one.    Already using!

My beef with trend view has to do mostly with time increments.    I don't like the random column durations you get with the default setting, nor the random default line times.

Since the line and tick settings don't change as you change time scaling, the user needs the number of columns to be highly composite, so that the column width is most  likely to remain sane as you change time scale, so most desirable would be 12 or 24 columns (like why there are 24 hours in a day, 60 minutes in an hour, 12 inches in a foot, 36 inches in a yard, etc.).    Since DMD specifies the column count indirectly as N_lines + 1, then it would be ideal for lines to be adjustable up to at least 11 or 23, rather than the current max of 10.   With a max of 10, the best available setting for lines is 5, to give a column count of 6, which isn't bad.

Second, once you do get a good increment width, the actual column times are datumed on a random basis (probably based on when the trend was enabled), so the line time will be 10:29:06 or something random.   Better to reconcile the line time to some multiple or divisor of the column duration, like if the column durations are 10 seconds, justify a line to the minute strike.

Also, trends can easily span days, and I don't believe there is anywhere on screen (without clicking for a snapshot) that identifies what day's 10:29:06 you're looking at, so maybe add the day and date at the bottom of the trend, at least as an option.

Might be better to have the user just set the column width in time duration per column and then either adjust that setting or column count when scaling the trend overall.

Thanks!

[franji1]

Since the line and tick settings don't change as you change time scaling, the user needs the number of columns to be highly composite, so that the column width is most  likely to remain sane as you change time scale, so most desirable would be 12 or 24 columns (like why there are 24 hours in a day, 60 minutes in an hour, 12 inches in a foot, 36 inches in a yard, etc.).    Since DMD specifies the column count indirectly as N_lines + 1, then it would be ideal for lines to be adjustable up to at least 11 or 23, rather than the current max of 10.   With a max of 10, the best available setting for lines is 5, to give a column count of 6, which isn't bad.

So, possibly have the number of vertical time lines be a function of the Time Scale value?

Second, once you do get a good increment width, the actual column times are datumed on a random basis (probably based on when the trend was enabled), so the line time will be 10:29:06 or something random.   Better to reconcile the line time to some multiple or divisor of the column duration, like if the column durations are 10 seconds, justify a line to the minute strike.

When it auto-pans, we can sync up with some multiple/quauntization of the Time Scale value, e.g. 10, 30, 60 seconds, 10, 30, 60 minutes, whole hour.  Another feature would be to let you set the absolute time of the left edge.

Also, trends can easily span days, and I don't believe there is anywhere on screen (without clicking for a snapshot) that identifies what day's 10:29:06 you're looking at, so maybe add the day and date at the bottom of the trend, at least as an option.

Never thought a realtime data gathering would span days - the data set range is a function of number of changed values, not time, so this does make sense.  FYI, the Status Bar of the Designer app shows the date/time stamp of the mouse cursor in a Trend View.  Normally it just shows the HH:MM:SS.mmm along with the Y axis value of the mouse (also 2nd Y axis value if you have 2 Y Axis set up).  But if the date is different than the current date, you get the full MM/DD/YY HH:MM:SS.mmm on the app status bar (left edge).  This current implementation doesn't take up any additional real estate, which is important.

[RBPLC]

Never thought a realtime data gathering would span days

I frequently use it spanning days to optimize and troubleshoot.

[Controls Guy]

So, possibly have the number of vertical time lines be a function of the Time Scale value?

That could work.   I think the best solution is probably to turn the current paradigm inside out, from having a window time width and dividing it, to having a column width and multiplying it.   Then to scale time, (LOVE the scroll wheel!), either the number or the duration of the columns is changed (or maybe either based on a user config).  Probably should also have a easy way to pan without changing scale.   Currently, you could zoom out, move the mouse and zoom back in, which isn't bad, but panning at constant time zoom as well might be nice.   If the column duration is what's scaled, it should be in sensible increments like the overall window scale currently is.

When it auto-pans, we can sync up with some multiple/quauntization of the Time Scale value, e.g. 10, 30, 60 seconds, 10, 30, 60 minutes, whole hour.  Another feature would be to let you set the absolute time of the left edge.

Yup, or just pick a even line time from the get-go would be even better.   But failing that, your suggestion would work fine.

Never thought a realtime data gathering would span days - the data set range is a function of number of changed values, not time, so this does make sense.  FYI, the Status Bar of the Designer app shows the date/time stamp of the mouse cursor in a Trend View.  Normally it just shows the HH:MM:SS.mmm along with the Y axis value of the mouse (also 2nd Y axis value if you have 2 Y Axis set up).  But if the date is different than the current date, you get the full MM/DD/YY HH:MM:SS.mmm on the app status bar (left edge). This current implementation doesn't take up any additional real estate, which is important.

Oh OK, I thought that might be the case, and I looked but I didn't have any multi-day trends running to check.    Looks to me like there's some unused chrome at the top of the trend to the right of the buttons.   Might be nice to see the day/date continuously, rather than for mouse position, but not super critical.   Yeah, max bang for the pixel is critical, acknowledged.

[Controls Guy]

I frequently use it spanning days to optimize and troubleshoot.

Me too.   I often just leave one or more trends running on a local PC at the user site with selected telling parameters trending rather than do a log.   Typical duration before rolloff, maybe 3-5 days.

[Controls Guy]

Then to scale time, (LOVE the scroll wheel!), either the number or the duration of the columns is changed (or maybe either based on a user config).

On further consideration, I don't think changing the number of columns can work by itself as the only zoom method.    Starting from a likely column width, you only have a few steps zooming in before you're at one column.   Zooming out, it's not going to be long before you have so many lines on-screen that it's hard to pick out the data or write the line time at the bottom of the line.

So changing the column count is at most a hybrid with changing the column width.   You might change the count a few times, then change the column time width and reset the count, rinse and repeat.

So, changing the column count may not be worth putting effort into, since you would still have to change column widths periodically anyway.

[RBPLC]

Probably should also have a easy way to pan without changing scale.   Currently, you could zoom out, move the mouse and zoom back in, which isn't bad, but panning at constant time zoom as well might be nice.

This was what my original request was for. I didn't realize that you could zoom using the scroll wheel which I am using frequently now. My intent would be to zoom in using the scroll wheel to a certain zoom level and then be able to drag the plot left/right to view different time periods. Effectively doing what the slider at the bottom does but without having to use the slider.

[Controls Guy]

This was what my original request was for.

That was where I got the idea!      Once they edumacated us there was a simple way to zoom, there should be a corresponding way to pan.

[PLCwannabe]

New Feature request for trends: 1ms resolution, so I can graphically compare 2  sine waves . 

[Controls Guy]

I think there would have to be some data buffering in the PLC.  I doubt DMD is going to be able to move data that fast out of the plc.

[Controls Guy]

AND AIs that will go that fast.

[RBPLC]

the options dialog is modeless - just move it out of the way

I didn't realize you could do this. Always learning something.

[Bolt]

I often wish we could access all of the Options Dialog while in a Historical Trend View.  Usually to Move Up/Down (or remove) an Element once you have found a spot of interest in the trended data, and you would like to be able to see all the offending coil data points next to each other in the pane.

I also frequently run trends for days, make a change to the program, let it run for a few days, see how different operators take to it, how many times they think it's necessary to push a button, see that they are pushing the wrong button/at the wrong time, etc.

Does anyone else feel like DmD cripples with too much Trend View data compiling, and frequently have to kill DmD from the Task Manager and start it over?

I regularly think/wish Trend Views should be in a stand alone application, like DmLogger, and not in tabs of DmD.e