# POWER CHART Problems EXPORTING data to csv file

**URL:** <https://forum.inductiveautomation.com/t/power-chart-problems-exporting-data-to-csv-file/101482>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [January 28, 2025, 11:13am UTC](https://forum.inductiveautomation.com/t/power-chart-problems-exporting-data-to-csv-file/101482 "2025-01-28T11:13:46Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jiguti](https://avatars.discourse-cdn.com/v4/letter/j/e495f1/32.png) [@jiguti](https://forum.inductiveautomation.com/u/jiguti)\
**Post date:** [January 28, 2025, 11:13am UTC](https://forum.inductiveautomation.com/t/power-chart-problems-exporting-data-to-csv-file/101482/1 "2025-01-28T11:13:46Z")

</div>

Hello. I'm using POWER CHART in PERSPECTIVE.

Im loging with INGNITION HISTORIAN data like TEMPERATURE. A float value with 2 decimals. Example: 23,56 ºC

Everything is ok for visualize the data in graph. The problem begin when I'm in the power chart and use the "EXPORT" option to csv file.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/3/d3795e7ff508b4f0f8c3471ea136eb1cfde5a8ab.png)

The CSV file show values like this:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/9/7907f0b8ac6295f52be2103bbb1414849502f84f.png)

They're not the same type of value.

I checked that in my database is OK:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/1/21c2fca57b0df93352199e90d09b4eae92b1316b.jpeg)

You can see (for expample with temperature) is a float value with 2 decimals. I think is OK in the DATABASE.

Inside perspective property editor can change only date and time format for exporting item. Nothing more..

Some idea what is happening??

Thanks so much  
Jose I.

---

<div class="post-metadata">

**Author:** ![MG3](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mg3/32/84125_2.png) [@MG3](https://forum.inductiveautomation.com/u/MG3)\
**Post date:** [January 28, 2025, 11:46am UTC](https://forum.inductiveautomation.com/t/power-chart-problems-exporting-data-to-csv-file/101482/2 "2025-01-28T11:46:07Z")

</div>

I have a feeling that this issue is flipped and the values are automatically formatted in the Ignition DB Query Browser. For example, I just replicated your issue (using simulated tags) and looking at raw the CSV, I get values like:

> 1738063481806,-49.25258255004883

But when I look in the DB Query Browser, they are nicely rounded.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/a/2a737513e2569f8d02de3bee660a2816c2d1837d.png)

I did just have a look and tried some different properties on the chart to try and find a quick easy solution (Ignition based solution) but unfortunately I couldn't find one.

Until someone from IA replies the only things I can think of would be to format / transform the tag values before they are stored in history OR set the column format in Excel (as they are just really long floats) - formatting in Excel has been mentioned as a solution before:

> [@Exporting Large Numbers](https://forum.inductiveautomation.com/t/exporting-large-numbers/67526):
>
> I have a client who uses Ignition to historize the discharge data and generate their reports for the city/county. As part of their report they require a exported CSV file of the data used to generate the report. Well they have just turned over 10M gallons on their totalizer and now when opening the CSV file Excel had decided to round the number to 1.00E+07 dropping any fractional numbers and whole numbers that became fractional in the rounding to E+7. The data displaying in the Vision Table loo…

---

<div class="post-metadata">

**Author:** ![jiguti](https://avatars.discourse-cdn.com/v4/letter/j/e495f1/32.png) [@jiguti](https://forum.inductiveautomation.com/u/jiguti)\
**Post date:** [January 28, 2025, 12:53pm UTC](https://forum.inductiveautomation.com/t/power-chart-problems-exporting-data-to-csv-file/101482/3 "2025-01-28T12:53:28Z")

</div>

It can be solved in excel, but there are some problems. For example the number of decimals are not always the same:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/a/2ac875cfc3a4f2d69d48f6f2bd53ce489cd3b072.png)

In the image you can see sometime is 14, sometimes 15.. and when you transform the columns in excel are all at the same time.

And in excel the decimal is 1 more (I dont know why).. 15.. 16..

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/3/73fda6fb6bd2eedbf506e027334faf2d8439058f.png)

where can we format / transform the tag values before they are stored in history?? What part in Ingnition I mean.

I think it will be the best solution because you can get the data directly and no changes after that will be needed.

Thanks so much

---

<div class="post-metadata">

**Author:** ![MG3](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mg3/32/84125_2.png) [@MG3](https://forum.inductiveautomation.com/u/MG3)\
**Post date:** [January 28, 2025, 1:34pm UTC](https://forum.inductiveautomation.com/t/power-chart-problems-exporting-data-to-csv-file/101482/4 "2025-01-28T13:34:47Z")

</div>

I have just had a look into this (couldn't remember if there is a way to it directly on a tag) so I attempted to create an **OPC** / **Derived** tag that uses the `round(value, dp)` to format the numbers. However, in history it was all stored the same (when I did an export).

May need to see if anyone else has run into this issue as I am almost out of ideas.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [January 28, 2025, 1:38pm UTC](https://forum.inductiveautomation.com/t/power-chart-problems-exporting-data-to-csv-file/101482/5 "2025-01-28T13:38:04Z")

</div>

It is floating point. The underlying data is always mantissa and exponent. Rounding is a **display** operation, and Excel follows its **own** display rules.

Also note that 32-bit floating point simply **cannot** retain two decimal places for such large numbers. Even a 64-bit float can only hold ~16 significant digits.

What is the real problem here?

(I suspect a locale problem mis-interpreting the decimal point.)
