The current version of the PI Interface for OPC XML-DA seems to only support SOAP 1.1. All recent OPC XML-DA servers are developed following SOAP 1.2 standards, meaning the PI interface will not connect. Please enhance the interface to also support servers using the newer SOAP 1.2 standards.

This also relates to tech support case 00857284

Add PI Interface for OPC XML-DA documents to the Live Library

The PI XMLTool that is bundled with the PI Interface for OPC XML-DA does not function with Windows Server 2019 even though the PI Interface for OPC XML-DA itself is documented to function. Can the client tool please be worked on so that it will function with the same operating systems that the interface does. This is a key component to aide in the troubleshooting of the interface as well as determining the correct instrumenttag field by the browsing the XML-DA tags on the server.

On PI Interface for Foxboro I/A 70 series version 2.4.2.12, the supported operational System are Windows 2008 R2, Windows 7, Windows 8 and 8.1, Windows 2012 Server.
Can we also test the interface against Windows 10, to included it as a supported OS?

The PI Interface for OPC DA is packaged with the PI OPCtoCSV tool which extracts all OPC Items. When the tool is run into error with certain branches, the tool will stop and disconnected from the OPC server/tunneller. For example: “GetItemProperties(“xxx”) error 0x800706be. The remote procedure call failed. pEnumleaves  Next() returned 0x800706ba”
If we could specify an option for the tool to skip those branches in error and also attempt to reconnect to the OPC server/tunneller, for automation purpose for the tool to continue running instead of exiting.

Rockwell FactoryTalk Batch v12.01 allows to output batch data to a SQL database as well as EVT files. Just like with EMDVB, the PI Interface for FTBatch should be able to use both data sources.

There are no current direct native interface connectivity to Hitachi ABB Mach systems.

Current suggestion is to investigate IEC 61850 or Modbus could be investigated as an option.

The interface instancesnames contain the plantsnames and I want to put the interfaces with the same plant name together in the list.

As a PI System Administrator, I would like to monitor the point count and other parameters for scan class 0 via Performance Counters. Currently, this is only exposed via the UniInt Health Tags.

ABB 800xA offers a batch capture mode that is more flexible than ISA88 since it doesn't match all unit procedures to units, but rather acquires them at the beginning of the batch. Currently the interface is designed to only retrieve batches that follow the ISA88 model.

Currently, AMI Interfaces require a rebuild of the AMI cache files when the PI Server is migrated to a new machine/hostname (Although to clarify if the hostname does not change during the PI Server migration the cache does not need to be rebuilt). This is undesirable for large AMI implementations as rebuilding the cache files can be a time consuming process.

It is requested that AMI Interfaces should be able to handle PI Server migrations with new hostnames without rebuilding the AMI cache files

Werum has recently released the next version of their PAS|X Database, and it bolsters a new method of Data Access. OSIsoft will need to release an re-tooled version of their PI Interface for Werum PAS|X to support this latest Werum version and the new data access method.

There is no easy way to verify that historical data moved from one PI Server to another using the PI to PI Interface isn't missing data on the target PI Server.

When primary server is down, secondary server is accessed instead of primary server, which is good. However, in the case of output point with source tag, it stops working, then restarting the interface instance of interest is needed. Of course, if we set up UniInt Failover that backup instance keeps its session with secondary server, this issue can be prevented. But, it will be better if source tag is also switched to secondary server.

This affect to delay in Event\Trigger points. KCS: Delay in Event Points.

When using Event Points, we purposefully do have a delay (if excMax is > 2 s then 2 s else 0.9*excMax) for advise tags (Trigger Point) before they're sent to the PI Server if the event value has not changed since the last scan.

Currently if EFGEN is configured to evaluate PI Points at the event end, long batches require recovery start time to be set before the start of the batch. This leads to a long recovery process as many completed batches will be evaluated again.