smcnabb
My feedback
-
9 votessmcnabb
supported this idea
·
-
39 votes
An error occurred while saving the comment smcnabb
supported this idea
·
-
81 votes
An error occurred while saving the comment smcnabb
commented
Also same issue as Jackie Li and PDUHAMEL. We have some analysis that don't need history. This makes O&M more difficult because we always see errors. It would be better to have the ability to choose which analysis participate in backfill.
smcnabb
supported this idea
·
-
14 votessmcnabb
supported this idea
·
-
45 votessmcnabb
supported this idea
·
-
329 votes
At this time, this item is not currently scheduled for a release of PI Vision. If this changes, this item will be updated to reflect the current status.
smcnabb
supported this idea
·
-
83 votessmcnabb
supported this idea
·
-
7 votessmcnabb
supported this idea
·
-
138 votes
At this time, this item is not currently scheduled for a release of PI Vision. If this changes, this item will be updated to reflect the current status.
An error occurred while saving the comment smcnabb
commented
I agree with Bryan1. It seem it should be a standard built in symbol or control. It's a historian so being able to view archived values in multiple ways seems an obvious use case.
smcnabb
supported this idea
·
-
4 votessmcnabb
supported this idea
·
-
14 votes
An error occurred while saving the comment smcnabb
commented
would like to know the use case and design decision for this change. Why does the interface override a system setting for the folder? And why is this listed as an enhancement request if the "enhancement" is restoring previously defined behavior?
The behavior is now significantly different, it doesn't appear to follow standard conventions and there doesn't appear to be any documentation explaining the new behavior or reason(s) for the change.
It definitely is causing problems for our system and use cases because if the file is ever accidentally deleted or needs to be temporarily or permanently moved, manual intervention will now be needed to create the files, with the correct names, and with the correct (previously inherited) permissions. It no longer is automated and managed (as expected) by the interface. With more than a couple interfaces (we have over 50 easily), management of this is now a nightmare.
smcnabb
supported this idea
·
-
77 votes
I know this thread is old but this needs to be revived and addressed.
The ICU needs to either be decoupled from the MDB, or there needs to be a mechanism where users can bulk edit settings that affect multiple interfaces. Perhaps by allowing the batch file to override the MDB (rather than just having it one way), migrating the settings into AF where they can be managed by the administrator or just allowing the batch file to be the "master" copy.
Every time we have to change even a single setting now, it has to be done manually via the ICU. When dealing with hundreds of interfaces, what should be a simple change has become a time consuming, tedious and error prone task. I don't know how many hours we have burned being stuck clicking through the ICU just to make a change that could have been done quickly, easily and consistently via a simple bulk edit of the batch files. Worse yet, many of these settings are likely to need change over the life of a PI system, or even as the system is tuned and optimized, so chances are most users will be faced with the unpleasant task multiple times over.