Phillip Knight

My feedback

  1. 21 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 Connectors » General  ·  Flag idea as inappropriate…  ·  Admin →
    Phillip Knight supported this idea  · 
  2. 9 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

    4 comments  ·  PI Connectors » General  ·  Flag idea as inappropriate…  ·  Admin →
    Phillip Knight supported this idea  · 
    An error occurred while saving the comment
    Phillip Knight commented  · 

    Always placing the AF hierarchy under the /UFL element limits the usefulness of the connector. I may want to associate my ufl elements (thinking hundreds to thousands) to parent elements to facilitate collections, rollups, child-parent relationships. Assuming weak references to the UFL build AF structure is a solution is not manageable and does not enable these use cases.

    Also allow for the UFL to build AF structure based off of user named templates, not UFL.<template>. The prefix is nice that it associates a source of the data, but why? Let the end-user configure this, or have option to specify an optional prefix. As built this is too rigid for every use case.

  3. 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 Developer Technologies » PI Web API  ·  Flag idea as inappropriate…  ·  Admin →
    Phillip Knight shared this idea  · 
  4. 3 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 Interfaces » Other Interfaces  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Phillip Knight commented  · 

    COUNT, ANALOG and POINT all have FLDTIME fields, collecting data from these records should be consistent. For configurations where sampler may have large degrees of latency from the FEP, using different timestamp strategies may result in significant time differences between tags. The choice becomes timestamp from sampler with significant time delay from the EMS, or inconsistent count data.

    In addition, GE has said recently for meters (COUNT), if the meter read does not change value, but the timestamp does, ISD will not consider this an exception and PI will not be able to collect this read. For accumulators this is not acceptable to certain consumers of this data. Being able to sense change using FLDTIME should work around this problem with ISD.

    Phillip Knight supported this idea  · 
  5. 339 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

    31 comments  ·  PI Vision » Authoring Displays  ·  Flag idea as inappropriate…  ·  Admin →
    Phillip Knight 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