Closed Ramalama2 closed 3 years ago
I'd like to preface this by saying: I understand your question and why you would want it. But: It doesn't make sense to ask this here. Marlin and Klipper are two very different firmwares and exclude each other. The display that we have on our Ender 3 V2 has nothing to do with either of them - Marlin just drives the display.
So imagine Jyers would code Marlin the way you asked - making the display blank. What do you think would happen if you uninstall Marlin and install Klipper? Exactly - the display would not respond because you just uninstalled the function that drove it earlier.
Go ask this in the Klipper GitHub. Also see this: https://www.reddit.com/r/ender3v2/comments/mdtjvk/octoprint_klipper_v2_lcd/
I'd like to preface this by saying: I understand your question and why you would want it. But: It doesn't make sense to ask this here. Marlin and Klipper are two very different firmwares and exclude each other. The display that we have on our Ender 3 V2 has nothing to do with either of them - Marlin just drives the display.
So imagine Jyers would code Marlin the way you asked - making the display blank. What do you think would happen if you uninstall Marlin and install Klipper? Exactly - the display would not respond because you just uninstalled the function that drove it earlier.
Go ask this in the Klipper GitHub. Also see this: https://www.reddit.com/r/ender3v2/comments/mdtjvk/octoprint_klipper_v2_lcd/
nah, i don't ask to merge it to one firmware, just a separate one, you will be able to flash between a marlin and klipper display firmware.
our display is not driven by marlin, our display has actually it's own mcu, it communicates with the firmware on the printer board and is completely independent. So it's not getting driven by anything.
Making a super simple klipper firmware for this display wouldn't actually impact anything. And since this display isn't driven by anything and communicates over a serial connection with the board, Jyers is the only one that can do anything, klipper devs have nothing todo with this.
Cheers
Oh and btw, thanks for that Reddit link, didn't knew that someone is already working on it, amazing 🙈
While obviously I would love to send some love to the klipper users and help to make a decent UI implementation for the V2 display, the real issue comes down to time. It took me about a week of looking over the old display code before I felt comfortable enough with it to rewrite it, and then I at least had something to work with. I don't have that kind of time now, and I have absolutely no experience with klipper or how it handles its operations. The implementations that exist currently leverage having the V2 connected to the pi rather than to the actual mainboard which I find fairly telling about the difficulty of the latter.
TL;DR - Maybe at some point if I have time, but just it's not in the cards right now.
all good, thanks Jyers, we have all rl.
the thing is, most of the klipper users including me, doesn't really miss the display. fluidd or mainsail are awesome and you have anyway the ability to connect octoprint to it. But i doubt that many klipper users want or uses octoprint either. For example i have octoprint as option or as gui, but don't really use it.
You should definitively try out klipper, cause let me say, once klipper, always klipper 🙈 And reprap with the new framework is amazing too. Don't want to say that i don't like marlin, marlin is great, but yeah, once you tryed klipper or reprap, yeah 🙈
Thanks Jyers, and have a good rest ✌️
Yeah, I'm on the edge of trying Klipper - I only heard good things about it. Print quality seems to be much better.
However: I'm using the display intensively to do maintenance eventhough I have OctoPrint running. Ex: jogging the printhead, preheating the printer, Z-offset...
You realize you can do all of that via OctoPrint too right?
On Mon, Jun 7, 2021 at 10:33 AM Steve Heller @.***> wrote:
Yeah, I'm on the edge of trying Klipper - I only heard good things about it. Print quality seems to be much better.
However: I'm using the display intensively to do maintenance eventhough I have OctoPrint running. Ex: jogging the printhead, preheating the printer, Z-offset...
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Jyers/Marlin/issues/970#issuecomment-856041285, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPE4Q4T2GTUFKMX222CICLTRTRGNANCNFSM46GQCHZA .
Yes, of course. But it would still mean that - whatever I want to do on the printer - I need to do through my mobile phone or another device. Sometimes I have my phone somewhere else while working on the printer.
It's all doable and would need a workflow change from my side - but so far I'm happy with Marlin and the display and see no reason to dispense with that.
You realize you can do all of that via OctoPrint too right? … On Mon, Jun 7, 2021 at 10:33 AM Steve Heller @.***> wrote: Yeah, I'm on the edge of trying Klipper - I only heard good things about it. Print quality seems to be much better. However: I'm using the display intensively to do maintenance eventhough I have OctoPrint running. Ex: jogging the printhead, preheating the printer, Z-offset... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#970 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPE4Q4T2GTUFKMX222CICLTRTRGNANCNFSM46GQCHZA .
klipper users dont really use octoprint, cause octoprint doesn't communicate with the klipper api (moonraker), instead octoprint sends G1/2/3 commands to the klipper socket (emulated printer). The reason why we want to use the moonraker api, is because that klipper reads and interpret directly the gcode file, instead of getting lines sended from octoprint.
Don't ask me what the exact benefit is, it's more about the more "native" feeling, so that's why klipper users use mainsail or fluidd. And almost never octoprint.
By the way, I mentioned that reprap is going into same direction as klipper with the new dfs/framework and they integrated or working right now on plugin support. Reprap is right now a middle thing between klipper and marlin, it runs on the mcu like marlin, but uses similar config approach to klipper. There is pressure advance and adxl support is comming. Don't take me wrong, linear advance is very similar, but not the same.
What i mean in the end is, the duet framework with plugin support will win in the long term over marlin and klipper, just because their devs are amazingly good. While klipper is in this point 💩
But right now, at this moment, i would say, that klipper is the best firmware so far 🙈
I just wrote this, to make things clear, why klipper users should prefer mainsail or fluidd. Both are almost the same gui's with very minor differences, but i would prefer fluidd if you have to choose, because it's snappier, and has 1-2 features more.
Cheers ✌️
Yes, of course. But it would still mean that - whatever I want to do on the printer - I need to do through my mobile phone or another device. Sometimes I have my phone somewhere else while working on the printer.
It's all doable and would need a workflow change from my side - but so far I'm happy with Marlin and the display and see no reason to dispense with that.
Ah, btw, klipper supports the line display too (the old marlin ones), sadly not the touch based ones. But raprep supports almost all sorts of touchdisplays (or only touch displays)
Thank you for this write up - I really appreciate it. Especially the comparison between OctoPrint and Mainsail/Fluidd.
I'm actually quite on track regarding Klipper and debated the switch a couple of times in the past already - but at the moment I'm just not ready to ditch the DWIN display. I have seen some implementations with Klipper where you would connect the display directly to the RPi - but it's still missing a lot of features. But I'm 100% sure I will switch to Klipper somewhere in the future.
I've been doing some research on this and it seems that making that DWIN display work with klipper might not be impossible.
I think you're familiar with Desuuuu's fork of klipper that added support for the DWIN T5UID1 touchscreens (CR10S pro, Ender6) directly through mainboard. Ender 3 V2 has a T5UIC1 DWIN encoder controlled tft display which, according to DWIN Chinese forum is more simple/basic than T5UID1 ones. The T5UIC1 is serially controlled with simple instructions detailed in the T5UIC1 kernel application guide.
I see odwdinc has successfully made a python class to control the display through raspberry pi UART and GPIO but I'd really prefer Desuuuu's approach (through mainboard). Maybe someone knowledgeable enough could take a look into their work and adapt it to make this work like it does in Marlin.
I've read on klipper Discord server that adding support for UART passtrough/serial bridge in klipper firmware would make adding support for these kind of displays a lot easier. There's been a PR on this matter but unfortunately got abandoned. Maybe we could look into that as well.
To my knowledge devs don't seem to give much interest into this right now but one of the main reasons people are not switching to klipper on their Ender3 V2 is due to that display not being supported yet. I've used mine on Jyers/Marlin and now on Klipper the absence of that display is really felt. I know I could just buy and switch to a classic Ender 3 display but why not make this work?
Porting Jyers' awesome work to klipper would be best. :heart:
Cheers!
Disclaimer I'm not a software developer though wish I were. I'm just a hobbyist who found about GitHub and would like to help in anyways. :grin:
@ihrapsa You've definitely done your research! And very well put, however there is just one note I would like to make is that the T5UIC1 encoder controlled screen is only simpler in the aspect of the screen firmware. The T5UID1 touchscreen requires a lot of work programming the screen as that is where most of the UI mechanics are handled. The T5UIC1 on the other hand has to have all of its UI handling done by the mainboard. This means that from a mainboard firmware perspective, the T5UIC1 is going to be significantly more difficult to implement than the T5UID1. Not at all impossible, but certainly more difficult.
@Jyers That's definitely true. All the work needs to be done on the klipper side (klippy host and firmware). I think the display only holds the splash screen, icons, fonts and the instructions set it can be programmed with and it seemed to me that a "dumber" display would be easier to control. Though It's quite beyond me to estimate how difficult would be to replicate the Marlin code that deals with the display here in klipper source code.
It's pretty frustrating to be clueless on stuff you want to achieve. But I guess that's the thing with new skills, frustration is always the begining of learning. Anyways, if anyone wants to hop on this project I'd be willing to help/test/feeback.
Really appreciate your time to respond! 😊
Im glad to see that this discussion is still going on, would be nice to see a working display too, but really, if it takes to much time, people will endup using rpi displays anyway.
I mean on marlin a display is mandatory, since there is no need for an pi or anything else as the sd card reader, but klipper is a different story, you have the webgui and an rpi or any other computer anyway controlling it.
I just want to say, if it's not worth the effort, leave it guys. If you still want to give it a go, i would be already happy to see anything on that display, doesn't need to control or output anything from klipper, 4 dumb buttons for 4 macros would already do it 😂
Basically im using here my z endstop as srew calculate macro, to no do it always from the phone and for the display, for myself I don't even use the creality board anymore, since it's just 🤦 And i think many people, that really starts into digging and compiling firmware and modify and bring love to the ender will switch out everything sooner or later anyway 😂
Just my thoughts, but what you do is your beer. Anyway, thanks very very much that you all at least think of it and have fun ✌️😘
Hi, First, thank you for your work and well probably im asking for more work 🤣
However, is it possible that lets say you remove everything of the display and give just a possibility to add icons and link those icons with gcodes?
That's basically everything that's needed for klipper or reprap. No fancy temperature readings or anything else, just icons and sending gcodes.
I'm wondering why no one else already asked about this 🙈
However, thank you anyway! Cheers ✌️