I have a NX4024T032, and nextion editor v 0.41.
When I configure a waveform for dir=rightalign the redrawing is very slow until wave reaches left side of waveform element. Then it draws at same speed like other dir-values.
If additionally waveforms sta is set to "crop image", there is some extra drawing right from the waveform area, until wave reaches left side.
This happens on editors debug screen and on real display.
My waveform dimensions are :
x=23, y=109, w=361, h= 101
On all elements, where sta=crop image is possible, i can change the picc index at runtime, and background of element is changed. Except waveform - it stucks at the background selected at designtime, regardless of changed picc index. There is no error output.
Bug or feature ? Should i do more than simply change the picc index of waveform ?
However, the displays and the editor are a very good idea, i love it !
Waveform is a large part of static firmware - this in not a bug.
Because there are too many things the firmware must be doing to capture 4 channel data
it will be limited to 0 to 255 data via serial and less customizable.
The wider the waveform, the more scrolling, the less samples per second possible.
I am uncertain which is your HMI requirement, displaying data or beautifying.
If your data changes with the background, perhaps swap pages with new waveform.
attempting to crop will require an entire background redraw - okay if data 12 samples per hour.
thank you for your quick answer. I have put 2 issues to one posting, may be not that good idea.
The first issue is slow redrawing of waveform, when dir is set to "right align".
I have attached a simplified Sample from my project. You can see that behaviour, when
you start the Waveform Generator at the Debug window.
You can see also the drawing of lines outside the Waveform-element. It seems, that Waveform in this configuation paints much more, than necessary. Note also the better performance, when wave reaches the left border.
My real world 3.2"display shows the same slow redraw, and drawing outside as the debug window.
I think, - a bug. At least that drawing outside of elements borders should not happen.
The second issue is that "not changing of background when sta = crop image and picc is changed". My intention was a switch between a day- and nightdesign background (beautifying!). In my sample you can switch between designs by clicking at the stars, or the sun.
Ideally this switching should occure only twice a day (automatic). The waveform should show a history from last 12 (or, may be 24) hours.
I don't know something about your implementation of waveform redrawing. But there must be a redrawing of the waveforms background (worst case: of the whole area) everytime, when Waveform gets new data, or refesh is required. Regardless of what type of background is selected.
The background of component should change at least when "ref" is applied to component (if automatic refresh really causes problems).
You wrote, that switching to a new page (i. e. one for day, and one for night, right ?) might be a solution. I can't find this a satisfying solution, because i can not have a global waveform (visible at same position, size and style on different pages), and therefore all my collected history display data is lost, everytime i switch between pages. If I want to have it back, i have to keep track of current page, and reload the history from MCU everytime page is switched. A great waste of short resources.
I believe, that the first issue is a real bug (both, in editor and in firmware).
The second issue may be a bug (i believe so), or a feature by design. However, a better support for changing crop image index (picc), at least when "ref" command is applied to waveform element, would be great.
Thank you again,
I am looking at your HMI now. (waveforms update over serial, not too much info gained from HMI side)
What is your sample size? What is the inter
val between add commands.
OHHH ...whose idea was it for a 5x5 hotspot (faceplant).
Always fun trying to locate these when it's not your design. =)
Okay, I will give a quick report on what I see with your provided HMI and version v0.41
- drawing inside wave form -so I have to ask what value did you give that was outside.
By definition, green is runtime changeable. So picc not changing is in error.
I will have to check previous versions to determine if picc was green and/or functional
- The main portion of the waveform is embedded in the firmware, not in component.
- this means the waveform is mostly NOT interpreted and will run faster as binary.
- but it also means less interaction and dynamic changes.
There are a number of questions I do have, especially on how often the adds are made.
So I will report to the dev team that their accuracy in attribute colors needs attention.
okay, I am still formulating a means to switch pages between updates.
2 mins between updates is plenty of time to make a swap of two pages, but it would be noticed.
The 1/10 second timer is a potential issue. I would recommend reviewing the thread Nextion v0.40 timer component and waveform for hints at reducing clock cycles:
The waveform scrolling is cycle hungry, and although you said 2 mins between updates, but mentioned it takes longer to reach the other side before smoothing (negative direction in integer math will always require the added cycles needed for flag compares and an extra subtract : 0-value). Besides this integer cycle time, you may have a side effect from a timer overflow where timer events take longer than the .tim value. You will see in that thread, as I played with an oversized 6 channel gui waveform, that the time needed to scroll on a larger pixel range was taking around 1400ms to iterate. You should perhaps time your events to see if you are indeed getting all done in 100ms and if not, then you create a cascading overflow until caught up - if caught up.
I agree with a pane to see page components, and do I like tree-views, but even a straight list would be useful. I personally recommend the 5x5 hotspot, but perhaps I should say a 30x30 until it is ready LOL.
The waveform can make use of a few extra commands when updating (if using page switch).
ref_stop and ref_star as well as the addt command for bulk data updates.
So you may be able to swap pages in a reasonable amount of time.
I can not replicate, on right it does draw at 361st which is occupied by a grid line, but on right-align this is the first line position. A grid line is not a border and is fair game when it uses it. Since mine is being well behaved, could yours be miss aligned by one or 2 pixels? Accidental movement, or I may have missed the why mine is behaving well.
Jumpy will be the negative direction I spoke about. Once it reaches the other side, the internal data array will be full and we can see they make use of lower cycles by changing their rendering approach.
Good morning Patrick,
i'm sorry, but the first sample i've sent to you does not demonstrate the overdrawing effect. This issue is only visible, when waveforms sta=="crop image".
I have made a new sample. See attached WaveThing2.HMI.
The 0.1s timer is removed - this was a remain of the attempt to build a clock display, also the TICK hotspot component. The other hotspot is enlarged now, so you can use it to refresh the pages background.
If you use the debug window, and run Wave Generator, you should see the problem. I've made a screenshot, and marked the issue with a red ellipse (not part of the HMI).
By clicking at the right bottom corner you can refresh the pages background.
The behaviour of my display is consistent with debuggers behaviour. If necessary, i can send you later a picture of the display showing the issue.
I don't know, what your rendering approach is, and how it works, but the rendering of a "right align"ed waveform is simply a mirrored version of "left to right" drawing. The "right to left" direction needs some more brain acrobatic.
However, the internal redrawing cycle time of waveform should be shorter for less than capacity count of values, because there is no need for redrawing the entire waveform area. And there should be no remarkable timing difference between drawing a line, or moving a piece of a bitmap from left to right, and moving or drawing the same to opposite direction.
May be, this redrawing issue, and the "not changing background when sta=="crop image", and picc changes"-issue are related things - and there is a solution to fix both. With the (may be...) result of more efficient redrawing.
You have successfully made the points on the crop image not changing backgrounds - This has been reported successfully. You have successfully demonstrated drawing right of waveform. Now ....
I am going to present a understanding of the Nextion firmware, which I don't write and have no means to dictate what the programmer of the firmware must do. I may have one of the best understandings of the firmware behaviour, so I am always working at exceeding the Nextion design limits, but it has limits. This understanding is a necessary to create successful Nextion projects that can press the Nextion limits
I will report the error, and I can certainly envision the pattern of commands used that produce the error. But the timeline to when it is resolved - this I have no control over. The result of how it is finally handled and resolved is also something that I have no control over. It may be decided that cropping attempt has failed and is discontinued and prevented on right-align, this is up to the firmware programmer and is out of my control. So back to an understanding.
What the designer of the Nextion has managed to do is amazing. This firmware fits within the 64K of flash and 8K of SRAM of the STM32F030C8T6 on the back of the Nextion. This drives the whole Nextion HMI user design at runtime. The 8K of SRAM is important, it is shared between the firmware requirements and the user HMI design, and as you can see from your status bar in the Nextion Editor 3584 bytes of the available 8192 bytes is dedicated to your user HMI design.
It is a fine fine fine balance to squeeze the firmware requirements into such small spaces, and if it exceeds its 1/2 (firmware half is a bit more than 50% now), it starts chewing into the user's 1/2, and this would result in some projects no longer working as the now existing 3584 bytes will be reduced to accommodate a firmware growth. It is for this reason the resulting decision of how the waveform issue is eventually resolved. If it can be resolved without expanding into the user's 43.75%, right aligned cropping might be resolved to function as you desired. But if not, .. well you should see the point.
The Nextion is not a desktop computer, and its main function is for Human Machine Interfacing. And it is somewhat cool that we can program it to exceed it's designed intentions, but its goal certainly is not to replicate a desktop or cell phone type system.
I mention this as your 1/10th second timer was to add a clock, and it is possible - I worked this out in the v0.40 waveform issue just 10 bug reports ago (provided you the link above for you to examine the things needed to be considered in order to achieve it). But when we exceed a press/release request and status reporting functionality design - the onus is on us as users to utilize the available resources in a balance of the limited resources and limitations of the device if we want to be successful.
When we have this understanding and properly aligned expectations, many things can be achieved that far exceed the creators original design expectations.
thank you for your reply. I'm with you - the Nextion is a fine piece of work, and a great idea, to give small MCUs with limited capacity a chance to present a nice GUI. From my side - it does much more than i've expected. I'm really impressed by the work of your firmware programmers, and other software people, including the creators of the designer.
I think, they will find a solution, not today, or tomorrow, but time will come.
I would love it, letting the moon or sun shine through the waveforms grid lines ;-).
Regarding the clocktimer: I'm very new with Nextion displays, my first Nextion came on last saturday.
So my first idea was to build "any living thing" on the display, without programming another MCU, and so the clock-idea was born. Soon i found, that that was not the intention of Nextion designers (especially not for basic displays w/o RTC). So i gave up this. My MCU will have a RTC, and internet connectivity - so it can handle date and time, formatting strings etc. much more efficient. After that i've read your v4.0 waveform posting, and i've learned: a timer based clock at Nextion IS possible - but may be a waste of short ressources.
For now, i'm going into my holydays.
I wish you, and the people at ITEAD Studio, a happy, and successful new year with much more great ideas.
Just one last thought to let the sun and moon shine through for Christmas.
Why not just use a crop image waveform that has .dir as right to left?
- sure it starts out on the left, but after it is in use for the 12 hour 360 pixels, it runs the same as right-aligned.
switching the day page and the night page would requires MCU space for the current data
uint_8t ch0, ch1, ch2;
since the MCU has this value before sending over serial simply add to your buffer,
You are also in control of when next update is being fetched, so switch right after an update
you can the use the addt command to fill the switching page
- two smaller delays when switching from day and night ...
But - the cloulds / stars shine through
I'm back now, and i hope you had a good start into the new year.
You are right, this "double buffering" would work - but then i need
1080bytes (or 1440 if i want a 4th channel) plus some extra bytes for buffer and transfer logic
on my tiny, tiny Arduino. Assumed, that my values are from 0 to 100, and in most cases >10,
i have 3 bytes per value to transfer (2 digits and a separation colon), this is a block of 3240bytes for 3 channels, or 4320 bytes with 4 channels. Plus some bytes for commands , linefeeds, etc.
Assuming Arduino's SoftwareSerial @ 19200 baud - this would take 2 or more seconds,
during this time, the arduino is blocked (and the Nextion too, i believe).
Beside this, this solution would need at nextions side the memory for 2 identical pages (with different backgrounds), and all the effort, to keep them consistent (at designtime, and at runtime).
Not really efficient, but possible.
Whats about 'global' waveforms: they never forget their collected data, except on reset or special command, and one can add data, regardless of their visibility. Redrawing is only necessary, when this waveform is referenced by a visible page. But this not a bug report, this is a feature request.