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.
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.
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?
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.
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.
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.
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.
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.