Start a new topic

crop component loses state due to auto refresh?

Hello,


I'm also new to using Nextion, and i am building a project with multiple pages which i switch between. Each page has 2 main pics, one showing all ON and other showing all OFF states of graphic LEDs or other components in general. I use either the picq command to switch between the "active" and "inactive" component bitmaps, OR i have just started using the crop component's picc attribute to set the background picture/graphics to show the intended "active" or "inactive" component. (the documentation really sucks)


So far this strategy has worked very well.


But i have been struggling for a few days trying to make a few "LEDs" on a status page show either ON or OFF state, by using crop components and changing the picc value.


The status page is jumped to by clicking a button on one of the other pages. Before i jump to the status page, i set a global variable for the state of each LED on the status page and when i jump to the status page, i use a series of if()..else statements in the post-initialization event looking at these states and then setting that LED's crop component picc value to show the proper picture (On or OFF).


This is one of the if..else statements:


...

if(Welcome.LatchPemf.val==1)

{

  LPemf.picc=14

}else

{

  LPemf.picc=15

}

...

All other statements for the crop components are identical. The code compiles successfully. 


What i have noticed is that when i click to go to the status page, all the crop images displayed are the default ones (ie: "OFF" state), except for a couple of the variables which seem to work. The coding is identical but the behaviour is totally inconsistent. 


What i noticed is that if i put a delay=1000 statement after setting the crop component's picc value, i see the correct value for about a second, then it is reset to default value.


Can anyone explain what's happening and why it is refreshing / resetting the crop component picc value?


i have tried searching for a couple of days now, and tried different programming tricks to get around this, but i'm at a dead end.


Any help or tips would be appreciated.


Thank you.



One possible way to get deeper understanding is via Enhanced Support

https://www.itead.cc/enhanced-support-tickets.html

Register and Login to the new Forum if this is giving you a 404


Basic Understandings for Designing a Nextion HMI

https://nextion.itead.cc/forums/topic/basic-understandings-for-designing-a-nextion-hmi/


Basics in Debugging

https://nextion.itead.cc/forums/topic/debugging-basics-in-debugging/


Thanks for the links. A bit about my background: I am an EE with about 35 years of professional experience designing embedded systems, so i am not new at this and i understand the debug process very well. Thanks for the information, though.


I have been using print and printh statements in the offending page's code. What i find is that my code works exactly as it is supposed to (as far as i can tell), but when it is finished the postinitialization process, the crop components in question are refreshed or returned to their default state.I am using global variables for storing the "LED" bitmap state. These global variables do not get inadvertently modified during running of the postinitialization process. 


As i stated earlier, all of my statements in the postintialization process are sequential, one if/else statement following another and each group of code deciding between displaying one of 2 bitmaps to be displayed by the crop component. Using print statements inside of each if/else statement shows that the code is executed exactly as written (unless the compiler or nextion internal code is doing something not published). If i insert a significant delay inside each if/else statement, i can see each crop component display the correct bitmap in sequence, but as soon as the postinitialization routine reaches the end, the crop components revert to their default states. In other words, they do not keep the states assigned to them and there is an unknown process that reinitializes or refreshes these components. 


I have not been able to find anything yet in the links that help with this problem and i still can't see how to solve it. I've tried using things like ref_stop and ref_star commands, as well as other commands, to see what effect they might have but so far i have not found anything that works. Also, as mentioned, one of the crop components on that page seems to work (one in the list of if/else statements, even when moved to a different position in the code sequence), as well as when ALL the crop component picc values are changed from their default state, and this behaviour is consistent in its operation success while the others are consistent in their operation failure. So this compounds the problem. Why does one particular component (same one every time) as well as all these components when used together, seem to follow the coding while other combinations do not and get refreshed or reset?


Is there any information from those here that have either designed this display or those that have been using it for a while and have extensive experience with it, that can give me an answer as to why the screen is refreshing like this on this particular page after running the postinitialization process? Is there some hidden process going on that is not documented? Is there a work-around for this?


Sorry for the long posting. Thanks again to anyone for any help.





the old rule, "one picture shows more than 1000 words" ...

why don't you just upload your HMI ... maybe there is somebody who like to digg into yours ...

from your words, I even don't catch your real issue ...

 


1 person likes this

Hi Norberto.


   Hey, 35 years experience.  Why didn't you lead with that.

   Nextion doesn't do credential checking and then make special allowances.


