Physical UI support?

[mhv-shared]

Do you plan to add support for LCD + encoder? Or will control always be done through octoprint?

[KevinOConnor]

Do you plan to add support for LCD + encoder? Or will control always be done through octoprint?

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

[brunofporto]

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.

[KevinOConnor]

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

[brunofporto]

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

[ghost]

Wouldn't it be better to attach the LCD to the RPi? Since the host benefits from running Octoprint + klipper,I added a cheap $9 ILI9340C lcd with TouchUI plugin enabled. https://learn.adafruit.com/3-dot-5-pitft-octoprint-rig/overview

Though I do understand that one of the primary goals of Klipper is drop-in replacement.

[brunofporto]

TunaLatte... I can't argue with that.... Even the 3.5" LCD TFT is no more than US$ 16....

[KevinOConnor]

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

[KevinOConnor]

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

[ghost]

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. Would be also good to have MCU stats/debug info (like klippy log info) running in realtime on LCD (without host communication) as preliminary support for MCU LCD.

[andreq]

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 : Scratch that SPI screen, might be better off using an HDMI one. Should add less stress on the CPU.

[KevinOConnor]

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

[Bobblejot]

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.

[lenne0815]

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.

[Bobblejot]

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 :-)

[rafaljot]

RepRap Full Graphic Controller is the worst option due to slow communication. Now Marlin 2 32bit has trouble with it.

[dragonnn]

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

[rafaljot]

Exactly

[hg42]

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? Simply take the touch UI plugin of octoprint and use it. It couldn't get better. Touch UI is a lot faster and much more convenient than scrolling through menus and clicking.

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... Full control everywhere.

Additionally, many people have older smartphones laying around and doing nothing. Just install one of them on the printer. In fact I do this since I have octoprint on my printer. You can even use a big tablet.

Additionally an old monitor and any kind of keyboard or mouse can be used. On linux you may find solutions to run a web browser fullscreen (easiest will be using F11).

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.

[andreq]

^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

[marcio-ao]

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.

[marcio-ao]

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

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.

[jakep82]

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.

[KevinOConnor]

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

[rafaljot]

What I expect from LCD is:

1. preheat
2. manual bed leveling, move x,y,z
3. Z offset
4. interrupt with halt button

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 With normal options, wifi status, etc.

I have Printoid Premium but for me it is not professional solution for everyday printing.

[marcio-ao]

@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

[marcio-ao]

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.

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.

[KevinOConnor]

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

[marcio-ao]

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

[KevinOConnor]

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

[marcio-ao]

@KevinOConnor : Right now having two boards in a printer seems a bit odd. But I imagine in the future it will be more common to combine an ARM processor with a microcontroller on one PCB -- the BeagleBone already does that on the same die. Certain boards, such as the Prusa Einsy, support an ARM daughter board. I suppose you're just planning for the future -- it just feels a bit peculiar today :)

[theopensourcerer]

@marcio-ao I see a LOT of folks who already have a Pi connected and wired into their printer all the time. Usually running Octoprint ;-)

[marcio-ao]

@theopensourcerer : I do fear the day we have to apply security patches to our printers, however, because they would be running an OS.

[KevinOConnor]

On Tue, Jan 09, 2018 at 05:15:17PM +0000, Marcio Teixeira wrote:

@theopensourcerer : I do fear the day we have to apply security patches to our printers, however, because they would be running an OS.

Hah! I fear the day we can't apply a security update to our printers because they're doing networking using some obscure microcontroller code instead of using a general purpose operating system.

In my opinion, wifi and ethernet on 3d printers is definitely going to happen. Going into the market with a $500+ printer and then telling their users they need another $500 computer just to do something with it.. I don't think that will be competitive.

-Kevin

[marcio-ao]

@KevinOConnor ; Brave new world! Anyhow, thank you for answering my questions. I think I have a better idea of what your objectives are and what Klipper is aiming for! Keep up the good work!

[ismangil]

With Klipper, is the current X Y Z position available anywhere in the host, or can OctoPrint display it somewhere? The reason I asked is because currently that's the only parameter not available in OctoPrint, and only available on microcontroller board LCD.

[hg42]

Octoprint has a plugin for displaying Z (extracted from the gcode sent, I guess). I guess, you cannot follow X Y anyways, because it's changing too fast...

[marcio-ao]

I have made a mockup of a simple UI that could easily be integrated in Klipper:

Marlin currently uses U8G for graphics, but rewriting all that in Python would be tricky. My UI proposal uses the built-in character generator in the ST7920 driver chip, so it only requires a few SPI commands to work. The only graphical element is the progress bar rectangle and shaded portion, the rest is done using the text buffer which is conveniently XORed together with the graphics buffer by the chip. The nozzle, bed and rotating fans also use the built-in character generator, so animating the fan requires a SPI transmission of only about six bytes.

