Freetronics Forum

Posted: **Wed May 22, 2013 12:32 am**

I have a V2.0 lcd shield sitting on an Eleven, V1.0.

There is one line of lcd.print() code that refuses to display a limited number of decimal places.

example;
float Irms = emon1.Irms;
lcd.print(Irms,1);

This should constrain the number of places to one - I get three to four - random!

All other lcd.print() statements for other variables, eg lcd.print(X,1) lcd.print(Y,2) etc play the game and the lcd displays one or two places.

There is nothing anywhere that I can see that would cause one line to be corrupted.

Has anyone seen this random behaviour in their code?

Posted: **Wed May 22, 2013 11:34 pm**

Only Irms and PF have an issue - the other variables accept the decimal place confinement code.

I agree, there seems nothing wrong with the code - but the problem is there somewhere and why only two of the variables?? Its random!

Don't get a headache from the code...

The code is on http://www.openenergymonitor.org

Posted: **Wed May 22, 2013 11:47 pm**

Code: Select all

// EmonLibrary examples openenergymonitor.org, Licence GNU GPL V3

#include "EmonLib.h"             // Include Emon Library

#include <LiquidCrystal.h>

EnergyMonitor emon1;  // Create an instance


LiquidCrystal lcd(8,9,4,5,6,7);


void setup()
{  
  lcd.begin(16,2);
  //Serial.begin(9600);
  
  emon1.voltage(5, 232, 1.5);  // Voltage: input pin, calibration, phase_shift
  emon1.current(1, 570);       // Current: input pin, calibration.

lcd.clear();
}

void loop()
{
    
emon1.calcVI(20,1000);         // Calculate all. No.of wavelengths, time-out
  
  }
  
  lcd.setCursor(0,0);
  
  lcd.print("V=");
  lcd.print(Vrms,1);
  lcd.print(" I=");
  
  }
 
  lcd.print(Irms,1);
  lcd.print("   ");
 
   
  delay(500); 
}

Posted: **Thu May 23, 2013 1:22 am**

platypus wrote: I agree, there seems nothing wrong with the code - but the problem is there somewhere and why only two of the variables?? Its random!

Hi platypus,

Just some random thoughts, in addition to John's suggestion:

- Are the "incorrect" values sensible ones (ie is it the correct number, just with too many digits)?
- What happens if you tell it to print(Vrms, 3) for the same value?
- Do you always get 3-4 decimal places for those variables, or only sometimes/for certain values? Do the extra digits change?
- If you do a Serial.print(Vrms, 1) then does that come out the same (it should use the exact same formatting code for the number, so that narrows it down to either the number formatting code or the LCD display.)

The other thought I had is that the print() for floating point actually takes a 'double' (ie a double-precision floating point number, twice as big as a 'float' with twice the precision), and looking at the EnergyMonitor library it also stores those values as 'doubles' internally. So saving them to a 'float' actually makes the conversion double->float->double, throwing away precision and then adding it back again.

Probably not important when you only care about 1 decimal place, but what happens if you change the local variables from 'float' to 'double' as well?

- Angus

Posted: **Thu May 23, 2013 5:14 am**

I pulled out my ethermega and ran the data again - same type of lcd.

By the way have a look at this http://arduino.cc/en/Reference/Float
In Arduino, float is the same precision as double - it doesn't matter how they are used - still 4 bytes.

Serial output
V,I,KW,KVA,PF all set as serial.print(X) in the source file code - see back a couple of posts for the cpp - right down the end. The sketch calls data to the serial window using emon1.calcVI()

Default for float or double is 2 dec places

Get 2 dec places for all.

LCD output
Dec places set as (X,1) for V,I,KW,KVA and (X,2) for PF

LCD displays
V, KW,KVA each set as 1 dec place (X,1) - each displays 1 dec place
I displays up to 4 places, PF displays 3 places.

Set (X,2) for V,I and PF (KW,KVA commented out to make room for test)
Had to place V on line(0,0) and I and PF on line(0,1) and removed padding spaces to test display.

LCD with no set places
Get V, 2 places, I, 2 places and PF 3 places - not too bad.

I have a 20,4 lcd which I will setup and try - not sure that it will change things.

The data is not affected, its just an annoyance that output display is not held by all variables.

So the same behaviour on the 328 and the 2560 - so its not the controllers, but the program code.

But the cause seems elusive.

I have seen this behaviour in the past and it was caused then by copy/paste of code.
It was rectified by typing the code in - not this time.

Still,I can live with it - nothing is as perfect as it might appear.

Posted: **Thu May 23, 2013 6:45 am**

platypus wrote: By the way have a look at this http://arduino.cc/en/Reference/Float
In Arduino, float is the same precision as double - it doesn't matter how they are used - still 4 bytes.

How silly of me, thanks for correcting.

Looking at your code and your results again, I don't see any common patterns either. If you remove the EnergyMonitor from the equation entirely and just print known values, are you able to find a combination that reproduces it? (if you can find one then we can run it here, as well.)

At the same time, if you say you can live with it then that might be the least frustrating option in the long run.

Posted: **Thu May 23, 2013 7:22 am**

Yes,sometimes its not worth chasing things when its very likely tied up somewhere in the IDE source code.

No issues with precision - I have just been head down into it. But appreciate all the efforts put in by you with this rather frustrating issue.

Well its a proto only so I am not concerned.

Just running the ethermega and a 20x4 lcd - bigger screen same @!%#

We will likely move on from this type of proto system very soon into something more elaborate.

But I give these atmegas credit - they are not bad for their speed and memory size.

Thanks for your help.

Freetronics Forum

Limiting number of decimal places

Limiting number of decimal places

Re: Limiting number of decimal places

Re: Limiting number of decimal places

Re: Limiting number of decimal places

Re: Limiting number of decimal places

Re: Limiting number of decimal places

Re: Limiting number of decimal places