Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Display update/ Menu #364

Closed
MrKekson opened this issue May 31, 2018 · 28 comments
Closed

Display update/ Menu #364

MrKekson opened this issue May 31, 2018 · 28 comments

Comments

@MrKekson
Copy link
Contributor

MrKekson commented May 31, 2018 •
edited

Hello.

I'm thinking abut committing some time to this projekt. And my current problem is i don't see the flow rate on the screen, so i wanted the software change between the feed rate, and the flow rate. Additionally, i'm thinking about a basic menu for 12864 screens.

First just some selectable screens. Like the first would be the current one, the second would be a more detailed screen of the settings( open for ideas here).

My other idea is, some marlin style menu, so we could use the dial to change basic settings, without octoprint, like FR, flow, fan speed, temps, predefined level positions for the head etc. I think it would be handy, that i don't need to use my tab if i want to change tem to +5, or type m160 comands to set the fan manually.

I'm also thinking about adding dinamic display functionality to the screen eg: the x/y cordinates are not that usefull during print, we could display print related informations on the bottom line, like ETA etc.. https://plugins.octoprint.org/plugins/detailedprogress/

So is there any plan already in motion regarding this subject? Do you have any ideas about it? Any input would be valued.
@Nume1977
Copy link

Using the display might be interesting, but code has to be made for the both hardware and software side.

@MrKekson
Copy link
Contributor Author

MrKekson commented May 31, 2018 via email

@oderwat
Copy link
Contributor

oderwat commented May 31, 2018 •
edited

I may be wrong but I think hardware driver is not yet working for what you want to do. There is some work in the work-lcd-20180115 branch for supporting buttons. I did not check what it all does but it seems to be only a start.

I think you need to create support for the encoder (and possibly buttons) for sending input events from the printer to the controlling software. There those events need to adjust values aka react to this input. This will then update the calculations. You may also need/want to have OctoPrint to reflect theses changes. For this you probably need an OctoPrint plugin (or code changes) which then update the values in the GUI. This may then create feedback to the Klipper software.

I myself was thinking about using the encode for simple z-stepping as baby stepping works on Marlin (if not updating the z-offset which is also an option there). Something like that could probably done all on the printer and I bet @KevinOConnor would hate it (as it is pretty unsafe to do when not having any constrains which I what I think would be needed to make it useful).

Creating a whole menu on the display could be done, there is a lot of free space on the printer MCU usually. But I think this should not be done on the MCU.

What I think what would be feasible would be some regular "input events" sending to the host part and from there a way to "build" menus. Those could be handled as a plugin to Klipper and developed aside.

@slipstreamliner
Copy link

I wanted to also mention the work-lcd-20180115 branch. I think what we've ended up with here is so many different boards are out there now, there hasn't been a lot of dedication to fully fleshing out one screen when the next may require a totally different method. That said, jump right in.. I've been thinking of this issue myself lately.

As @oderwat is suggesting, if you begin to explore that branch you will eventually come across what Klipper is currently feeding back to the display screen. I do not think I've ever really determined what @KevinOConnor had for here as a vision. Enlighten us? =)

