Loss of very small order values during excel exportation

[mattecst]

Hello,

I'm occurring this problem while exporting data in Excel through the "Write to Measurement File" function.

I'm measuring a small capacitance, picoFarad order, and it's correctly reported on my front panel output display (example: 4,457E-12) but when I export the data with the "Write to Measurement File" function as an Excel file all the picofarad-order-values are approximated to zero.

This problem doesn't happen if I chose to export the file as a text (LVM format) and the values are correctly reported as the example.

Is there any way out or I am condemned to export the data as a text file?

I also thought that I can multiply that data by a power of 10 in order to have a bigger order but I don't like that way.

[OEM_Dev]

Are your numbers too long?

https://support.microsoft.com/en-us/kb/269370

[aputman]

It's likely an Excel rounding issue.  Change the formatting of the numbers to display more decimals.

[mattecst]

---

@OEM_Dev wrote:

Are your numbers too long?

https://support.microsoft.com/en-us/kb/269370

---

They might be actually but the page you linked says digits past the 15th place are set to zero.. It should show the numbers before the 15th place 

[mattecst]

---

@aputman wrote:

It's likely an Excel rounding issue.  Change the formatting of the numbers to display more decimals.

---

I tried to change the number of decimals but the result is a long series of zeros. 

I believe that the axpproximation is during the exportation and not in excel. 

[RavensFan]

I see from your screen shot that you are using a decimal comma rather than a decimal point.  I'm wondering if that is contributing to your problems, at least for the scientific notation numbers.  (Since the other numbers seemed to have made it through okay.)

[mattecst]

---

@RavensFan wrote:

I see from your screen shot that you are using a decimal comma rather than a decimal point.  I'm wondering if that is contributing to your problems, at least for the scientific notation numbers.  (Since the other numbers seemed to have made it through okay.)

---

I don't think it really matters I believe it's just because the computer is set to the Italian settings and we use the comma instead of the mark 

[RavensFan]

It may not because the other numbers came through okay.

But it also might.

Many time issues with converting numbers are causing by using the wrong symbol for the decimal point.  Some LabVIEW functions default to a decimal point.  Some default to whatever the system setting is.  A mismatch between what symbol is used in the file, and what the LabVIEW function is expecting can cause problems.

I'm just throwing the possibility out there for something to look into.

[mattecst]

Sure, I appreciate every second you're giving to my cause I didn't mean to sound grumpy.

Anyway I was trying with a bigger capacitor and that's the result: 

But if I try to increase the number of decimals

Seems like it doesn't go any further than the 6th place after the decimal mark 

[RavensFan]

Dig into the Write to Measurement File some more.

I know that some of the other LabVIEW write to file functions default to 6 decimal places and cuts off after that.  It may be happening within that function as well.  (Are you using the blue Express VI?)

Can you attach your VI?