Alternative Screenset (and FW) for H5

[GeckoSub]

[EDIT]
This very long thread started with a question about how to use physical buttons with the original non-touch H5 FW.
Then Max published his latest touch-capable FW and screenset but I felt I could modify it to better work for my needs.
So months later, that endeavour ended up in a completely new screenset and a modified FW:

Here's a bit of a breakdown on how this screenset/FW works and how it sometimes differs from Max's but the overall idea behind it was to get rid of things I didn't need in order to be able to enlarge other components - like the coordinate readouts and buttons used often. And then along the way, I added some small quality of life improvements:

• There's no Y-axis stuff at all, so this screenset is not for you if you need that
• You can add external, physical buttons now. The idea being that we wont need the keyboard at all, everything can be set on the touch display but it can be nice with a some tactile push buttons for e.g. jogging and start/stop. I personally have a custom keypad with 10 keys that also double as a numpad. Knock yourself out - or just stick to only the touchscreen
• The custom FW keeps the decimals stable, combined with a mono-space font it means the coordinates no longer "jump" left or right
• Also, metric mode should pretty much always show two decimals now, even in most "input prompts". For imperial, it should (mostly) be locked down to three decimals - all in an effort to make the interface nicer and calmer to look at and a bit more consistent
• There's hold down mode(scrolling) for the +/- buttons. I think that might be handy when setting feed speeds for general turning along the Z
• There's no multistart button in this screenset, but you can still set multistart (and disable it) within thread mode (though not in any other mode)
• There's now a button for toggling between radius and diameter readout
• You can set a known diameter or a Z-dimension by long pressing the X/Z coordinate box (using +/-) will toggle between pos/neg values
• There's a Delete All Limits function (long press on left limit)
• Pitch for Thread mode is now separate from all the other modes (which are still all linked to each other). This means, that when you change a pitch in any other mode, it doesn't affect the pitch in Thread mode and vice versa
• Run is "play" and you can also think of it as a "set" button for when e.g. setting pitches and passes
• You zero an axis by pressing its coordinate box
• You disable an axis by pressing on the smaller X/Z at the very left of the coordinate box
• Tapping the spindle value box will cycle the display between showing RPM, Angle or Turns
• You can toggle the color of the X/Z coordinates and spindle value between white or green by long pressing the small X/Z to the left or the spindle value box
• Long pressing the pitch text box will toggle that box's font as some fonts don't work well in imperial modes
• Short pressing the pitch text box will reverse the pitch
• Tiny change: "MM" is now "mm" in the unit text box and "IN" is "in" whilst TPI is still "TPI".
• The numpad now has the "0" at the very end which I found a bit more intuitive
• There's a table in the FW where you define which modes you want availble. Idea being you can disable some if you know you wont be using them, thus making it easier to cycle through them all on the screen
• Modes also change color to give a little bit of visual feedback when changing - you can define the colors used in the FW

If you are interested in this, I suggest you skip the next 80 or so comments and just scroll towards the end as the newest versions of the screenset and FW are down there.
As of the time of editing this post, the post with the latest versions is this but I may forget to update this link so scroll down further to check for even later versions.

DISCLAIMER (AI DID THIS...!)
Whilst the base FW is indeed Max's, I can't code and ChatGPT/Gemini did all of the changes. So, I can't promise it wont crash your machine! Use at your OWN risk, go slow, please test!
Also, do check the posts late in this thread from the (few) people trying this so far as they will be the best at reporting bugs - personally, I am on a quite different "fork" of this screenset/FW that has DRO capability so I haven't actually used it myself apart from some simple testing.

I will leave all the other comments in this thread up - but it's a lot of trial and error stuff, so you can skip through most of it.

---

[OLD post about touch buttons and PS/2 commands starts here]
I thought this would be easy, but then again, I don't know code and just throwing ChatGPT ideas at the problem but nothing is sticking, yet.
But I was thinking that the easiest way to get started on making some touch functionality work on the Nextion would be to "just" have the display send out print commands that would equal the PS/2. So, e.g. I could have left and right limit touch buttons and they would send/print an "a" and "d".

But I can't get it to work.

It seems the ESP32 is seeing something because when I press touch buttons, the blue LED lights up on the ESP. I have a few different test buttons all trying to make the ESP32 read an "a" or "d" (left and right limits). Some are hex, some are straight "a" and "d", and they use printh and print syntax. And if I plug the Nextion directly "into" serial monitor, I can see the presses come through at least the "a" and "d" but the hex versions show some funny characters.

So, I am beginning to think it's the H5 FW code that may only be set up to see print commands if they are coming in from a PS/2 or coming in on the keyboard connector port? Perhaps the ESP32 needs some sort of serial.read turned on?

If I can make this "touch = PS/2 approach" work, I think I can get a whole lot done on the touch GUI without having to do any real coding, haha;)

Any ideas on this @kachurovskiy?

[kachurovskiy]

Hi @GeckoSub, here's my latest progress on making touch work with H5. You'd need to upload both h5.tft and h5.ino

h5.zip

The only thing I know not working there is RPM display, not sure why. Perhaps there are other bugs since I didn't test much yet.

I'm afraid you won't be able to get much done without coding though so consider getting into that a bit.

[GeckoSub]

Awesome, thanks so much for this, you're a super star:)

I can see that it's done a bit differently than I thought: You are sending "component IDs" from the Nextion buttons to the ESP not the actually hex/letter. And then you have that "hex to keycode" list in the code to map the key ID to a function.

But this is great. Even if I use my own screenset if I make sure to name all of my text boxes, buttons and hotspots the same as yours it should still work:)

Next level/step would be for the ESP32 to send a command to change a button state on the Nextion. This way, we can make the limit buttons change their icon/color.
If anyone has a snippet of code that will work for this, I am all up for trying it out.
That said, I see you have the distance between limits now turn up - when a limit has been set, so besides the sanity check of having those values, it's also a visual reminder that the limit is indeed set (or not)

Also, sorry for asking for code help right away but... in case you can find the time, any chance I can ask for the bit to not ask for "set all stops"? As it is now, I don't think I can even start a threading operation without having set X stops, but I don't have an X motor. So, if we can make threading work without asking for X-stops it means that I can even get rid of the X limit buttons and the up and down jog arrows:).
But no pressure, only if it suits you - this is already a great jumping off point:)

[EDIT] this is less of an issue than I thought - it seems last state is stored, so if I turn off X it wont ask to set those limits even after reboots - that's great. But in a 2-3 weeks times when my scales arrive and "we" may have found a way to to implement scale data/DRO, then I would need it;).

Anyways, thanks as always Max. This is super, super cool!

[kachurovskiy]

Thank you. As you said, setting the stops on X and then disabling the axis should get you the desired threading logic.

[AlanMerry]

Hi Maxim,

I have installed your latest Touch Screen code which looks great.

I am just running it is test/desktop mode for now.

A couple of observations.

1. The response is very slow.
2. Space between buttons. Currently the buttons adjoin each other which can result in presses for adjacent buttons being registered e.g. the "M" (Metric/in/TPI) and the "+" key. Can we introduce a gap between the buttons?

[kachurovskiy]

Thanks @AlanMerry. Serial communication is much slower than PS/2. I'll try to include a gap between those 2 buttons in the next update.

[GeckoSub]

Almost There
So, I took the screenset I have been working on and used Max's new touch FW code and pretty much made it work.

I made sure I had all the same text boxes named the same as in the Max's screenset. And then for the buttons there are two ways to do this.
Max's code use the specific individual ID from the Nextion of each key - which is sent by just enabling the "send component ID" in the touch event under each key in Nextion Editor. But these IDs get assigned consecutively as you place the keys. You can not rename the ID in the attributes box in the editor. So, if you're designing your own GUI, you will most likely end up with different IDs than Max. Two ways around this. You can edit the table in Max's code to align with your key IDs - which is probably the better way.
I did it the other way where I made each key "fake" a new ID by printing (sending) a HEX value when you press the key. You put this in the touch event, but it's a bit finicky, I could only get it to work on press and not release. [edit] My bad, it works on both press and release, and of you want a hold down function, it works too as long as you but the "01" version of the hex in the press event and then "01" in the release event.
Anyways, most of it works now:)

Stuff To Work On

• My jog keys somehow stay on and keeps moving the axis. I will look into that - or maybe I will just map use "send IDs" and change the table in the code, then the buttons should work exactly as in Max's screenset, I think. [Edit] Fixed now, just had to make sure both touch and release are on. I got it to work both with sending ID and changing the code table and by faking the ID with a hex code.
• I also put in some code Chatgpt suggested to keep the decimal places at two always, so the X/Z values don't jump left and right depending on the number. It's a nice little change.
• Have to figure out how to do it for the limit values too, though last time I tried, it broke the code.
• And then I have to figure out why I can't get out of E-stop
• Oh, a big one, have to make my Numpad work. There are no numbers on the front page of my screenset but I have a numpad page.
• Some of those longer messages about SSID, wifi, etc, I will shorten them in code and also try to find a snippet of code that will make them scroll sideways as my down sized text box is too small for some of them.
• My buttons are less "clean" than Max's. His only spit out the ID (hex) on presses, mine has some filler garbage(?) in them, unless they are text box presses. I am speculating that it's because I use images for my buttons and they change between two pics. Max doesn't change between pics for his buttons but have the Editor attributes change the base color and highlight color when pressing the button. Well, a few of them have pics, but then he places a hotspot "button" over them to get the touch function - so still not changing between pics for graphics. (Tip: the debug monitor in Editor actually shows the real hex values, which I couldn't get Arduino IDE serial monitor to do so found HTerm instead, but turns out it's not needed. And even the Editor debug shows some error about pic2 when I test my "pic-changing" buttons).
• Will edit the PNG a bit more. E.g. I will make the limit arrows way smaller as they are colliding with the limit values now [edit] Done now:)
• And then, "as always", I'd like to get scale/DRO input at some point which is why I am trying to perservere with this screenset and the bottom left DRO-related buttons.

@kachurovskiy Thanks again, this code is so good to have!

[GeckoSub]

@kachurovskiy
Heya Max,
Even though I am trying to get your new touch code to work on my own screenset I did notice two small things.

• +/- buttons don't have the hold feature, only jog buttons do, I think. Probably on purpose but perhaps it would be good to make them be able to scroll faster through values than having to tap each time? That way, when adjusting feeds on the fly or going from a thread pitch to a fine feed, we may not even need the numpad much.
• The jog buttons are perhaps a tad too sensitive, I think. They may need a debounce or whatever it's called. You have to tap really fast to be able to just change by one increment. So, if I am in increments of 1mm, one tap often moves 2 or 3mm.

As for my own work on the screenset, it's slowly getting there.
I managed to get a DRO value from a magnetic X scale onto my X text box now, which is very cool, but it rolls around and resets to 0 every time the counter gets full so it's still useless, haha. The standalone DRO code doesn't do this so it must have happened in the merger somehow but since I am using ChatGPT and still don't actually really understand the issues it takes forever to try to fix these things.

Also, I don't have a numpad on the main page but I got my thread pitch table to kinda work - meaning I long press the pitch text box and my thread table will come up on a second page and I can pick a thread. But after that, the selected pitch doesn't turn up in the pitch text box until I hit either +/- or the mm/inch/TPI button or maybe jog or reverse pitch. Also, after being in the thread table when I get back to the main page, I start at TPI for some reason and 0.01 increments. Not the end of the world, just a bit buggy.

[kachurovskiy]

Hi @GeckoSub, thanks for the feedback, I agree. There's latency involved in communicating with touch screen that makes all key releases happen later than they should, especially if the display is being updated at the same time due to e.g. spindle running.

[GeckoSub]

Ooh, spindle running, yeah - need to get to that point, haha. So far all of this is just on the bench:).
I will probably have to live without my DRO for a while longer and start on your screenset to keep things none/less-buggy.

BTW, when you developed your latest touch code and screenset - did you find a way to either have the USBTTL adapter for the Nextion and the USB-ESP32 cable connected at the same time or to update the HMI by going through the ESP32?
As it is now, I am plugging in and unplugging cables all the time, haha.

[kachurovskiy]

I'm updating the screen via memory card and ESP32 via USB cable.

