Without having seen your project:
The addt command is going to hijack the processing until all byte values are received.
This behaviour should be deemed normal, and there is no method to inject a doevents command
If using a while or for statement,
inserting the doevents into the loop will allow for the timer and other events to be processed
If you are not using doevents,
the default and expected behaviour is to complete the issued tasks before proceeding further.
Part of this may be in the way you have chosen to implement your design.
Perhaps implement your design so that it does not take more that one second to complete each update to the waveform and thus allow the timing needed to update the status bar and timer.
Next steps will be
1) attempt to implement the timings needed in your project.
2) If this fails, recreate this in a simple single page project, and upload the HMI and compiled TFT.
3) I will take a look at your HMI and see what I can recommend
4) If there is no solution to be found, I will have it forwarded to the dev team.
Also, if v0.38 is not creating the issue and allows for your project to continue, I would recommend continuing to use v0.38 while the matter for 0.40 is being looked into.
Unzip and run from a clean folder.
You can open the Build Folder (opens to bianyi)
Go up one level, should reveal a backup folder
If a v0.38 compatible version exists, it will be in this backup folder.
You will receive this reply be email before the zip file has propagated.
You may need to wait a bit before downloading to allow for this propagating.
Please continue on the path towards finding a solution and upload your HMI.
That would be correct and the expected behaviour.
While the Nextion has not completed tasks with the waveform, it wouldn't be updating other code
I haven't been able to get the timer to stop working, it resumes again when work is completed
How many samples as you attempting at what rate?
This type of information is not included in your HMI file
I want you to try this: issue a ref_stop before sending the 3 data points and a ref_star after sending the 3 data points.
This will not refresh your waveform while receiving the points, but after all three are received. So for each round
The issue here could be the size of the waveform (length), and the fact that scrolling takes a lot of time.
I have been playing with an oversized 800x480 and 320x480 6 channel gui created waveform replication
What I have been discovering is the additional length adds more scrolling time.
So much so that on 6 channels and 480 length, the time to refresh one set is near 1400ms.
I imagine what happens with a 150ms timer if it takes longer than 150ms to refresh is that you end up building a queued list of refreshes that have been requested but not performed. Therefore, before the waveform is able to leave and do all these other events on your HMI design (such as update the time), it sees that it has another update and continues. It should eventually end in a stack overflow.
So in my 6 channel example, setting it at a 50ms when it takes 1400ms, should be expected to cause problems much quicker. But knowing it is 1400ms, if I then set it to 1500ms, I have almost 100ms for other maintenance. It is better to only have 40 samples per minute and it keeps on working, then one that is problematic. Or even at 2000ms and only 30 samples per minute with more confidence that I have created a wide enough margin to avoid errors.
Circle back up to the top, Your waveform component can take advantage of the ref_stop and ref_star that mine can not. I would try it and see how it improves. Your waveform is 737 pixels in length. What you need to do is send at your 150ms and disregard the timer for now. Time by hand just how long it takes from GO to when your data reaches the right side edge ... then divide by 737. This will give you the time each data set is taking. When you know this, you can adjust so that you have room for other code to happen between data points.
send me your timer code
Did you remember to use the command doevents in your loop?
Hmmm, I was thinking about the timer event code
but within any loops .. you should be including doevents .. this will allow the timer to trigger, as well as update the screen with various other things being refreshed
If you aren't using doevents in your HMI code, then the default is to hijack processing till your loop is finished.
Have you made changes to your HMI since, or is it still the same as you have posted.