There are few points you caught correctly.

There are still somethings you are tripping over.


Nextion is rendering indeed exactly as told - result is what you asked for

Nextion does not have hidden process


Nextion Instruction Set for v0.48 is the new site

https://nextion.itead.cc/resources/documents/instruction-set/


Perhaps I can rename the link from "Basic Understandings" to "Oh don't forget".

 - but what you are missing was covered in this document.


When you discover your error, you'll understand how basic it was.

You are over complicating things with path of ref_stop and ref_star

 - except for the Waveform, such is not useful 


Debugging is available and offered - albeit with a fee, but speedy response

Reminders provided in links for free


A call for answers from "extensive experience with" you already have

HMI shows use of multiple Globals for a single state

LatchOne is used, Led1 is used, light1 is used


You have lost logic to keep all synchronized by over complicating it


One global holds actual state

Much less complicated than what you have

Perhaps in this manner

tft
(1.81 MB)

sorry, but you became a victim of your own "strategy" ... :-)


I reworked yours a bit ... anyway there are many things to rethink when playing with HMI's ...


    - your usage of globals  ... a reason for unexpected ...

    - your logic workflow  ... a reason for unexpected ...

    - your understanding of NE objects and how they work ... a reason for unexpected ...

    - ...


anyway, working with such limited devices is a bit different than coding on the PC with nearly unlimited ressources ...

don't think too much as engineer, think as a geek ... and have fun ...


rar
(115 KB)

Thank you very much for the reworked example: i see that you used the dual-state button, which i didn't realize could also be used as crop image function. So i have definitely learned something useful about your display.


However, can you explain why my original code, which uses if/else statements, doesn't work? Am i using illegal code? I can compile, no problem, syntax is OK. I originally took the nextion programming language statements as though they were in C language and would operate in the same way.  If i  ran my code in a c compiler such as gcc (with appropriate syntax corrections), it would work. "Why doesn't your display also do so?" was the big question in my mind.  I did not see any reference to not being able to use multiple sequential if/else statements in a row or any potential problems associated with them. ie: my code *should* work - so why does it not?


In answer to my own question, during debugging, i discovered that my code does, in fact, work, but after successfully executing the code, *something* in your system decides to refresh or reinitialize the state of the crop components to default value. I have no control over said "something". Which is why i came to you in the first place.


Although i understand your preferred paradigm for programming, it is not easily readable for maintenance or to understand what's going on. I program the way i do because of at least 3 decades of product development and experience with many different programming languages. I am essentially "documenting" my code by writing it in an explicit, easy to read way. Everybody has their preferred way of doing things, and i prefer to do it my way as for me it is more logical. Which worries me when using your display, since i didn't really violate any of your programming rules yet the outcome changed without warning. Which is why i am still confused why my code didn't work as it should have.


And, yes, i do realize that small embedded systems do not haver unlimited memory to lay with, but less than 10 bytes or words of space should not be critical in your system (is it...?), unless we're talking about code space like processors in the 80's, which i used to code using assembler - so i am aware of code and data space limitations, thank you.


That's why i came to the conclusion that there must be some hidden process or something going on that would not execute my code properly. As i mentioned previously, my code DOES work, but then something comes along after it is done and refreshes or reinitializes the state of the crop images. It was only after your responses that i finally understood what that "something" was:  your programming language is not C and i have no idea how you have designed your equivalent of an OS or architected your display system. Your system behaves in (for me) unpredictable ways when i try to work it in certain ways, even though logically it should work, whether you love or hate my preferred coding style. I made the fatal error of assuming that your system would execute my code like C code on a uC and not do something undocumented as soon as it was finished. Sorry for my assumption.


There should be nothing wrong with my usage of globals, or my logic workflow - it is my preferred method. My usage of globals is correct, as is my logic flow and my usage of coding language statements that are specified in the nextion coding language list, although you may not appreciate them - it is a matter of opinion. I find, in contrast, your method, although compact, to be, as i said, unmaintainable and not easy to debug and follow...in other words, it is your logic workflow that for me can cause unexpected issues. You say "toMAHtoh", i say "toMAYtoh"...


But again, i want to thank you for sending me the example of how you would do this. It has given me new insights into the use of the dual-state button, and i will incorporate it into my design and also into the limitations of your display. By the way, my project interfaces to multiple subsystems and it is quite complex. I had to create the Test.HMI project because many of the things i'm doing are proprietary and i could not send it out to you. Thus, i do need to use multiple globals to handle all the different subsystems and associated states. 


