PI Interfaces
Welcome to the
PI Interfaces feedback page!
We created this forum to hear your ideas, feature suggestions and feedback on PI Interfaces. Please suggest your most important features and design change ideas on this site, and vote for your favorite ideas.
Please note that your ideas and comments posted here are visible to all other users.
- For bugs, please open a case with OSIsoft Tech Support through myOSIsoft Customer Portal (https://my.osisoft.com) instead of sharing them on this site.
- For documentation feedback and bugs, please report to documentation@osisoft.com instead of sharing them on this site.
-
Log bad timestamps for the PI RDBMS Interface
When the PI RDBMS Interface gets a bad timestamp from the source RDB that it cannot coerce into a PI Timestamp, the actual bad timestamp received from the RDB should be logged as part of the error message.
This would coincide with the following error:
"pitm_settime() error - 15002. Using current time."
7 votes -
Alert user when the interface discards values
Example: When using a distribution tag, the number of tags returned and number of values sent to PI can be mismatched, due to missing aliases or data that does not need to be collected.
It would be helpful to identify what values are dropped or were not updated in PI. While there is the @rows_dropped variable, it can only be used for distribution tags and may have limitations when used with stored procedures.
4 votes -
Accept weeks and years in the relative time syntax for history recovery start and end times
For whatever reason, times such as -1w or -1y are not accepted, but times such as -1mo and -1d are OK.
Please make the PI Interface for RDBMS accept the same relative times that other PI programs accept.
2 votes -
Add option to select interface behavior for bad timestamps (PI RDBMS)
When the PI RDBMS Interface gets a bad timestamp from the source RDB that it cannot coerce into a PI Timestamp, the interface attempts to use the current timestamp instead and logs the following error:
"pitm_settime() error - 15002. Using current time."
The interface should instead include an option that controls what to do in this situation. The potential options would be to either discard the event entirely after logging an appropriate error or to use the current timestamp of when the event was retrieved (Also logging an appropriate warning).
2 votes -
Improved handling of PIBUFSS initialization
We have encountered a situation where we were unable to write out-of-order data to PI through the buffer subsystem from an interface, apparently because the buffer subsystem was not yet fully initialized when the interface connected to it. Please implement an appropriate wait cycle at interface startup, to ensure that the buffer subsystem (on which the interface is dependent) is fully initialized and available before permitting the interface to complete its connection and initialization.
Note the case in question arose when the interface service was configured with a dependency on the PI Buffer Subsystem service.
1 vote -
RDBMS time stamp precision
Currently the ODBC connection is configured with a SQL date time parameter when retrieving the TS parameter (snapshot time stamp).
Due to the fact lots of sources system having more precision in their time stamps, it makes it hard to compair source time stamp to the pi time stamp (precision and rounding issue in SQL).
I request to add support for sql datetime2 into the ODBC connection, or an option to read the time from the snapshot in seconds since 1.1.19701 vote -
History recovery from multiple tags with one output tag
I have a scan-based output point writing multiple PI values to the relational database as described here:
https://livelibrary.osisoft.com/LiveLibrary/content/en/int-rdbms-v4/GUID-1A194D2B-388B-4FD7-8B82-D85EDDBBC572I would like to perform history recovery for such an output point, but this is currently not possible because the output point is scan-based:
https://techsupport.osisoft.com/Troubleshooting/KB/KB01139/Since event-driven tags can have only one source tags, I cannot recover historical data from multiple PI tags with only one output tag.
1 vote -
Accept the dd-mmm-yyyy format in the absolute time syntax for history recovery start and end times
The PI Interface for RDBMS currently accepts the format dd-mmm-yy but not the format dd-mmm-yyyy for history recovery start and end times.
The former format lacks the century, so the year is ambiguous. The latter format solves this problem and so should also be accepted as a valid time format.
1 vote -
New start-up parameter /SYNC_TIME defining a floating-window during which the interface will keep a RDB table in sync with PI data archive
The new RDBMSPI param: /SYNCTIME=relstarttime,relendtime
for instance /SYNCTIME=-6h,+1hWhen set, the interface:
- after each execution of a query, which shall have the same "floating" window in its WHERE clause; for instance:
SELECT time, value, status FROM table1 WHERE time BETWEEN GETDATE()-6 AND GETDATE()+1;
reads events for this tag from the PI data archive (for the interval defined by /SYNC_TIME) and compares timestamps from both sets. The "master" is the set from the rel. database; that is, if in the set taken from PI, there are timestamps, which were not returned from…
1 vote
- Don't see your idea?