[GeckoSub]

I'm updating the screen via memory card and ESP32 via USB cable.

Ah, got it:)
I bought a USB TTL adapter for a few bucks so I don't have to fiddle with the memory card. It's just two clicks in the Editor to send a new tft to the display so I use that a lot - for changes that don't involve uploading new pics, the reflash takes just a few secs.

[GeckoSub]

Hi @AlanMerry,
I have been working on a screenset of my own for a while, the idea being to have DRO features and better spaced buttons and as few as possible - e.g. by moving the numpad to a pop-up page. The latter is still a bit buggy but since I saw your post, I just made a version that has the numpad on the main page and should work exactly as Max's does. Maybe you can try it out and see if it works for you (tft files attached).

A few things to be aware of:

• there's no Y stuff at all, so not for you if you need that
• I don't really use many of the button icons from the NanoELS as they still don't make sense to me. For now, it's text mostly (a benefit of being on a 7'' display)
• the smallest text box may be a tad too short to show the longest messages but should show most messages in full
• not all buttons light up when pressed though I can prolly make that happen with a tad more work. It's only a visual aid that the button has indeed been pressed - even witout the "touch light" the buttons are coded to send the same commands as Max's buttons
• Max's blue "back" button is now at the top, maybe not the best place for it but I don't know how much use it sees in real life
• Run is "play" and you can also think of it as a "set" button for when e.g. setting pitches and passes
• Run and Stop buttons are honestly a bit small, even on the 7'' display. But if you actually end up thinking, you'd use this screenset I could try to find space to make them bigger
• You zero an axis by pressing its coordinate box
• You disable an axis by pressing on the smaller X/Y at the very left of the coordinate box

I will attact the two tft files, they are both for a 5'' display but just one is upside down from the other. (I hope zipping them is fine, as the forum didn't accept the tft files).
H5_V11_GS_MOD_03_5inch.zip

@AlanMerry in case you try this out, let me know if any of the buttons aren't doing what they should. I am connecting them to the code in a slightly different way than Max did in his tft, but it's an easy fix if something is missing or jumbled.

@kachurovskiy
[EDIT - this seems to have been solved unless ChatGPT's code pasted two posts down is dangerous]
One more thing I noticed for the next revision. Can you try to make the number of decimals stable? As for now, they seem to jump between 0-3). Not a biggie, just a bit jarring visually.
I think I sorted it out in my "own" bastard code but can't recall how and I still only managed to do so for the main coordinates and not the on the limit coords. But it does indeed look nicer:)

[GeckoSub]

@kachurovskiy
Maybe not proper forum etiquette but I renamed this thread as I am now adding some alternative _tft_s.

@AlanMerry
Here's a new one where I crammed the limits together to make room for much larger Run and Stop buttons.
I kept the jog buttons as is, thinking they needed to stay more intuitive (bigger risks hitting the wrong jog button than the wrong limit).

Also, whilst funtionality is almost unchanged, I made the pitch box at the bottom right at the end of the numpad into dual action. So, a short press now works the same as the Run button - which also works as "set" for setting values. The result is that if you're typing a pitch value now, to lock it in, you just have to hit the pitch box to save it. So, you stay on the same bottom line when typing making it a bit more user friendly. To reverse the pitch, you long press the pitch box now.

TFT files are here for 5'' displays. Two different versions if you need to turn it upside down:
H5_V11_GS_MOD_04_5inch.zip

[GeckoSub]

Bigger Run/Stop Buttons, Long Press For Font Color Change, Overall A Bit More "Quiet"
OK, one more - V5 from my end now. Probably the last one for now unless any of you actually end up using this and report some bugs:).
But I think it looks a little cleaner now:

Text boxes for status/mode are now moved to the top.
Buttons for unit, increments, multi start and "back" moved down towards the numpad and became smaller, which I think it OK as they are not used that often (well, maybe increments is - let me know).

Also, if you long press the axis denominator (the little X or Y to the left), the font for the coordinate box will change color to green. Long press again and it will go back to white. Short press still disables the axis.

One small downside is that the text box is now far from the numpad so when you type, the values don't show just above the numpad as before. But personally, I am OK with that.

Again, if anyone on a 5'' display ends up using this let me know if anything is broken.
And if the number buttons are too small, I have room to move that pitch text box to the right of the numpad up next to the Mode text box at the top right - and then we can make every numpad button a little bit wider.

TFTs for 5'' displays attached:
H5_V11_GS_MOD_05_5inch.zip

Some Pointers

• There's no Y stuff at all, so not for you if you need that
• I don't really use many of the button icons from the NanoELS as they still don't make sense to me. For now, it's text mostly
• Not all buttons light up when pressed though I can prolly make that happen with a tad more work. It's only a visual aid that the button has indeed been pressed - even witout the "touch light" the buttons are coded to send the same commands as Max's buttons
• Run is "play" and you can also think of it as a "set" button for when e.g. setting pitches and passes
• You zero an axis by pressing its coordinate box
• You disable an axis by pressing on the smaller X/Y at the very left of the coordinate box
• You can change the color of the X/Y coordinates by long pressing the smaller X/Y to the left
• Short pressing the pitch text box (to the right of the numpad) works the same as the Run (play) button - so it will set the value you're typing on the numpad
• Long pressing the pitch text box will reverse the pitch

[GeckoSub]

Moving Decimals Fixed
[B R O K E N - don't reply, will try to fix it]

Yes, I am on a dangerous path - using chatGPT to make coding changes for a machine tool...
But I asked it to make sure I only ever see two decimals whilst in metric and three in imperial (which I will likely never use). It almost worked on first try, some values (0,3,6,9, etc) dropped all the decimals but a few more prompts and it worked - also, worked for the limit values. So, nothing jumping around now. It also insists that these shortened values are not messing with internal math but that they are only for display but I don't have the skills to verify that.

But it sure is pretty now, the coordinates and the decimal point never jumps left or right - which was what I was after:)

[edit]
The broken part was that the code started rounding the pitch entry in t3 text box which was not cool. Some revisions only rounded until I had typed enough numbers or hit "play" but still not a nice experience. I think it's solved now and I will share some code once it's tested beyond the bench. Or if anyone wants to take it for a real spin, let me know and I will share it.

[GeckoSub]

@kachurovskiy Two more tiny ideas for your next revision:)

Numpad Number Sequence
I feel like it flows better in use if the 0 on the numpad is at the end and not at the start. I have yet to come across needing to type a 0 before any of the other numbers - but I always need to press 0 at least once or twice when setting a pitch. So, my finger is flowing from left to right already when setting pitches so it just feels better that the zero is at the end;)

Case in point, even if setting a metric 0.80 pitch, the way you get this typed is and locked in is: 8-0-0-play.

Disable All Stops (Limits)
[EDIT] I figured out how to do this on the Nextion side, so it's in my screenset since V7.

Also, perhaps a "disable all limits/stop" addition to the code would be a nice little addition. It wouldn't need more buttons as it's fairly easy to set up a long press in the Nextion HMI to send out a second hex, I am using that feature a bit already. So, in use, a (shortish) long press of any of the limit buttons would disable them all:).

Backspace Does What?
[EDIT] I've deleted it in my screenset since V6 which for me is OK if it really only serves as a backspace for the numpad.

And finally, can you tell me what the "backspace" button does? I know it goes back one space when typing on the numpad, but any other uses? If not, I may drop it from my own screenset.

[GeckoSub]

V6 - Bigger Numpad, Bigger Coordinate Numbers on X/Z
Yep, the "big" changes are pretty much as the title says.

Also, I swapped the Run and Stop buttons since I wanted the Run button closer to the numpad as it is used at the end of typing numbers to lock in the pitch value. The pitch value box served that function before but now lives on the top right in that "multi function text box". I could possibly make the font for the pitch values a bit bigger if needed.
I got rid of the "back(space)" button. If you're typing a pitch wrong it doesn't take much longer to just hit "stop" which will cancel all the numbers and then just retype.
Deleting the backspace button made room for a double sized increment button which I think will be handy when jogging.

The rest still works the same as before:

• There's no Y stuff at all, so not for you if you need that
• I don't really use the button icons from the original NanoELS as they still don't make sense to me
• Not all buttons light up when pressed though I can prolly make that happen with a tad more work. It's only a visual aid that the button has indeed been pressed - even witout the "touch light" the buttons are coded to send the same commands as Max's buttons
• Run is "play" and you can also think of it as a "set" button for when e.g. setting pitches and passes
• You zero an axis by pressing its coordinate box
• You disable an axis by pressing on the smaller X/Z at the very left of the coordinate box
• You can change the color of the X/Z coordinates by long pressing the smaller X/Z to the left
• Short pressing the pitch text box works the same as the Run (play) button - so it will set the value you're typing on the numpad
• Long pressing the pitch text box will reverse the pitch
• The jog/increment cluster is a teal color in this screenshot but in reality my Nextion shows it more like a baby blue.

Also, a slightly modified FW
This screenset works nicely on my bench with a modified FW that keeps the decimals stable so the coordinates don't jump left or right. Also, the new FW adds hold down mode for the +/- buttons. I think that might be handy when setting feed speeds for general turning along the Z.
But since I can't code and ChatGPT did this, I can't promise it wont crash your machine;). E.g. one of the first revisions for the hold down mode made the jog buttons move, too - super dangerous! But I think I sorted that out. If you want to try this FW, let me know and I'll share it.

tfts here for 5'' displays:
H5_V11_GS_MOD_06_5inch.zip
(Two files but one is just an upside down version)

[GeckoSub]

V7 - Same Looks As V6 But With Delete All Limits And Button "Light-up"

Changes from V6
Almost all buttons light up on presses now except for the limits and the top text box.
I changed the font for the limits coordinates to a mono-space 7 segment one so now, those coordinates also don't jump left or right anylonger when values change (at least on my custom FW).

Pointers

• There's no Y stuff at all, so this screenset is not for you if you need that
• Long pressing the left limit cancels all limits
• Run is "play" and you can also think of it as a "set" button for when e.g. setting pitches and passes
• You zero an axis by pressing its coordinate box
• You disable an axis by pressing on the smaller X/Z at the very left of the coordinate box
• You can change the color of the X/Z coordinates (green/white) by long pressing the smaller X/Z to the left
• Short pressing the pitch text box works the same as the Run (play) button - so it will set the value you're typing on the numpad
• Long pressing the pitch text box will reverse the pitch
• +/- buttons also work with hold down mode now - like the jog buttons (with my modified FW)
• There's no backspace button, I don't think it's needed

Also, a slightly modified FW
This screenset works nicely on my bench with a modified FW that keeps the decimals stable so the coordinates don't jump left or right. Also, the new FW adds hold down mode for the +/- buttons. I think that might be handy when setting feed speeds for general turning along the Z.
But since I can't code and ChatGPT did this, I can't promise it wont crash your machine;). E.g. one of the first revisions for the hold down mode made the jog buttons move, too - super dangerous! But I think I sorted that out. If you want to try this FW, let me know and I'll share it.

TFTs for 5'' displays are here:
H5_V11_GS_MOD_07_5inch.zip

[EDIT]
The enable/disable all limits is "badly" coded as of now. Remember, it works by long pressing the left limit but it basically just toggles all the remaining three buttons (and the left limit) to the opposite state of what they are in. So, you can get out of sync. Say, two of them are already off then if you long press the left limit, those two will not stay off, they will toggle to on whereas the other two will go from on to off. A real coder could solve this small issue in a sec, but I will need a bit of time with the AI dude(tte). It's not a biggie, no safety concern and actually hitting all of the buttons to turn them off in quick succession doesn't take much longer than long pressing one button.

[GeckoSub]

V8 - Better Delete All Limits and Also, A Push Button Custom FW

Same looks as before:

Changes
Looks exactly the same as V7 but previously the Delete All Limits simply toggled whatever state the individual buttons were in so you could get out of sync when trying to delete all. Now, it does what it's supposed to do and clears any limit that may have been set.
But that functionality is no longer in the screenset - it's been moved to the FW.

Pointers

