[FR] LCD display control through gcode

Features
1

One really useful thing about the LCD is that you can control it without being near a computer/phone.
It would be useful to make the LCD capable of doing everything, including doing bed screws adjust through purely the LCD. But this could be expanded to allow any menus and dialogs to be triggered through gcode e.g. filament load detected/runs out. It should ideally run gcode based on the user input conditions.

I think it would be best to write the dialogs in the config file. Here are some examples of a possible config section for a useful scenario - filament loading, feel free to make any suggestions.

This could be one for detecting filament loads, first by selecting the temperature and then performing a load routine followed by confirming load is successful

First, filament sensor triggered runs this gcode:
DISPLAY_DIALOG dialog=filament_load_detected

Which refers to a config section:
[display_dialog filament_load_detected]
heading: Fil. load detected
options: Load PLA, Load ABS
gcodes: ; gcode actions depending on the input, starting with the first option
preheat_pla
load_filament, ;
preheat_abs
load_filament

The load_filament macro could also make use of a dialog:
[gcode_macro load_filament]
gcode:
; whatever your load gcode is...
DISPLAY_DIALOG dialog=load_filament_dialog
[display_dialog load_filament_dialog]
heading: Filament load
options: Filament loaded, Filament not loaded, Colour not correct
gcodes:
M84, for loaded
load_filament, for not loaded
; extrude some more to purge old colour
DISPLAY_DIALOG dialog=load_filament_dialog

The most common screen has 4 lines of text, it should be possible to display it in such a way on the screen:
Heading
>Option 1
Option 2
Option 3
and if any more options, it could scroll like the existing menus do, but keeping the heading visible.

I see this feature useful in other scenarios too, for example with filament runouts or requiring the user’s attention before starting prints if the enclosure door opens… the possibilities are endless if all it takes is a config section and an extended gcode.

If any developer is interested to work on it, feel free to use my plan, but if no one decides to work on it chances are that I’ll do so (once I get an idea of where to start!)

2

Nowadays, this is not worth the effort, IMO.
KlipperScreen has all these features, supports touch and is super flexible.

1 Like
3

If only it would be as easy done as said…

Some technical issues:

  1. Not every application processor used has an hdmi port for klipper screen, likewise an extra usb port for touch control

  2. A commonly available lcd screen is about the price of the hdmi cable needed, let alone the ~ÂŁ30 for the lcd. In some cases even cheaper than the hdmi cable, cause you can just reuse your old screen for free, very important since I know of some that outright refuse klipper since it renders their display almost useless.

  3. (my scenario) The smallest lcd with touch is 4.3 inches. The voron 0 display is ~1 inch with the knob. Last thing anyone would want is to lug around an external screen for their printer when the voron display literally fits into the skirt with nothing sticking out( not even the knob if you move things around a bit). Plus let’s not even start talking about the mess of wires (power, usb touch, bulky hdmi cable or fragile ribbon cable for those lucky enough to have RPIs). For me right now it’s literally a single 10 pin rugged but not bulky cable towards the mainboard.

  4. people suggest using an android phone for klipperscreen. It works but feels especially clunky, sometimes the phone crashes but the printer doesn’t, but that’s no good since you can’t even control it. From experience, the latency is also horrendous even compared to octoprint over wifi

Other issues or considerations:

Although some people might prefer a touch screen, the rotary knob does everything. Even my 2d printer uses a d pad and achieves everything needed, including navigating through complex menus with dialogs and even entering a wifi password. A refined non touch interface will reliably do everything you need, key word being reliability

Even if the klipper screen phone doesn’t crash, using it as the display seems like an afterthought when you could properly integrate a display + user interface. It feels odd (and is not cost effective) to have a separate device with a separate charging unit only to fulfill one of the core features of the printer.

One more benefit of the classic lcd approach is simply the ease of use. Personally the haptic feedback of a click wheel makes the deal for me. It’s also a lot more intuitive for people who find touchscreens complicated and confusing

I have to disagree with you, there are many people who don’t have the hardware requirements for klipper screen. Many people buy the classic lcd/oled displays since they’re dirt cheap and serve the job (did I mention with very little power consumption?!). I would think it’s a matter of preference with the screens, although I do hope that the lcd displays won’t be left behind and forgotten with little development on that side

4

They are already left behind. The LCD touch support never made it into Klipper and any LCD pull-request in the recent (2 years+) past has been rejected. Probably also, since the lead developer thinks that the entire LCD code would need a major refactoring and not just patching in new stuff.

I am not trying to discourage you, just bear in mind that the response / resonance may not be what you had hoped for.

Personally, I think the “dumb” LCDs are a thing of the past and I will not shed a single tear since I never liked the concept. Especially since there are nice alternatives like 2.8inch Capacitive Touch Screen LCD For Raspberry Pi, 480×640, DPI, IPS, Optical Bonding Toughened Glass Cover, Low Power Solution

The price point is an argument, but honestly: 3D printing as a hobby is most likely one of the most efficient ways to burn money.

Regardless, good luck!

5

Interesting conversation and I’d like to add my two cents.

Personally, I don’t think that having a large, sophisticated user interface attached to the controller in a Klipper 3D printer set up is the right way to go, nor does it follow the Klipper paradigm. I see the controller as having the task of interfacing to the printing hardware - not interfacing with the user.

