Matt Voll

My feedback

  1. 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  · 
  2. 2 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PI DataLink » Functions  ·  Flag idea as inappropriate…  ·  Admin →
    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  · 
  3. 54 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  · 
  4. 1 vote
    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  · 

    @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  · 
  5. 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  · 
  6. 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  · 
  7. 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  · 
  8. 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  · 
  9. 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  · 
  10. 44 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  · 
  11. 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  · 
  12. 8 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  · 
  13. 116 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    "Would it be acceptable to show markers for only some of the raw values as long as there are enough to accurately represent the data, ...."

    Absolutely NOT! This would make 'trace markers' uselss!

    show all data points. I would expect, like Processbook, that if there were too many data points on the trend to be displayed properly that the markers would essentially turn off and the trace would merely be a line, until such time as the time range was shrunk to a point where ALL data points could be shown.

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

    We’ll send you updates on this idea

    22 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  · 
  15. 9 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PI Interfaces » PI to PI Interface  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  16. 12 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 →
    Matt Voll supported this idea  · 
  17. 228 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

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

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

  18. 88 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We’ll send you updates on this idea

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

    I've spent some time today trying to re-create the issue i had originally seen in the Tech Support case that generated this feedback item. I tried creating AF analyses from scratch using existing input tags that I was able to add 'in-order' and 'out of order' data into. I had also, previously, attempted to duplicate the original elements/analyses/tags from my tech support case and set the analyses back to the way they were before I had made changes to them.

    The end result . . . i was not able to create any scenario that counters your premise . . . that '*' = trigger time. I am happy because the ramifications of this not being true is . . . . ugly . . . but i'm frustrated in having no way to explain the behavior i originally saw (as well as the fact that this premise still contradicts what was communicated to me supposedly from a Product Specialist via a Tech Support Engineer

    I will again add the caveat that the original tech support case was on a system running AF 2017 R2 and we have since moved to AF 2018 SP2. I know specifically of a handful of items fixed between these two versions directly concern issues around automatic recalculation and analyses. I would not think any of these issues would have been related . . . but at this point I cannot say for certain whether one of those issues was causing the issue in someway that was not apparent at the time.

    I am also still very much keeping a close eye on the usage of automatic recalculations in the new version as we have never been able to fully 'trust' auto recalc and have had continual problems with it performing as it should. I have two cases open now concerning discrepancies between results from backfilling vs results from normal running analyses using auto recalc. FYI

    An error occurred while saving the comment
    Matt Voll commented  · 

    Another comment . . . that may be the original tangent point in which led to the discussion during my original case of what '*' actually means in terms of backfilling, late data, out of order data, and normal operations . . .

    Is there a difference between having Variable = 'attribute1' and Variable = Tagval('attribute1','*'), or are they the same? Especially in the context of attribute1 being non-late process data and the analysis being triggered on attribute2, late lab data.

    An error occurred while saving the comment
    Matt Voll commented  · 

    Everything you state is EXACTLY what my assumptions were prior to my original post on April 10th . . . where I was provided with information contradicting these assumptions, and thus turning my world upside down :). I would love to be correct in my original assumption and incorrect in my thinking over the last 1.5 months.

    I'm not exactly in the practice of keeping incorrect analyses floating around, thus the analyses that were causing issues have been adjusted. Instead of event-triggered on the lab data (like you even suggest) I switched them to perioidic and they were structured in such a way that all lab data now becomes out of order in relation to the analysis, thus late arriving data will cause the analysis to be recalculated.

    Anyway, I did, just now, attempt to create a duplicate set of analyses and output tags . . . switching them back to be event triggered on the lab data. However based on my previous observations I do not trust that backfilling is an accurate representation of what is occurring during normal operation . . . thus i will give this a few days to run normally and then compare the two sets of results form these analyses

    I cannot pin point to any obvious items that may be part of this . . . but the other caveat to through out is that originally this system was on AF 2017SP2 and as of last week its on 2018R2. There were some analytic related bugs fixed that were causing me/us problems, but again nothing i would think having a directly impact here.

    An error occurred while saving the comment
    Matt Voll commented  · 

                   "For analytics, '*' does NOT refer to Now but rather refers to the trigger time"
     
    Your statement is in direct contradiction to what I was told through a Tech Support call concerning issues with Analyses giving incorrect results (that WERE corrected if I manually backfilled . . . thus its a difference between how backfilling behaves and how real time analyses behave). 
     
    Previously, I have always been under the assumption that '*' represents trigger time. But my analyses were not behaving like they should. The explanation provided did fit with the observations I was seeing.
     
    I would be happy to revisit the issue . . . however . . .  I have no real complaints on tech support engineers with OSIsoft, they're great, but it is clear that they have varying levels of experiences and different strength areas. Previous experience of having tech support calls involving intricate issues with AF Analyses like this suggest that it would not be worth while to call and roll the dice on who i get.
     
    These issues are hard to identify because they are the most evident by a backfilling behaving differently than normal real time analyses. While Automatic recalculation addresses a big part of this, it does make it more confusing as well. At this point, it has become common to have 'incorrect' analysis results that are simply fixed by backfilling . . . but that means any testing to what the problem is difficult because hitting evaluate or backfill on the analysis is not trust worthy.

    An error occurred while saving the comment
    Matt Voll commented  · 

    Process Data (not late), a like a Flow Rate, used in an analysis with Lab Data (late), like a concentration. The lab data could be anywhere between 2 hours late and 14 days late.

    One of the more obvious configurations would be to have an analysis 'event triggered' on the lab data. The trigger time could be 2 hours ago (or 14 days ago), but the process data's snapshot would be <10 seconds ago. The misconception that '*' represents trigger time is the issue . . . because it leads to a very simple analysis that is also incorrect. just using tagval('process data','*').

    Again its confusing that you are suggesting that using tagval('process data','*') is incorrect but then using '*' outside of a tag retrieval function is correct.

    This is also hard to come up with 'on the spot' examples, because this is a situation where backfilling/evaluate behave DIFFERENTLY than normal running over time. I see a lot of 'solutions' given that are essentially 'well, just backfill'. Backfilling does seem to treat '*' as trigger time and not snapshot time ALWAYS. The evalute button does the same thing. The example I had most recently (from Case 00564622) was adjusted so that the analysis is not event triggered, but periodic, then relying on the automatic recalculation to hit when the late data finally arrives.

    An error occurred while saving the comment
    Matt Voll commented  · 

    No I had not tried that. ParseTime is used for Strings . . . Asteriks is usually with apostrophes ( '*' ). Putting those those together ( ParseTime('*') ) gives a Calc Failed. I had not thought until now to try using quotes with the asterisks . . . ParseTime("*") and that does calculate properly. How does Parsetime("*") and '*' differ, attached picture.

    The attached picture also suggests a further confusing aspect of this problem. Used outside of any tag retrieval functions, '*' means trigger time . . . but used inside of any tag retrieval functions, '*' means snapshot. Is this correct? That's very confusing.

    (side question, i don't recall any other situation in where the usage of "*" is appropriate)

    I do believe this would address the issues I had mentioned . . . however I would argue that this is far from ideal. I believe the confusion between * vs snapshot vs trigger time is likely a common misconception and thus a not obvious problem. I believe the ParseTime solution is a not obvious work around, requiring extra variables on MANY analyses. It would mean that I would need to include ParseTime("*") in nearly every analysis created that contains process data (usually 'not late') and manually entered data (usually 'late'). Not Obvious problem + Not Obvious solution + extra overhead on many analysses = :( .

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

    We’ll send you updates on this idea

    5 comments  ·  PI Vision » Symbols  ·  Flag idea as inappropriate…  ·  Admin →
    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
NEEDS MORE DISCUSSION
RESEARCHING/EVALUATING
DECLINED
PLANNED
STARTED/IN DEVELOPMENT
IN BETA/PREVIEW
COMPLETED