Cheers



no, your code doesn't work, and it won't work in ANY programming language ...

honestly, I didn't see such a programmers error as yours for a long time, especially not from a ">30 years experienced" one ... :-)

  • ALL=0
  • LED=1

  • if LED=1
  •    z=1
  • endif
  • 'status of z?
  • if ALL=0
  •     z=0
  • endif
  • 'status of z?

what's the staus of 'z' at the end of this psudocode... 1 or 0 ...

and I bet, the result is exactly the same is ANY programming language, even in BASIC ...

easy to read and manageable code is great per se, but it seems you neither can read nor manage your own few lines ...

and for such you really ask for help with >30 years experience ...

Nextion Secret Code Handling: (finally revealed to the public)

 - allow for users flawed logic to still compile when syntax still correct

 - allow for code to be executed as written.


No Compiler compiles semantically - it must be purposefully programmed.

It will not guess as to what you may have meant - it will only do as you told.

As such, you code as written would not yield desired result in any language/compiler.


In the Nextion Compile process syntax would be checked

 - check for the correct number of parameters

 - are specific parameter of the correct type (text/integer)

In the Nextion Debug process

 - you can see your process run (simulated and not an emulator)

 - here you can pick up on errors such as no picture resource #17

Okay, maybe let this one slide as you claim a subset


But as far as tripping over your logic in only a few lines of code and then blame such rendered results as some hidden conspiracy code in Nextion that must be tossing random code into commercial projects?


Ditch your three 3 decades or how you use to do it in the good ole days

 - such logic flow didn't work then on an Atari, C64, 8051

 - such logic flow won't work moving forward with any current microcontroller on the market.

It's not a matter of personal preference ... "toMAHtoh", "toMAYtoh"...

  - bad logic will never work - except to yield exactly as requested.


There are always many ways to accomplish

 - as written in the tutorial for you

 - Gerry used dual-states

 - my TFT had you downloaded and run would had seen such working correctly used your crops.


Nextion is not C programming language, it is a series of instructions

 - there was no reference to not being able to do successive if clauses

 - there is a Nextion Instruction Set showcasing how to do so (if statement

   so to even look to this as a reason .. again flawed logic.


Nothing in the Nextion system refreshes anything except the Order of Events

   this was outlined in the link Basic Understandings for Designing Nextion HMIs

   in the section "Nextion Order of Events"

   - But when users own logic refreshes and overrides previous logic

This is not a compiler of error of Nextion Editor or Nextion Firmware


What is wrong with your use of Globals again is not a syntax issue

 - but I certainly imagine one of the root causes leading to tripping over logic.


Why set a Status and never change the actual state of the pin?

 - this leads to an led on the HMI device showing active - but never will be.

 

if(Welcome.LatchAll.val==0)
{
  Welcome.LatchAll.val=1
  All.picc=2
  groupA.picc=2
  light1.picc=2
  light2.picc=2
  light5.picc=2
  groupB.picc=2
  light3.picc=2
  light4.picc=2
}else if(Welcome.LatchAll.val==1)
{
  Welcome.LatchAll.val=0
  All.picc=1
  groupA.picc=1
  light1.picc=1
  light2.picc=1
  light5.picc=1
  groupB.picc=1
  light3.picc=1
  light4.picc=1
}

None of your logic is directed at this multiple global location to set LatchOne...

Maybe good for visual, with again no action, but again All will not light 1-5 on Status


But hey 35 years experience - this is beginner errors in just a few lines of code

And your answer to this is "must be something inside Nextion"


You were quite resistant to review the Basics - but Basics is where this is at.

As stated earlier - Basic Debugging  techniques would have allowed you to stream

your values for a visual check. 


Such "3 decade" doesn't allow your side as the possible cause.


But now you know - so you should be on track





light1.picc=2

 

A Crop Component is cropping by its nature

 - where placed pulls through the background of .picc resource number

 - there is no need to re-render this with GUI picq on press and released

 - simply change the .picc attribute to desired picture resource

(Resource should be full size as stated in the Nextion Instruction Set)

 

picq 125,44,72,72,17

 

When resource 17 is not present, nothing will be rendered

 - In Debug, this error is caught with 0x04 0xFF 0xFF 0xFF

 - Nextion Instruction Set describes

 - Debug shows parse error in red Parse: Invalid Pic ID