Start a new topic

NexLoop

[#22441] NexLOOP : ITEAD Studio

Hi! 

I have a problem with NexLoop. The file is attached. When i use in arduino loop NexLoop with othe functions, it does not work. When i use only the NexLoop in arduino loop  - NexLoop works. Can you explain this? A saw the example with Smart Fish Tank. There are the NexLoop and other functions in main arduino loop. And it seems to be ok. A have got the latest library for arduino downloaded. 

txt
(2.17 KB)

Hi,
I have the same problem, i have some dual state buttons on my screen, and when i compile only with nexLoop function it works, but when i add some other functions the buttons stop working. How did you solve this? I am using arduino uno. And working with timer library to work with multitasking.
Thanks for help in advance.
Here is a snipet from my code.

 

void loop() {
  
  timer.run();
 


void Timer800 ()
{
  nexLoop(nex_listen_list);
  ZapisTempBojler();
  ZapisTempKotel();
  SobniTerm();
  ObtocnaCrpalka ();
  VklopPeletiPec ();
  BojlerCrpalka ();
  Izhodi ();
  zapisTempSpBojler();
  zapisTempSpPeleti();
  nastavitevTexta();
  checkStats();
}

 

 


1 person likes this

Hello!

The same problem on my side :(


However - I noticed that it is not that the buttons (and actually anything else that is in the nexLoop) doesn't work when other functions are also present in the main arduino loop. When I observe serial monitor then I could notice when arduino is executing the other functions and when it's going to execute nexLoop. When I was able to press the button at the time when arduino was busy with that nexLoop function then the button actually worked, But this is unacceptable, because you need a lot of luck to click the button while arduino is on that function.

This is really difficult for me to understand - even if I change the the state of the button at other time than during nexLoop, the arduino should only read the state of the button while going through nexLoop - but it doesn't...

And also as similar to the posts above - when I leave only nexLoop in the arduino loop then it works all the time (but I guess, then arduino loop is all the time looping on nexLoop function so all the changes are intercepted as mentioned above) 

I'm also arduino uno user..


I'll be grateful for any suggestions!

  


1 person likes this

yes I have same problem. When I insert another command in main loop, nexloop functions dont work.

I'll be grateful for any suggestions!. I think this is a bug.

Itead must solve this problem. 



1 person likes this

It looks that there is more people experiencing the same problem! However I can also see that there are people making quite big projects with Nextion displays and i don't believe they would be successful if they would experience the same phenomenon. Could somebody advice what need's to be done? I tried different approach for coding the arduino part, but it always ends up with the same result. Is it only happening with arduino uno? is it maybe some part of configuration (of itead arduiono libraries or hmi code or..??) to avoid this issue? or is it really a bug as mentioned above? 

Please could somebody suggest solution?!?!

Really nobody else experienced and solve this problem? Please help - for me it really kills the project with the Nextion arduino library.... ITEAD studio - any comments from your side ? I'll try to put it in a bug section - maybe there we will get some reply?

The reason for this is most likely in the asynchronous nature of the communication and the way the library deals with it.

Whenever you touch/release a component the display sends the data stream to the MCU, but if the buffer is not read and processed before you call any other Nextion function (e.g. getText) this call flushes the RX buffer destroying any evidence of the previous event.


I'm working on a port of the ITEAD library for Particle devices that addresses this issue.


One possible solution is to queue commands and make sure the RX buffer is never flushed but always processed properly.

Thank you for the answer! What you say is that there is really an issue with the current library! I was thinking how other people write bigger applications with Nextion, but maybe they do not use this library...


After your post I tried to use com_stop and com_star instructions to keep all not executed commands in the buffer when main loop is not going through the nexloop function, but this also did not work well for me.. 


..still in a search for good solution...

You can work around this issue even with bigger projects once you understand the problem.


e.g. before you call any function that might mess with the buffer, test for `nexSerial.available()` and if there is something call `nexLoop()` before the other function - this won't solve the issue but reduces the impact on your project.


1 person likes this
Hello Scruff, Could you describe this more exactly?i think I have the same problem. How can I check this? Can you give an example hire this should look in an arduino code? Thanks Joachim
I experienced the same problem, i've tryed to add the nexSerial.available() trick but it did not help too much, i've partially solved using a metro timer in the screen update.
I think that this behaviour of the buffer has to be solved becouse makes the screen almost useless to see any realtime data and wait for user imput in the same moment.
we hope for some improvements for the future, is it there any official statement from ITEAD about this ? did they realized that they made a race car but they forgot one wheel ?

I change nextion baud rate 115200 and reads analog inputs every 10 second. I solved my problem.

yes, but it just a work around, there is a basic flaw in the design of the system or how the serial buffer are handled.

 

With the serial bottle neck there will only ever be workarounds.


But going for higher baudrate will be the least intrusive for the rest of your code.


Another easy (ugly) option is to call `nexLoop()` before calling any other class function that flushes the buffer and avoid any of these calls inside the component event handlers (set a flag and process in `loop()`)

Since the latter is a PITA I've detached reading of event messages from the actual event handling (first read all received events and only add a callback pointer to a call queue that will be called after the message loop is done).


Further optimization will include temporary deactivation of result reporting where irrelevant (unused return values), "scripting" (transfer multiple display commands in one unbroken stream, which should keep the even feedback from mixing with command results), replace flushing of RX buffer with an implicit call `nexLoop()`, ...


But all this means a major rework of the library. 

In my Particle port I've only got first adjustments in the library framework as prerequisites.

And the separation of message parsing and callback execution as well as rudimentary scripting are implemented, but the rest is still only thoughts.

But I have so little time to push this forward.


1 person likes this

Hello Scruff,


thanks for your answer. I will try to set up the baud rate to 115200 and call my function before the nextLoop. I hope this wil help.


"But all this means a major rework of the library"..."But I have so little time to push this forward"...I will hope that ITEAD will do this work for their costumers soon...


i am just wondering how their fishtank example is working. There is a updatetime() function after nextloop.


Thanks Joachim

Login or Signup to post a comment