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).

I had a case (794719) with a customer who would like to have SNMPTrap interface available on our live library so that he can browse online instead of downloading the user manual.
Thank you!

allow instruction level data to use batch level start time. Add an option to allow this. use case: the instruction level start time is the time when the DOT should be ramped up or down.  The batch start time is a few minutes before that timestamp.  To get the turbines adjusted in time, they need to use the batch start time.  This gives the operator enough time to adjust the set point and have the new target met by the instruction start time.

The new CSI UCOS API now supports a "bumpless download".

"CSI has recently added what they call a “bumpless download” feature to their UBrowser application that the interface uses to communicate with the database. What this does is allows the database to be updated without stopping the service. "

Please implement this feature.

Note: This was previously Enhancement 121741.

Add support for Conversion Factor PI Point attribute to PI Interface for BACNet.

Note: This was previously Enhancement 118928.

Upon initial configuration, the XML config file does not include the default interface settings.  This can cause confusion for the user.  Explicitly add the elements for the default values to the XML config file.

Note: This was previously Enhancement 123207.

OPC HDA Interface would be enhanced to use  switch '/outputsnaptime'.  For output tags, the interface would use the timestamp from the original event that triggered the output to timestamp the data.

Note: This was previously Enhancement 124754.

Add functionality for the Davis to Pi Interface to read additional sensor data points. The Davis to Pi Interface does not support the use of additional sensors, such as a second or third temperature sensor. The Davis console supports additional sensors, but the Pi Interface cannot read them.

the ability to disable the timezone adjustment.

currently we are calculating daily kpis on our global pi server. with PItoPI we are sharing it to the site pi-servers.
so the daily kpi for e.g. 1st januar 2019 00:00AM sould alwas have that timestamp. Because if the forward it to e.g. britain, it has the timestamp 31st decemper 2019 11:00PM (adjusted -1h to austrian time)

plz make it possible to disable it via Location2.

Failover mechanism in fxbais (Schneider-Electric PI interface for Windows) doesn't lead to a failover when the primary interface node loses connection to the network (f.i. when its NIC fails). It just starts buffering and sends its data after the connection is back again.
It keeps on updating its watchdog CALC block on IA, so no take over is initiated.
Some applications require "near real time" data, so if it comes in a day later, it's not very useful.
In such a case, the secondary interface node could perfectly take over the data collection.

For a PI tag with a specific scan class, if no new value is collected by the PI Interface after a period of time (for example 2x the scan class) , the interface will add automaticaly the value "No Data". It will avoid the usage of a dedicated analyze for this, in the PI Server. And like that, the PI user will be aware of the issue, by using any PI Visualization tool.

Hi all,
 
i got to know this standard:
Standards – SiLA Rapid Integration
This standard is a really good approach to connect various types of lab equipment. Over it it is possible to fetch for example the RPM of a mixing device, temperature of a heater etc.
For my understanding, this screams loudly for a time series recorder with analytic options.
 
Thanks for your support
Thorsten

Right now PerfMon only supports ArcNoReplace. PerfMon has a history of failing over if a server is unreachable. And since PerfMon only supports Hot failover, every time it fails over the new interface tries to write values that the old one already wrote. I would like to be able to specify ArcNoReplace so I don't get an error flood every time the interface fails over.

Currently DNP3 outputs are done one event at a time. We could improve performance by either supporting multiple DNP messages per TCP packet or multiple analog output commands per DNP message.

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.1970

Having the support of the PI Annotations in the PI-to-PI Interface.

We see a data gap in one PI Data Archive after the machine hosting the PI-to-PI interface was one hour in the future. In this case, the buffer disconnected from the machine when the issue happened, The buffer did not work correctly and there was a data gap in the target server.