Feature request -- user settable display mode in trend

[Controls Guy]

I'd like to be able to have the vertical axes in hex, binary, etc, and especially unsigned.    The Opt -> scaling dialog could still be in decimal if that's easier.

I'm trending several DINTS that are actually bit words, and I'm more interested in bit counts and positions than the equivalent decimal value, and it's hard to intuitively infer that from a decimal value plot.   This is especially true since there's no UD cast, which makes bit 31 special as well as way more significant in magnitude than any of the others.

[franji1]

If they are bits, cast them as bits.  You then get a set of on/off for the Y axis, not numeric value based Y axis

If it's not that, please explain what a plot would look like with D0 with the following hex values where only 1 bit is changing per line:

0x00
0x80
0x00
0x80000000
0x80000001
0x00000001

[Controls Guy]

Sure, but I can't put 32 bits in a trend, let alone 96.

Also, I guess I was actually thinking of a live value display per pen at the side vs. the actual axis line legends.  That would give me the real-time bit count and position approximation I'm talking about.    Significant deviations in the trend give you directions on where you might want to take a snapshot, which would also be in the radix selected.

For the moment, I'm getting some of what I'm looking for by trending MyDINT[V0]:UW0 and MyDINT[V0]:UW1.   That way I can cast unsigned and all the bits work the same direction.

[franji1]

Sure, but I can't put 32 bits in a trend, let alone 96.

You can do 32 in a single trend view using multiple panes.  My monitor probably could do it in Portrait mode.  See attachment.

[Controls Guy]

True, but I need more like 96-128.

Here's a view with 96.   Looks like it's on a portrait monitor, but it's just tiled three-wide with two other trends.

[franji1]

0x80000000
0x80000001
0x00000001

I guess I still don't see the value in having the axes being labeled in hex vs. decimal (let's assume unsigned hex) for the plot above.  You could not tell the difference in the plotting of these last 3 values, even though (from your perspective), they are almost all equal to each other (just 1 bit is different across each value).

I think you just need a higher density bit plot (e.g. one that can handle 96 bits)?

[Controls Guy]

Well, two things.

1) As previously noted, 'axis labels' was my error and I was actually picturing value displays tracking up and down with the pen labels.

2) Live numerical values and the line trend serve different purposes.   You're looking at the trend for long term, well, trends and exceptions to the trend, and floating value display would be for ongoing real-time evaluation.   Snapshots are good for getting a precise numerical value at a point in time or a point visually identified on the trend line.

[franji1]

We are eventually heading to a feature where you select the default display format for any specific element whether that element is being monitored in Data View, Ladder View, Trend View, or wherever  (e.g. D0 is HEX, D1 IS Timer Accumulator, D2 is SWAPPED ASCII).   I think this will solve your desire (and you only have to do it ONCE for any element).  We already have this concept for specific Structure FIELDs (e.g. Timer .Acc field default display format is NOT native integer, but Millisecond Timer Accumulator HHH:MM:SS.mmm)

Ladder and Data View currently supports overriding the default format on an instance by instance basis, but a majority of the time where you want to override the display format, you want to override it in all views in all contexts.  Even after this is implemented, you will still be able to override the selected default format specified for THAT element in the specific Data View or Ladder View context, just like you can for a timer .Acc field in Data View or a relational contact.

[Controls Guy]

That seems like a really good idea. 

Semi-related -- I'd also like to have Data View be able to display a small range of values on a single line.    Application is for when there's a string value in 10 consecutive MHR registers or something like that.    I realize Data View is legacy so I have no idea if that's doable.

Thanks!

[franji1]

That seems like a really good idea. 

Semi-related -- I'd also like to have Data View be able to display a small range of values on a single line.    Application is for when there's a string value in 10 consecutive MHR registers or something like that.    I realize Data View is legacy so I have no idea if that's doable.

Thanks!

If it's not random access (you said contiguous MHR), Memory View can do that.  Very very customizable (number of columns, range, continuous zoom level settings).  It would be easier to do 10 of those than try to get a Data View to do "columns".  Don't even think about editing with columns in Data View (every other column is an edit column???).  It sounds like Memory View is closer to what you want than some strange Data View.

The poll rate on Memory View isn't that great - but that could be "made to work" if that was an issue.

[Controls Guy]

Yeah, that's what I've been doing.   No, if you specify MHR2000-MHR2009 as the line entry, it would just show as 20 characters, quoted, ASCII, whatever.    Any edits would apply to the whole range.    I have been using Memory View (which I love BTW), but when you have half of each range you need in ASCII (preferably as a single entity) and the other half mixed between INTs and bit words it can bit a bit awkward.

Speaking of Memory View, I'd still like it to be more seamless than it is.   Continuously polling by default, simultaneously writable by default, fewer (no?) confirmations.  AB does it.

[franji1]

I get what you're saying.  DirectSOFT supports that concept because it has no "string" memory.

Legacy features are not something we are striving for, but here's a possible 21st century solution...

Create a subroutine triggered on C99 that moves SS99 to MHR[V99] range using STRPUT.  Data View with SS99, V99, and a C99 bit to fire it off.  You can even have it to a FILL of spaces or NUL chars for padding if you want.  Think of it as a very powerful macro language.

[Controls Guy]

Yeah, I know, I was hoping not to have to add any logic.  (Make DMD do it instead!   )

OK, I guess I'm going to need STRPUT and GET so I can monitor as well as edit.  Workable.

Also, Modbus doesn't know from string either.   When I can get strings into and out of SS using Modbus without logic then that changes this whole discussion.   It's not being used for anything in the PLC, only accessed via the HMI, a bunch of logic and memory dedicated to shuffling it around so DM will recognize it as a string really isn't justifiable.   In fact, the only reasons the string data is in the PLC at all are so I can do a monolithic config backup and so the other HMI can also see the strings (I never have been able to get the HMIs to share them directly).