Integrating this into Klipper would be easy. The function "void lcd_cmd(bool rs, bool rw, uint8_t data)" would be the only thing in the Klipper FW, and the rest of the code could be trivially ported into Python. The Arduino sketch is here and I also made a goofy video this weekend showing some animation capabilities (I plan to make it into an Instructable as AFAIK, nobody is really using these displays in this way).

I may try porting some of this into Klipper, but I'm not entirely sure I know how to do it quite yet!

• Marcio

[KevinOConnor]

On Mon, Jan 15, 2018 at 03:23:05PM +0000, Marcio Teixeira wrote:

I have made a mockup of a simple UI that could easily be integrated in Klipper:

Very interesting!

I think the biggest challenge will be the 72us delay - that's a bit long to pause (even for Klipper's low-priority background tasks). It's interesting that a standard serial port is actually faster than lcd writes (250000 baud is 40us per byte).

To account for this, the mcu code could have a buffer that pushes out writes to the lcd (with appropriate rescheduling between each byte) and the host software could fill the buffer as needed. I could probably create some test code for this if you're interested.

and I also made a goofy video showing some animation capabilities.

Hah!

-Kevin

[marcio-ao]

@KevinOConnor: The pause does not need to be part of the lcd_cmd(...), as long as each command could be scheduled in the future when the LCD would be ready for the next command. The FW would have a function like schedule_lcd_command(time, rs, bool) and the Python code would do repeated calls like this:

schedule_lcd_command(current_time + 72 1, 0, 0, 0x00); schedule_lcd_command(current_time + 72 2, 0, 0, 0x00); schedule_lcd_command(current_time + 72 * 3, 0, 0, 0x00);

The only delays that would be necessary inside "schedule_lcd_command" are to honor the 600ns minimum period of the SCLK signal; there are 24 bits in each command, so "schedule_lcd_command" would take 14.4us to execute per command.

Does this fit into the required granularity of Klipper?

[marcio-ao]

Of course, all this timing stuff is sort of a pain in the ass to handle from Python. Your idea of simply having a buffer I can write commands to is much more convenient. Each command consists of two bits, rs and rw, and a data byte... these could all be packed in a uint16_t, if that is convenient. If you could provide me with a function like that, I could rewrite the rest of the Arduino code as a .py file and take it for a test run.

[marcio-ao]

On second thought, something that takes an unsigned char* and a int8_t size argument would work just as well. I can pack the sync, rw, rs and data bits into a 3 byte buffer and Klipper can deliver them to the LCD on my behalf. This would make the function a bit more generic since it would not need to be specific to the ST7920.

[marcio-ao]

To summarize all this, this could be the Python routine for sending bytes:

send_lcd_spi_command([0x00, 0x00, 0x00])

There would need to be a way to specify the minimum SCLK period (600ns for this display), either as an argument to the function, or in the config file. There would also need to be a way to either schedule commands at specific times in the future, or to configure the minimum time between the end of one command and the next (72us for this display). So the config file for a ST7920 might look like this:

LCD_PIN_CS = G4 LCD_PIN_MOSI = G3 LCD_PIN_SCLK = J2 LCD_PIN_MIN_SCLK_PERIOD = 600ns LCD_PIN_MIN_CMD_INTERVAL = 72us LCD_LCD_DRIVER = "lcd_st7920.py" # Tell Klipper which LCD module to initialize

[marcio-ao]

This particular display does not ever send data back, but I have worked with a color touch LCD that does require that. I'm not sure how to expand the above interface to contain the reply to SPI commands. That could become trickier if it is done asynchronously via a queue. Fortunately, at least the RepRapDiscount display does not require that.

[KevinOConnor]

On Mon, Jan 15, 2018 at 10:38:28AM -0800, Marcio Teixeira wrote:

@KevinOConnor: The pause does not need to be part of the lcd_cmd(...), as long as each command could be scheduled in the future when the LCD would be ready for the next command. The FW would have a function like schedule_lcd_command(time, rs, bool) and the Python code would do repeated calls like this:

schedule_lcd_command(current_time + 72 1, 0, 0, 0x00); schedule_lcd_command(current_time + 72 2, 0, 0, 0x00); schedule_lcd_command(current_time + 72 * 3, 0, 0, 0x00);

The only delays that would be necessary inside "schedule_lcd_command" are to honor the 600ns minimum period of the SCLK signal; there are 24 bits in each command, so "schedule_lcd_command" would take 14.4us to execute per command.

Does this fit into the required granularity of Klipper?

It's difficult to make that work well, because we don't want the lcd updates to be run at a high priority - if a stepper is going off at a specific schedule, then we want the stepper events to occur and any lcd events to be delayed. That means, we don't really know the time that the lcd writes will occur. (Or, more precisely, we really don't want to attempt to calculate a good update time given all the other things going on in the system.)