Along with a large display not being part of the Klipper paradigm, the additional communications needs may be a problem in some systems that are using serial interfaces or the host’s computing power is marginal for the basic tasks at hand. If there is any kind of substantial bandwidth required for a user interface attached the controller (ie showing the Gcode Viewer functionality), then I could see the number of MCU Too Close situations increasing significantly.

I have four printers running Klipper right now. Two have KlipperScreen touch user interfaces, one has a small LCD/knob user interface and the last one doesn’t have any. I don’t see any difference in usability or productivity in any of the printers and, when it comes right down to it, I really do all the work using the Mainsail web page.

This doesn’t mean that I would recommend no controller based user interface; in a printer farm, I can see having a small display showing a progress bar as well as giving the operator a chance to halt/cancel a print or change the filament spool without going to or bringing over a laptop. If I had a small LCD, I would like Klipper to provide it with the ability to set the nozzle height in PROBE_CALIBRATE which would make that operation a bit easier without going back and forth to the controller (if this functionality exists, please let me know).

I think the desire for a sophisticated user interface on the controller is based on the basic 3D printer approach (ie no host) in which the user has to load gcodes from an SD Card but as Klipper does not have this functionality then the need for anything other than a simple user interface is made redundant.

1 Like
6

I never knew that existed - thanks.

But the size requirement for the voron 0 and similar printers rules out anything over 1-1.5 inches.

Also I don’t think it is the right thing to do to reject any changes to the lcd code. The largest part of the code modification is to load up a custom menu on demand, where code can just read the config file and create a new section in display.cfg. The lcd is still supported, thus it shouldn’t be neglected when the community offers a solution that works. I doubt it needs a ton of modification. My high level plan plans for the extended gcode to only call for a display refresh and then call equivalent code that normally moving the knob calls.

Forgive me for leaning so heavily against klipperscreen, but I strongly believe that there should always be an alternative

I think there is a need for a more refined lcd interface since not every klipper printer user is willing to fork over the price of two filament rolls when they already have a compatible lcd. Going the klipperscreen route right now will just make the stock lcd essentially e-waste

Unless klipperscreen gets the graphic/character lcd support, the standard klipper lcd won’t be made redundant

Anyways I should really start poking at it, if anyone knows where I should start looking please let me know

7

Interesting opinion.

I do agree with the fact that the microcontroller might experience more load with a display. Thing is - I don’t really expect many people to even use the gcode viewer, that’s what the slicer preview is for. The lcd is also very customisable, in my one I changed it around to display the file name being printed which is sufficient.

Regarding the mcu overload, I believe it will be a non issue. I’ve stress tested the lcd before by (very) rapidly turning the knob and forcing it to display different menus. No errors.

Here are my two cents about complications with loading files:

with the last part about loading files from an sd card: how else would one print a file without a network connected? I’m not the only one in this situation, those that have a portable printer and printers situated in an area without wifi or cable should use a screen to print from usb/sd . Sure, klipperscreen does this but so does the old lcd that you already have.

I’m also thinking about commercial budget klipper printers, adding a touchscreen is too expensive but if you have no screen then how are you starting a print without ssh-ing into it and adding WiFi credentials?

These are two reasons why I think the lcd isn’t obsolete, but I guess there are also reasons why klipperscreen is better. However there should be a choice between the two unless they merge into one(which with the amount of people using klipperscreen should very much happen)

8

A lot of this is probably already possible. I implemented the bed tramming part here: Bed Tramming from the LCD

You can probably borrow the principles there to implement some of the other things you describe.

Ironically, I ditched my LCD for KlipperScreen about a year ago for the reasons discussed in this thread.

9

Thank you

That basically covers everything I need without getting my hands into the python code. I didn’t really get my hands onto the display data config sections yet since there was little documentation I could find, but now I can figure it out a lot easier.

10

How much experience do you actually have with Klipper?

If you don’t have a network connection and you want to load in a new gcode file into your printer you are SOL (shit outta luck mug).

One of the most basic requirements of Klipper is that you have a network connection to the printer. It doesn’t matter if you have an LCD UI connected to the controller or the host; you still need a network connection to load gcode files into the Klipper host. As for all other functions, your web interface (Mainsail, Fluidd or OctoPrint) provides that capability as well.

I wouldn’t call a user interface local to the printer (either connected to the controller or host) “obsolete”, I would call it “redundant”.

11

Not if you set it up with a display whist you still had a network around! USB sticks (or in two of my printers USB to full size SD adaptors) can also store gcode.

Part is because I couldn’t be bothered to reconnect my voron 0 every time to a new wifi network, part is that the room my other printers are in doesn’t have any networking whatsoever!

I’ve used klipper since late 2022 so very little experience, but all this time except for the initial two months of setup and occasional tuning I have never touched the web interface.

12

There ain’t no mechanism to do that from a controller user interface. Implementing it would be non-trivial and, as I indicated in my original post, it wouldn’t be following the Klipper paradigm.

I think you need to spend some time actually using your Voron as a printer. The controller LCD doesn’t have the capabilities that you seem to think they do.

You may not like it but there needs to be a network interface working with a Klipper based printer in order to be able to load gcode files into it.

13

Yeah the display isn’t too suitable for that, I do want to work on it to make it better for printing files easier

I know klipper should really have a network connection but realistically you don’t need one to print from virtual sd card or whatever you point it to like a usb drive. Yes the lcd can start prints and I’ve done that before