• There's no Y stuff at all, so this screenset is not for you if you need that
• Run is "play" and you can also think of it as a "set" button for when e.g. setting pitches and passes
• You zero an axis by pressing its coordinate box
• You disable an axis by pressing on the smaller X/Z at the very left of the coordinate box
• You can change the color of the X/Z coordinates (green/white) by long pressing the smaller X/Z to the left
• Short pressing the pitch text box works the same as the Run (play) button - so it will set the value you're typing on the numpad
• Long pressing the pitch text box will reverse the pitch
• Long pressing the left limit cancels all limits (if using the custom FW)
• +/- buttons also work with hold down mode now - like the jog buttons (with the modified FW)

Also, A Custom FW
Whilst the screenset should work just fine with Max's h5V11 FW, there are a few things that might make it feel a tad nicer with the custom FW:

• Any function that can be controlled on the PS/2 keyboard can be mapped to a touch button now. The idea being that we wont need the keyboard at all, everything can be set on the touch display but it can be nice with a few select tactile push buttons for e.g. jogging. In this version, buttons and pins that are already defined are Jog (L-R-U-D), Increment (Step) and Mode Cycling
• The custom FW keeps the decimals stable so the coordinates don't jump left or right
• There's hold down mode(scrolling) for the +/- buttons. I think that might be handy when setting feed speeds for general turning along the Z
• There's a Delete All Limits function (mentioned already)
• Tiny change: "MM" is now "mm" in the unit text box but inches still show as "IN" and TPI as "TPI". I think the latter is correct, but I should probably change "IN" to "in" in the next revision. OCD, I know but hey, I did say it was a tiny change!;)

But since I can't code and ChatGPT/Gemini did this, I can't promise it wont crash your machine! Use at your OWN risk, go slow, please test! Info on how to map the pins and set the long press and hold down timings are in the ReadMe and in notes in the top of the code.

Screenset TFTs for 5 inch displays (two versions in case you need to flip it):
H5_V11_GS_MOD_08_5inchB.zip

The custom FW:
h5_V11_NO_DRO_GS15.zip

[GeckoSub]

V9 Screenset - Only One Text Box for RPM/Turns/Angle + Dual Duty Numpad FW
@Clive66 asked if we could bring back how the original, non-touch H5 FW handled the RPM, turns and angle which was by using the WIN button on the PS/2 keyboard to cycle through them. The idea is each value can be shown larger than when they each have their own box and it's something I wanted myself, too so I made it happen:

BUT it took a FW change to make it happen, which means this screenset really only works with the custom FW now. If you use it with Max's H5V11 FW then you wont get any RPM, turns or angle values displayed at all.
And the warning is becoming even more real as "we" (AI) changed a fair bit of stuff. So, please do test properly before use!

Also, I added the new code for the consolidated RPM/Turns/Angle text box to a FW that makes my keypad do double duty as a numpad, so all that numpad code is in this FW, too. It shouldn't really be an issue, you can just leave it as is and just define your pins and key commands as you need to.

Other small changes in the FW and screenset:

• Increments change color now to better indicate that they have changed. Red for the coarsest, then yellow, then green
• I couldn' decide on which font to use for the Pitch text box, so you can cycle through three different ones by tapping the box. Two of them are mono space fonts and of those two, one is the same 7-segment font that's used on the X/Zccoordinates. (The font change and the font color change probably gets wiped on reboots, though as I can't figure out how to make the Nextion store it in eeprom).
• The new all-in-one RPM/Turns/Angle text box can also change colors (green/white) like the Y and Z coordinates. Long press the RPM/Turns/Angle text to make it happen
• "IN" has become lower case "in" to be in line with the lower case "mm". "TPI" is still upper case

I packaged both 5'' and 7'' tfts this time:
H5_V11_GS_MOD_09_5_7inch.zip

The custom FW is here:
h5_V11_NO_DRO_GS31_ONE_RPM_BOX.zip

And I babbled on for ten minutes in this video showing the screenset & FW features - though the latter half is about the dual duty keypad. That said, take a look at this youtube video if you have time to waste;)

The double duty key/numpad is this thing in case you're interested:

[Bart95580]

Hi,
As mentioned in my previous reply, my plan is to implement Maxim's solution (X and Z axis) to my lathe. I have to finish the current solution before to go deeper in the code and do improvements.
For now I don't know if a DRO implementation is my priority, but I strongly suggest to split the big .ino file in several header files. The C code will be code more readable and easier to maintain and to test.

I started my implementation with the H5 version 10 and now moved to v11. For each release, I spent some time to split and adapt this code to my needs.
So before to release your 12 version, I propose you to separate the code between global/ generic files and personal implementation files.

For example, In my development environment I have the following files:

1) A .ino file with the global code from you and Maxim.

It should be great to have few comment lines at the beginning of the code with informations about version, change and release date.

2) parameters.h. This file is about all the customisation for my lathe, stepper motors, encoder, keyboard keys, wifi, etc...

This file should not change between releases

3) web.h.

This file is the french version of the web page and can be changed according to my/ users needs. This file should not change between releases

4) display.h.

This file is about all display functions including your updateDisplay() one

This is a basic idea how we should organize the code, and may be more .h files will be needed in the future
When a new release is available, we have only to change the ino file (and may be the display one). This will be a time saving for any user running a previous version of this code.

:-)

[GeckoSub]

Thanks for the thoughts but there's a but - which we will get to later.

I did think that splitting some of this up made logical sense and I've seen it in a few other projects but since I am not a coder and rely fully on AI, I just went with how it was - I think it even said it was preferable for some reason. But then again, even with my limited skills, I have caught in outright errors from time to time.

That said, when I added the DRO functionality I did insist on it adding .h and .cpp files. But I feel like some of the DRO parameters still ended up in the main .ino.

Either way and this is the before mentioned but - I am honestly not sure how much more work I can put into this. I will probably just do 1-2 more rounds of slight debugging on some small issues for my own use. But I am behind on a "real" project that may very well end up paying my bills - something which documentary photography is no longer very good at doing - so I really have to start being smarter about how I spend my time. And to "rewrite" the FW would take too long with my limited skills - it's been a lot of trial and error just to make these smaller changes that I did implement. In the end it worked more or less and it was good fun, but it took weeks which I just dont have anylonger.

Hope that makes sense and I may revisit it more in depth later down the line, just not much time for now.

[Bart95580]

I can split your original v11 file and send them back to U in a file zip. It's simple and no change to do on your side.

[GeckoSub]

I can split your original v11 file and send them back to U in a file zip. It's simple and no change to do on your side.

Thanks so much for the offer:).
I think that would be great - but perhaps let's wait a few days. Then I can have a go at adding those two changes I mentioned (modes in different colors and a table for enabling/diabling modes). I think they would be nice to have for other people, too:)

Thanks again:)

[Bart95580]

ok waiting for U

[Bart95580]

Hi,
Now, my lathe environment is ready for the tests and I am testing the files U sent me.
the _"h5_V11_NO_DRO_GS31_ONE_RPM_BOX.zip" code file + TFT in _"H5_V11_GS_MOD_09_5_7inch.zip" file
works fine except for the RPM display.

The HMI source file you sent me ("H5_V11_GS_MOD_09_RPM_Turns_Angle_Box.zip") with the same ino file works fine for the RPM display (different look), but when I want to reset the Y axis, It doesn't do the job and set an unwanted upper X limit.

Do you know what I'm doing wrong ? or may be I don't use the right hmi file with the right ino file ?

[Bart95580]

Sorry, forget/ ignore this previous post. The mistake was on my side.

ino Code and tft works fine except may be for the spindle rpm at high speed. The spindle speed is correct between 30 and 1600tr/mn, but if I increase the spindle speed over 1600, the displayed speed decrease. From 1600tr/mn to 2300tr/mn, the displayed speed go down from 1600tr/mn to 1000tr/mn. Any idea about the root cause ?
I am new in this environment and I don't yet know all the subtleties.
I have a 1200pulses/tr encoder, Encoder Gear is 80 teeth and spindle gear is 40 teeth.

[GeckoSub]

Hi Bart,
Apologies for the late reply - was slammed with some work and away from this forum.
Glad you mostly got it sorted out.

As fot the RPM issue it actually sounds quite like what I encountered, too. The speed seemed fine up until a point and then it would drop off and display a lower value despite me spinning the lathe faster.

The fix for me was to use a larger pulley on the encoder. I started with a 1:2 ratio so the encoder spun twice as fast as the spindle and either the encoder or the ESP/FW couldn't deal with that. So, I printed a 1:1 pulley and now I can spin the lathe at full speed without having the issue.

I think I meant to test and replicate this on Max's FW but never got around to it as I found the fix in the meantime. There's a chance it may not be an issue on his FW, that perhaps somehow my FW is taking too many resources away from something else, but that's pure speculation. It would be cool, if you could somehow check on his FW, too.

Also, from memory, I think it has been mentioned that some of the encoders can be a bit picky about having proper voltage. Something about that even though they may be labelled for 5V, they tend to like a bit more. Not sure, but I think you can find something about this if you do a search on the forum.

Hope you figure it out:)

P.S. As for the other small FW changes and your offer to repack the code, I will try to find the time next week to add in some of my latest non-DRO features, small as they are.
Speaking of DRO, I just finished installing a magnetic scale on my Z-axis, but only the one on the X is implemented in my most recent DRO-FW. So, will have to get into the code again anyways, hence why I hope to get around to the above, too.

I am also waiting for the list bits and bobs to button up my electronics enclosure and to machine my final panel. Being on a small tropical island has its benefits but fast shipping is not one of them;)

[Bart95580]

Ok, I see. U have the same issue with the high speed on h5 screen.
As i am still a beginner, I have some additional questions for U.

1. The ellipsis mode is not available ?
2. What is the purpose of the "multistart" button ?

For now, I want to finish my build and will do the investigation in the code later.

My next steps are:

1. add a custom usb keyboard.
2. Rebuild the X axis stepper motor support. The current one works in petg but the température is to high. I want to print a polycarbonate version for a safer version.
3. add a manual encoder to the X axis (like for the Z axis)

Here is a picture of my build

[GeckoSub]

@Bart95580
Hello again,
A bit pressed for time these days but I will see what I can do about the issues you raised. (Found some time today - so check the later posts further down, it has a new FW attached)

Ellipsis
I think you are right, I feel like I noticed that missing, too when I was working on this - but since I don't have a motor on the X, I probably didn't look into it much. (I actually got rid of the rest of the modes that needs an X-motor on my later versions). That said, it looks like it's all still in the code so maybe the fix is easy. I can try to find time to see if I can get it back but since I do all this with AI, sometimes it takes a while.
I know I have promised to do another round of improvements on the non-DRO FW that you have now and get it to you so you can split it up. And just the other day, I finally did add some more (almost final) improvements and fixes to my latest DRO-FW so I will really try to find the time to "port" those back to the non-DRO version - which is the version that makes the most sense for users with ballscrew-modded machines. Let me try to find the time this weekend (I know I have said this before...).

Multistart
I am pretty sure it relates to multistart threads. Which I guess I thought I wouldn't ever need so I dropped it from my recent DRO-screenset to make room for other stuff. To get that back is a little bit more tricky as it would need a revision of the Nextion file, too to add it to the screen. If I ever need it, I think I can hook up the external keyboard or assign one of my custom buttons to trigger it.

As for the custom keyboard, Clive made it work with an off-the-shelf USB keyboard and some sort of adapter board.
And as you can tell, I did too though I just used the regular pins and mechanical key switches.
I actually still haven't decided whether I like the screen or the physical numpad the most for numerical input. Which, given that I thought I would absolutely like the tactile one the most, almost shows having it on the screen may be totally fine. That said, I have a 7'' screen. On a smaller screen, having an external numpad, physical may start being preferable. For start/stop, increments and jogging - I think tactile buttons are a great upgrade. And I find myself tapping through modes on the keypad, too. But maybe not so much for numbers and limits.

Printed Parts
I am lucky in that I have a capable little CNC mill, so I made the Z-motor mount out of alu and I don't have an X-motor. But I do fairly often mock up parts in PLA before machining them in alu. But speaking of PC, I am just a few days away from finally buying an enclosed printer to replace my old bed slinger. I will buy this secondhand, too as I do most things for the workshop. But I think I will start printing a lot in ABS-GF as I saw in some Clough42 videos that it looks amazing for small panels and enclosures. Maybe a bit of PET-CF and PC, too for mechanical parts. Also, I think @gueee likes to print in ABS-GF.

