Physical UI support? #2
Comments
My personal opinion is that new hardware designs would be better off talking directly to the host and use octoprint. For existing hardware, I think it would make sense for Klipper to support common lcd panels. I don't have an immediate plan to add support. Contributions are welcome. -Kevin |
|
Please, I would like to contribute with this - just to have very simple functions (like show status, homing, change filament commands, etc) and use the card reader. What do you recommend as a starting point? I do know the (very) basics but not sure where to start besides your documentation. |
|
On Mon, Jul 31, 2017 at 06:00:03PM +0000, brunofporto wrote:
Please, I would like to contribute with this - just to have very simple functions (like show status, homing, change filament commands, etc) and use the card reader. What do you recommend as a starting point? I do know the (very) basics but not sure where to start besides your documentation.
What hardware did you wish to support? If this is for basic lcd
support, then what I would do is add a pass-through mechanism in the
micro-controller code that would allow the host code to bit-burst out
data to the lcd controller. Then the python host code would need to
contain the logic necessary to draw the screen.
See the src/spicmds.c code for an example of how this was done to
communicate with the ad5206 chip.
…-Kevin
|
|
Thank you! I have the http://reprap.org/wiki/RepRapDiscount_Full_Graphic_Smart_Controller connected to the RAMPS. The src/spicmds.c example should solve the data sent to the LCD part witch is already nice. What about the other way around? Reading the encoder and push button to execute simple commands like change filament, move axys, etc.? Would be simpler to run this code directly from the MC or would be interesting the have MC sending messages back to the host and process the request there? Other interesting enhancement would become able to read the SD card :D |
|
Wouldn't it be better to attach the LCD to the RPi? Though I do understand that one of the primary goals of Klipper is drop-in replacement. |
|
TunaLatte... I can't argue with that.... Even the 3.5" LCD TFT is no more than US$ 16.... |
|
On Tue, Aug 01, 2017 at 03:18:40PM -0700, Bruno Porto wrote:
Thank you!
I have the http://reprap.org/wiki/RepRapDiscount_Full_Graphic_Smart_Controller connected to the RAMPS.
This should solve the data sent to the LCD part witch is already nice. What about the encoder and simpler commands (change filament, move axys, etc.)? Would be simpler to run them directly from the MC?
Klipper is designed so that all the kinematics and timing is done in
the host software. So, it would not work well to attempt to process
general user commands solely in the micro-controller. However, it
should not be a problem for the micro-controller to pass them back to
the host for processing - the comms are fast enough that a button
press could be sent and a full screen draw returned faster than a
human eye could detect.
…-Kevin
|
|
On Wed, Aug 02, 2017 at 03:51:52AM -0700, TunaLatte wrote:
Wouldn't it be better to attach the LCD to the RPi?
I'd certainly recommend that for new hardware designs. I don't have
any objections should someone wish to get existing hardware
functioning, however.
…-Kevin
|
|
I see now, it made sense to me at first since in my case I had to add a host (rpi) to my existing setup due to the nature of how klipper works, same story with LCD. |
|
is there any CPU concern to run Klipper, a browser with octoprint and driver for one of those : https://www.waveshare.com/3.2inch-rpi-lcd-b.htm ? Edit : |
|
On Tue, Nov 21, 2017 at 09:05:32PM +0000, Andre Q. wrote:
is there any CPU concern to run Klipper, a browser with octoprint and driver for one of those : https://www.waveshare.com/3.2inch-rpi-lcd-b.htm ?
An RPi3 has a ton of available CPU power. I'm not familiar with that
particular hardware, but I doubt it would be an issue.
…-Kevin
|
|
I have been looking at using a Nextion display recently with Marlin and just came across your firmware. I like what you have done a lot and think i will give it a try but was wondering if you think a Nextion display would be difficult to integrate? as even though i do use octoprint i still like to have local control of my machines. |
|
I dont think for the nextion any integration is needed at all, it just works as a display for the pi and thereby should work with octoprint just fine. |
|
The Nextions are small HMI panels so you need to upload your own interface designs to them. I have plenty of displays i could just use with Octoprint and the Pi directly but i do like the idea of just a custom solution for my own machine, Plus i have a 4.3" Nextion sitting doing nothing that i want to play with :-) |
|
RepRap Full Graphic Controller is the worst option due to slow communication. Now Marlin 2 32bit has trouble with it. |
|
I think we should more concentrate on getting UI connected to Rassberry Pi, on it even a slow LCD won't be any problem (just run the UI in separate thread). |
|
Exactly |
|
Hi, I'm new to Klipper and it seems to fit ideal to my own plans. In fact, from what I read in the forum, most things are already solved by you, even problems I didn't think of, really nice, Kevin... now on the topic: I don't really get why everyone wants some LCD. I bet everyone here has a Smartphone? This also has the advantage to be able to take it with you, say when cooking coffee or on the toilet (or use another device). And you can see the printers webcam... Additionally, many people have older smartphones laying around and doing nothing. Additionally an old monitor and any kind of keyboard or mouse can be used. Do you need any more? I do not think it is worth to invest time in simple LCD screens. I have two laying around and didn't have any need for them for years. |
|
^This, so much! I plan on using this over the RPI https://shop.pimoroni.com/products/hyperpixel and from my initial test, it's gonna work great as a replacement from my old Graphical LCD running Marlin. One could use a cheaper screen sold in many size from China. I'm not sure there should be much time invested in getting those old graphical/character LCD running on the arduino anymore. It will take a good chunk of the processing power for sub-part user experience. The only thing I'll be missing (for now) is a physical rotary encoder/buttons with some macro, but it might be from many years of using the graphical LCD ;) Edit : Btw, there's a script to launch TouchUI at boot time : https://github.com/BillyBlaze/OctoPrint-TouchUI-autostart |
Not all displays use a SPI protocol. A lot of printers use the RepRapDiscountFullGraphicsSmartController, for example, which uses a pain-in-the-ass non-SPI protocol that is extremely sensitive to timing. Perhaps this could be solved by defining a command called "send x bytes to LCD" and the firmware would know how how to send bytes to the specific type of LCD that was configured, either using SPI, or something else, as in the case of the RepRapDiscountFullGraphicsSmartController. |
|
The biggest downside I see in having host send raw bytes is that the graphics protocol would need to be re-implemented on the host side, which is Python. I can see two disadvantages to that:
An alternative would be to have the FW be compiled for specific displays, like in Marlin. The FW would generate all the screens, but the host software would simply tell it what values to draw on the screen. For example, it may say "show the temperature as 220C", or "show a status message of Print Failed", or even, "show a menu with the following items and notify me when the user made a selection". This would have the advantage that the FW could pretty much borrow graphics code from Marlin and use Arduino graphics libraries such as U2G as is, but it would require the definition of a higher level API and add hardware dependencies to the FW. I can see why this would go against the spirit of Klipper. |
|
I've been using Printoid for a couple years now. I have the Pro version, but they also offer a free version. It's actively developed, and offers an attractive, touch screen optimized experience for OctoPrint. It gives me full remote control of my printer on my phone from anywhere in my house (or the world if I wanted to set up WAN access, but not worth the hassle for me). It also streams my webcam so I can monitor my prints from the couch. In other words I'm not sure it's worth the effort to develop a new interface unless someone really wants to use one of the crappy RepRap LCD screens from RAMPS and their ilk. If you really want to attach a screen to your printer, get a 7" Nook tablet for $50 and install Printoid. That's a million times better than a RepRap LCD, and not very expensive either. |
|
On Mon, Jan 08, 2018 at 10:34:04PM +0000, Marcio Teixeira wrote:
> If this is for basic lcd support, then what I would do is add a pass-through mechanism in the micro-controller code that would allow the host code to bit-burst out data to the lcd controller. See the src/spicmds.c code for an example of how this was done to communicate with the ad5206 chip.
Not all displays use a SPI protocol. A lot of printers use the RepRapDiscountFullGraphicsSmartController, for example, which uses a pain-in-the-ass non-SPI protocol that is extremely sensitive to timing.
Perhaps this could be solved by defining a command called "send x bytes to LCD" and the firmware would know how how to send bytes to the specific type of LCD that was configured, either using SPI, or something else, as in the case of the RepRapDiscountFullGraphicsSmartController.
Exactly. Send a burst of bytes to the firmware and have it transmit
it to the LCD using whatever goofy protocol the LCD supports. Add in
simple run length encoding and I suspect most screen draws could be
done in a couple hundred bytes. That's something that can be
transmitted in a few milliseconds.
On Mon, Jan 08, 2018 at 10:49:42PM +0000, Marcio Teixeira wrote:
The biggest downside I see in having host send raw bytes is that the graphics protocol would need to be re-implemented on the host side, which is Python. I can see two disadvantages to that:
1) It may be slow. Python would be a poor language to implement graphics code.
Python on an RPi is going to be faster than C on a micro-controller.
Python on an RPi is going to be dramatically faster than C on an 8 bit
micro-controller.
2) It would not be possible to make use of Arduino code that was already written to support the various LCD modules out there -- everything would have to be ported to Python, which would make adding support for different displays a very laborious process.
The last time I looked, most of the Arduino libraries helped get
around the limitations of the AVR platform (little ram, small flash
space, slow math ops, etc.). I suspect a simple implementation in
Python wouldn't be too bad (eg, use a simple framebuffer and burst out
the framebuffer on every change). It certainly wouldn't work well on
a large lcd screen, but anything like that should be wired directly to
the RPi (or whatever the host is) anyway. I suspect the only
interesting "LCDs on an MCU" are those old RepRap style LCDs that many
existing printers already have wired up.
…-Kevin
|
|
What I expect from LCD is:
during printing "printing..." is enough, so it is not a problem for uC. Next idea I like is LCD connected to rPi with simple text interface and dialer. or left/right/up/down/enter keypad. For instance on ncurses I have Printoid Premium but for me it is not professional solution for everyday printing. |
|
@KevinOConnor : Just to clarify, the reason I am pushing for a RepRap LCD is that I am running Klipper on an TAZ USB printer that is hooked up to PC - there is no Raspberry Pi in the loop. While in your documentation, you stress that Klipper is to be run on a Raspberry Pi or a BeagleBone Black, I would be happy with an arrangement where Klippy.py could be made into a Cura module and be made to talk directly to the Klipper FW from the PC -- no need for a single board computer or OctoPrint. This is one of the reasons I like Klipper better than Redeem: Redeem is tied directly to the BeagleBone Black, while Klipper can be used on hundreds of PC connected printers (although I fully realize that is not your intent!). Of course, at that point a good question might be why I need an LCD if I have a PC hooked up to my printer. Well, I suppose that it a good question, though I tend to use the LCD quite a lot even though I could do the same by hitting buttons on Cura -- old habits die hard :) -- Marcio |
I suppose you're right. I'm suffering from flashbacks from the days in which 14kbps modems were a thing, nevermind the fact that 250000 baud is 17x faster and 124x64 pixels is way less than even the smallest animated GIF from the 90s. |
|
On Tue, Jan 09, 2018 at 06:31:07AM -0800, Marcio Teixeira wrote:
@KevinOConnor : Just to clarify, the reason I am pushing for a RepRap LCD is that I am running Klipper on an TAZ USB printer
Of course - there's no better reason! A number of people have these
LCDs and it would be good to have some basic support for them. I
think new hardware would be better off not wiring the LCD directly to
the micro-controller, but that's just my opinion.
[...]
that is hooked up to PC - there is no Raspberry Pi in the loop. While in your documentation, you stress that Klipper is to be run on a Raspberry Pi or a BeagleBone Black, I would be happy with an arrangement where Klippy.py could be made into a Cura module and be made to talk directly to the Klipper FW from the PC -- no need for a single board computer or OctoPrint. This is one of the reasons I like Klipper better than Redeem: Redeem is tied directly to the BeagleBone Black, while Klipper can be used on hundreds of PC connected printers (although I fully realize that is not your intent!).
The reason I don't recommend this, is that people tend to use their
PCs for all sorts of tasks - playing video games, doing large
downloads, playing music, copying files, defragmenting their disks,
etc. The Klipper host software does have some real-time requirements
- they're pretty lenient - generally no better than a couple of
hundred milliseconds - but things don't work well if the code isn't
scheduled regularly. On a dedicated machine, this isn't difficult to
have confidence in, but it's much harder to be confident about on a
general purpose machine doing general purpose tasks.
Also, the RPi3 isn't expensive and it adds some nice benefits to the
printer (eg, wifi, ethernet, web cam). There is a large active market
for these types of single board computers, so I expect we will
continue to see them get cheaper and more powerful over time.
…-Kevin
|
|
@KevinOConnor : Good point about real-time requirements, this is something I had not considered. Is there any possibility of having Klipper FW run using data from an SD card? I understand from some of your previous posts that you explained that some of the functionality, such as the PID loop, required involvement from the host, so I realize this would not be possible currently, but assuming the control loop could be added to the FW, is there anything else standing in the way of an unattended print? I understand that what I am proposing is midway between what Klipper currently does and what Marlin does. I guess I am thinking of using your existing serial protocol as a much more low-level alternative to GCODE that could be written to the card by the host and interpreted by the microcontroller, and still be used offline, but free the FW from having to compute kinematics. Aside the point you've already made about a SBC being cheap (which is true), are there any other reasons you chose not to have the FW do enough work on the microcontroller to support an unattended print? |
|
On Tue, Jan 09, 2018 at 08:23:54AM -0800, Marcio Teixeira wrote:
@KevinOConnor : Good point about real-time requirements, this is something I had not considered.
Is there any possibility of having Klipper FW run using data from an SD card? I understand from some of your previous posts that you explained that some of the functionality, such as the PID loop, required involvement from the host, so I realize this would not be possible currently, but assuming the control loop could be added to the FW, is there anything else standing in the way of an unattended print?
Yes, there is buffer management, error handling, and status reporting.
The kinematics is a trivial amount of code in the host - the bulk of
the code is elsewhere. The more logic that is added to the
micro-controller code, the more effort is needed when porting to a new
micro-controller. Certain tasks (like buffer management) are trivial
on a general purpose machine (with 100s of megabytes of ram), but can
be quite complex when done on an MCU (with ram measured in kilobytes).
I understand that what I am proposing is midway between what Klipper currently does and what Marlin does. I guess I am thinking of using your existing serial protocol as a much more low-level alternative to GCODE that could be written to the card by the host and interpreted by the microcontroller, and still be used offline, but free the FW from having to compute kinematics. Aside point you've already made about SBC being cheap (which is true), are there any other reasons you chose not to have the FW do enoughwork on the microcontroller to support an unattended print?
I think that is your answer though - single board computers are not
expensive and there is every indicator they will continue to get more
powerful with even less cost. So, I wouldn't spend a huge amount of
engineering time to build a solution that doesn't work well - the user
wouldn't have wifi, wouldn't have a fancy web page, wouldn't have a
web cam, wouldn't have the live gcode viewer, etc.
…-Kevin
|
it's not work for me, because MKS MINI 12864 has some changes to the pin definitions. I do not understand how to make an analogy between the pins that are in the marlin config file and ramps. |
|
On Mon, Apr 09, 2018 at 09:56:46AM +0000, dn wrote:
> @danilovdorin - if the board follows the RAMPS pin convention, then you'd also use the pins found in the config/generic-ramps.cfg file:
>
> [display]
> lcd_type: st7920
> cs_pin: ar16
> sclk_pin: ar23
> sid_pin: ar17
it's not work for me, because MKS MINI 12864 has some changes to the pin definitions.
If I understand it correctly, the "MKS MINI 12864" display is based on
the UC1701 lcd chip. Software would need to be written to support
that lcd chip in Klipper.
…-Kevin
|
|
We have basic UI support now. I'm going to close this issue. I understand more work could be done (in particular, menu support), but I don't think it makes sense to leave this issue open. |
Mesh Leveling Alpha 1
# This is the 1st commit message: tmc2208: Report register field values in DUMP_TMC Report values of TMC2208 register fields in DUMP_TMC command to help in tuning and diagnostics. This also adds functions to refer to register fields by name for TMC drivers and register mappings for TMC2208. Based on Kevin O'Konnor's <kevin@koconnor.net> prototype. Signed-off-by: Dmitry Frolov <dmitry.frolov@gmail.com> # The commit message Klipper3d#2 will be skipped: # tmc2208: Select IOIN register mapping on init # # Signed-off-by: Dmitry Frolov <dmitry.frolov@gmail.com> # The commit message Klipper3d#3 will be skipped: # tmc2208: Fix prev commit to pass tests # # get_register(): Skip HW access when not connected to real HW # The commit message Klipper3d#4 will be skipped: # Revert "tmc2208: Select IOIN register mapping on init" # # This reverts commit 665fc88. # The commit message Klipper3d#5 will be skipped: # Revert "tmc2208: Fix prev commit to pass tests" # # This reverts commit 347600b.
…3d#2 Signed-off-by: JaeYoung Kim <jykeith123@gmail.com>
…eads-20200121 Add configuration description of DS18B20 to Config_Reference and add …
Fetch upstream
Fix status updates for python objects
and others
Do you plan to add support for LCD + encoder? Or will control always be done through octoprint?
The text was updated successfully, but these errors were encountered: