I think if you bypass GEP and the measurement routing system and instead use the openHistorian socket API to send HistorianValue objects directly into the archive, you can use System.BitConverter.DoubleToInt64Bits()
to save the full-resolution 64-bit floating point value as a long integer. The only problem here is that the value wouldn’t show up properly in any of the displays because every one of them assumes the value was stored as a 32-bit floating point number.
Here’s the code used in LocalOutputAdapter that converts the measurement into a HistorianValue.
// Since current time-series measurements are basically all floats - values fit into first value,
// this will change as value types for time-series framework expands
m_value.Value1 = BitConvert.ToUInt64((float)measurement.AdjustedValue);
m_value.Value3 = (ulong)measurement.StateFlags;
Given that the LocalOutputAdapter is not utilizing Value2, you could get the best of both worlds if you utilize use that to store the full resolution value.
m_value.Value1 = BitConvert.ToUInt64((float)measurement.AdjustedValue);
m_value.Value2 = (ulong)System.BitConverter.DoubleToInt64Bytes(measurement.AdjustedValue);
m_value.Value3 = (ulong)measurement.StateFlags;
Note that any option you choose here will likely adversely affect the archive’s compression and cause the archive to be larger than what would typically be expected.
As for whether there are plans for future enhancements to support other data types, the answer is yes. However, as of yet there is nothing concrete, and therefore also no timeline. We may get to it soon, and we may get to it never.