Start a new topic
Not Taken

Gauge set starting point =- "val" angle

I first thought that setting the "val" angle for the gauge in the gui would set the starting point ("0") but apparently not. That would be a logical feature to add.


To set the correct starting point, i worked out something with value mapping but just starting arduino few weeks ago so i am sure someone can workout a simpler way to do that.. Anyway, hope this helps someone.


Example with temperature reading (0 to 120c) starting point at 310deg angle : 


    int zpsum = (temps[0]);

    zpsum = map(zpsum, 0, 120, 0, 270);

    if (zpsum >= 0 && zpsum < 50){

      int zpsum1 = zpsum;

      zpsum1 = map(zpsum1, 0, 50, 310 , 360);

      zpsu.setValue(zpsum1);

    }else{

      int zpsum2 = zpsum;

      zpsum2 = map(zpsum2, 50 , 270, 0, 220);

      zpsu.setValue(zpsum2);

      } 


Thanks for posting your method to deal with gauges that need to dip below the horizontal horizon.  If people read the board first as they should, it should help them. 


With regards to the starting point, adding more attributes to the firmware steals space away from your HMI designs -- Just so you know.  The gui does infact set the gauge .val attribute at "0" when added to the page.  In this case, 0 points 9:00, west, or 270 degrees.  Val is the angle in degrees from start, the question then becomes on what scale and that is different for every user.  On a single dashboard, it is easy to have 6 gauges each with a varying scale.  38 litres of fuel in 90 degrees, 260 degrees temp in 90 degrees, 8000 rpms in 200 degrees, 300 kmph in 270 degrees, oil pressure ... etc.


A point on a scale is the degrees of arch / range.  8000 rpms in 200 degrees is 40 rpms per degree.  Rpms / 40 is degrees needed to adjust in your gauge.  You gauge offset ...?  Depends on how you designed your dashboard so +/- your offset.  There is an IF clause needed only in cases where the design has the start point below the gauge start at "0".  You will find in integer based math (the Nextion does not have floating point - (so 60000/2001 is equal to 2), that it is best to perform your ratio multiplications before your divisions.


Your approach with creating a function for you gauge "on your MCU" is a good approach. It doesn't clog up the firmware, and that allows you to do more in your HMI designs.


I am now reviewing all of the Feature Requests, this will take some time, patience please.

carried forward

Login or Signup to post a comment