Anyways, please also consider the following: Klipper requires at the very least a multi-core raspberry pi(unless you want to run in vsd mode and feed it right in, but that's awkward).. so I suppose the question is: Why use your printer's crappy display when you could get a waveshare 5 or 7 inch touchscreen for cheap, attach it to the pi, and voila... TouchUI to your hearts content and well, a lot more flexibility.

@MrKekson
Copy link
Contributor Author

MrKekson commented May 31, 2018 via email •
edited

@slipstreamliner
Copy link

slipstreamliner commented May 31, 2018 •
edited

Why would it take additional development? I'm confused, you have TouchUI installed right? Do you mean you'd need to somehow reduce the resource usage? There are jut a lot of ways to approach this... you could even use an old cel phone with a web browser to connect to TouchUI... it's really rendering the display that is killing the pi, not the webserver itself.

@MrKekson
Copy link
Contributor Author

MrKekson commented May 31, 2018 via email •
edited

@oderwat
Copy link
Contributor

oderwat commented May 31, 2018 •
edited

@MrKekson you did understand that the data you want to edit on the menu needs to be send for and back in addition to the other information? It would be much easier and probably also less intrusive and more stable to just do that on the pi.

You may also want to go to your RasPi .. type top then press 1 and check out the actual load when it is printing something. There seems to be plenty of room. I didn't use a RasPi ever with anything than the terminal though :)

I think "adding a display" was not necessarily meaning to add a a full graphical OS (+X) but just adding a touch display and using: https://plugins.octoprint.org/plugins/touchui/ for what you want to do.

Showing information on the printer defined displays is (imho) not the problem. But obtaining input and moving it to the host to apply it to the calculations. The "printer" MCU is pretty much a slave.

@MrKekson
Copy link
Contributor Author

MrKekson commented May 31, 2018 •
edited

Touck UI is just a grapic mod, so the Javascript of octorint's gui is the same, so you do need a browser to run. And i think we can get away with it, if we would run some lightweight X UI, like LXDE. But my consern is, if i press the GCode viewer, or just by chance the browser crap itself, and create some nasty cpu load, then i don't wan't to screw up a print. Also octoprint is advising against running the gui on the same PI, possible, but i prefer reliability. Also, since there is allready feedback to the klippy server from the board, rg: temp, end stops. Transmitting 3 more input should not be a problem. Sadly, i won't have free time til weekend, so let me get back about that later on.

About top: the utilization is no more then 25% on my raspi 3, but a hanging browser could stop my 4 core 8 gig desktop for a fev sec 📦

@slipstreamliner
Copy link

If I have a large number of prints going and i want to ensure I don't spike my usage.... I actually just run Remmina to connect to my workstation, and access the octoprint gui from a browser pointing back at the pi's octoprint instance... i've had zero performance issues with this(no client side javascript being executed on the pi)... I think you might want to consider working on an X86 port if you want some true reliability, which is actually on my todo list.. welll.. it's done, but I haven't had time to iron it out.. .I get so many promo microcontrollers it's insane, so all of my printers either have a dedicated PI or Beagleboneblack or in one case a MinnowBoard...

@MrKekson
Copy link
Contributor Author

MrKekson commented May 31, 2018 via email •
edited

@oderwat
Copy link
Contributor

oderwat commented May 31, 2018 •
edited

I use Klipper without OctoPrint (controlling it directly with Simplify3D from my iMac) anyway. I actually even disabled OctoPrint on the pi, because I never use it anymore. This was partly, because I can't stand this WebGUI stuff. So I sure would not want to "fiddle" on the printer display besides of a quick Babysteps adjustment.

TouchUI ... yeah I got that pretty wrong. I actually though it is some TFT "driver" which also can be used to render to a mobile device.

@slipstreamliner
Copy link

@MrKekson Well... you are requesting an enhancement, which I'm guessing this will be marked as soon... so, the likelihood of someone devoting their time solely to adding this functionality to 12864 screens seems unlikely at the time. This is why I have suggested some other options for you to get a good experience from Klipper. While I'm sure that eventually most common LCDs will be fully supported, it's just not a priority. In addition, regarding the Remmina client, I'm unsure if what you mentioned was directed at that.. but in that case the js would be executed on the machine you have remoted into and opened the browser @ your octopi instance.. not on the pi. If you really want to see the feature added, perhaps give Kevin some patreon support and mention it.

@slipstreamliner
Copy link

@oderwat and yes, just to underscore your statement.. I can't imagine what you'd really need to be doing outside of something like babystepping. You should have a mechnically sound machine before you start running Klipper... your prints in essence should be 'set it and forget it' when tuned appropriately.

@KevinOConnor
Copy link
Collaborator

I'm open to someone sending enhancements to the display support. It's not something I'm particularly interested in developing myself.

As mentioned above, there is button reading code on the work-lcd-20180115 branch. That button reading code will also be needed for filament runout sensors, so it's something I'd like to see get cleaned up and committed. If I get time, I may tackle that part of the work, but I don't plan to develop menus myself (again, I am open to someone else submitting it though).

-Kevin

@slipstreamliner
Copy link

You know, Marlin uses some pretty flexible code for screens, but it's incredibly arbitrary. I am going to give it some thought, see if there's a good method for doing this without writing a full library for each screen type... if so, I will see what I can do. I just know some screens, like the one for the Wanhao Duplicator i3+/Maker Select Plus v2/Cocoon Create is a miniDGUS/DWIN screen and uses proprietary software to create menus. I have no idea if this would even be workable. Will update later... should this be an enhancement? --David

@AxMod3DPrint
Copy link
Contributor

Just to add a use case here for menus/using the encoder. We generally use the menus for configuration, IE setting offsets after probing or on the fly changes like changing feedrate via the encoder. The latter being one that we use a lot. Whilst there is a slider in Octoprint to change the feedrate it's a little clunky. Generally we're inspecting the print at the printer when this happens and rather than bringing up octoprint on our control computer (we have 5 printers, 3 Smoothie & 2 ex Marlin, now Klipper) it's quicker to do this at the printer.

@slipstreamliner
Copy link

slipstreamliner commented Jun 17, 2018 via email

@snoopen
Copy link

snoopen commented Jun 27, 2018

I own a i3+ rebadge, haven't yet moved to klipper but thought I'd chime in with info I've found on the i3+ LCD. Two projects i3PlusPlus and ADVi3pp-LCD here on github have done a lot of work on the LCD. They've got some nice info on how Marlin was updated to work with those screens, and they host a copy of the Dev kit for the screens. I've had a look myself but was a bit overwhelmed.

@slipstreamliner
Copy link

slipstreamliner commented Jun 27, 2018 via email

@AxMod3DPrint
Copy link
Contributor

@shoreliner see issue #404

@slipstreamliner
Copy link

slipstreamliner commented Jun 27, 2018 via email

@MrKekson
Copy link
Contributor Author

MrKekson commented Jul 2, 2018

Finally got my 12864 + ramps on the customs, so i can start to test and push changes soon.

So so far my goals are:

  • Show the flow rate somewhere ( suggestions pls)
    so far i'm thinking to change the FR, to FL ina timely manner, eg: every x second
  • Make the knob changing the Feedrate from the printer controls( should be ok for a baseline for further menu options)
  • Maybe, deactivate/change the behavior of reset button, so it won't work like a self destruct button for klipper.

@oderwat
Copy link
Contributor

oderwat commented Jul 2, 2018

@MrKekson Afaik the reset button does a hardware reset. You can only cut the cable.

isn't everything else more or less related to what @mcmatrix does with his menu code #404 ?

I would like to be free in what I configure onto the knob movement in the status screen. I would probably setup z_adjust for my needs. FR/FL I would want to change in a sub menu. I believe this can be done when #404 finishes.

@MrKekson
Copy link
Contributor Author

MrKekson commented Jul 2, 2018 via email

@oderwat
Copy link
Contributor

oderwat commented Jul 2, 2018

@MrKekson M117 was implemented some days ago. I didn't test it yet but it is supposed to replace the toolhead info line (xyz). Z is shown on my display already. Printing time left could go to the full left and Flow Rate below Feed rate.

image

(I can be hired for creating professional mockups)

@MrKekson
Copy link
Contributor Author

MrKekson commented Jul 2, 2018 via email

@KevinOConnor
Copy link
Collaborator

Quite a bit of work has been done on menus in issue #404.

@github-actions github-actions bot locked and limited conversation to collaborators Dec 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@snoopen @oderwat @MrKekson @KevinOConnor @slipstreamliner @AxMod3DPrint @Nume1977