Start a new topic

Data trending

Hi all,

I'm making a project with my not enchanted 3.2 inch Nextion HMI. Its my first project so still i have a lot to learn :-)

I want to log data of 5 values in 3 trending screens on the HMI:

-Pressure transmitter 1 (Screen 1)

-Pressure transmitter 2 (Screen 1)

-Delta pressure (Screen2)

-Flow 1 (screen 3)

-Flow 2 (screen 3)

This data also needs to be saved for analyses, and must contain date and time.

The data should be available for around two months.

I could not find usefull information about how to make a trend with the Nextion HMI, en how i can store the data?

Someone has any idea how to make a trend on the Nextion HMI?

First, where to store the two months of data. 

If you have the enhanced version 3.2, then it will have an RTC and an eeprom that can house 1K (1024 bytes).  This is not much space for entries.

Second is where are these values coming from?  Typically they are received by the MCU and not by the display, so it makes much more sense to do data logging from the MCU side - how depends on what facilities are available to your MCU to perform the data logging.

Third, you have a few possible choices to show a trend,

1) perhaps the waveform component which is limited to 4 channels

    - is valid only while on that screen, data dumps between screens

    - so data needs to be backfilled when your screen loads

2) design your gui from gui commands of the instruction set

3) combine components together create your desired way to display your desired trend.

Another consideration to your design is

- how many data points are displayed in the trend?

- what useful information are you trying to pull from raw data?

- what is needed to be displayed?  just raw data points or more?

Post a picture of what you envision as "trend", it may be by another name.

Thx for your fast reply,

I will explain in more detail what my plan is:

First point:
The EEPROM is more useful for important variables like set-points. A trend will use also a lot of write cycles for this purpose, and it's very programming intensive to retrieve a part select-able by date and time of a historical trend from EEPROM. I would rather store data on a SD card or something what also can be removed by a user to analyze the data on his PC as a option, if he not want to use the historical trend on the HMI. The stored data can be raw data too of course, may be directly from the MCU.

Second point:
A 4-20ma signal is sent from a sensor to a 4-20Ma to 0-5V converter. The converted 0-5v will be converted into the MCU by a 12bits A/D convertor. 

Third point:
After conversion the data will be sent to the HMI via UART to a "number like n0" which is representing a 0-6 Bar pressure as example. Every 500ms i will update the values on the HMI screen for all of those sensors. So the trend must print a line following this value every 500ms. The printing of this line also needs to continuing while not on that page so if you enter the page you can see the trend of the last minutes.

Basically i'm meaning with trend: a line printed at real time on the HMI screen based on the value of n0.
With a historical trend i'm meaning: the value of n0 from the past two months over a select-able period of time.

The video in the link below also shows what i'm meaning with a trend:

Also this picture is a good example of a real time trend.


I hope it's clear now what I'm willing to achieve. If there is any option to do this it would be great..
So far it seems like it's not so easy to implement?? :) Any help will be appreciated.



Very easy to implement in rough form, MANY details to get it right.

It is all about the number of pixels you are in effect changing on each update.

Okay so a Nextion Editor Waveform Component provides the graph within the green grid including the grid. The waveform is a dominating cycle-hungry local-only component.  It does not persist its data when you swap pages (there is no such storage to do so),  It is limited to a byte range for values between 0 to 255 at one pixel per value.  value 200 requires a waveform of height 201 and the pixel will be drawn on the uppermost row.  You use one pixel column per data point. The longer (wider) your Waveform the more MCU cycles the Nextion requires to shift the Waveform over 1 column to prepare space for the next pixel.  Your 3.2" is 240 height and 400 width.  So you aren't going to be able to send 250 without it being ignore as off-screen.

The axis of your waveform will need to be best statically drawn from a background image that you make as a page background.  Your axis for your values .. you will need to scale, take your reading, and consider things like 500 max value but only 178 pixels ... a little math, add your data points according to this calculated skewed scale for display purposes, record as actual values.  The axis of your time line can not really be done as a scrolling text (vertical grid lines I believe are static ... so they wont be moving with).

Because the waveform is cycle-hungry - make static into your background image wherever possible and few changes.  Your sample rate is going to dictate much of what you can do between adding your samples.

Also, if switching pages, returning to the waveform will be BLANK.  You will need to send those data points across the wire again - so they have to be accessible to the MCU so it can send.

The add command sends one byte value for a specified channel

- subsequent add to the same channel scrolls the data in that channel

- an add to a different channel is from start, so on updates, add ch1, add ch2, and add ch3

The addt command sends a specified number of bytes for a specified channel

this speeds up the add command drastically - but, if you state a block of 100 values, you will be stuck in that receive until the last of the 100 bytes have been received.  This you will need to use when you need to backfill the data on the screen when you return to it from off page.

The add and addt commands are sent over serial. 

You can not do add 1,2,n0.val  it is add 1,2,173

The debug in the Editor has a Waveform Generator to assist

Sample rate is key to getting a smooth waveform - it isn't an oscilloscope =)

So this gives you a bit of info to play with, get the rough functionality started

Later we can look at where you clean up and steal back clock cycles

I did play around with the waveform last day. Actually it's not too hard to make a basic trend as long you stay on that page. So for now i want to experiment with some other functions and come back later to this thread if i have any troubles with recovering the data..
Anyway thanks for this advice. It did give me a good insight of the possibility's.


Login or Signup to post a comment