Matt Voll

My feedback

  1. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    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  · 
  2. 4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  NOC Services  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  3. 58 votes

    We're glad you're here

    Please sign in to leave feedback

    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  · 
  4. 14 votes

    We're glad you're here

    Please sign in to leave feedback

    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  · 
  5. 13 votes

    We're glad you're here

    Please sign in to leave feedback

    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  · 
  6. 16 votes

    We're glad you're here

    Please sign in to leave feedback

    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  · 
  7. 135 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    14 comments  ·  PI Server » Analytics & Calculations  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  8. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    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  · 
  9. 54 votes

    We're glad you're here

    Please sign in to leave feedback

    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  · 
  10. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PI Interfaces  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll shared this idea  · 
  11. 83 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    Matt Voll supported this idea  · 
  12. 22 votes

    We're glad you're here

    Please sign in to leave feedback

    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  · 
  13. 47 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  PI Server » Analytics & Calculations  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  14. 66 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  PI Vision » Look & Feel / Styling  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  15. 40 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PI Vision » Authoring Displays  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  16. 18 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PI Server » Notifications  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  17. 87 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  PI Vision » Ad Hoc Analysis  ·  Flag idea as inappropriate…  ·  Admin →
    Matt Voll supported this idea  · 
  18. 162 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    The combination of circular references and Automatic recalculation is hugely problematic. There are a number of ways to inadvertently create a circular reference and the methods for identifying them, especially if they are not your own analyses, can be incredibly tedious.

    Circular References cause Automatic Recalculation to endlessly loop through recalculations. There is no proactive way to identify this as a problem. It eventually can be noticed by manual backfills being in the queue for longer than normal . . . or by an eagle-eyed user noticing that certain analyses continuously flip into the 'backfilling' status.

    Matt Voll supported this idea  · 
  19. 4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  PI Server » Asset Framework (AF)  ·  Flag idea as inappropriate…  ·  Admin →

    We strive to provide a basic set of UOM classes that we felt would be useful for our general customer base. We also understand that each user has different needs, which is why users can provide their onw UOM class based on their needs. This request seems to fit that model in that you can add a UOM class for your specific needs.

    Matt Voll supported this idea  · 
    Matt Voll shared this idea  · 
  20. 24 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  PI Server » Analytics & Calculations  ·  Flag idea as inappropriate…  ·  Admin →

    Can you clarify if your use case has 1 output PI Point or multiple PI Point(s)?

    Is there any reason why you are not using RDBMS interface to bring your table data into the PI System? That would remove a lot of complexity and greatly improve performance.

    Matt Voll supported this idea  · 

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