On Mon, Jan 15, 2018 at 10:44:51AM -0800, Marcio Teixeira wrote:

Of course, all this timing stuff is sort of a pain in the ass to handle from Python. Your idea of simply having a buffer I can write commands to is much more convenient. Each command consists of two bits, rs and rw, and a data byte... these could all be packed in a uint16_t, if that is convenient. If you could provide me with a function like that, I could rewrite the rest of the Arduino code as a .py file and take it for a test run.

I've put together a test branch (work-lcd-20180115) with some rough code with a simple buffering system. It's based on the comms protocol you outlined earlier. I don't have the equipment, so it is not tested (other than some simple unit tests). However, maybe it can be expanded to your needs?

The basic idea is that klippy/lcd_st7920.py has two high level functions - send_command() and send_data(). The first is used to write a command byte (RS=0) to the lcd. The second is used to write a data byte (RS=1) to a particular DDRAM / CGRAM address.

-Kevin

[marcio-ao]

@KevinOConnor :

The first is used to write a command byte (RS=0) to the lcd. The second is used to write a data byte (RS=1) to a particular DDRAM / CGRAM address.

I'm not entirely sure whether "rs" is supposed to mean "write data", but looking through the ST7920 datasheet, it seems like it is only used in "write_ram" and "read_ram" opcodes and reading cannot happen in serial mode, so it seems like a good call to condense it down to two functions with a single byte of data.

That means, we don't really know the time that the lcd writes will occur. (Or, more precisely, we really don't want to attempt to calculate a good update time given all the other things going on in the system.)

Okay, this makes sense. Since the LCD commands have a clock signal, they can be sent out as fast or as slowly as needed. You could even do work in between sending individual bits, if that would be convenient.

I've put together a test branch (work-lcd-20180115)

Okay, I'll see if I can get to this week. The Marlin folks have also expressed an interest in this lightweight UI, so I have my work cut out for me. I'm now trying to rough out a menu system to go with the status screen.

[marcio-ao]

@KevinOConnor : I build the "work-lcd-20180115" branch, installed the new FW, and then added the following to "config/lulzbot-taz6-2017.cfg":

[lcd_st7920]
cs_pin: PG4
sclk_pin: PJ2
sid_pin: PG3

However, when I run Klippy I now get:

INFO:root:Sending MCU 'mcu' printer configuration...
ERROR:root:MCU error during connect
Traceback (most recent call last):
  File "./klippy.py", line 196, in _connect
    m.connect()
  File "/home/aleph/git-repos/klipper/klippy/mcu.py", line 604, in connect
    self._send_config()
  File "/home/aleph/git-repos/klipper/klippy/mcu.py", line 558, in _send_config
    self._name, self._shutdown_msg))
error: MCU 'mcu' error during config: st7920 not configured

Any ideas?

[KevinOConnor]

On Wed, Jan 17, 2018 at 03:44:35PM +0000, Marcio Teixeira wrote:

@KevinOConnor : I build the "work-lcd-20180115" branch, installed the new FW, and then added the following to "config/lulzbot-taz6-2017.cfg":

[lcd_st7920]
cs_pin: PG4
sclk_pin: PJ2
sid_pin: PG3

However, when I run Klippy I now get:

INFO:root:Sending MCU 'mcu' printer configuration...
ERROR:root:MCU error during connect
Traceback (most recent call last):
  File "./klippy.py", line 196, in _connect
    m.connect()
  File "/home/aleph/git-repos/klipper/klippy/mcu.py", line 604, in connect
    self._send_config()
  File "/home/aleph/git-repos/klipper/klippy/mcu.py", line 558, in _send_config
    self._name, self._shutdown_msg))
error: MCU 'mcu' error during config: st7920 not configured

Any ideas?

I'd need to see the full log (attach /tmp/klippy.log to this issue). Also, try a FIRMWARE_RESTART, and after getting the failure, issue an M112. (The M112 will add more debugging to the log.)

-Kevin

[marcio-ao]

@KevinOConnor : Here is the log file:

klippy.log

[KevinOConnor]

On Wed, Jan 17, 2018 at 08:29:32AM -0800, Marcio Teixeira wrote:

@KevinOConnor : Here is the log file:

Oops - a timing race with configuration vs starting off the background demo code. Can you "git pull" and try again?

-Kevin

[marcio-ao]

@KevinOConnor : That worked! I modified "lcd_st7920.py" to turn on the blinking text cursor. You can see it on the upper left. There probably still are a few timing issues as I am also getting some garbage Chinese characters. But hey, it's a first step! Where would I go to alter the timing from 72u to something longer?