Feature: Support for MKS DLC32 board plus TS35-R LCD display. #759

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.

I have added the LCD control UI for MKS DLC32, but in fact, I can briefly introduce it:

1. Adding a set of MKS like UI to add icons and font libraries is not difficult using LVGL, and the implementation logic is relatively clear. I will handle it independently using a FreeRTOS task. In fact, the FreeRTOS of ESP32 is very powerful, but in ESP32_ GRBL, I personally believe it has not played the role of FreeRTOS, such as IPC communication.

2. But in the end, due to my personal programming skills, after I joined the UI, the highest processing speed will become slower, which means high-speed engraving will fail. Therefore, I designed a serial screen program for MKS DLC32 and DLC using ESP32, and I found that this not only ensures ESP32_ In addition to the performance of GRBL or FluidNC, the UI experience is also great.

I have added the LCD control UI for MKS DLC32, but in fact, I can briefly introduce it:

1. Adding a set of MKS like UI to add icons and font libraries is not difficult using LVGL, and the implementation logic is relatively clear. I will handle it independently using a FreeRTOS task. In fact, the FreeRTOS of ESP32 is very powerful, but in ESP32_ GRBL, I personally believe it has not played the role of FreeRTOS, such as IPC communication.
2. But in the end, due to my personal programming skills, after I joined the UI, the highest processing speed will become slower, which means high-speed engraving will fail. Therefore, I designed a serial screen program for MKS DLC32 and DLC using ESP32, and I found that this not only ensures ESP32_ In addition to the performance of GRBL or FluidNC, the UI experience is also great.

Of course, there are still many areas for optimization in the program. Recently, I have been researching the data flow of FluidNC, and I need to understand the direction of serial port data so that I can add a serial port screen better

no updates

Any Updates? I saw in the wiki “LCD TouchScreen data is available to be ported into a special “only MKS DLC32″ build.” and didnt know if that meant that there is a fluidnc that supports the LCD.

There is no LCD version of FluidNC from the core developers.

Any Updates?

We are very unlikely to do this. The developers are working on a full-featured pendant based on an M5Dial, which will work with a variety of different controller boards, not just the MKS DLC32.

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.

Hello professor, I would like some help, please
I have a problem with the MKS DLC32 card, which is that I cannot reach slightly high speeds with it. Is there a software solution, or perhaps an electronic board to amplify or accelerate the signal perhaps?

We are very unlikely to do this. The developers are working on a full-featured pendant based on an M5Dial, which will work with a variety of different controller boards, not just the MKS DLC32.

Hello professor, I would like some help, please
I have a problem with the MKS DLC32 card, which is that I cannot reach slightly high speeds with it. Is there a software solution, or perhaps an electronic board to amplify or accelerate the signal perhaps?

Reading through this. Is there anything working. I have seen one YouTube video with a TFT showing long box buttons.

There is no support for TS35-R LCD display, none of the primary developers are working on it, and if someone else were to write the code, we would not add it to our mainline code base because it would require more FLASH storage that is available on most of the controllers that we support. The pendant solutions that we support are described at http://wiki.fluidnc.com/en/hardware/official/M5Dial_Pendant and http://wiki.fluidnc.com/en/hardware/official/CYD_Dial_Pendant .