I’m using the nextion display
.I’m going to make the user slider like the picture below.If you know well, please reply.Even if I search everything, there’s nothing to refer to.
Hi and welcome @murondo!
The answer is as short as disappointing: You have to code it all yourself. Nextion does not come with a widget that does this out of the box. It’s unfortunate that they decided do go for such misleading pictures/animations.
While it is possible to code it yourself, I honestly cannot recommend it. If you’re already hitting the limits of Nextion before getting started, leave it alone, it is not the right product for you. Nextions benefits are that you can drag and drop your UI using the built-in widgets. That makes development easy and fast. If you need stuff they don’t offer, their language and ecosystem becomes a true pain in the ***. No global functions, no arrays, no libraries, only most basic math (not even () or operator precedence) - that’s not the environment you want to start coding custom widgets.
You should think about learning and using lvgl. Among other advantages it comes with a built-in widget for a circular slider 
And unlike Nextion, lvgl looks (almost) as nice as in the pictures out of the box.
Since you explicitly asked for references for such a slider on Nextion there are none AFAIK. Sonoff were the first people insane enough to do it on Nextion. In the UNUF discord people are working on it but it either doesn’t look nearly as pretty or it’s way more work than they’re willing to spend (which means something).
I somewhat covered this topic within another recent post of mine (bottom of the first post): Unleash your Nextion
Kind regards,
Max
2 Likes
When I used the nextion word, you were right.Only the screen was made plausible, but there was no communication with users.I didn’t think I’d been upgrading for a long time.Thank you.
Are you sure this is a touch slider? To me it looks like a white dot on an image.
To adjust it you press ‘+’ or ‘-’.
Edit: ok, found a demo, it is touch:
https://ksr-ugc.imgix.net/assets/035/176/394/2176c62cb0978eef0eb0fcfd546d9c43_original.gif?ixlib=rb-4.0.2&w=680&fit=max&v=1633849810&gif-q=50&q=92&s=29da46ad67a2c1791d34a21c734a0db9
1 Like
Nextion editor?
Can you tell me how to make it?
You have to code it all by hand.
I just made a quick demo to demonstrate it.
RoundSliderDemo.HMI
Code can probably be optimized to make calculation better and behaviour smoother.
1 Like
OMG! I sincerely thank you for your support.
I’ll apply it a little bit more.
It’d be nice to bring the point dot image to the drawing.^^
I will use it so that it appears more smoothly from 0 to 100.
Thank you.
“They” have shown how something like that can be done with a few lines of code…
Part 1: The Sunday Blog: Circular controls - Part 1 - Nextion
Part 2: The Sunday Blog: Circular controls - Part 2 - Nextion
1 Like
It is a ring and you can touch it, but not much else.
First of all, it’s not draggable, you can only touch it and it jumps to that position (though this can be partially fixed by running the code in a timer). It’s also using 64 bytes of user RAM for the string based LUT (which is painfully slow but that doesn’t matter too much here).
Secondly, while it is done more code-efficiently than @philipp900’s completely hardcoded approach, I’d for sure not call it “few lines of code”, which implies that a beginner could easily understand and replicate it. It does require some work and knowledge about Nextions quirks and limitations which in turn requires experience. And that’s exactly what most Nextion users IMO do not want to mess with.
I still think my recommendation and thoughts from above are appropriate.
Kind regards,
Max
1 Like
Just to annoy those people that thought to themselves “that guy can only complain. shall do it better”, here’s an actually draggable circular slider with true 1 degree resolution. As a bonus, the knob changes color with the temperature. I think I like this even better than the colored scale.
Oh, and btw: it doesn’t use split-string-arrays nor code generating scripts (both things that shouldn’t even exist).
Click the image to get to the repository with the demo file.
https://github.com/MMMZZZZ/Random-Stuff/tree/master/Nextion%20Round%20Slider%20Draggablehttps://github.com/MMMZZZZ/Random-Stuff/raw/master/Nextion%20Round%20Slider%20Draggable/demo.gif(image larger than 4 MB)
Kind regards,
Max
And here are some other examples of how to implement dragable ring sliders, with HMI and details, that I’ve been documenting over the past few weeks along with some other things you can do to expand the built-in capabilities for processing Nextion gestures.
1 Like
@krizkontrolz : That’s IMHO the way to go! Expand as much as possible the built in functionalities… instead of being negative all the time about a presumed lack of capabilities. Thank you for sharing your code!
Decomposing a complex task into smaller sub tasks until the latter can be executed with the available tools and functions, that is the true core of software development.
I admit, this requires sometimes a years long learning curve. But everything which isn’t acquired through blood, sweat, and tears isn’t worth anything. That’s why I think of the Nextion approach a very good compromise: readily available components for quick prototyping and simple industrial (their main target market) applications, in conjunction with a simple and easy to learn language which allows the ambitious developer to go beyond that. You want some extra functionality? You can get it by investing some extra work. There is nothing bad about that.
Sorry @Max if I oppose to your reiterated rants, do you have personal reasons for being so negative about Nextion? I’ve read through the 2 linked Nextion blogs, Their solution, albeit coarse, is exactly sufficient for the required range and resolution. It is code efficient and without all the explaining comments, it’s definitively only a few lines of code. It is obvious that @krizkontrolz’s solution is more universal by allowing almost arbitrary resolution, but at the expense of more code lines which seems logical.
That’s IMHO the way to go! Expand as much as possible the built in functionalities…
Here‘s the key difference compared to my position. When it comes to productive development my opinion on ‘the way to go’ is ‘expand as much as sensible’.
Without any doubt is it an interesting challenge to do coordinate transformations from ground up with only rudimentary integer math. In my opinion though, there‘s a clear difference between a challenge and productive development. If you buy a Nextion screen for the sake of having fun with it, then by all means, make it run Doom. Do all the crazy research, use all the neat as well as the dirty tricks and hacks - I’d love it. However, if you bought it for productive usage then you bought it to speed up development because that‘s essentially what you get for your money compared to a bare screen with a microcontroller. Ease of use; reduced dev costs (at the expense of higher part costs) and - very important - reduced maintenance costs because of reduced complexity. Often enough Nextion is a good choice for these reasons and makes a lot of sense (in case you forgot or missed it: I have pointed this out before). If so, then digging through research papers to find suitable algorithms, to then port them to Nextions restricted language, to get essentially a gimmick (more on that later) seems to me like you not only toss out any time, complexity and maintenance advantages out of the window, but also two grenades right behind to make sure nothing‘s left to even hit the ground.
Now some may think “what maintenance?? write it, test it, done!” Yeah, that works until you need to add some functionality (more steps f.ex), change some layouts, whatever. Especially in times of component shortages where the same product can easily ship with a dozen different board revisions it should be clear that changes are often enough unavoidable. And just to give one example where this slider solution adds maintenance costs/headaches: imagine you add a feature that requires/does a page refresh (ref 0). Well, great, now your slider doesn’t have a knob anymore. One more thing to keep in mind, one more thing to work around, one more thing that can go wrong. This is, no matter how much it bothers you personally, a disadvantage. From my own experience I’d say for the first hack like this you don’t care much, also not so much for the second. The third time you get annoyed and if you need to rework any of these you’re pretty much pissed of by the whole rat tail of certain changes. That’s my experience.
So my criticism - in this case - is less against the Nextion screens themselves but more against how it‘s marketed both by Nextion and also parts of the community. Claims like „look what you can do with a Nextion“ are in this context misleading because they imply it was (much) easier to do it on Nextion than f.ex. on a normal microcontroller. In reality, on the latter you simply write #include <math.h> and done. At least one hour of R&D time and money saved as well as a lot of headaches for the guy after you that has to work with your code base. This is what I want to get in the heads of people. If R&D time or money is limited, don‘t f*ing reimplement the standard C math library.
I called this circular slider thing a gimmick because in my eyes it doesn‘t offer any additional functionality compared to a normal slider. 90% is purely the visual, the something-else-than-standard-linear-slider. 10% is convenience for the layout because it might be more compact / space efficient in your particular layout.
If we were be talking about having a slider at all compared to no slider, I’d understand it somewhat more because the gain in usability would be quite significant. But we’re talking about replacing a normal slider that works just fine IMO.
As for my criticisms towards the technical side of Nextion, there are two that are related to this topic. One is simply the limits of the Nextion language. Some of them are really annoying and I cannot believe that there would be legitimate technical reasons to not change them except for the dev time. Example (there are others): no char to int “conversion” (there is nothing to convert ffs! A char is just a number so let me read it!).
For a long time we‘ve been hearing from the Nextion forum admins that this was (mainly) due to the STMs running out of firmware space. And yet they introduced a whole new TouchCap component, and yet they added a progress bar to the bootloader, … Something doesn‘t seem to add up here but please keep in mind that I haven‘t yet taken the time to verify what I‘m implying. Also, this argument gets (very) slowly less important because Discovery and Intelligent Series screens have significantly more flash than the Basic and Enhanced series.
The other one - and this really targets the whole „[enter any feature request here] can already be done“ argument - is the fact that anything you implement yourself runs on top of an interpreter which has a massive overhead (about a factor 3000). I did some benchmarks but I never took the time to properly document it here; so right now you need to trust me on these values.
No matter how you turn it, anything you do in the Nextion language runs three orders of magnitude slower than native code, so any fancy square root algo takes away precious time and thus responsiveness. Maybe except for the intelligent series, I would not say that the screens have an excess of processing power…
It is totally possible that in some cases it‘s faster to send values from Nextion to the MCU, process them there without interpreter-overhead, and send the results back to Nextion. That is just ridiculous (for me at least).
After this I hope you understand my position a little better. In my eyes Nextion isn’t just bad. But it’s not perfect either; and some people - including those at Nextion - seem to forget this sometimes. There is room for improvement and there are cases where Nextion is not the best solution.
Now, regarding my comment on their blog post. The fact that it’s not draggable wasn’t so much a criticism towards the blog post than a clarification for those that clicked your link that you posted in a thread with the title Touch draggable ring slider. For me at least, it makes quite a difference whether you can actually slide your slider or not.
You also seem to have missed my point about the “few lines of code”. Yes the solution is not very lengthy - never said that anyways. Also, I’m well capable of differentiating between lines of code and comments, but thank you very much for the reminder. The point was that just because it’s not 10 pages long doesn’t make it intuitive/beginner-friendly. Yes, again, the blog post does a rather good job explaining it, though it does hide some of the annoyances (f.ex. how to populate the LUT with values? Well you have to calculate them yourself. Looks easy and simple if they’re just written there but if you have to do it on your own it does make quite a difference - especially if you need more than a hand full of them).
In my head, a beginner (in the sense of: someone who has to ask a search engine about a “touch draggable ring slider for nextion”) that reads “oh it can be done with a few lines of code” likely expects little effort required compared to a normal slider - which would be the logical reference to compare with. And I think most of those people would be surprised in a not-so-positive-way what the “easy” solution looks like. But that might just be in my head.
But everything which isn’t acquired through blood, sweat, and tears isn’t worth anything.
This, sorry, to say, is utter bs. The amount of work and/or pain spent on getting a job done is not correlated with the quality of the result. In both cases you can end up with a beautiful solution as well as a steaming pile of sh*t. And no matter how much or little effort was required for a good solution, you can always be proud of it. If it took only little effort, be proud that you worked so efficiently. If it made you go through hell, be proud that you succeeded and didn’t give up.
Regards,
Max
Edits to fix the typos
5 Likes
Thank you very much!
The " The Sunday Blog" solution has no dragable ring.
In general, expanding the capabilities by building on bricks to come to more complex solutions is a nice and common approach. Just, the nextion programming language lacks these capabilities (‘click m1,0’ as sub function replacement is a joke). To repeat: ‘click m1,0’ as sub function replacement is a joke! This language can’t be taken serious. And the nextion team is not able to even fix this as some sort of compiler only fix.
So, the sunday blog is a nice example from an experienced guy who has to ship around all these obstacles one has to learn by heart.
Max is right, this device could be much better.
1 Like