Start a new topic
Solved

Page does not hold values of it's components

 I have written MCU code in a way so that each page components get changed only when this page is active (displayed). So if switched firsts time to a page I see first default values recorded in the component and then those get changed by MCU code. But after switching to other pages and returning to the same page again - all values are again DEFAULT and then again get updated from MCU as if this page displayed the first time.

Why doesn't Nextion keep received values of the component when page gets switched? Why switching pages should drop values of the inactive page?

Please let me know

Vlad


I'd think that's because the whole page including all its components and variables get pushed out of scope.

Similar to automatic/local variables in C code too.

If you want them to stick around you'll have to declare them global, just as you would in C.


1 person likes this
This is quite possible indeed... yet Would be nice to hear response from Itead team. Using components as local has to do with their assignment according to man pages. Components can still be local and static like in C functions.

 

Vlad, waiting for Itead's staff response is going to take much time indeed.


Behaviour of pages in order of execution is

  • PreInitialize Event
  • Page Loaded with default values of HMI design
  • Postinitialize Event
  • loop while waiting for other events (touch, serial command, timer, etc)

Declaring variable as .vscope global is definitely needed. (I usually do this on first page).
1) In event that changes pages, store value to this global variable before page command.
2) In page PostInitialization event of loaded page, retrieve value from global.

You could also chose to do this over serial as well
  • put notification for MCU in PressEvent (capture notification, issue store routine to MCU)
  • put page command in Release Event
  • put notification for MCU in PostInitialize Event (capture notification, issue restore routine)

Scruff.r is right about scope.  The STM32 chip devotes 3584 bytes of SRAM to pages (compile process attempts to catch any violations while TFT is being generated).  page change dumps current to begin loading requested page, so .vscope global is required.  Neither the STM32 flash, the Winbond Flash nor the microSD is user writable (with exception of upload routine).  So this leaves the 3854 byte restraint.


In the link, I uploaded an HMI (you could download it to look) that demonstrated this global
Perhaps this may be of some use to you

Makes sense Patrick,  if memory is that limited, they don't want to make variables static... But then making all my variables "global" will not help either - I may reach 100 variables (counting only those which need "ref" command such as picc updates) which I want to be ready when screen gets focus... same problem with memory limitation...
Seems I have only one solution - speed up dynamic page update and keep all variables local...
thank you....
Vlad

 

If you are willing,


Perhaps I could look at your design and propose possible solutions.


Since v37, there is a new click command.  It allows you to issue the serial command

click m1,1 to trigger hotspot named m1, (runs code in) Touch Press Event

click m1,0 to trigger hotspot named m1, (runs code in) Touch Release Event


a hotspot minimum size is 5x5 pixels, and is not an obvious visual component.

placed out of the way from where users would instinctive "click here",

the click command would provide up to 2 function (Pressed/Released).


Perhaps grouping commands you need for refresh inside this capability may free up how many global variables you would actually need.  I also am failing to see where a picc update needs to needs to be global.  But I am not really certain what your end goal is.


If you do not want to put anything up public on the board, the email address zieditor@homehub.info will always get to me.

Thank you for offer but I have to skip it -  HMI file will not tell the whole story, MCU code is complex ... for a developer like myself (30+ years of embedded computer systems development) it would still take weeks to understand...

 This is a in-flight controller for a piloted experimental aircraft........

=)  Thank you Vlad. 

Though I am a good programmer, I think you just saved me from a headache and many asprins.


So note on the bottom status bar, you will see the RAM:3584B restraint they are limiting for a page.

When you compile your multipage HMI, you will notice how each page has used.

Without globals being considered, everything clears during page changes and starts fresh.

You need functions Nextion side to deal with this PreInitialize, PostInitialize, click command etc.

The STM32F030 chip in the Basic Model is limited to 8K, firmware shares this with pages.


Perhaps if constraints get too tight, it is noteworthy that the Enhanced Models 3.5" and higher now allow for 8192B as well as more flash and MHz.  The benefit maybe it is the same editor and same HMI design on the Enhanced so your HMI work would transfer later if needed.  The Enhanced uses a different firmware in that it includes the functions for the added RTC and GPIO that the Basic doesn't, but otherwise remains consistent.





Vlad, an after thought.


You are aware that in the Nextion Editor - every attribute that has a bold green attribute is auto-updating.

In a crop component .picc is auto updating so setting it will auto-update without needing ref command.


Likewise, if you are setting an attribute that is not auto-updating, assigning the attribute that is auto-updating will bring the entire component with all attributes up-to-date.


Example for a Text Component using page0.va0.val (where .vscope is global)

  • t2.pco=page0.va0.val // set font color to 2016 green - this doesn't autoupdate
But if I follow that with an autoupdating attribute like .txt which is autoupdating
  • t2.pco=page0.va0.val  // doesn't autoupdate - color not seen on screen yet
  • t2.txt=t2.txt    // updates t2 with same text it had - and updates color as well - now green

Put these into a hotspots m1 Pressed could allow you make use of the click command fewer globals.
  • page0.va0.val=2016  // set needed values
  • click m1,1                  // call your function trigger to run commands in Pressed Event





1 person likes this
I am well aware of auto-updating attributes versus non- and make use of them, so I thought... but...I missed this important point - to update auto-updating "val" AFTER non-auto-updating ".picc"  .
I upvoted your post for that:)
Thanks

 

Here is the list of Components and attribute that should be updated last

(  ... But where is .picc attribute used besides Crop Component?)

( in both v37 and upcoming v38, crop .picc is auto-updating)


Page Component (page0)

if .sta solid color - set .bco

if .sta image - set .pic

if .sta no background - use ref 0

Text Component (t0)

all cases: set .txt

Scrolling Text Component (g0)

all cases: set .txt or .en

Number Component (n0)

all cases: set .val

Button Component (b0)

all cases: set .txt

Progress Bar (j0)

all cases: set .val

Picture Component (p0)

all cases: set .pic

Crop Component (q0)

all cases: set .picc

Hotspot (m0) is Non Visual

no autoupdate attribute

Gauge Component (g0)

all cases: set .val

Waveform Component (s0)

no autoupdate value - must use add or addt to update values

Slider Component (h0)

all cases: set .val

Timer Component (tm0) is Non Visual

all cases: set .en or .tim

Variable Component (va0) is Non Visual

no autoupdate attribute - setting .val or .txt va0 now holds new value

DualState Button Component (bt0)

all cases: set .val

                or .txt (new in version 37)

CheckBox Component (c0) (new in version 38)

all cases: set .val

Radio Component (r0) (new in version 38)

all cases: set .val


Nevermind the where is .picc used ...

I do so many of my designs without crop images in other components

I found too many.



Non auto-updating I use most:
Text comp txt.picc,
gauge,picc,
slider.bco and .pco (solid color)
slider.picc (crop)
changing those only when alarm state triggers... should just move assignment to before the "val" update...

 

Vlad, I am assuming we have solved this issue.  I will mark it has solved.

Your assumption would be a lie because it is as I reported

 

Login or Signup to post a comment