Currently, it is recommended to use the read-only version of a PI Interface if only reading is required, and to have separate read and write instances of the read-write version of a PI Interface if writing is required. (Reference: page 15 of the PI Interface For OPC HDA user guide, and I assume that the recommendation applies to other PI Interfaces as well)

This approach is unnecessarily complicated and can still be made more secure. Instead of having read-only and read-write versions of a PI Interface, consider having read-only and write-only versions of a PI Interface. That way, the recommendation becomes impossible to violate and is therefore no longer needed, and it avoids the migration from the read-write version to the read-only version if writing is no longer required.

Since PI Interfaces are slowly being replaced with PI Connectors, the implementation of write-only versions makes sense only for commonly used PI Interfaces such as OPC DA, OPC HDA, RDBMS, and SNMP.

PI-ACE Manager looks at the PI-Module Database to see if the individual modules are running. The Class Library sub-processes updates the PI-MDB when it starts & stops. If the process dies, it does not always update the PI-MDB values. So, there is no supported way to verify if the Class Library sub-process is running.

The PerfMon interface can't monitor the existence of the process. I have found that I can use the OSIWMI interface to find the Class Library process based on the Command Line of the process.

The WMI interface will only update the PI tag if the process is actually running. If the process does not exist. There are zero rows returned and WMI does not update the PI Tag value.

So, please update WMI interface to return a system digital state when no processes fulfill the query.

The WMI interface will optionally update the query returns one or more rows, but the column contains NO DATA. This is not the same as the request.

The current EFGen interface "Status" health tag displays a value of "Good" if it is connected to the data source but does not factor in if it is writing Event Frame data to PI. There is not currently a straightforward way to drive a PI Notification to alert that there may be an interface issue in the scenario that the interface is connected to the data source but can not write event frames. Either the criteria for what results in a status of "Good" needs to be revisited to include both connectivity to the source data as well as actively writing Event Frames, or a new parameter should exist to allow end users to see when the last successful Event Frame was written. That would allow users to send notifications if new event frames have not been written for a certain number of hours or days, so that a PI Administrator may inspect the interface to ensure it is operating as expected.

Currently when running any event frame generator interface (EFGen, PIFTBatch, etc.) in history recovery mode, there is no way to monitor progress of the actual history recovery. The only way to determine status is to check message logs periodically looking for the message "Switching to [REALTIME] data processing.". It would be helpful if there was a way to check progress of the history recovery (i.e. percent complete) along with an estimated time until completion. I'm currently in a position in which I'm running a PI-FTBatch interface history recovery, but also have users who need access to FTBatch EVT data generated after the start of the PI interface history recovery. I currently have no way to communicate to the users how long it will be before this EVT data is processed into event frames in PI.

Additionally, it would be great to have the ability to perform history recovery on a single EVT file in the event of an issue with a particular recipe. Currently history recovery is a time based operation only. Allowing for history recovery on a single EVT would allow a more surgical option while helping minimize the time not spent in real time mode.

PI Interface for OPC HDA, as well as OPC HDA COM Connector, offer a tool called HDATagBuilder to collect all tags on an OPC HDA Server and export them to a CSV-file that can be used with PI Builder.

This tool, however, is currently not able to correctly handle double-byte characters well. If it finds one inside item ID's or descriptions, the property value (whether it's the tag name, the description or the instrument tag) simply becomes a blank.

Please fix this, as more and more DCS's are capable of using them, and even PI DA can handle tag names containing them, given some restrictions (see KCS: PI Tag Naming Constraints).

When Eventframe Batches are created by a Batch Interface, the used Unit in the plant is created as Element in AF and linked to the Unitprocedure EventFrame. Unfortunately it is not linked to the parent Procedure Event, leaving the "referenced Element" list of procedure event empty.
If a user wants to create a report over all Procedures a certain unit was involved, he has to download all Procedure Events and Unitprocedures via Datalink and do the filtering there.
With PI Batch it was possible to search for PI Batches using PI UnitBatch criteria like Unitname. We need this feature in Eventframes as well and could achive this by linking the referenced Elements of the child Unitprocedures to the Procedure Event or by creating a new filter mechanism in the eventsearch. I would prefer the referenced elements though.

Hello,
the PI Event Frames Interface Manager application must be run in the same machine that hosts the PIEFGen interface. This is an issue regarding our security rules because, the PIEFgen interface runs in secured machines and we don't want to allow users to RDP to these machines only for setting batch configuration (triggers, batch nr...) .

This issue did not exist with PIBatchgen as the setting of batch configuration (triggers, batch nr ...) was available inside PI SMT.

It would be great to either be able to run PI Event Frames Interface Manager in a different computer or to be able to set up the batches through PI SMT.

a lot of your existing Batch Interfaces are based on RDBMS (Simatic Batch, DeltaV, ABB). But there will always be some Batchstorage solutions based on a relational database which are not included in your source system list. For now Honeywell Procedure Analyst or ABB Workflowmanager are such systems.
If we users had a generic RDBMS to Eventframe Batch Interface where we could do the mapping between relationale database rows and your typical Batch Interface placeholders by our own and define triggers for different batch levels just like we can define triggers now for additional batchinformation, we could connect to a much wider range of batchstorages to transmitt data to Eventframes.