Like, you can change it on the fly in the settings menu? That would be neat.
We always do that G92 thing. This makes me think that we should be doing this with M851, but I think it is reasonable to do this configuration for us. I’ll see how quick I can add that. I might also check out the machine settings first, which would give us a chance to change it from the screen itself.
Toggling it in the “features” menu was easy enough. “Machine” seems like it is really focused on the settings in Marlin. The only trouble is that the CNC mode requires resetting the whole LCD. The laser mode works right away. I think if I looked closely at the way the infoMenu is initialized, I could figure out how to fix that.
I fixed the homing menu, and I also removed that M18. Those changes were pushed.
I would like to come up with a better debugging tool. I am wondering if I can use the Marlin mock machine to interact with this over UART.
I gave it a shot adding the touch plate enabled and G92 Z offset being set in the config.ini. Enabling the touchplate option works, however the offset doesn’t carry over past a reboot. Like it’s not getting stored in flash. A new config.ini at boot works again. I even changed the #define PARA_SIGN value thinking that maybe it just wasn’t overwriting the current flash values. Calling it a night. Hopefully someone smarter than I am can get it across the finish line. To get it back working again, I have a configuration.h define with the proper offset for the V1 touch plate.
Here’s a link to the branch I was working in.
That’s awesome!
I think I know what got you… Let me just test it out… Why does it take so long to update this font…
When it stores values, it converts them to unsigned ints. Then converts it back to a floating point (without telling us). So a 0.5 turns into a 0, which gets turned into a 0.0.
I just changed it to multiply it by 1000 before storing it, and then dividing it by 1000 when it reads it in. I could keep it as an int the whole time, but we’d need to convert it to a double before sending it anyway, so we might as well leave it as a double.
I’m just going to merge your commits into my branch, and then fix it there. But it does work. Hooray!
I’ve been dorking around with trying to see what is going on in the serial port more definitively than watching the controller I have on my desk. So I connected the screen to an FTDI, and wrote a little python script to respond to a few messages and print what the screen is saying. IDK what to do with it, so I made it a gist, in case one of you were interested in poking around with it.
Yes, I did. I don’t think you would be interested in it though because I hacked it about to do what I wanted and in doing so would have destroyed other functionality that I am sure you would want to keep intact, I never expected others would be interested. I can’t upload the source here…too big…so I’ve put it on my google drive and shared it.
@dart1280, Thanks. Since I know you edited it from Loki’s code, I can easily tell what you changed, and I know this code well enough now to try to see what you were doing. These are the things I think you changed:
There is clearly a lot of thought and care put into these changes. They come from a good base of testing and experience trying to use this to get things done. Sorry if any of my comments are curt. I am really thankful for you sharing your changes.
Most of these I can fit in easily, some will be a bit of work. Some of them might be done better in a different way, so if you want to explain some of the changes, I can better incorporate these into this version of the screen.
The more I look at this code, the more I realize it is going to be an enormous challenge to get this merged upstream. The more we work on it, the more the cnc_mode menus look different than the classic or unified menus. One of the biggest labor sinks in that process is just going to be getting the icons in all the different sizes, and if we wanted to, the different languages…
I forget now where it is, but I put the M105 query to a 20 minute polling frequency as a workaround. It will connect fine with that settings and you essentially eliminate that pesky M105 noise on the gcode screen.
I saw that same change in Dart’s code. It seems good, but if you miss that very first message, or you need to change the baud rate, it will say “no printer connected” for 20 minutes, or until you reset the board. There must be another good message to confirm that the printer is connected. Or even better, just fix M105 so it actually parses the message from a machine with EXTRUDERS=0.
What kind of controllers are you all using? Anyone using grbl? What about on Marlin, what boards and configurations are you using? I would like to support as much as possible, but I will be targeting the Skr pro first, and then the rambo, because that’s really common here, and for the most part, people with other boards know enough to manage it themselves. But I have a grbl board on my LR, so I wouldn’t mind getting that to work if it isn’t too hard. M106/M107 stuff makes me think you are all running Marlin.
Sorry, a small tangent but you all seem better at this than me.
For the screen firmware, and board firmware…is there any reason I should not allow the compiled .bin files to be synced from the gitnore file? I am thinking I can make any changes, compile and sync/push everything to github. That would allow me to directly link things from the Docs and not have to compile, upload that file and then change the link to it every time. If I can keep it easy like that I can do things like link the bare tft setup (updated regularly) and the one you guys are putting together.
All good questions Jeff…lets see if my wine addled brain can remember any answers!
I have been playing with the Makerbase TFT24 as that supports GRBL. (as that is my main interest as I feel it fits with machining better than Marlin) and it uses a ‘$’ as a heartbeat.
You really only need laser at about 5-10% so you can see where the spot lands and at 100% to see what the effect is on the target… all other values IMHO are superfluous,…but there was room for 6 icons 
The G92 Z20 was to raise the laser head 20mm after the probe to allow the removal of the probe plate and wiring, then lower the probe manually -20 plus the plate thickness. If all that can be achieved with 2 buttons so much the better…probe…raise…return to zero and set z to zero.
The G30 was work in progress to achieve the above.
I can’t remember where the babysteps icon was, but I remember thinking babysteps was not really needed for laser work (as focusing the laser is done manually and not with a Z axis).There is nothing I can see on the features menu that would warrant elevation to the printing menu, in fact, I would prefer a lot of the layers removed in a perfect world) as they are not required in laser engraving.
The redrawfan got in the way of the CNC_Laser interface instead of the fan interface in the unified menu (configuration.h) somehow…I’m afraid I can’t remember exactly what though. Anno Domini!
The extra symbols in the console were for GRBL commands…yes.
I got as far as my skill level would allow and I came to a grinding halt trying to find out how to get the TFT firmware to handshake with the controllers GRBL (permanent printer not connected) , the MKS TFT is GRBL savvy but having received a TFT24 from MKS it’s CNC and Laser firmware is truly horrific (the 3dPrinter firmware looks quite good but the laser/cnc version is just an afterthought) and would like to switch back to the BTT TFT35 IF I can find out how to get the handshake working!
I found if you tried to completely disable the M105 it lead to a world of hurt compilewise!..setting the frequency to something that was not intrusive seemed like the best option.
It’s usually a process thing. Keep the source repository for, well, source. Keep the binaries out of it. The exceptions are releases. Alternately, flog your minions a bit more, and get DI up and really functional… 
edit: CI, I have no idea what DI is… Low blood sugar, need lunch…
I’m using BTT SKR 1.3 equipped with TMC2209. FW is derived from Marlin 2.0.3 with EXTRUDERS=1 and pin remapping. My screen is TFT35 2.0 the version without knob and Marlin mode
Thanks @jeffeb3! Seems that none of the float values in the config.ini are populating correctly.
For board I’m using BTT SKR 1.3 with TMC2208, Marlin 2.0.5.3 with extruders=0 and close to the default Marlin pin assignments. Like @loki I’m using the TFT35 2.0 without a knob.
Git doesn’t manage binaries as well. It tries very hard to keep track of them, so anyone that pulls down a new copy of the two has to download every binary that you’ve kept in the history. Not fun. Text files are fine because it only keeps the differences. It can’t figure out the differences with binary blobs.
Using the releases page in github is a good way to do it. Or we could probably leverage what we learned from Marlin builder to quickly make a bin for every commit. I’m not sure the best way to expose that though. For now, I think the plan should be releases, and just try not to do more than one every two weeks. But usually, none for a few months.
This is really helpful. Thank you. I do want to get grbl working, but that may require some real brain surgery. I was hoping you were going to tell me it mostly worked already :).
Those reports are just what I needed to know. What version of screen, what board, what Marlin and what features, especially extruders. I’m glad we’ve got a bit of variety. I have a v3.0 with a knob and a v2.0 without. I have an skr pro with bugfix/marlin 2.0.6, extruders=1 and 2209s. I also have a python script that indentifies as a Marlin board.
Ryan, let me know what you think is missing before you can ship this. I am going to poke at it while it keeps my interest. I think the loki version I PRed is more stable than the dart one I made this morning. I don’t know your schedule either, but I think we should put a feature freeze on this loki version and just do bugfixes on that and make it the first version.
I am using the latest Marlin debug version on a skr 1.3 with 2209 drivers, extruders=0, no pin mods. I have a tft35 e3v3 with the knob at the bottom. I do not connect a computer but use the SD card on the TFT35 to run all my files.
EDIT: I am not familiar with github other than to download stuff. Also not very familiar with C, but I have heavily kluged the TFT firmware to my liking. I have eliminated a bunch of screens, moving the functionality around where I like it. I will give you moral support, but I don’t think I can learn enough, quickly enough, to be of any real help here.
I get it now, perfect, thanks!
I can test it again in a bit. Any ideas about the m119/terminal? I did have a couple small tweaks I was thinking about but…not sure what is important yet.
Me and you both buddy! Amazingly I have started to pick things up and can actually help once and a while. Just test and keep your eyes peeled. We’ll get there eventually.