Axis Encoder/Handwheels
I thought I was going to put an encoder on the Z, but I decided to try without it and I don't feel I am missing it. But that's likely because I still have the regular ballscrew and halfnut, so I can move long distances fast pretty easily. And for ELS, I use it in a fairly simple manner - mostly for threads. And for that, it's easy enough to jog with the buttons to set the limits. And then for general turning, I use the Z-motor mostly as powerfeed sometimes with and sometimes without set limits and my X-dro to hit depth. So, not much need for a Z-encoder there, either. Or maybe it's just a case of me not fully understanding what I am missing out on. If you have ballscrews, I would think having handwheels is definitely "needed".
Also, I think the ESP only has four HW counters to be shared for encoders and any scales you may be using. It's probably enough for most people. But you couldn't have two handwheels, a spindle encoder and two scales, it seems.
But if you find that you use the Z handhweel a whole lot, perhaps check where @gueee is on his "adaptive flow" coding on the MGPs which aims at making it faster to use without sacrificing the small increment feel.

Anyhow, I am babbling so will stop now:)

[Bart95580]

[Bart95580]

The DRO is a build in feature in this model

[GeckoSub]

That's a nice looking machine and panel, too:)

So, the machine already has linear scales on it but did you swap both axis - or none of them - for ballscrews?
My thinking is that if you have ballscrews, the scales are probably redundant but if you have leadscrews you may want to check out my DRO version of the FW? That way, you can still use the lathe in a more manual mode like before you added the ELS.

I have two videos (one short, one long) showing the DRO feature in this thread and some more words on how it works. But it's pretty simple. No handover of data between ELS and scales. The display will show either one of them depending on what you choose. The X DRO is a bit more "advanced" since it has Rad/Dia mode and Abs/Inc and a way to input a known diameter (which it turns out, is already in the code, I think).
I haven't yet added Abs/Inc to the Z nor a way to set a known workpiece length. That's the last round of coding I need to do and then the DRO FW should be pretty OK for most use cases. It won't have a tool offset library - that's more work than I can find time for and I don't even know if my quick change tool post is repeatable enough to make good use of it.

[GeckoSub]

New Version of the FW (NON-DRO V32)
I mentioned that a while back, I "forked" this custom FW into what I need - which is to have DRO capability. But along the way I also added some other little GUI improvements and bug fixes. And it makes sense to add these to the NON-DRO custom FW, too. So, I had Gemini take a stab at doing that.

I did a quick test on my machine and it seems to work - though I tested it with my DRO screenset. But it should still work with the latest NON-DRO screenset from earlier in this thread.

Here's a list of the recent changes (I may have forgotten some):

• Modes now have different colors (you can customize these in the FW)
• Ellipsis mode shows on the display again (it was gone in the previous version)
• You can define which modes are enabled (shown on the display) in an easy-to-edit table in the FW with true/false statements
• Thread mode now retains its pitch value independently of what pitch is set in any other mode. Other modes have their pitch “connected” to each other (you change it in one mode, it carries over to another)
• Fixed a bug where stopping an operation in any mode would reset that mode to Gear and the pitch to 0
• Long pressing the X/Z coordinate boxes lets you input a known diameter or length for that axis

And of course, the rest of the changes from my earlier versions should still be there:

• Push buttons can now be mapped to pins. They will work the same as the PS/2 keyboard keys
  (This FW version has all the pins mapped for my custom 10 button keypad, which does double duty as a numpad)
• +/- now has hold down mode so you can scroll through pitch values instead of having to single tap
• Decimals are stable, always 2 in metric, always 3 in imperial (I hope).
  (If you use my custom screenset this means the values don’t jump left and right when jogging)
• Long pressing the Left Stop (Limit) deletes all limits
• RPM, Turns, Angle now consolidated into one box. You toggle between them by tapping the value. You can also turn this font green by long pressing the small RPM/Turns/Angle text
• You can also switch between white and green font for the X/Z by long pressing the small X/Z to the left
• Short pressing the same little X/Z disables that axis
• Increments change color depending on their value - red for the coarsest, then yellow, then green
• You can swap between three fonts for the pitch value by tapping its box

Known Issues:

• The imperial mode is a bit unpolished. Some text boxes and value may overlap others. Honestly, I don't know if I will get around to fixing it. To do so, I'd probably have to play with the text and button box sizes a fair bit with is a pain in the butt... Perhaps an OK fix would be to make the font smaller for the Imperial guys, but again, I can't put much time into that...
• The right limit/end stop is sluggish to update. I think it does register a touch but doesn't show its new state until the FW registers another function being done, like moving an axis. So, in reality it may not seem too bad. But I think I have it fixed on the DRO-FW so will likely try to get it fixed on this one, too
• The values on the limit buttons may be a tad jumbled or not aligned well to the text box. It's fixed in my DRO-FW so will try to make it happen here, too

H5_GS_NON_DRO_V32.zip (PLEASE DON'T USE THIS ONE. BART HAS REPORTED SOME ERRATIC MOVES AND OTHER BUGS)

@Bart95580 do you mind taking V32 for a spin and letting me know how it works? I tested it quickly today and thread mode behaved as expected. (I don't have an X motor mounted but the FW doesn't know that and the values changed as they should have)
I honestly don't think I can put much more time into the non-DRO FW (this one) as I won't be using it. So, feel free to do whatever you want with it from here on out:)

And if you are interested in my DRO FW, let me know:). Just today I managed to get Abs/Inc working better. It wasn't zeroing independently but it does now and Abs/Inc works on the Z as well. And you can input a known Z value now, too. But I should probably start a separate thread to share the DRO FW and DRO screenset.

[Vincam1]

I would love to try out your DRO FW and DRO screenset. Are you willing to upload the most recent versions?

[GeckoSub]

I would love to try out your DRO FW and DRO screenset. Are you willing to upload the most recent versions?

Of course, no problem. But can you give me a day or two? Here's the reason:
I don't have a motor on the X, so in the current DRO-FW, the coordinate box for the X always shows the scale. I don't have a way to toggle it to show the ELS coordinate - as I do on the Z.
Also, the toggling function to go between ELS and DRO value for the readout is only working via a push button right now.
But I think I have come up with a nice enough way to have this be done on the touchscreen. So, I need to edit the screenset a bit and then the code again afterwards.

Once I have this done, I will start a new thread only for the DRO-FW, drop the files there and tag you in that post.

[GeckoSub]

I would love to try out your DRO FW and DRO screenset. Are you willing to upload the most recent versions?

Check over here for the HMI, tft and FW files

Be VERY careful about jogging on the touchscreen buttons, especially on X. But I think that's an issue on the stock FW, too.

[Bart95580]

Hi GeckoSub,
OK... My electrical wires used for transmitting information are too stiff for the large number of manipulations I do during testing.
So I did a full check of all my wires before the tests.
Unfortunately, the results show that the latest versions contain too many small bugs and an overall instability.
So I checked the 5 last releases and chose the more stable one for the tests.
From my point of view, the best release we can use as starting point and future development for a non DRO version is to going back to H5_V11_GS31 for the FW and H5_V11_GS_MOD_09_5inchA.tft for the Nextion screen. This release is not perfect but is the closest solution to a final version.
For my tests, I used a 5" Nextion screen without any additional keyboard and no material in the lathe chuck
Here are my tests about this version:

• Zeroing X axis => OK
• Zeroing Y axis => Ok
• Manual encoder X => Ok
• Manual Encoder Z => Ok
• Change pitch => Ok
• limits => Ok
• multi pass running in all modes => Ok
• Long Press on X or Z change Green/ White color => Ok
• Short press on X or Z enable/ disable the stepper motors => Ok
• Spindle running at Full speed (over 1600rpm) => Ok Display is correct
• RPM/ Angle / Turn display => Ok
• Incr button => Ok (with color change)
• Wifi connection => Ok
• Gcode web page => Ok

------ Modes --------

