Tags created by a PI Connector can be renamed, but these renamed points can be "forgotten" if the Connector's point cache is lost. Updating the Tag Mapping configuration file can avoid this cache loss, but I would like to be able to rename Connector tags without updating this configuration file.156 votes
We are working on this request. We plan to provide users the ability to pick their tag naming convention and not worry about managing a cache file.
Support for health tags (similar to UniInt health tags), Windows performance counters, or any other way to bring Connector status and health information into PI tags to put them side-by-side with Interface health monitoring.91 votes
We understand and acknowledge the importance of this request. We are evaluating how to provide a homogeneous and unified experience for health information across all our connectors.
PI System Connector: Need real time snapshot data support for the PI System connector.65 votes
This item is under technical review. Currently, support for collecting Snapshot data can be achieved via PI to PI interface and should be considered for achieving this specific functionality.
The editor should allow you to see in real time how it interacts with the data. Being able to test the INI file prior to loading some file would make it much more manageable to read a variety of data format and insure that it has the expected behavior before starting the connector and having to use a trial and error approach. A good example of this is what Microsoft does with PowerQuery in PowerBI. This would allow troubleshooting UFL issues much more easily and allow more people to use the connector without having to spend a serious amount of time testing all the various scenarios.
The editor should allow you to see in real time how it interacts with the data. Being able to test the INI file prior to loading some file would make it much more manageable to read a variety of data format and insure that it has the expected behavior before starting the connector and having to use a trial and error approach. A good example of this is what Microsoft does with PowerQuery in PowerBI. This would allow troubleshooting UFL issues much more easily and allow more people to use the connector without having to spend a serious amount of…64 votes
The PI Interface for RDBMS is one of the most used PI Interfaces. Unfortunately, the fact that it is a PI Interface makes it unnecessarily difficult to use, and turning it into a PI Connector can help alleviate this. No more Location codes, squishy PI ICU, distributor tags, SQL file in the InstrumentTag, strange notations in the ExDesc, etc.52 votes
From this item description it looks like the major pain point with existing RDBMS interface is providing configuration information (to the tags and interface). I would like to understand more if the request behind the connector is to solely minimize providing configuration information to the existing interface and tags?
As a PI Admin relays allow for improved security of process-network-to-DMZ communication. This will greatly aide in the PI Connector for OPC UA's deployment in production systems.43 votes
We are currently working on adding Relay support for PI Connector for OPC UA.
allow historical data access with custom time ranges, like OPC HDA35 votes
We have a feature in the upcoming 1.2 release of the connector that will allow you to collect data from OPC UA tags that do not have current values but do have history. We would poll these every 60 seconds (default) to find new data.
Was that part of this request in any way? Can you describe in more detail what you would like as a feature that prompted you to vote for this time?
Support for Alarms & Conditions. This data type would be good candiate for storing into Event Frames. Tell us more about your use case in the comments, which source system you have that support A&C, and how you would select which A&C to collect/not collect. How would you like Event Frames built and named?35 votes
We are currently evaluating how to appropriately and effectively bring this functionality forward. We are working through details pertaining to implementation of this functionality.
Currently Connector configured to rertieve event on change and not based on a scan class like interfaces.The Connector suscribes to the changes, and when a change comes in to the server, the data will be sent to PI connector. We need option to retrieve the data every certain minutes even data is the same and is not changed on OPC server.
We understand that for slow changing points, values might not change often and thus there is a need to collect values at certain time intervals as opposed to on change. However, scanning at frequent intervals leads to increased load on the server and thus can lead to performance degradation. We are discussing how best to solve this problem with PI Connector for OPC UA.
Ability to change which PI tag the PI Connector for OPC UA writes to without having recreate new PI tags
Currently, once PI tags are created by the PI Connector for OPC UA the connector uses the point ID for its mapping from the OPC UA server to the PI tags. Thus, if a configuration change occurs on your OPC UA server (i.e. NodeIDs change) the only way to map the newly named (with no change in the data stream) NodeID to a PI tag is to create a new PI tag instead of simply changing the configuration on a PI tag. As a PI system administrator, I want the ability to change a PI tag attribute (i.e. Extended Descriptor) and have the Connector automatically update which data stream is written to that PI tag.
Currently, once PI tags are created by the PI Connector for OPC UA the connector uses the point ID for its mapping from the OPC UA server to the PI tags. Thus, if a configuration change occurs on your OPC UA server (i.e. NodeIDs change) the only way to map the newly named (with no change in the data stream) NodeID to a PI tag is to create a new PI tag instead of simply changing the configuration on a PI tag. As a PI system administrator, I want the ability to change a PI tag attribute (i.e. Extended Descriptor)…29 votes
We are currently working on incorporating functionality that will allow users to write data to existing tags without having to recreate a new set of tags.
Allow a hostname override when connecting to the OPC UA endpoint. We have some use cases where the URL returned by two independent OPC UA servers has the same name. This prevents the Connector from connecting to the correct endpoint. Allow an IP address to be specified in the config, which would be used to connect instead of the URL hostname.25 votes
To ensure that data continues to flow from the OPC UA server to PI Connector for OPC UA, the connector could be configured to switch to another OPC UA server under the same conditions as the OPC DA Interface23 votes
We are currently working on enabling server-level failover for PI Connector for OPC UA.
As an equipment specialist working centrally, I wish to deploy my AF Element Templates including Analysis and Notifications Templates to my remote sites so I have them managed from a central location. This also insures that remote sites are using the same calculations and KPIs.22 votes
We have considered including this functionality natively as part of the PI system as opposed to including this in the connector.
Sometimes we need to send data back to our sources. Connectors should support output tags21 votes
RWE Power AG
“But one really important feature we need, is the ability to write back from PI into the SCADA system
Until now, we couldn’t find anything about this (important) functionality.
So our question is if we can use this connector bi-directional?
And if not, is this already in the roadmap for this connector?”20 votes
Can you share with us any info about your use case for sending data back to the SCADA system? For example, what is the purpose of that data? How many tags and how often will you send?
Adding the Relay and the DCM framework to the "legacy"IEC 104 Connector in order to improve the architecture management and security19 votes
Collecting more data to understand the need and use case behind this request.
Ability to turn off auto creation of PI tags - When data is sent via REST to a PI Connector for UFL service ,currently it looks for a PI Tag in the PI Server and if the PI Tag does not exist it creates a new PI Tag. It would be good if we could turn off the feature if not required as in our case we have a naming convention for PI Tags and we create the tag names in advance so would not like to allow for the auto creation of PI Tags.19 votes
I’m not sure why this would be needed. In the UFL connector you need to specify the name of the tag that you write to. And if that tag already exists, it will write to it. If that tag does not exist, then the connector would create that tag with your desired tag name. Why would you want the connector not to create that tag?
This should be self-explanatory. I'd also suggest making Linux versions of all software available, but this Connector would be a great start.19 votes
We are evaluating this proposal. If this request is for a specific distribution of Linux, kindly forward that information to me or please leave a comment with the device type/name or Linux distribution name.
Example 1 - OPC
If a new connection needs to be made to one OPC Server, restarting the connector forces all data sources (and potentially connections to multiple OPC Servers) to be restarted.
Example 2 - UFL
If my web service is down and I do not want to connector to keep trying to access to REST Server, I cannot stop/disable only one data source18 votes
Add the ability for PI Connectors to create future data point. This is especially useful for the PI Connector for UFL. The current workaround is to manually create the point as a StoredValues=FutureData.17 votes
- Don't see your idea?