Display update/ Menu

[MrKekson]

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]

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

[MrKekson]

The hardware driver is already working. Not shure if it works with all panels, but the 12864 on my anet e10 is fine.

On 31 May 2018 at 16:18, Nume1977 notifications@github.com wrote:

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

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/364#issuecomment-393545588, or mute the thread https://github.com/notifications/unsubscribe-auth/AC1Bov6xKrrqww8itZqD27wTqNoPgU8qks5t3_vHgaJpZM4UU4LB .

-- Oli

[oderwat]

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]

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]

Well, i do have a hd display on my raspi, and i'm thinking about how to utilise it, but considering it's doing kinematics, and octoprint, i dont want to run a full hd GUI on it, so that would need some development too. And the current display is sufficient for quick check, except the flow rate. But i think, some basic settings would be usefull. May not even be a full menu. Like with the knob, i could select items on it, like the fan, extruder etc, press on it, their icon and data would be inverted, and we could set the fan with the knob. Nothing major, but it would be sufficiet, so i won't need to get my tab or phone, even if i just want to raise temp by 5.

On 31 May 2018 at 20:27, David Hargrove notifications@github.com wrote:

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 https://github.com/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 https://github.com/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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/364#issuecomment-393629223, or mute the thread https://github.com/notifications/unsubscribe-auth/AC1BopuRPAIM91T9FtoAFDYtUTF-B1wxks5t4DYXgaJpZM4UU4LB .

-- Oli

[slipstreamliner]

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]

Running a browser, means you need to run a X server, and some front end on your Linux, what is cpu intensive, and since both octo, and klipper need some near real time calculations, i don't want to interrupt it, by running a complex js frontend, on a browser. I think using a tablet is way easier, but still, the 12864 screen can be utilized a bit more imho. Nothing major, just the basics as i sad earlyer.

I think i'll check the knob and it's input this weekend. Modding the current one, to display frames, and inverts, should not be a problem Imho. And the limit switches should work like the knob from an input standpoint, but i did not checked that code yet.

On 31 May 2018 at 22:40, David Hargrove notifications@github.com wrote:

Why would it take additional development? I'm confused, you have TouchUI installed right?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/364#issuecomment-393672357, or mute the thread https://github.com/notifications/unsubscribe-auth/AC1BorrSmQLgUCIzuiy6ujcKif38rW6Tks5t4FVEgaJpZM4UU4LB .

-- Oli

[oderwat]

@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]

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]

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]

Pi is fine for me, did not crashed for the last 4 months, in fact, my home heating is running from a pi2, and that has a 2year + uptime. Port is forwarded on my router, so it's accesible from anywhere, and if i open it from anything else, then the JS code will run on that device, not on the pi. We can duscuss it in FB, or on forum, but please keep this issue about the current 12864 menu screen, and ideas about it.

On 31 May 2018 at 23:26, David Hargrove notifications@github.com wrote:

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...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/364#issuecomment-393685788, or mute the thread https://github.com/notifications/unsubscribe-auth/AC1BooWTff7YuHndgq2adtOtSajI-4qdks5t4F_7gaJpZM4UU4LB .

-- Oli

[oderwat]

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]

@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]

@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]

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]

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]

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]

I am starting to realize that this perhaps does warrant some additional attention sooner than later... this is another one of those hurdles that people have when moving to Klipper.. The idea that you can't control your machine from its normal control panel can be somewhat daunting and in the case of some i've helped with installations involved them running from room the room. I have been absolutely swamped lately -- a friend purchased a fairly popular t-shirt website(as a full business) and we are currently "demystifying" their database schema and overall processes. Voodoo. I hope to get moving on this and additional work on PRU error detection methods/irqs as soon as I can.

You know, i need a break from tearing apart horribly structured javascript... so I am going to dive in for a bit.

Thanks,

David

On Fri, Jun 15, 2018 at 3:25 AM, AxMod 3D Print notifications@github.com wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/364#issuecomment-397536852, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQefsxFb4n9z2qRMpZS3tXyNE383_ks5t82FXgaJpZM4UU4LB .

[snoopen]

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]

I have The Monoprice MSP.. I've actually used the software but it's incredibly non-intuitive, the only instructions available are in incredibly low resolution on youtube, and the speech is a heavy chinese accent that I cannot understand. With that said however, the overall system seems rather simple but there's literally no explanation for 75% of the fields you're asked to enter. I've spoke at length with Mr Andrivet about this and what he experienced with ADVi3++ and LCD Dev -- he indicated that in addition to the two screen designs, there is yet another variant of the 'DGUS' called 'DGUS Mini' that requires a totally different application for menu creation. I actually have a number of contacts at Wanhao, and they may be able to assist in finding more updated documentation that could be used for this line of printers.. of course, keep in mind that just like ADVi3++ requires the screen to be flashed separately, this would be yet another alteration the user would have to make. And.. i'm just unsure as to how this would work with Klipper.

I really would like to get to work on some of the more common LCDs out there; i've just finished launching my first 3d printer upgrade. I would insert a shameless plug here but I will refrain. Anyways... anyone taking a crack at fleshing out button support?

On Tue, Jun 26, 2018 at 10:07 PM, Scott notifications@github.com wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/364#issuecomment-400519576, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQQX0uruQ4zLae5vqzlLV-f5_dTqJks5uAujugaJpZM4UU4LB .

[AxMod3DPrint]

@shoreliner see issue #404

[slipstreamliner]

Very nice! Checking it out.

On Wed, Jun 27, 2018 at 3:24 AM, AxMod 3D Print notifications@github.com wrote:

@shoreliner https://github.com/shoreliner see issue #404 https://github.com/KevinOConnor/klipper/issues/404

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/364#issuecomment-400569974, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzNQQHJ1_lpcrybF82upqyQNLQO2Conks5uAzMxgaJpZM4UU4LB .

[MrKekson]

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]

@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]

Yes, subbed to that issue. Thanks.

The screen still need a bit of resign imho. Displaying flowRate is a must for me.

The bottom x/y coordinates part, could be used like marlin m117,displaying usefull messaged from the controlling software(eg: octo). Z is a good to see thing too.

On Mon, 2 Jul 2018 at 16:27, Hans Raaf notifications@github.com wrote:

@MrKekson https://github.com/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 https://github.com/mcmatrix does with his menu code #404 https://github.com/KevinOConnor/klipper/issues/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 https://github.com/KevinOConnor/klipper/issues/404 finishes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/364#issuecomment-401823853, or mute the thread https://github.com/notifications/unsubscribe-auth/AC1BouiN7IiDRWXoiUI74i96Amq3AR-Qks5uCi3YgaJpZM4UU4LB .

-- Oli

[oderwat]

@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.

(I can be hired for creating professional mockups)

[MrKekson]

Looks good. I think the print % can stay, but we can change the text in it, jumping from % -> spent -> left. And the bottom line can change between, m117 and the position?

On Mon, 2 Jul 2018 at 18:18, Hans Raaf notifications@github.com wrote:

@MrKekson https://github.com/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: image] https://user-images.githubusercontent.com/719156/42174925-282c059c-7e24-11e8-908f-5ad9ef886078.png

(I can be hired for creating professional mockups)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/364#issuecomment-401857839, or mute the thread https://github.com/notifications/unsubscribe-auth/AC1BohyIlqPS1O0jupkuLDBtyPTtS69Hks5uCkfHgaJpZM4UU4LB .

-- Oli

[KevinOConnor]

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