• Cut => Ok but can't switch "External" to "Internal"
• GCode => seems Ok. GCode web page is displayed, but didn't test it with real gcode
• Async => Ok
• Gear => may be Ok but I don't know what should be a good behavior for this mode. For now, When press the RUN button, the tool go from right to left ( from one limit stop to the other). By doing a long push on the right arrow, the tool go back to right limit and run again to the left.
• Turn => Ok (can't switch "External" to "Internal")
• Faces => Ok
• Cone => When pressing RUN, Display show "ON" , but nothing happen. Not able to change ratio, or External / Internal
• Cut => Ok and External / Internal option works with a long press on the pitch to get negative value ( This External/ Internal option works only with this Cut mode)
• Thread => Ok, Cone ratio works, a negative pitch reverse the thread direction. Both works as expected. I can't switch "External" to "internal" .

In this release

• MultiStart is not working => It's not critical, we could remove this button
• Ellipsis is missing

So in a nutshell this non DRO release would be great if U can fix:

• Internal / External switch work for each mode
• Cone mode works
• Ellipsis mode is displayed and works as expected
• Possibility to hide display some modes like U did in the latest versions.
• Possibility to display a different color for each mode is welcome (but just a nice to have)

[GeckoSub]

Hi GeckoSub, OK... My electrical wires used for transmitting information are too stiff for the large number of manipulations I do during testing. So I did a full check of all my wires before the tests. Unfortunately, the results show that the latest versions contain too many small bugs and an overall instability. So I checked the 5 last releases and chose the more stable one for the tests. From my point of view, the best release we can use as starting point and future development for a non DRO version is to going back to H5_V11_GS31 for the FW and H5_V11_GS_MOD_09_5inchA.tft for the Nextion screen. This release is not perfect but is the closest solution to a final version. For my tests, I used a 5" Nextion screen without any additional keyboard and no material in the lathe chuck Here are my tests about this version:

• Zeroing X axis => OK
• Zeroing Y axis => Ok
• Manual encoder X => Ok
• Manual Encoder Z => Ok
• Change pitch => Ok
• limits => Ok
• multi pass running in all modes => Ok
• Long Press on X or Z change Green/ White color => Ok
• Short press on X or Z enable/ disable the stepper motors => Ok
• Spindle running at Full speed (over 1600rpm) => Ok Display is correct
• RPM/ Angle / Turn display => Ok
• Incr button => Ok (with color change)
• Wifi connection => Ok
• Gcode web page => Ok

------ Modes --------

• Cut => Ok but can't switch "External" to "Internal"
• GCode => seems Ok. GCode web page is displayed, but didn't test it with real gcode
• Async => Ok
• Gear => may be Ok but I don't know what should be a good behavior for this mode. For now, When press the RUN button, the tool go from right to left ( from one limit stop to the other). By doing a long push on the right arrow, the tool go back to right limit and run again to the left.
• Turn => Ok (can't switch "External" to "Internal")
• Faces => Ok
• Cone => When pressing RUN, Display show "ON" , but nothing happen. Not able to change ratio, or External / Internal
• Cut => Ok and External / Internal option works with a long press on the pitch to get negative value ( This External/ Internal option works only with this Cut mode)
• Thread => Ok, Cone ratio works, a negative pitch reverse the thread direction. Both works as expected. I can't switch "External" to "internal" .

In this release

• MultiStart is not working => It's not critical, we could remove this button
• Ellipsis is missing

So in a nutshell this non DRO release would be great if U can fix:

• Internal / External switch work for each mode
• Cone mode works
• Ellipsis mode is displayed and works as expected
• Possibility to hide display some modes like U did in the latest versions.
• Possibility to display a different color for each mode is welcome (but just a nice to have)

OK, thanks so much for the diagnosis and all the work in trying all the different FWs - I know it's a hassle.
It's such a pity that I can't replicate your issues. But I guess it makes sense to revert back to what actually worked the best. I say pity because a lot of hours were put into the latest versions but at least most of that was useful for my own DRO version, too. Also, I really liked the idea of having all the logic for long presses/font change and color change moved from the Nextion to the FW as it's easier to work on on the latter. But GS31 doesn't have that and I think we will just have to keep it as such.

Anyways, long story short. I will try fixing GS31 which shouldn't be too difficult as the issues have all been fixed in various other FW versions.
I may do 2-3 versions again, though - sorry for that - but one would fix:

• Internal / External switch work for each mode
• Cone mode
• Ellipsis mode

And the next version would add:

• Possibility to hide display some modes like U did in the latest versions.
• Possibility to display a different color for each mode is welcome (but just a nice to have)

I wont be in the workshop today, though. Need a day off;).
I will try to have this done Mon/Tues.

[GeckoSub]

Tiny Update (no files yet)
It's raining non-stop today which means no scooter ride to the workshop. But I have made most of the code changes needed to sort out GS31 - but I do need to test it a bit in the shop before sharing it here.

If we assume people will only ever use Multistart as part of a thread mode operation, we can delete its designated button as a small change to the stock code means we can now fully enable/disable Multistart from within the regular thread mode parameters.
So, the slightly updated GS_MOD_09 screenset will now have a Dia/Rad button instead of the multistart button:

And for the coding-capable users, that button can almost be considered multifunctional. You could FW code it to do other things as the text it displays comes from the FW and is not a hardcoded image in the Nextion Editor. It would be a bit unintuitive though as the naming of the button, text boxes within it and the commands they trigger are all about "DiaRad" but it could be done if you so wish.
(Ideally, I would change it all to e.g. "universal_button" but apologies, I am not going to do that).

[GeckoSub]

Final Files

So, I did as @Bart95580 suggested and worked on GS31 according to his bug list and my own tests.
On my machine it seems everything works now.
But it may not on yours but here's the problem. I am totally worn out now and really don't want to look at this code anylonger. I also can't troubleshoot issues I can't replicate and finally, I really need to get on with some projects that can actually pay my rent.
Apologies if I am leaving anyone hanging:(

I will hand it over as is and you are more than welcome to report bugs here but it's likely that I wont be able to find the time to look into them or at least not in a timely manner. Maybe someone else can, though.
H5_NON_DRO_GS31P.zip
H5_V11_GS_MOD_09B_screenset.zip

I am actually nervous about sharing this as whilst it runs really smooth on my machine in my tests today, I also just tried a quick test with the stock H5V13 which was really unstable with my screenset, which is weird. In the past, when I have tried with Max's stock FW I feel like the only difference was missing some of my newer tweaks, not outright weirdness. Not sure what that means, hopefully it's just a wrong HW parameter messing with stuff.

Finally, I will also link to a video (long, again) showing what I changed and then going into an overall overview of the features and finally some thoughts on how to use Gemini for non-programmers - in case anyone finds something in the FW they want to change.
I mention in the video that I think I know why @Bart95580 had those issues with passes never starting or being stuck at pass 1. It looked to be a simple swap of the spindle encoder pins, but now I am not so sure. I feel like it has to be a parameter thing as I did have that issue in one iteration today and swapping the pins in the FW, seemed to be the cure. Anyways, if you have passes issues, try the encoder swap pins and if it doesn't help, I have no clue what's going on.

[Edit]
Adding a few more random notes:

• The GS31P FW does have the true/false table where you can define which modes you want actively shown on the screen
• It also has a table for setting the color of each mode, you can set them all back to grey/white or whatever else you want
• @Bart95580 mentioned how Gear mode works on his machine. It's the same on mine and I think it's the intended behaviour. I think of it as a "powerfeed" mode. Then again, I never actually tested how that mode on the Max's stock HW
• The FW has been meddled with a fair bit though I have tried my best to keep from doing huge changes but I haven't gone through it and checked if all the code comments (A)I made still make sense. Most of them should however
• As shown in the video, I did add the "set Dia" and "set Z" feature (long press on the respective coordinate box) to this FW. But it turns out that it's already in Max's FW except I can't find a way to set a positive length for his type of input. I think that's one feature that could be improved on in the code. Most intuitive would probably be to code the +/- buttons so that at the end of the input those buttons can toggle the values between positive and negative
• The logic for font changes and font color color is now back to being handled on the Nextion side (it's not in the FW). Again in an attempt to keep the FW a tad simpler but it does make making changes to this more convoluted
• Also, as mentioned in the video, the jog touch buttons are still iffy. The double/tripple tap issue seems solved in the more "departed" FW like V114, so it may be worth it for someone to compare GS31P and V114 and try to implement how V114 handles this

[Clive66]

Thanks for all your hard work. I am sure others will try your screensets and iron out any remaining bugs.

[GeckoSub]

Thanks for all your hard work. I am sure others will try your screensets and iron out any remaining bugs.

Thanks Clive,
Do feel free to post any bugs here. If it's something I recognize and it looks simple, chances are it's small fix and maybe I can find the time to look into it. If I can't, I will just say so but no harm in posting and asking:). It's just that we have gotten to a point where I couldn't replicate the worst bugs that plagued Bart so I was flying blind. And while AI does indeed work for this, it's not exactly fast.

But fingers crossed that the latest combo solves most of the bugs:)

[GeckoSub]

Adding Two More FWs: GS31S and GS31U

Not tested as much as GS31P but tried to improve two things.

GS31S makes it possible to "set dia" and "set Z" as a negative or positive value. Just hit +/- whilst in the prompt for the value before locking in the value on the green Run button. That's the only change from GS31P but I don't know if something deeper broke from this change.

GS31U "fixes" the iffy touchscreen tapping where a double or tripple increment jogging move could happen from a single touch.
The known downside is a jerky start to continous moves. Again, I don't know if anything deeper is broken.

GS31S_U.zip

And a 4min video to show the changes in effect.

[Clive66]

I have tested the firmware with a 7inch screen and all works for me except switching from external to internal thread. Is there a specific command to action this? If not I am happy to search for a fix as everthing else is fine for me.
Thanks again.

[GeckoSub]

I have tested the firmware with a 7inch screen and all works for me except switching from external to internal thread. Is there a specific command to action this? If not I am happy to search for a fix as everthing else is fine for me. Thanks again.

That's welcome news. I'm very happy and relieved to hear that:)

External/Internal
As for the external/internal toggling when being prompted for this, the left/right jog buttons should be doing the toggling. This is how it is in Max's stock FW and one of the things that should be fixed now in the latest three FWs (GS31P/S/U). Please try and let me know if it works.

Jogging Issue
Also, depending on which FW you are on, you may or may not be able to consistently single-tap-jog on the touch screen. I don't have handwheels so not sure it it's an issue on those but it's better on external buttons (at least with GS31U). As far as I understand, it's some kind of delay issue that's inherently harder to solve on the touchscreen but not so much on external, physical buttons.

Another Way To Get To A Specific Position
I had a short convo with Max in the "issues" part of the forum and he reminded me that in his stock FW you can actually use the numpad to set a specific length of move. I am not sure if my FW lost that ability - I think perhaps it's still there. But say you want to set a very precise depth of cut for a thread or turning operation. If the jogging is iffy, I guess you could move the carriage off of the part and use the "move according to numerical input" feature. From memory the way it works is that you start typing on the numpad (the controller will assume you're inputting a pitch) but instead of pressing Run (ON) after the input, you press the jog button that corresponds to the direction of the move you want to make. The machine will then make the move after which you could set the limit. That might be the simplest way to set a precise X-depth (or Z) if jogging tends to under/overshoot.

I haven't used it myself as without an X-motor, it's not that relevant to me (and my Z external jog buttons behave really nicely with no skipping or accidental double taps).
But I think, a while back, we also talked about how just switching to a finer jog increment sooner is also a safe way to creep up on a part/dimension.

[Bart95580]

Hi GeckoSub,
nice release !
a lot of improvement and bugs fixes in this version
Sorry for this late answer, but I spend a lot of time to create a custom keyboard for my lathe

Here are my first tests about this GS31U version with H5_V11_GS_MOD_09B_screenset:
Zeroing X axis => OK
Zeroing Y axis => Ok
Manual Encoder X => Ok
Manual Encoder Z => Ok
Change pitch => Ok
limits => Ok
multi pass running in all modes => Ok
Long Press on X or Z change Green/ White color => Ok

Enter numbers on screen pad => Ok

• if validate with Enter => pitch change
• if validate with left or right arrow => carriage tray move to the distance

Dia/ radius button => Ok
Short press on X or Z enable/ disable the stepper motors => Ok
Spindle running at Full speed (over 1600rpm) => Ok Display is correct
RPM/ Angle / Turn display => Ok ( and color change ok)
Incr button => Ok (with color change)
Wifi connection => Ok
Gcode web page => Ok

------ Modes --------
Cut => Ok (Internal <> External selection with right or left arrow)
GCode => seems Ok. GCode web page is displayed, but didn't test it with real gcode
Async => Ok
Gear => Ok ?? ( need may be an Y axis)
Turn => Ok
Faces => Ok (Internal <> External selection with right or left arrow)
Cut => Ok and External / Internal option works with a long press on the pitch to get negative value
Thread => Ok (except cone ratio), a negative pitch reverse the thread direction. Cone ratio don't work
Ellipsis => Ok

Cone => Don't work
cone ratio can be change (numbers on screen) but pressing "run" button or any other button reset cone ratio to 0
running Cone mode with cone ratio = 0 => screen display "ON" but nothing happen

X Axis
When I enter numbers from the screen pad for ie: 10mm, If I press the up or down arrow the cross slide move to 10mm (confirmed by my DRO), but the screen display 20mm.
I have to check if it'coming from my side or from the FW

---

So for me the remaining bugs are the X axis value displayed on the screen and the Cone ratio

May be I am doing wrong things ??

[Bart95580]

Hi GeckoSub,
nice release !
a lot of improvement and bugs fixes in this version
Sorry for this late answer, but I spend a lot of time to create a custom keyboard for my lathe

Here are my first tests about this GS31U version with H5_V11_GS_MOD_09B_screenset:
Zeroing X axis => OK
Zeroing Y axis => Ok
Manual Encoder X => Ok
Manual Encoder Z => Ok
Change pitch => Ok
limits => Ok
multi pass running in all modes => Ok
Long Press on X or Z change Green/ White color => Ok

Enter numbers on screen pad => Ok

if validate with Enter => pitch change
if validate with left or right arrow => carriage tray move to the distance
Dia/ radius button => Ok
Short press on X or Z enable/ disable the stepper motors => Ok
Spindle running at Full speed (over 1600rpm) => Ok Display is correct
RPM/ Angle / Turn display => Ok ( and color change ok)
Incr button => Ok (with color change)
Wifi connection => Ok
Gcode web page => Ok

------ Modes --------
Cut => Ok (Internal <> External selection with right or left arrow)
GCode => seems Ok. GCode web page is displayed, but didn't test it with real gcode
Async => Ok
Gear => Ok ?? ( need may be an Y axis)
Turn => Ok
Faces => Ok (Internal <> External selection with right or left arrow)
Cut => Ok and External / Internal option works with a long press on the pitch to get negative value
Thread => Ok (except cone ratio), a negative pitch reverse the thread direction. Cone ratio don't work
Ellipsis => Ok

Cone => Don't work
cone ratio can be change (numbers on screen) but pressing "run" button or any other button reset cone ratio to 0
running Cone mode with cone ratio = 0 => screen display "ON" but nothing happen

X Axis
When I enter numbers from the screen pad for ie: 10mm, If I press the up or down arrow the cross slide move to 10mm (confirmed by my DRO), but the screen display 20mm.
I have to check if it'coming from my side or from the FW

So for me the remaining bugs are the X axis value displayed on the screen and the Cone ratio

May be I am doing wrong things ??

[GeckoSub]

@Bart95580
That looks almost like great news:)

As for the double X - silly question I know, but maybe you are just in diameter mode as opposed to Rad...? I feel like it may default to Dia after a "set dia" input, not sure if it does it after a "numeric move".

As for the Cone, since I had that working just a few days back, I think I can check if something went missing in one of the last revisions. I remember setting the ratio to 0.5 and the X value did indeed half after the pass. I didn't even catch that cone in threads ever had an issue. I'll see if I can find time to check those things.

In reg. to Gear mode, the way you described it in an earlier message is the same as it works for me. It's basically just a powerfeed, I think(?). There is no auto-return nor X moves so maybe no Y, either. I think gear may just mean synced with the spindle? I don't think it's a gear-cutting/hobbing mode.

