Start a new topic

globals and why/how to use 'em

I've enough experience with my Nextion LCD now that I understand pretty well how it works, and how to minimise visual glitching/updates when changing between pages.  By this I mean that there are ways to minimise the need to "re-send" all the data for your gauges, etc., when you return to a page.


Say, for example, you have a page showing values for sensors, and from that page you might go to a different page via a button press.  When that different page is done, and you return to the original page, then all of your dials, numbers, etc., reset back to a default state and you have to do an update of all the values.


Well, you don't.


It's all to do with how the Nextion processes pages, and how global variables work.


Global variables are simply variables that KEEP their values no matter what page is displayed.  So if you have (say) a slider on a page and make it global, then when you return to that page the slider will have the same position/value as it had last time


So, global variables are

a) persistent - they never die

b) only initialised once, the first time they "appear"


With (b) what I'm saying here is that unlike programming languages that you may be familiar with, the Nextion has an odd way of handling globals.  And that is, globals do NOT EXIST until you load the page on which they are defined.  This is really important to remember, as it influences how to use them.


Whether you're using a variable, or a control (slider, button, etc) as a global, the object only becomes "alive" when you load the page in which it is defined.  When a global FIRST becomes "alive" then, and only then, the Nextion initialises it with the value that you set in the editor.  It's a ONE-TIME initialisation only.  From then on, whenever you switch to that page - the variable is already in existence and is NOT initialised again.


This is a good thing. A great thing!  Because it means that if you use globals on a page for your controls, and you go to another temporary or sub-page and then come back, all your globals will have the same values you had when you left the page in the first place.  So you don't need to re-send all the values.  Your page will look "complete" and "filled out" the very first tim you see it. 


If instead, you used local variables, then they get re-initialised every time the page loads.  So for example, a slider will initialise with 0, or whatever you set the val to - and then your code has to re-send the correct slider value.


Globals, you can see, can save you a LOT of code and communications.


There's one other use for globals - and that's to set initialisation values for controls on pages that have not loaded yet.  Consider for example where you have a title for a page.  You might read that title from a SD card, and need to set the value even though the page isn't loaded.  The solution is to have a global that's on the current page and put the title string in that variable.  Then, in the preinitialize event on the page requiring the title, you can copy the string value from the global (previously intialised) to the page's title.  The nextion does this preinitialise before doing the display of any objects, so you don't get a flash of blank followed by a delay while your program communicates and "fills in" the stuff on the page.


So, globals are your friend - of course you have to consider memory usage but to be honest I haven't come close to maxing out memory and my use is pretty complex.  


In summary, consider the benefits of having persistent values between views of a page, and the consequent easing of the burden of re-writing values for controls, digit displays, etc.  Things look so much more professional when you don't see the updates, right?


globals, their usage and the way how they work compare to locals have neither never been a secret nor ever been hidden ...

the system of globals versus locals is also nothing Nextion unique, every modern programming language which offers functions and subroutines do use them ...

 

globals are no universal weapon, but used at the right place in the right way can save a lot of time ...


sys0, sys1 and sys2 are global per se, without any declaration, without any additional ram usage ...

The Nextion appears unique in that globals only become "instantiated" when the page containing them is actually loaded. From that point on they are persistent as with other languages. It's useful to know/understand because you simply can't use them if they're not "there" yet.  Unless I'm mistaken how this works on the Nextion.


with one sentence ...

you are wrong ... and it seems you never tried it out ...

 

HMI
(6.91 KB)

That's very interesting - I am happy to be wrong but I did extensive tests. I will do some more.


you don't need to visit a given page to make globals of this page accessible ...


the fact that you must access globals with a page-prefix is documented many times ...

Could it be that the global is initialised for the first time when the page containing it loads, but if you write a value to it BEFORE the page loads, then the value you write is over-written when the global is initialised for the first/only time, and thus appears not to work?  I did many tests trying to use globals on "other" pages which were not loaded, and the tests never seemed to work.




I'm aware of, and use, the page specifier.


Mmh. Wrong again - I just tested and its OK

Something in my original tests is failing, so sorry for the errors I will find and report what I was doing wrong :(


Nextions exactly do as your code was designed for ...


if the result is not your expected, obviousely your design was wrong ...


Globals work very well, without any of your described limitations ...


:-)

HMI
(6.93 KB)

Right. I have found and fixed my mistake. When things don't work as expected, one tries to understand if there's a bug in the program I wrote, or if the system which I'm learning is not behaving as I expect. Despite now looking foolish with my explanation, nonetheless I have learned something and without writing my post I would not have known. So that's a good thing. OK for you to delete the post if you wish.


The error - either I did not put the page prefix - most likely, or possibly I did not have the global flag set on the variable - less likely.  I use page prefixes all over the place, so it's not as if I'm not aware of this. In any case now I have both set correctly and removed the "intermediate" variables it is working.  Clearly, as you say, user error.






no need to delete, in any case a good learning and exercise for others ...


that's the nature of FreeChat ...


:-)

The concept of global vs local is called Scope, hence the .vscope attribute.

   - global is accessible from anywhere

   - local is not available from other than its context 


I want to add that the Waveform is a local only component

   and it is only accessible within the page that contains it

As of v0.47, most dynamic attributes of a global component

   are now added to what is stored in the global section.

It is not guaranteed that the static (not in green) attributes be global.

   (Historically, pre v0.38, only .txt and .val were guaranteed global)


System Variables listed in the Nextion Instruction Set, are global

   - such as: baud, bauds, dim, pio3, sys1, pwm4, spax 

   - these do not encroach on the sram available to the users HMI design

     (3584 bytes in most models, and 8192 in select enhanced models)

   - System Variables do not require page prefixes, they are pageless

      but user HMI globals will require page prefixing unless with their local scope.


The build process of the HMI into TFT now contains global, local and page total SRAM usage

    in the Output pane of the Nextion Editor.


It is still awe inspiring that with such larger and more complex HMI designs,

    that we have not run out of SRAM much sooner.

Such a testament to Nextion's design.

Login or Signup to post a comment