AVEVA™ PI System™ Feedback Portal

Welcome to our new feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas and comments are visible to all other users.


This page is for feedback specifically for AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Add a new idea Subscribe
Status Declined
Product AVEVA™ PI Server
Categories PI Builder
Created by Kenneth Barber
Created on Aug 20, 2022

RELATED IDEAS

Throw an error if both excdev and excdevpercent or both compdev and compdevpercent are present when publishing

Currently, if you publish a PI Point configuration that contains both excdev and excdevpercent or both compdev and compdevpercent, the "percent" versions silently take priority. This means that if a user imports excdev and excdevpercent, edits only excdev, and clicks on Publish, PI Builder will give no indication that the excdev edit was not made. Please do not make PI Builder silently make decisions for the user. Please throw an error to let the user know that an edit to both excdev and excdevpercent or both compdev and compdevpercent at the same time does not make sense, and let the user change their PI Point configuration to what they intended.
  • ADMIN RESPONSE
    Aug 20, 2022
    We are reluctant to make changes per the original posting due to backwards compatibility concerns. We have customers with years of PITagConfigurator spreadsheets that have migrated over to PI Builder. If we were to change behaviors now, it could become problematic. Lastly, since this behavior is well documented and has been documented for many years, we do not feel it's the right time to add this enhancement in PI Builder.
  • Attach files
  • Guest
    Reply
    |     Aug 20, 2022
    We actually do not know if a user had made changes to both (or any for that matter). In order to know whether changes had been made, we would need to query the server before sending the values and doing a compare. As you might imagine, this is very expensive and would dramatically slow down the operations. Consider an Excel spreadsheet with 100,000 rows or more. The current behavior is the same as the previous PI Tag Configurator Excel Plugin for PI Points.
  • Kenneth Barber
    Reply
    |     Aug 20, 2022
    Stephen, I was thinking more along the lines of throwing the error if both excdev and excdevpercent or both compdev and compdevpercent are present when publishing, regardless of whether either of them was changed. PI Builder assumes that anything that is published is an edit, regardless if the value actually changed or not. That is the assumption that I'm rolling with.
  • Guest
    Reply
    |     Aug 20, 2022
    Kenneth, We will consider this. However, one of the biggest use case we have had is for users to pull in every column, make the necessary changes, then publishing back. This is true for both PI Builder and the previous PI Tag Configurator. What you're describing would break that use case. In addition, what you're describing can be accomplished today if the user simply pulls in 1 of those columns, make the changes, then publishing back. Thanks for your feedback. We will evaluate this in our planning sessions for future releases.
  • Kenneth Barber
    Reply
    |     Aug 20, 2022
    Stephen, what if, when the user tries to publish both excdev and excdevpercent or both compdev and compdevpercent, they are given the choice to either stop the publish or choose one of excdev or excdevpercent and/or one of compdev and compdevpercent to be edited? Then that use case that you mentioned would not be broken, and the user will not be forced to delete columns.
  • Guest
    Reply
    |     Aug 20, 2022
    Throwing an error or selection box would break the existing behavior. If the behavior is documented then I can't see any reason to do anything else.
  • Kenneth Barber
    Reply
    |     Aug 20, 2022
    James, if by "break", you mean "change", then yes, my suggestion will break the existing behaviour. And so will every other change suggested on OSIsoft UserVoice. Documenting a program's behaviour is not the end of the road. Improving the behaviour is the next step. I've already described what is wrong with the current behaviour and how to fix it. I'm not sure why you feel that this change isn't worthwhile. Is there something obviously wrong with a choice menu popping up? Am I missing something?
  • Guest
    Reply
    |     Aug 20, 2022
    I've been configuring PI tags since 1998 and I've routinely deleted the excdev and compdev columns before publishing because I thought the behavior was the opposite as described in these posts. I use span and a standard escdevpercent and compdevpercent for tag configs. All these years I could have saved myself a couple of steps. I do have to change totalizer spans to say 1000 to make this work. I think having both is redundant. I don't know why PI would store both internally as either one can be calculated from the other with the span. I don't know which one of the two it keeps but I'm guessing escdevpercent and compdevpercent since it calculates the other by default. I was thinking not including escdev and compdev checked by default since these appear to be derived values and then someone who configures tags the opposite of me can go in and check them and uncheck the other. Of course I haven't figured out how persistent choices are. The biggest gotcha I found with PI Builder is that you can't choose record number (recno) even if you wanted to from the list as it is the one attribute that didn't make it over from Tag Configurator. (Yes descriptor is now Description for some reason and Tag is now Name but the functionality of both is the same). If there was ever one to not include I'd say typicalvalue. What purpose does this have besides keeping one from creating tags when it isn't between the zero and max based on the span? But a minor inconvenience. I routinely document my point creations by sending out tag build configs and when some tags got accidently deleted, (they were created with the same name on another server, different source), I no longer had a record of the record number to enable me to recover their history. The fix by OSISoft helpdesk was to go into the list and hand type in recno in the end column every time I dump tag configs as it is not persistent into a new sheet. Anyway, I should post this in another comment.