[Edit] Max has now added a bit of a manual to the main H5 page and Gear mode is described there - and I think we are OK. Here's a screenshot of his mode description:

Max does mention that you can "quickly reverse the pitch" by pressing the pitch button. Well, I made that a long press... a short press on that button toggles the font. Maybe I should swap short and long press on that function, then. I have a reverse button on my external keys so I don't actually use the touch for that but perhaps others would.

[Bart95580]

ok, U R right for the Dia / Rad button fix this.
Any possibility to keep the Dia/ Rad last settings at boot like for the Thread limits ?

[GeckoSub]

ok, U R right for the Dia / Rad button fix this. Any possibility to keep the Dia/ Rad last settings at boot like for the Thread limits ?

It may already be like that... Last time I had a memory issue, Gemini said that every 5 secs, pretty much everything gets put in the memory. But I do know that I spent a few hours a while back trying to "fix" values that I thought didn't get stored but the problem was me not waiting 5 secs before rebooting.
That said, honestly not sure if Dia/Rad parameter gets stored with everything else or it's more that it toggles itself back to Dia when inputting a value? I mean, it kinda makes sense that it goes to show a diameter mode after a "set dia" input but if you use the "numeric move" (inputting a value and then pressing the arrow) then maybe that's counterintuitive as that value would be a radial value (on the X)... Maybe that's the real issue and not so much a memory bug.
I pretty much only work in Dia mode, personally. Anyways, we will see if I get to it next time I have a look. But the most important for me is the Cone ratio fix (and cone ratio in Thread mode, too).

BTW, good luck on the keyboard. I use mine a lot:)

[GeckoSub]

Cone Mode and Memory Fixes
Cone Ratio Bug
There was a bug where you couldn't input a ratio in Cone mode nor a ratio in Thread mode. It would keep prompting you for it. I think it is fixed now. But I only did one quick test and did not test to see if anything else broke.

Also, I have no idea how cone mode is supposed to work. On my machine, I have to move it back to the right with the jog key before it starts its one and only pass - but at least it does so according to the ratio. If you revert back to the start once again with the jog key, it will do a second pass - but one step deeper according to the same ratio. But I also didn't have any X limits set which may play into it. So, the ratio is possibly fixed but I don't know how the mode is supposed to work. You can ask Max or perhaps see if any of the old H4 videos show the behavior of this mode.

Memory (Dia/Rad)
@Bart95580 also noticed Dia/Rad may not always be intuitive. Here's how it seems it worked before. It would have no "state memory" saved and would always boot up in Diameter mode. I made two FWs this time. They both (hopefully) fix the cone ratio bug but they differ in how much is changed for the Dia/Rad memory fix.

GS31V: Cone ratio fixed(?). Dia/Rad now boots as Rad as default (you can change this in line 1030 by a simple true/false change).

GS31X: Cone ratio fixed(same code as above). Dia/Rad now gets written into the memory so should boot up as you last used it (memory is supposedly written every 5 secs so don't reboot too fast if you want to test this). But this FW also fixed a small bug where the X value wasn't stored whilst the Z was - they both are now. Slightly bigger code change than above.

Why two FWs this time?
I have no idea how you guys reflash and if it's a lot of work to input all your own parameters or if it's just an easy C+P of that section? If it's tedious work, then GS31V only changes the whole of "Section 13" plus the number 1030 line so you could just copy paste those two changes from GS31V into your GS31U FW and you should have cone mode fixed and half a memory fix.

But if it's easy enough to change all your personal parameters, then GS31X should have slightly better memory logic.

H5_NON_DRO_GS31V.zip
H5_NON_DRO_GS31X.zip

[Clive66]

Thanks for this update. Which version of the 7 inch .tft should we be using?

[Bart95580]

Hi,
I tested the GS31X version.

• Cone ratio ==> Ok
• Cone mode => not working ??? I am not sure but I think it was working the first test I did with the G31X release. ( something stored in memory ??)
• rad / Dia= > Ok

A little bug which is not critical remains : when I press the Down arrow, the mode change to "Cut". This bug was already there on the "GS31U" version

[GeckoSub]

Hi, I tested the GS31X version.

• Cone ratio ==> Ok
• Cone mode => not working ??? I am not sure but I think it was working the first test I did with the G31X release. ( something stored in memory ??)
• rad / Dia= > Ok

A little bug which is not critical remains : when I press the Down arrow, the mode change to "Cut". This bug was already there on the "GS31U" version

OK, I think I can check that out in a day or two.

@kachurovskiy sorry to bother you here but could you briefly explain what the Cone mode's normal behaviour is as I am flying a bit blind in terms of my trouble shooting on this one.

When I last tested it on my custom FW, Cone mode doesn't prompt for passes so it would only take one pass according to the ratio. Say, I had set Z-limits 10mm apart and set a ratio of 0.1 it would take one pass and end at 1mm depth. And no auto reverse along the Z for a new pass - I would have to do that with the jog buttons. But when it got back to the start Z it would auto-start the next pass and then end up at 2mm depth. I think this could be the actual normal behaviour according to your writeup of the modes?
But I don't get the part about how to do multiple depth of cuts? In the example above how would I divide that 1mm deep cut into, say, 5 passes so that it would only take a 0.2mm "stepover" on each pass?

[kachurovskiy]

@GeckoSub cone is not a pass mode. It just makes the tool travel in the cone pattern according to pitch, spindle rotation and limits. It doesn't keep the cutter in-thread if the motion is interrupted for any reason (there's no SYN for cone). https://github.com/kachurovskiy/nanoels/tree/main/h5#cone

[GeckoSub]

@GeckoSub cone is not a pass mode. It just makes the tool travel in the cone pattern according to pitch, spindle rotation and limits. It doesn't keep the cutter in-thread if the motion is interrupted for any reason (there's no SYN for cone). https://github.com/kachurovskiy/nanoels/tree/main/h5#cone

Thanks Max. I think it may work as intended in my bastard FW then. I did read the manual, however I was still not sure about how to make multiple cuts to a set depth. I think I got it now, though.

Hi, I tested the GS31X version.

• Cone ratio ==> Ok
• Cone mode => not working ??? I am not sure but I think it was working the first test I did with the G31X release. ( something stored in memory ??)
• rad / Dia= > Ok

A little bug which is not critical remains : when I press the Down arrow, the mode change to "Cut". This bug was already there on the "GS31U" version

Hi @Bart95580.
Unfortunately, I can't replicate any of your issues.

Down Button Triggers A Mode Change To Cut
Whenever I use the down arrow it only ever moves the X. Then again, I don't have an X-motor. But Gemini says there's nothing in the code that would make the down button change modes. If this is an external, physical button that does it, it's probably a pin issue. It could be that you have it wired to pin 10 which in the FW triggers a mode change.

As for Cone mode, see Max's reply above. It seems to be a fairly simple mode and yet, I am still not 100% sure how it works but I feel like it works as intended on my machine. It takes cuts according to the ratio and the pass can be reversed with the pitch reverse (neg/pos) button - and you can "rewind" with the arrow. That's how it behaves on mine. I wont be able to find the time to load Max's stock tft and FW so can't check it there. Also, it seems that to take multiple passes the way to do it would be to increment along the X for each pass. So, I imagine the most important is to make sure your "X-offset" for the very first cut is so far from the part that you don't end up taking a huge cut as you get towards the end of the taper. And then after that first cut, you would increment in towards the part with the X-jog button having made sure to change to a small increment step first. At least this is how I imagine this mode is meant to be used.

BUT speaking of reversing the pitch, we actually lost that ability and I didn't even notice until testing the above. So, I fixed that and also added back the change to red when the pitch is negative. I also swapped the logic for short and long press so the short press now does the neg/pos toggle and long press cycles through the three different fonts for the pitch display box.
I did however leave out the forced font change when choosing an imperial unit. The user can do that and it will get stored in the memory after that (I think).

(Go here for the files or scroll down to the post with the V32A FW and 09C screenset )

[GeckoSub]

@Clive66
Use the 9B in this post: #345 (comment)
As for A/B versions, the only difference is that one is upside down. Start with the A version and if it's upside down, the B should work.

[GeckoSub]

@Clive66 Use the 9B in this post: #345 (comment) As for A/B versions, the only difference is that one is upside down. Start with the A version and if it's upside down, the B should work.

Apologies, had to make a new FW but it necessitated a new screenset, too:(. Hopefully, you still have the new display on the bench and it wont be too much hassle to change it to 09C attached to the post below.

[Clive66]

Hi GeckoSub. I have got the bug now and want to play around with the Nextion editor. The 09C screenset contains an HMI files but it appears to be in the format for a 5 inch display. Could you possibly share a 7inch HMI file if you have one. It would save me a lot work.
If not no worries and thanks for all the contributions to the project.

[GeckoSub]

Hi GeckoSub. I have got the bug now and want to play around with the Nextion editor. The 09C screenset contains an HMI files but it appears to be in the format for a 5 inch display. Could you possibly share a 7inch HMI file if you have one. It would save me a lot work. If not no worries and thanks for all the contributions to the project.

No worries, it's all in the post further down.

[GeckoSub]

Sorry, but new Screenset File and FW...
@Bart95580 reported a persistent issue with Cone mode and some weird jog arrow behaviour a few posts above but I couldn't replicate them.

But whilst trouble shooting I realized we had lost the ability to toggle the pitch to a negative one. So, I went about fixing that. It used to be on long press of the pitch box whilst short pressing would cycle through three different fonts. But it makes more sense to have the pos/neg toggle on a short press as it also works as a reverse in some modes (e.g. Cone Mode).
But the long press was handled by the Nextion and I really don't want to have to deal with any code changes in the Nextion (as the AI sucks pretty badly at the Nextion side of things). So, I had to move that to the FW which means, I had to make a new screenset file. Apologies, but there's a 99% chance this will be the last time I will bother with the Nextion, so please bear with me and use the 09C tft version attached here.

Also, FW-wise, besides fixing the missing pos/neg toggling I added back the color change so a negative pitch shows in red again. And finally, I found another small memory bug where a pitch wouldn't get stored unless you cycled the mode before rebooting. That should be fixed now, too. But as always, the "global memory" only gets written to every 5 secs so make sure you don't reboot sooner than that if you want to test it.

Speaking of testing, I think I am out now. If this latest FW (32A) is a step backwards I have to ask you to go back to the latest one that you felt was the best and try to fix whatever is missing. I made it pretty far with AI, so I am fairly sure you guys can fix the last little things.

H5_NON_DRO_GS32A.zip
H5_V11_GS_MOD_09C.zip

[Bart95580]

Don't spend time one the jog arrow behavior. Due to multiple tests between release and my customization, the fault was on my side

[GeckoSub]

Parting Thoughts on Working With Gemini (AI)

As you guys know, this custom FW was all done with AI. In this post, I will share how I went about it.
Supposedly for people who already know a bit about coding Cursor and Claude are the better tools for this but I wouldn't know.

I started with ChatGPT and it was a lot of hit or miss. A lot of compiling errors. I'd say 80-90% of its proposed changes wouldn't compile and it would forget "house rules" I set for it over and over again. And it would be incredibly cocky and self-assured which made it even more frustrating. Max suggested me to try Gemini (Pro) and this is what I have been using the most. Compiling wise, I'd say Gemini gets it right on the first try +80% of the time and when it doesn't, I C+P the compiling error back to it and then it gets it right within 1-2 tries after that. Oh, ChatGPT is way faster at replying, it starts "talking" instantly after a prompt. Gemini is a whole lot slower but the quality of its replies makes up for it.

I think the main advantage for a non-coder (besides being better at coding) is that Gemini can handle full file uploads. So, I could upload Max's stock file (or one of my own) as a baseline and then tell it what features I needed implemented. ChatGPT couldn't handle a full file.
A few times, Gemini has tried to send back a whole ino file - but never succeeded. So, that's why you see that my FW was divided up into sections. So, what I do now is ask Gemini to send me the whole section replacements incl. the bookending comments. So, it's a lot of C+P of easy-to-recognize sections instead of having to find specific lines of code.
I have also had luck sending it two full FWs and being very specific about exacly which features I wanted "ported over" from one to the other.

I will add some pointers in no particular order:

• Be very precise with your diagnosis of bugs. The more info and the more precise it is, the easier it is for Gemini to pinpoint the code issue.
• Small thing but often, when Gemini quotes line numbers they don't relate at all to what's in Arduino IDE though lately, that's improving
• Gemini can get stuck in its own little loop where it's out of sync and seems to be "behind". So, it will start trying to fix stuff that was already fixed and it will send changes that you already implemented. The only fix I have found is to start a new chat completely. I feel like there is more of a risk of this happening if I have given it quite a few files. I even had it stuck in a crazy stubborn loop where it kept insisting it was working from the file I had told it to whereas obviously it wasn't. It would quote lines of code as being in that file that surely wasn't there. Starting a new chat solved it but I wish I had noticed it sooner. Point being, if you feel like it's off or out of sync, just start a new chat.
• Also, once in a while it seems like Gemini starts thinking it knows what you want. So, it can start overreaching with its changes or assuming you'd want something changed that you didn't ask for. If that happens, you can tell it not to assume - or if it's too bad, you can start a new chat.
• Save FW versions often. You never know when you break something and if you have to revert back, it's nice to have more itirations
• I start every new chat with some house rules which makes everything easier going forward. Here they are:

HOUSE RULES:

• Never assume you know what I want changed
• Keep changes to one small step at a time
• Never try to send a full INO file back
• Whenever possible send full sections as replacements, incl. the bookending comments already present in the code
• Do not send code unless told to do so
• Keep replies minimal so as to not clog the chat

As for the "do not send code unless told to do so" it's because sometimes Gemini can start sending a ton of code in many different messages but I'd like it to first explain what it thinks the issue is (which it will do automatically) and then I can see if we are on the same page before we waste data and "page space".

I think these are the things I learned. Pretty basic but thought I'd share them nonetheless.

[Bart95580]

Hello GeckoSub, honestly, I'm impressed with the code you delivered with Gemini Pro.
I will have a look on the latest release U published today, but I think the non-DRO version is quite fine now.
On my side, I have finished setting up my personal PS/2 keyboard for the H5 (except may be for a futur joystick).
My next steps are to check that the machining modes actually work with a piece of metal and that the precision is good. My first tests show that on a 200mm Z travel I have a difference of 0.005mm between the H5 and my DRO. I can't tell if the error is on the H5 side or the DRO side :-)
For the X side, I'm a bit more cautious...

(picture of my keyboard similar to yours).

[GeckoSub]

Hi @Bart95580
The keyboard looks good:). Multicolor FDM printing for the keys, I assume?

Sadly, another thing I wont get around to would be to make a screenset without the numbers on it. I thought I would do it as I also have numbers on my "double duty" keypad and getting rid of the numbers on screen means we could make other items bigger. But a new screenset without numbers would mean going all the way back to the photoshop files, getting rid of the numbers and enlarging and moving everything else around. I guess you could take it even further and remove the jog keys, too or pretty much everything that's on the keyboard once it's proven itself. That would leave a lot of space to enlarge the remaining things - which might be welcome on the 5'' displays.
But if someone is more OK with doing graphic work than code, then it's actually very doable - and no changes in FW code or Nextion logic would even be needed. It would just be a new tft file.

ELS vs DRO
As for the discrepancy between the scales and ELS, I think it can be two things. Either the leadscrew is not cut with a perfect pitch or the scale is not calibrated perfectly but personally, I'd be quite happy with 0.005mm over 200mm. (I guess, it could also be the leadscrew not being fully parallel).
If you have a test dial indicator and 1-2-3 (25-50-75) block (or something else of precise, known length) you can check the DRO.
I did that for my DRO FW and had to add a compensation in the FW as (not surprisingly), I hadn't managed to mount the linear scales 100% true/level/parallel. Actually, knowing it would be almost impossible to mount it perfectly, I didn't really try that hard. My Z was out by 0.1mm over 200mm but the X was out by what amounted to to a staggering 0.48mm over the same distance. But it was an easy fix in the FW. As long as the scales aren't bowed or bent, I guess it's just a cosine error so with the compensation, I should be getting "perfect" readings now.

[Bart95580]

When I started with the H5, I didn't have a keyboard, and your custom firmware promised to do everything from the touchscreen. I think it's important to keep that functionality. But the ability to remove the numbers for better visibility or for new functions is an excellent idea.
I don't know the Nextion screen in detail, but is it possible to create a copy of "page 0" as "page 1", to remove the numbers on that page, and add a variable for page 0 or page 1 in the firmware?
This would allow users to keep the screen selection option in the firmware.

[GeckoSub]

When I started with the H5, I didn't have a keyboard, and your custom firmware promised to do everything from the touchscreen. I think it's important to keep that functionality. But the ability to remove the numbers for better visibility or for new functions is an excellent idea. I don't know the Nextion screen in detail, but is it possible to create a copy of "page 0" as "page 1", to remove the numbers on that page, and add a variable for page 0 or page 1 in the firmware? This would allow users to keep the screen selection option in the firmware.

I think the two page option is a nice idea, especially the part about keeping both options within the same screenset and I am pretty sure it's possible.
Sadly, I wont be able to find the time to implement this. The redesign for the second Nextion page image alone would take a while, though the swap/selection would likely only be a few lines of code (more on this below). I mean, if you only want to remove the numbers that's easy, but it would make sense to enlarge all the other remaining buttons/readouts and that takes a bit of time to do and make it look pretty and then once the image has been imported into Nextion Editor, you need to realign all the button and text frames there too. I mean, it's maybe doable in half a day so it's not too bad. I am just slammed with other stuff these days but it's nice idea.

I thought about it a bit more. I think the way to do the graphic part and nextion button alignment would be like this:

• Make the image for the new page in Photoshop/Photopea/etc and import as a PNG into Nextion Editor
• Also see my long post to Clive below about working Nextion. Especially the part about how I use two pages to enable the buttons to light up on presses. So, each main page would actually have a sub-page just for this.
• In Nextion, copy the old main page (this makes sure that all the button logic like ID Hex codes and the names of text boxes is the same on the new page which the FW will need)
• On the new page, change out the image to the new image (p0 under attributes)
• Delete all the Nextion buttons (boxes) that are no longer present on the new image/page (or drag them off the canvas)
• Resize and realign the remaining ones and go into each button's attributes and set its PICC and PICC2 to match the new image and the new light-up image. If you don't need the lightup-on-touch, then set PICC2 to the same as PICC or perhaps change "sta" from "crop image" to "transparency"

As for the swap code, it can likely be done from the Nextion side only. I recall from early on when I was trying to put in a second page with a thread pitch table and a third for a calculator that you can have some simple code that switches pages (via a button press) on the Nextion. Or you could possibly make a very simple landing page with two simple buttons for each of the main pages you want to be able to choose from. But I think the ESP/FW can also switch pages.
Max has a new screen and FW where Mode selection happens on a second page but I didn't check if the swap happens in FW or in the Nextion.

Oh, Gemini agrees that it's possible and even easy to just choose which page to start up on via a true/false statement in the FW. The downside of that, of course, would be that you need a reflash to change the page.
Come to think about it, we still have some buttons that don't have any long press logic, so the better way to do it would be to make a long press on one of those flip the page...;)

One more "oh". Gemini does say we'd run into a "data trap" issue where the display update functions would not yet work on the new page as the code uses the static page name for this, it seems. So, it proposes a change to make the name a "string variable" so the display updates are "dynamic". It seems like it thinks it's an easy change. So, even if you make the Nextion deal with the swap, you'd probably still need to change the FW a bit to deal with the different page names. Also, it proposed a forced refresh in the code right after a page toggle so that all boxes get populated right away with the correct values.

[GeckoSub]

Hi GeckoSub. I have got the bug now and want to play around with the Nextion editor. The 09C screenset contains an HMI files but it appears to be in the format for a 5 inch display. Could you possibly share a 7inch HMI file if you have one. It would save me a lot work. If not no worries and thanks for all the contributions to the project.

Hi @Clive66
That's cool to hear:)
I'll share some thoughts, tricks and files that might help you get started. Feel free to ask questions if you run into problems.

NEXTION EDITOR - TRICKS AND TIPS

Setting Up The HMI For Your Particular Screen
As for the HMI file, it's actually universal and will work for many series and sizes of screens but you do have to set it up for your particular screen. You should be looking for "Device" in the bar towards the top of the screen and to the right.

The 7'' is probably on the right hand side, perhaps in the middle-right:

And then from the "display" option on the left of that same pop-up, you pick the orientation. 180-horizontal works for the 7'' screen if you have it mounted with the SD card slot facing downwards. Otherwise, pick 0 degrees.

Getting the TFT File Onto Your Screen - The Simple Way
After having set up the "Device" and the orientation, you can go to the "TFT File Output" (or similar) in the File drop down menu to the left and move the file to the SD card and you know the drill from there.

Getting the TFT File Onto Your Screen - The Complicated Way
If you really want to muck around a whole lot, consider getting a USBTTL adapter, they are cheap and with one of them, you can flash the screen with a cable directly from the PC. But it does mean you'll have to unplug the TXRX cable each time. I got around that by putting in a DPDT switch so I can switch the signal between the ESP and the USBTTL adapter. Sadly, I haven't been able to find a way where we can use the ESP as the adapter and "flash through" the ESP - which would be really nice. But actually, if you think you will only do a few itirations of the screenset, flashing via a memory card is still fine. For me, the switch and adapter was a benefit because I did so many versions of the screenset and also once it forked out into "yours" vs. my own, I often had to reflash the Nextion to better check the bugs on the "communty FW". Also, I couldn't access the SD card slot once the Nextion was mounted in the panel as it has the buttons under it - which may be a good enough reason to actually mount it with the slot facing up...

Using Images In The Nextion Editor
The way the Nextion screensets tend to be made is with static images as a base. My screenset has two but the second one is just a brighter version of the first one. That's how I get the buttons to light up on presses - the button switches to the lighter copy of the image as you press and then switches back to the darker base when you let go. As for the light up function, Max does it a different way. From memory, he doesn't switch to a brighter image but instead he defines a brighter color for the button press. It's simpler but e.g. if you want the actually touch area to be larger than the button itself, which I do in some cases, it doesn't look as clean.

As for how to make that second brighter image, I guess there are many ways to do it. I think what I did was to take the main page, flatten it, then just use the Magic Wand to select the boxes (feather set to 0) needing "brightening" and then change the exposure. You can do them all in one go by clicking outside of a box and just inverting the selection. Or if you want some brightened more than others, just pick the buttons that have the same color.

But the use of images for the buttons means you can't just move buttons around or resize them - you'd have to edit or make a new image file. Also, some text and icons are actually part of the image - e.g. limits and arrows, so you can't move those icons either without editing the image. You can do that in Photoshop or the free browser-based Photopea.

Here are the two psd image files for the screenset image. If you work on them, you have to flatten them and export as PNG before importing them into Nextion Editor:
screenset_images.zip
I made my images in the screen's native 800x480 pixels. But I thought of future-proofing it for higher res screens and then down-res'ing just before export, but I forgot why I didn't go that way. I think perhaps at the time, no one had started working with higher res screens than the Nextion.

How Nextion Buttons Work
Let's see if I can explain this in manner that makes sense:). It will sound complicated but will make sense once you're a bit more familiar with the Editor.

The way Nextion buttons work is that they send an ID number when pressed. The FW sees this number and then there's a table which governs what gets triggered. Search for "HEX" in the V32A FW and the table should show up (somewhere around line 3623)
E.g. ID 4 triggers B_MODE which is a mode change.
And ID 49 is B_RIGHT which is a jog to the right (right arrow). Now, I somehow lost my comments in this table that better explains what each button does but I will attach a file that shows it.

