I’m looking to start a new discussion about the TFT screens Ryan is looking at selling. There’s a thread here where he’s talking about it a little.
There are a couple of great mods for the TFT screens already, and although they aren’t exactly the same versions, there seems to be a lot that can be transferred. So I’m really interested in talking about lessons learned from those developers and thoughts on how we can keep this maintainable.
It looks like @blomsd had a good starting point here:
I’ve looked at this a little. It looks like it works great, and it has pulled in the main repo as of Vx.x.25.
It looks like @loki edited that version. Loki’s version is here:
It looks like it incorporated a lot of blomsd’s changes, but it is built on BTT’s Vx.x.26, and it is convenitently in a fork, so it seems easier to update.
But in either case, there are some very destructive changes (naturally). Are there any ideas on how to make updates from BTT’s firmware come in more smoothly?
Ryan has started a repo with a fork of the BTT firmware. He’s started mostly from BTT to keep it up to date, and has focused on just getting rid of the errors. I want to work in this space, with the great fixes that have already been developed.
I’m seeing that @ronnycowart is editing some things as well. I didn’t find any details about what edits are going on though.
What features are working? What features aren’t?
I personally think the G92 stuff is the best.
I also like the gcode sender. Although the M105 prints were making reading responses super annoying. I am not sure what the cost of disabling that is, or if it would be better to just not print those in the gcode window. The laser and spindle stuff seems great, although I know not everyone will actually be able to use it. Blomsd’s code didn’t work with the knob for me (The version Ryan is selling has a knob). I haven’t tried Loki’s yet (I will today).
I’d love to see an M119 screen, showing the states of the endstops. That’s the first thing I did in the gcode screen.
I’d love to see the M115/M503 stuff. If nothing else, to tell us the version from Ryan’s firmware (425D, etc.).
I’d like to see baby stepping, although that can be a pain. I use on my printers with mesh leveling, but I wonder if it could also be used on a normal CNC to adjust the Z a little after a job has started. I’m not interested in the M851 interaction ATM, just a general Z offset on the fly.
The coolest feature would be Steve’s touch to jog screen that shows you the whole bed area, and then lets you jog to a particular part of it just by touching that part of the screen. I have no idea how hard it is to code something like that in these screens, but we’ve all got enough talent to figure something like that out.
As I’m in the debugging stage, #4 would be quite nice, just to verify connectivity and that the firmware made it to the board. I have a TFT35 V2 and a SKR Pro 1.2.
This is an interesting project. I’m still in the middle of my move but expect my MPCNC and programming computer back in a couple weeks.
Some of the BTT changes are pretty destructive. They do add a lot of functionalit but lots of if/then statements to try and maintain backwards compatibility.
My version was before the knob did anything. The big one to pay attention to is making sure M00 works and the gcode from SD card on the TFT doesn’t include the M84 command. It is buried in there and causes the Z to fall.
Babystepping wouldn’t work for me even though I have it on the TFT because I disabled auto-level which killed off all the auto level related features like babystepping.
Hi Jeff,
I’m really proud you found my work intresting!
As explained in the thread MPCNC BTT touchscreen firmware for TFT35 2.0 my intention was to port @blomsd project to the latest FW by BTT trying to keep all my modifications under some specific configuration defines (#define CNC_MENU and #define CNC_LASER).
Moreover I have added:
CNC specific icons and labels in order to avoid to change icons and labels already used by BTT standard FW (solution used in blomsd baseline)
CNC specific menu functions (laser.c and spindle.c) in order to avoid to deeply modify other menù functions developed by BTT for other purposes (e.g. blomsd was using fan.c to drive the laser)
My target was to modify the printing screen (the one with real time informations) in order to show only information relevant for CNC machines, I succeed removing the 3dprinting relevant infos but with my limited programming skills I wasn’t able to reorganize the icons in order to fill the available space.
@dart1280 have done some progress on my baseline, mainly adapting the laser management to his machine requirements but I didn’t have the time to integrate his modifications in my project till now.
I hope that working all together we will succeed having a TFT 100% configured for MPCNC.
So since I wrote this, I have been deep diving, trying to do to loki’s FW what loki did to blomsd’s firmware
I had it basically ported, but the CNC_LASER isn’t quite right yet. I am looking at that now.
Since 26, they have added a config.ini file that can turn a bunch of stuff on and off, including the unified menu, which is super annoying, but if we managed to push all of our CNC and laser stuff under a config option, we might have a chance of getting it merged back upstream. I have zero faith that they will keep it maintained, but there is a chance it will be a tad easier if we do get it upstream. So I am working on replacing CNC_MENU with an option in the .ini for cnc_mode and laser_mode.
I definitely need to follow through and verify these two features are still functional. Thanks for pointing that out. I have honestly jumped straight to loki’s version, because it already had 26 in it. I need to go back and look at yours to see if there’s anything that loki missed.
This is still a WIP, but you can see what I’m working on here:
The changes upstream have certainly been destructive. I definitely can’t spend a day on this whenever they do an update. It is not nearly as stable or as friendly to updates as Marlin is. So there’s a good chance this version will also remain on a version near this for a long time.
I do like the new config.ini capability. It would just mean that someone could change the config.ini file, and install the same binary files and they could change things like the cnc_mode or laser_mode on or off. I would also like to turn the spindle control off until someone actually activates it. Needs work though to make it a bit easier to use.
I like the config.ini’s ability to do custom gcode too, but I don’t have room on the cnc menu for a custom menu button. So I need to think about what I could remove to get that to fit in there. Maybe combine the spindle and laser into one menu.
Man this is very over my head so any improvements to make is a little easier would be awesome.
I see two main issues, over complicated file structure on the firmware, hidden commands (eg M84) built in that are not optional in config.ini. The bummer about the built in commands is the same options are in Marlin already Specifically M84) if we chose not to use them in Marlin it should not be in the TFT. The third minor is it is not well suited for anything other than printing but seems like if the first two things were cleaned up a bit it could be easy to fix the third.
The screen seems like it has a lot of possibilities but I have put some time into trying to figure it out and I get lost real fast.
This is definitely going to be a pain to work on, but if we get it working well enough, you could just treat it like the reprap lcd, and just keep the firmware constant. There’s nothing that says you can’t flash the firmware I just posted on an lcd and sell it as is, for years. I think we will want to do some updates to fix minor bugs as they arise, and I’d like to push the limits a little to do more, but the bar should just be set at “better than the reprap one” anything over that needs to justify the extra work needed to do it. Including extra time to test it.
I don’t see any reason you need to understand this as well as you understand Marlin.
BTW, you could probably connect this to a rambo too. We just need to enable the uart in the rambo firmware. It isn’t an skr screen.
Got about as far as I can with this, I have hacked it about to get what I wanted…not sure it will be of any help for those wanting to provide continuity to the firmware.
Also note I have the BTT TFT35 v2,0…not v3 although I also compiled it for a v3.0 and a E3 v3.0 and the display wouldn’t re-flash so it see’s the v3 firmware the same as the v2…
I just tried the homing menu is not working right. Home X homes Z, and the others don’t seem to work at all.
Something is up with my firmware or the tft. I tried a few things m119 from the tft terminal is inconsistent. m119 will either work or not with the same endstop triggered. But dual homing works fine in the old school LCD mode.
Hi Jeff,
hi had a look to your integration and I think that the configuration by variables instead of compilation switch probably can be integrated in the machinesettings.c (that could allow on the fly modification without TFT fw recompiling).
I would suggest, laso, to integrate @cmenard commit G92 Touchplate making the touchplate offset configurable by settings.c menu instead of define assignemnt in Configuration.h file.
Allowing machine configuration on the fly @vicious1 could sell the TFT with a general purpose firmware that can by re-configured by the final user just by switching on/off features in configuration menus instead of recompiling it.
That’s really dumb to have a hard coded M18. I don’t see any reason for that. It makes no sense to me. I will disable it in our branch. But a better solution is to probably change that line to be something from the config.ini file. If I get some time, I will make a PR for it.
