Matt Voll

My feedback

  1. 10 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PI Server » Data Archive  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Matt Voll commented  · 

    you give people the power to make analyses in AF along with the capability of backfilling . . . of course they are going to be in there backfilling years worth of data every time they make a new analysis. Anytime anyone asks for a new piece of data (calculation or not) . . . they will always want the history of that data point . . . so on AF analyses that requires backfilling.

    . . . and next day/week/month they will realize some additional item to put in their analysis and make the edit and backfill for all those years all over again again

    Matt Voll supported this idea  · 
  2. 2 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  PI Server » Analytics & Calculations  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Matt Voll commented  · 

    yes, using the ID as a default for the system makes sense. this enhancement request is less about changing that default behavior and more about having the ability to set a system's default behavior to something else, server side . . . instead of having to change it on individual user's computers.

    also, even if a case was made that the ID would need to ALWAYS default into the tag name . . . i'd still make the argument that being able to add other tag properties (ptsecurity, step, descriptor, exdesc) is a huge need

    An error occurred while saving the comment
    Matt Voll commented  · 

    utilizing AF analyses (which inherently leads to the need to have the Analysis Service create pi tags) does not mean that an AF User fully understands all the pi tag properties and does not mean that person is capable or permissible to modify normal process tags on interfaces. The typical AF user also may not fully understand the extensive usage of parameter substitution parameters, nor the need to keep some organization and structure necessary for us to to manage, find, and troubleshoot these tags when there are problems.

    having a defined exdesc=AFPAth... like in my above example is critical for us to be able to find where tags are being populated from later. This allows the tag name itself to deviate from the typical naming above while still allowing us to find the analysis.

    just because someone is given permissions to create analyses and thus pipoints does NOT mean we are making them piadmins where they have potential control over LOTS of process tags. But they should be able to maintain some permission on the tags they have created so that they can make changes to them . . . like switching step=1 to step=0 or vice versa. Thus making sure they are have the appropriate ptsecurity to allow them to edit the tag

    also access to the management tab in PSE is not the problem . . . regardless of whether they have that component installed . . . the above issues can only be addressed by modifying every individual's PSE installation . . . instead of having everyone's PSE settings at least default to some server side configuration. Its unmanageable to have to make this change on every users computer.

    one last example . . . at this was done by a 'piadmin' . . . because even many piadmins find it easier to create tags in SMT than use PSE to create the tags because PSE, by default, puts that ridiculous ID string of characters on the tag name and they don't realize the setting in PSE exists to modify that default behavior. The piadmin created a tag with the identical naming structure as one of our ControlLogix tags and had an AF Analysis output to it. Causing lots of confusion as why an apparent ControlLogix tag had no pointsource and no instrumenttagand, and difficulty for us to find where the analysis was.

    Matt Voll shared this idea  · 
  3. 2 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PI DataLink » Functions  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  4. 13 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PI DataLink » Functions  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  5. 8 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  NOC Services » Reporting  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  6. 3 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  PI DataLink » Functions  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Matt Voll commented  · 

    For us lab data is common numerical data point that we use Step=ON for. A process sample analyzed by a lab represents a single moment in time, when the sample was taken, and due to the infrequent nature of the sample (ranging from once per hour to once a day), it would not be accurate to represent this data, visually, using linear interpolation. The process could be following any variety of behavior between the data points; roller coaster ups and downs, steady average with occasional dips, erratic with occasional spikes, etc, etc. So lacking this context the most reasonable assumption is to have step=on and have the data merely represent the state in which the process was last analyzed. Higher frequency process data, like from instruments, is sampled/scanned/advise at a higher frequency, that is reasonable to assume a linear interpolation trend between data points since they are likely less than a minute apart (ignoring any compression factors in that statement).

    This step behavior also helps user realize that lab data should be event-weighted summarizations and not time-weighted. a once per shift lab sample is meant to represent 8 hours of time, if the process is down or a shift sample is missed, using time-weighted summarization results in the last sample before the gap to be over represented compared to other data point

    That explains why lab data would be Step=ON as a default. . . now when we get to subsequent data analysis . . . well different users want to treat the data differently based on their own judgement, and possibly make different assumptions . . . even lacking the context mentioned above. Taking a big data set for a modeling effort results in numerous decisions and assumptions in an effort to clean, filter, align data . . . I don't see any reason why they shouldn't be able to actively make the decision to use linear interpolation on a step=on tag if they so choose and makes sense for their analysis

    An error occurred while saving the comment
    Matt Voll commented  · 

    yes, so that a user can force the tag's interpolation to behave as if it was Step=off, instead of is true behavior of step=on

    Matt Voll shared this idea  · 
  7. 244 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    20 comments  ·  PI Vision » Reporting  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
    An error occurred while saving the comment
    Matt Voll commented  · 

    I'm tired of the printer marketing spam on this thread . . . rescinding my vote . . .

  8. 4 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PI Server » Analytics & Calculations  ·  Flag idea as inappropriate…  ·  Admin →
  9. 3 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PI DataLink » Functions  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  10. 59 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    12 comments  ·  PI Server » Asset Framework (AF)  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Matt Voll commented  · 

    I can change an attribute from a PIPoint reference to <None> and it will still show the green template box. Visually it looks like the attribute is still following the template when it is not exactly. You don't know whether it is or not without checking the template or by resetting it to template.

    Sometimes the tag names are structured to allow for parameter substitution in the data reference but sometimes that doesn't work out and the template's data reference will just be "Enter Tag Name". So i get the point of the data reference being changed with it still adhering to the intent of the template.

    However even in scenarios where parameter substitutions are used. I've had plenty of occurrences where i have had to change the data reference (for example from ..%Attribute%.UFL... to ..%Attribute%-UFL...) but this change was not carried through the attributes where the template is applied and those attributes still show like they are part of the template. The difference is only noticed on careful inspection or by hitting 'reset to template'

    It seems like there should be a middle ground. Green box for an attribute following the template EXACTLY. No box for attribute that exist outside the template. And then something like an orange box for an attribute that is part of the template but has had some small things changed about (different data reference for example)

    Matt Voll supported this idea  · 
  11. 2 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  PI Server » Data Archive  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Matt Voll commented  · 

    @Kenneth, in a bit flagging methodology the interger representation will be something like 0=None, 1=Run, 2=RunFwd, 4=RunRev, 8=Starting, 16=Stopping, 32=No Power, 64=Error, 128=Interlocked. This set of values is going to be different for different devices . . . uses are not going to be able to tell/remember what 8 means . . . it needs to be in a digital set.

    The digital set will unfortunately contain 128 items in it even though only 9 values are being used.

    We have numerous examples where a 16 bit method is being used (my above comment about being limited to 14 bits) . . . 16 bit example would be something like

    -one Status out of 27 possibles ​Integer=655560 ​Bit Flags- 1010 0000 0000 1100 1000

    Again a user is not going to really know/remember what 655560 means compared to the other 26 options

    Matt Voll shared this idea  · 
  12. 1 vote
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  NOC Services » Reporting  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll shared this idea  · 
  13. 11 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  NOC Services  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  14. 20 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  NOC Services  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  15. 2 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  NOC Services » General  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  16. 4 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  NOC Services  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  17. 47 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    8 comments  ·  PI Server » Analytics & Calculations  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Matt Voll commented  · 

    ChristophRose, good to know, thanks.

    I'm impressed that the configuration used in this way DOES show up in PI System Explorer . . . but its not a complete solution for this feedback item if it can only be completed through PIBuilder, especially when this method is not even described anywhere in the documentation.

    I would also argue that this method is just short of what is actually needed. In my opinion the need for Monthly analysis is going be more commonly based on day of month or first business day of the month.

    It also looks like you cannot combine Day and Month using the method below. It looks like it will follow the Month and ignore the Day configuration.

    An error occurred while saving the comment
    Matt Voll commented  · 

    meierke1 references this being the same request as another. The other one reads differently to me. The other one was also completed in Server 2018. I see nothing in the release notes concerning the ability to schedule analysis weekly or monthly . . . so it does not appear completed yet.

    We have not moved to Server 2018 quite yet . . . so someone can correct me if i'm wrong about whats in the release notes.

    An error occurred while saving the comment
    Matt Voll commented  · 

    'weekly' would be another somewhat common period for KPI type analyses in AF

    Matt Voll supported this idea  · 
  18. 18 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PI Server » Notifications  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  19. 11 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  PI DataLink » Format  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  20. 186 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    25 comments  ·  PI Vision » User Experience  ·  Flag idea as inappropriate…  ·  Admin →

    We are currently researching this item and evaluating it for a future release.

    If you have a moment, please let us know if you have a preference for how data item descriptions should be displayed in trends. For example, would you prefer to be able to configure the trend legend to show the item’s description, that the descriptions be shown under the plot area of the trend, or would you like them to be displayed in another way?

    Let us know what your preference is by adding a comment below.

    An error occurred while saving the comment
    Matt Voll commented  · 

    configurable options . . . descriptions visible: True/False, legend location: right/bottom.

    When hovering mouse over legend items it currently shows the name w/root, have that text box show description as well.

    Matt Voll supported this idea  · 
← Previous 1 3 4 5

Feedback and Knowledge Base

Posted ideas will have one of the following statuses.
Full definition of these statuses can be found on the Home Page.
No status
TELL US MORE
EVALUATING
PLANNED
IN DEVELOPMENT
COMPLETED
DECLINED