Now, here's where it gets "interesting". Max's screenset and FW uses a bit of a shortcut as each button/text box uses the "Content ID" function where Nextion auto-assigns the ID numbers consecutively as you add buttons during the design phase. BUT if you delete a button, the buttons created later than the deleted button will be moved up ID-wise - and these buttons will now send a different number and thus will no longer do what the FW expects them them to do. I think the same can happen if you move a button up and down the order (though that's not even that easy to do on in the Editor).

The way around this is to not use "Content ID" but hard-code each button in the Editor to send an exact ID number of your choosing - which is how my whole screenset is made. You basically insert one line of code (more on this later) in the button event in the Editor and the button will send the ID you "told it to" rather than what was auto-assigned to it. A nice bonus is that it ends up making the HMI file more robust as you can delete and make new buttons without messing up any other buttons.
To make this work, remember to untick the "Content ID" box for each button.

As for the "line of code" that you need to insert for each button, it's bascially just the ID number but in a hex format wrapped in some Nextion specific format and a "printh" command to actually make it send to the ESP32.
So, to go back to the ID 4 example for a mode change, you will see in my HMI file under the mode button's Touch Press Event attribute that it will have this line:
printh 65 00 04 01 FF FF FF which sends the number 4 to the ESP and thus everything will work as intended.

(The file I mentioned that I will add to this post, will include all these IDs-To-Hexes, so you can copy-paste from it you need to. It also has comments explaining what each Button/ID does.)

Long Press Functionality
Now, one more thing. If you want a long press funtion on a button, you need to also insert the printh hex in the Touch Release Event box but with one slight change. That last "01" before the "FF FF FF" should be a "00".

In this example, the left screenshot shows the plus (+) button's short press logic sending an ID of 42 but notice the 01 at the end. And the right screenshot is the long press with the 00 at the end:

The majority of the buttons in my screenset have both the 01 in the touch press attribute and 00 in the touch release - this means that you can add a long press function to them in the FW if needed. Except, the number buttons (numpad) and a few others don't have anything in the "release attribute" so they will only work for short press logic as it is now.

Fonts - Hmm....
Fonts are not intuitive at all. For each font you want to use or even change the size of, you have to compile/generate it from within Nextion in the size you want and then under the attributes for the particular text box you set the font number that corresponds to the one you just generated. That's why you see I have a ton of fonts listed.
To make a font, go to Tools-> Font Generator and then pick the font and size. BUT make sure that under "range" you don't pick "all characters" as it will take forever to generate and the whole TFT file will also get bloated and take longer to uplad. If you choose ASCII it should get you what you need and be much smaller and faster. Once compiled/generated the font will show up in the lower left hand window as long as you have the Font tab active under that same window. That's also where you can see what number was assigned to that new font and then you use that number in the attribute box under "font". But again, Nextion is too smart for it's own good as if you move the font up or down in the font windown (lower left) other fonts will likely changes numbers - but I don't think the attribute window will update accordingly. So, fonts in other windows may change since "their" font changed number. Or maybe it does resync, can't recall, but keep an eye on it or just refrain from moving new fonts up in order (using the arrows in the font window) - that way, older fonts will keep their number.
Actually, the more I think about it, maybe Nextion does indeed resync other fonts to their new numbers BUT if we have logic in the FW that relies on specific font numbers, then that will break (and we do have that for the pitch font change feature).

Other Quirks
I wish my memory was better, but sadly it isn't. So often when I find a solution, I forget what it was.
I especially had some challenges getting certain buttons to light up when pressed. Even with the second brighter image, it doesn't always work. I think it had to do with whether the button was a touch button with a text box in it or just a pure touch button. I think almost all of them light up now, except for the mode change and then mm/in/TPI (units) change. And Gemini is not much help as it doesn't know Nextion well enough.

Every time you hit Compile or Debug, I think Nextion auto-saves which caught me out a few times if I had made a change that didn't work. Also, the undo function doesn't always catch all your changes so sometimes, you can't easily revert back (so, perhaps save often). But that was more of an issue early on when I was trying to have more long-press, color-change, font-change logic work within the Nextion as the logic breaks easier whereas regular button "work" is hard to mess up.
That said, the Debug function is quite good as it opens a simulator window so you can check that button presses work and actually sends code or light up, if you want that.

Here's the Hex table I mentioned, two different formats, the bat. file should open nicely in Visual Studio Code:
Hex Table for Nextion Buttons.zip

Finally, this tutorial on Youtube helped me a lot to get started despite the "subject matter" being quite different and him using a lot of features of the Nextion that I am not. But e.g. I learned about the fonts and TFT cable upload from him and surely some more.

[GeckoSub]

Everything makes sense now, thanks for explaining.!

You're welcome:)
BTW, since you asked about "multiple images" - you can actually see the images used in the screenset in the window on the lower left. Same place where you can find the list of generated fonts. This is also where you would import a new image to. Or, replace an image with an edited version of that image - which is perhaps the most efficient way of doing it as then all the text and button components should still be on that new image.

[Bart95580]

Hi GeckoSub,
few comments...

• now I use your 32A version and it sounds good to me.

Thank U for sharing the informations and the tutorial about Nextion editor.
Based on these informations, I made a fork of your 9C.hmi file and I added 2 additional screens.
Here are the key points...

• The first screen is just memo about threads (not finished), the second one is a Cone ratio calculator (the calculator don't use any call to the ino file).
• I use a special key on my keyboard to switch in a loop between the screens: Main_page, page1, page2... Main-page, ect...
• Few lines are added to the ino file to handle the screen switch.
• Each time we switch from a screen to another one all the variables are reset, so for the Main_page I changed most of variables range from "local" to "global". This change allow me to keep the values of the main_page after some screen switch.
• The Cone mode use the "Reverse pitch" a lot, so I replaced the Dia/Rad button by the Reverse one on my custom keyboard.

[GeckoSub]

Hi GeckoSub, few comments...

• now I use your 32A version and it sounds good to me.

Thank U for sharing the informations and the tutorial about Nextion editor. Based on these informations, I made a fork of your 9C.hmi file and I added 2 additional screens. Here are the key points...

• The first screen is just memo about threads (not finished), the second one is a Cone ratio calculator (the calculator don't use any call to the ino file).
• I use a special key on my keyboard to switch in a loop between the screens: Main_page, page1, page2... Main-page, ect...
• Few lines are added to the ino file to handle the screen switch.
• Each time we switch from a screen to another one all the variables are reset, so for the Main_page I changed most of variables range from "local" to "global". This change allow me to keep the values of the main_page after some screen switch.
• The Cone mode use the "Reverse pitch" a lot, so I replaced the Dia/Rad button by the Reverse one on my custom keyboard.

Nice! Well done:)
I really like that cone page - I always thought multiple pages could be used for something exactly like this - graphic clues to how the mode parameter works. I have seen something very similar in some screensets for LinuxCNC and it's also a feature on some/many modern CNC controllers:). Well done again, we should make sure @kachurovskiy sees this for inspiration or merging:)

I did have an image/png for a thread table too long ago - but didn't know enough at the time to make it work. The png is actually present in some of the older HMI files but not "active" so I removed it from the latest HMI. I guess I should have left it in as it would have meant a less work for you. You may still find it if you go back a version or two in my HMIs and look in the bottom left window in the Editor.
Anyhow, the local vs. global setting and page swtiching is that all handled fully on the Nextion side?

[Bart95580]

Yes, Local to Global variables and calculation are fully handled on the Nextion side.
Nextion does not support float variables, so the calculation was a little bit tricky. :-)
The page switch is handled on the ino code side. It's few lines of code (switch, case, break... ) I added in my parameters.h file.
... and added the following code to the main ino file just before the end of section 16

// ****************** PASCAL switch screen number *************
else if (keyCode == B_SCREEN) {
pageSelection();
}
}_
// =================================================================
// Geckosub + Gemini 2.5 Pro - END OF SECTION 16
// =================================================================

When back from vacation, I am going to finish the thread calculation page

[Bart95580]

Here is the full change

line added in my keyboard.h (included in my parameters.h)

#define B_SCREEN 122 // change screen

Code added

// *********** PASCAL ( in parameters.h ) *******************
char* pagename= "page_main";  // first page to display by default
int seqpage = 0;              // sequential number
**void pageSelection()**
{
   switch (seqpage){
     case 0:  // page_main
       {
        pagename="page1";      
        Serial1.print("page ");
        Serial1.print(pagename);
        Serial1.write(0xFF); // fin de commande
        Serial1.write(0xFF);
        Serial1.write(0xFF);
        seqpage = 1;
        break;
       } 
     case 2 :  // page2
       {
        pagename="page_main";
        Serial1.print("page ");
        Serial1.print(pagename);
        Serial1.write(0xFF); // fin de commande
        Serial1.write(0xFF);
        Serial1.write(0xFF);
        seqpage = 0;
        break;
       }  
     case 1:   // page1
       {
        pagename="page2"; 
        Serial1.print("page ");
        Serial1.print(pagename);
        Serial1.write(0xFF); // fin de commande
        Serial1.write(0xFF);
        Serial1.write(0xFF);
        seqpage = 2;
        break;
       }
   }

[troiac]

I uploaded h5.ino to the ESP32 board and h5.tft file to the SD card.
But all the display shows me is the initial screen.
The first version of FW worked for me when there were only the letters X axis and Y axis etc. Since I try to upload a new FW and a tft file with buttons, the display only shows the initial text. When I insert the SD card with the tft file into the display, nothing happens, no loading or notification that the loading was successful or unsuccessful.
Where am I making a mistake? Previously, I uploaded the old FW there normally on the first attempt.
The FW is uploaded to the ESP32 normally.

[GeckoSub]

Hi,
Is this for the custom screenset (tft) and FW that I worked on?
The screen you are showing looks like Max's very first H5 tft file (I think).

If you are trying to load my custom files, then I am not sure what's going on. The only thing I can think of is that you may accidentally have picked the wrong file for your screen? I packaged both 5'' and 7'' versions. But I haven't checked whether the 5'' versions are working - they should be, a few others have used them (I don't have a 5'' screen myself).

Also, are you using the same SD card as when you first succeeded? The Nextions don't like large SD cards. So, if you are using a bigger one now, that may be why.

[troiac]

Yes, it's the first Max H5 tft file.
I couldn't upload any other ones there even though I used several SD cards.
I have a 5" screen and I've always used the file for the 5" screen.
Please upload the two files [ino and tft ] for the 5" screen here.
The ones that work on your device.
Thank you.

[GeckoSub]

Yes, it's the first Max H5 tft file. I couldn't upload any other ones there even though I used several SD cards. I have a 5" screen and I've always used the file for the 5" screen. Please upload the two files [ino and tft ] for the 5" screen here. The ones that work on your device. Thank you.

Hello again,
I don't think it makes any sense for me to upload my personal version - It doesn't have an X-motor but it has scale inputs. So, that's likely not the version you want.
The latest "working" version with both X/Y and no scales is in this post above already.
If that one doesn't work, consider scrolling upwards in the thread to an earlier version.

But here's the catch: It's unlikely that I will be working on this project anylonger and since my memory is pretty shot, I no longer really recall what changes were made where and what the bugs are - which is also why this thread is so wordy as I treat it like a build log or diary of sorts.
Anyhow, I think those files are what Bart is using and it's supposedly working well.

And then you may or may not want to add Bart's later changes. It also looks like he is on a 5'' screen so those files should work.

As for your SD card, I am still not sure what's going on. If you made it work once, it should be working with my files and Max's newer ones, too. I only used SD cards early on and then switched to using a cable adapter. I guess you have to make sure you put the file at the root and that no other files are there?
Supposedly, the Nextion can only flash from cards that are no bigger than 32GB, but I made it work with a bigger one by partitioning it like explained here. Don't know if that's of any help.

[tirex2012]

Hi, GeckoSub, I'm using your mod H5_NON_DRO_GS32A and am very pleased, but I'd like to point out that the part diameter preset is still unusable because it's counting in the wrong direction. So, as the tool moves forward along the X-axis, the part diameter decreases, but increases on the screen. Is it possible to fix this? Best regards!

[tirex2012]

OК

[tirex2012]

Now it works as it should.

[GeckoSub]

Thanks @tirex2012 !
I didn't find the time to look into this today as I would need to reflash the ESP and possibly the screen too and had too much other stuff I needed to deal with. And then go beg the AI to figure it out, haha.

Happy you made it work, that's cool!:)

[Bart95580]

just tried your fix.
It seems to work as expected
Thank you very much

[andreev-]

привет, еще раз спасибо за проделанную работу над дизайном, при изменении левого лимита на цифровое значение с клавиатуры оно не выставляется , может это связано в прошивке с долгим нажатием для удаления всех значений?