This rounding issue has to do with the way the trend system stores data. In Citect 5.30 and earlier every sample recorded by the trend system is squeezed into a double byte. Allowing for some overhead, you have a practical range of 0-32000 to store all trend information. This imposes a certain granularity or resolution limitation to all archived data. Citect 5.31 and later have the option of storing an 8-byte floating point value for each sample. This allows for 15 significant digits, so even LONG tags and REAL tags can be recorded without losing precision. The actual value is recorded in the data files without being scaled.

Consider the following example for 2-byte trends. Tag1 is defined as having an engineering range of -100 to 100. Trend1 is defined to sample Tag1 at some arbitrary period. As a part of the project, TrnSetTable() is used to force some old data into the trend for Trend1. To test the validity of the operation, the data from Trend1 is logged to a database using TrnExportDbf(). During the course of testing, it is found that some values are not coming out as they were put in; a value that is input via .csv file as -3.2 is exported to dbf as -3.20625. 

Why is this happening? Look at the engineering range of the tag. It is -100 to 100. That is a range of 200. Divide this range by the resolution of the trend system and you have a granularity of 0.00625. Coincidentally, that number sequence is amazingly similar to the error reported in the above example, -3.20625. It is to be expected that if the system was asked to store the number -3.21, it would yield -3.21250 when exported, and so on. Basically all data fed into the system will be rounded to numbers with 0.00625 as a common denominator.

This is the scaling/rounding limitation of the 2-byte trend system. One way around it is to adjust the scaling of the variable in question so that the rounding is more favourable. In the example above the variable scaling could be changed to -160 to 160 or even better -80 to 80 if the full +/-100 range isn't needed. These new ranges would allow a resolution of 0.01 and 0.005 respectively, which would be a lot neater. If this approach is taken, the associated trend files should be deleted for the scaling to take effect.  The other solution is to use 8-byte trends in Citect 5.31 and higher. Two-byte history files may be converted to 8-byte format with the Trend Conversion Utility available from the Citect.com Toolbox.