bdring
Feature: Support for MKS DLC32 board plus TS35-R LCD display.
Machine Context
MKS DLC32 board plus TS35-R LCD display.
Feature Description
Makerbase makes it's firmware open source and published source on GitHub: https://github.com/makerbase-mks/MKS-DLC32-FIRMWARE Maybe there is a chance to integrate TS35-R display with FluidNC?
Other Approaches
How I Can Help
I have DLC32 and TS35-R and can help with testing.
We are currently overhauling our communication systems. This is how the firmware sends status and receives user inputs. It does not make sense for us to consider things like this until we are done with that.
That will probably take a few more weeks.
This is obviously not a difficult thing. Of course, the more important thing is the stability of movement and communication. It is really not difficult to move the screen UI.
@solawc You are correct that simply moving code is often not particularly difficult. But doing it well, so it does not look like a "wart on the side", can be difficult. If we were to incorporate the code in the FluidNC code base, we would want to do in a way that could be extended and supported later. The quality of the code to be moved is unknown at the moment.
One consideration is that this particular feature benefits only one vendor's boards.
One consideration is that this particular feature benefits only one vendor's boards.
Yes but the board is open source and there are lots of users for these boards. Also there are other vendors with similar boards, for example Atomstack fits its laser engravers with boards similar with these and the firmware is fully compatible. The main thing is that having an lcd touchscreen is great. Best thing for me is using it as a control pendant. And if you start supporting lcd touchscreens, I am sure that more board manufacturers will start to adopt this feature.
FYI, I do have a slightly "hacky" implementation of LCD on MKS DLC32. Screen and touch works. Once I'll have UI running I'll share it.
However, please don't expect it to happen next week. I agree with @MitchBradley, doing it right takes time. The implementation of UI in the code base above is emmm, hair risinglly bad, to say the least. It goes against overall philosophy of FluidNC.
And @solawc, This is obviously A Very difficult thing to untangle C-style script ( naming intended ) where every single button position is hardcoded in multiple places and even simple move of a button takes a weekend. Let alone making this code resolution-independent.
The TFT-aware firmware from MKS appears to require a "big application" partitioning scheme that is not compatible with OTA firmware updates. To deploy that, we would need to rethink the way we do partitioning, possibly lose OTA, and possibly end up with a explosion of different installation choices. All of those would cause serious support headaches.
Many controls that are viewed as one from the outside. Have more than one CPU inside for different tasks.
FLUID NC must control the machine. :-) But it's a few people's turn to solve the operation with additional hardware. At the moment there are only a few ready-made solutions. But if you can support a project, you can campaign for your wishes.
My wish would be to open a department in the Discord that takes care of the external operation of FluidNC.
@MitchBradley , MKS code is not optimal for size in any way. I hope I can fit it without going "big". Also, we don't need everything. Just having status screen ( which in a way present already on machines with OLED screen ) and jog control would cover 99% of the stuff you need a screen for. Rest is implemented already through WEB.
Duplicating the OLED status display on the LCD would be a good start. I wonder if there is some way to save space by factoring out the font infrastructure so that it does not have to be duplicated between the SSD1306 library and whatever the LCD support uses? I would be pleased if that library could be restructured/rewritten to support better re-use of its interior components.
... but maybe I am overthinking it. The fonts in the SSD1306 library use about 2700 bytes, and some - perhaps all - of them are probably too small to be of much use on a bigger display.
Those are 1bit fonts, which are good for saving memory, but might be a bit of overkill, cause for 16bit screen you have to unpack it on the fly. Not sure it's a good idea.
LVGL has it's own font system, which I'm not a huge fan of, but it is what it is. They're not small.
The size of the .c files is not the same as the size of the compiled object code. C source often represents a single byte as a string like "0xFA, ", plus boilerplate, so .c files are often at least 6 times larger than the object code.
Storing binary data in a .c file is just not done. It is always represented in ascii form then compiled to binary.
Which is a questionable approach. I would prefer to keep binary data as binary data, build obj from it and link directly. Otherwise in theory you need a compile step when you binary data is built into .c which require external tool to be part of build system.
.d is a dependency file. .o is the compiled file but it also contains symbol information so the linker knows how to connect the binary information into the program. To find the size of the actual binary data in a .o file, you can run the command "size foo.o" - but the "size" command might not be easy to find on a given system. In a platformio installation, it is buried in a toolchain directory somewhere in the platformio data directory.
You can represent a monochrome, fixed-width, bitmapped font glyph in about 50 bytes or less. If you only have glyphs for the 95 printable ASCII characters, you are looking at less than 5K. Unpacking on the fly is trivial and fast compared to sending data over I2C.
I would prefer to keep binary data as binary data, build obj from it and link directly. Otherwise in theory you need a compile step when you binary data is built into .c which require external tool to be part of build system.
In practice nobody ever does it that way, at least in the context of C toolchains. For stuff like fonts, the binary data hardly ever changes so the "convert to .c" step is often done exactly once and the result is checked in to the source control system, never to be modified. There is a Linux tool "xxd -i" that will generate a suitable .c file from a binary file.
This is a solved problem with a lot of history. Please can we not waste time reinventing an ancient wheel?
The screen in question use SPI and most of the operations are sending command to set memory region and then pushing a bunch of pixels. The amount of data you have to push for those 16bit LCDs is much bigger then monochrome OLED, so you set it up as DMA transfer, otherwise you ending up with slideshow. So you render you font into memory buffer and then DMA it to the screen. That's also what LVGL does. But then it has it's own font system and they have variable-size fonts with Unicode support.
I wrote systems like this in the past and it's a lot of work. Especially when you start to worry about symbols outside of ASCII, like degree symbol ° for temperatures, euro-sign and so on and so forth. And then localization people knock your door and.... well.
So for this particular case, I would rather take existing library which cover all those corner-cases already and optimized for embedded. Plus you can just keep it as dependency outside of your code base.
I would prefer to keep binary data as binary data, build obj from it and link directly. Otherwise in theory you need a compile step when you binary data is built into .c which require external tool to be part of build system.
In practice nobody ever does it that way, at least in the context of C toolchains. For stuff like fonts, the binary data hardly ever changes so the "convert to .c" step is often done exactly once and the result is checked in to the source control system, never to be modified. There is a Linux tool "xxd -i" that will generate a suitable .c file from a binary file.
This is a solved problem with a lot of history. Please can we not waste time reinventing an ancient wheel?
For fonts, yes. For Images - i disagree, but would not insist.
Fonts and Pics can be used from SD.
This is a bad idea. Your machine will simply not boot without card, card removal for g-code upload will most likely cause crash. And also, like I mention above. You have to change LVGL for that, which mean that from this moment entire LVGL has to be moved into codebase and someone have to support it.
The more I think about it, the less I like the idea of adding additional UI code to FluidNC. The way to handle this opportunity is to add an extra MCU to run the UI. ESP32-S2 modules in the mini form factor are going for about $2 on AliExpress ($20 for 10, plus $3 shipping). You can get them with or without PSRAM for essentially the same price.
So the thing to do is design a little interface board - either as a 6-pack module or not - that adapts the mini pinout to whatever LCD/touchscreen you want. The "standard" interface that MKS uses would be a reasonable choice. The UI processor can talk to FluidNC over any channel you want - uart, websocket, telnet, bluetooth, .... If you want to use WiFi without an external AP, the UI processor can run the AP code so FluidNC is isolated from the flakiness that results from running the FluidNC ESP32 in AP mode.
If I were doing this, I would be tempted to do the entire UI in MicroPython. LVGL has MicroPython bindings, and there is also https://github.com/peterhinch/micropython-micro-gui .
I want to concentrate on core performance and stability in FluidNC, so I am going to insist that UI work be offloaded to separate processors via separate projects, developed, maintained, and supported by external teams.
I understand your reasoning and I do see sense in it. But look at this from customer perspective. You know that people want. They are not looking at this as an upgrade of machine without LCD. They just want to buy the board with screen, upload firmware and expect it to "just work". Or maybe they already have whole machine assembled with the screen and doesn't want to rebuild it.
You will loose people right at the line: "design a little interface board". They expect plug'n'play solution. That board already comes pre-flashed and work with the screen out of the box. So, no one will expect any less.
One more time, I'm not trying to convince anyone. I totally see your perspective.
Anyway, I started implementation of a screen mid-January just for myself, simply cause I have build machine based on that board a while ago. Then I notice bugs, failed miserably to fix them in their codebase and switched to FluidNC. Now, everything is running, but having black screen all the time is less then ideal. The screen is running already with text, pannels, layouts and buttons. It's just doesn't do much. Ones I'll have anything useful we can talk and look at the numbers, otherwise right now it's just a lot of hand waving.
BTW, I found this thread yesterday by total accident. I think I've found it too early.
I am not expecting random users to design a board - I am expecting you or someone like you to do it. "Customers" is an interesting word in light of the fact that the vast majority of users do not pay for FluidNC and do not donate to its support - but they do seem to expect a substantial amount of that support. The small number of core developers can barely get any work done.