Firmware Based on newer Klipper Version

[NightHammer1000]

Hello.

Current Firmware is based on v0.10.0-530.
Which is now almost 3 Years old.

Are there any plans to adapt the Firmware to a newer Version to make use of the Advancement of the last 3 Years?

[CChen616]

If you have basic knowledge of Linux systems and how to flash klipper firmware, you may refer to this topic:
QIDITECH/klipper#1
There are discussions about how to install a clean version of Klipper or how to upgrade Klipper (Not detailed enough though).

Currently, we are unable to provide a one-click firmware update package.

[NightHammer1000]

But doesnt this break the integrated Display?

Also, you said currently. What about future plans? This will decide if I return the Printer or not. I am not willing to pay over 600 Bucks on an outdated system.

In my first 2 Hours with the printer I already stumbled over an Unsupported G-Code I simply need because it Helps with Stringing. Orca Slicers Spiral Z-Hop. It Generates G17. Which this old Klipper Version does not support. And I am really not willing to start to tear apart new Hardware that cost that much.

[CChen616]

G17 is a G-code macro built into Orca or Bamboo printers, not originating from the official Klipper. If you still wish to upgrade Klipper, I will provide detailed firmware flashing instructions (You will need to flash mcu yourself) and list the files that need to be replaced after update. This method will not break the integrated display.

The solutions provided by others in that topic are essentially equivalent to starting from scratch with system flashing and installing Klipper, which would break the display.

[NightHammer1000]

This would be great. As some, things got much better from 0.10 to now. Especially Input Shaping.
If you could provide a Guide for this, this would be great.

And no. G17 is part of Klipper for a while now as part of the Arc support:
https://www.klipper3d.org/G-Codes.html#gcode_arcs

[CChen616]

My apologies, my intention was to clarify that the G-code generating the G17 is specific to Orca and Bamboo models and does not work on our machines. We expect to provide an upgrade tutorial by tomorrow.

[NightHammer1000]

Thank you.

With the newer Version of Klipper it will work. Has nothing to do with Model. It works on my self build 300x300x300 Bedslinger.
Just a matter of missing support in the old Firmware Version.

But thanks. Looking forward to it. This will Level up the Printer greatly for me.

[NightHammer1000]

Is it the /root/xindi folder thats resposible for the Display?
The makerbase-client systemd Service?

I see this Programm talks to the Moonraker websocket and also opens a serial tty.
This seems to be the Programm Talking to Klipper and the Screen.
So basically if I just update Klipper and moonraker to the newest version, flash the newers Klipper on the MCUs and leave the xindi as is, I should be good to go?

[CChen616]

This version has not undergone detailed testing. If you encounter any issues, please reply below and I will follow up. This update method is only applicable to the Plus3 and Max3 models.

Before start you need to prepare an SD card and an SD card reader.

1. Login to the printer system using ssh tools such as MobaXterm (Recommended) or Xshell

user: root
passwd: makerbase

2. Update klipper

cd /home/mks/klipper
# Discard all changes
git checkout -- .
# Downlaod the newest klipper
git pull

If error like below occurred during update:

Just delete the listed file

3. Flash MCU firmware

Remember to save each time changing config

For mother board MCU

make clean
# Configure according to the instructions shown in the picture
make menuconfig
make

Then download the generated klipper.bin to your pc and rename it with X_4.bin, move it to your SD card using reader. Then load SD card to the mother board, restart the machine.

For extruder MCU
Make sure no other USB device is connected to the printer
Start machine while pressing the boot button on the extruder board (You can release the button once the printer has fully started up)

Run

lsblk

and if it shows

sda            8:0    1   128M  0 disk
└─sda1         8:1    1   128M  0 part /home/mks/gcode_files/sda1

It means the Raspberry Pi has been connected as a USB device then you can keep going

make clean
# Configure according to the instructions shown in the picture
make menuconfig
make
cp /home/mks/klipper/out/klipper.uf2 /home/mks/gcode_files/sda1

Restart printer then the extruder MCU is flashed

For mcu rpi

# Configure according to the instructions shown in the picture
make menuconfig
make clean
sudo service klipper stop
make flash
sudo service klipper start

4. Replace files
Replace the corresponding Klipper files with the ones from the archive.
files_to_replace.zip
5. Download python library

/home/mks/klippy-env/bin/pip install greenlet==2.0.2

6. Restart klipper

sudo service klipper restart

You may need to update printer.cfg as new features added and something old is deprecated
Then Klipper has been successfully updated. Happy printing!

[CChen616]

Is it the /root/xindi folder thats resposible for the Display? The makerbase-client systemd Service?

I see this Programm talks to the Moonraker websocket and also opens a serial tty. This seems to be the Programm Talking to Klipper and the Screen. So basically if I just update Klipper and moonraker to the newest version, flash the newers Klipper on the MCUs and leave the xindi as is, I should be good to go?

We have modified some part of klipper and moonraker to accommodate makerbase-client which is controlling the display, if you want to also update moonraker, please refer to: QIDITECH/moonraker#1

[leadustin]

@CChen616
Just to be clear. I have completely updated my X-Plus 3 as described in my guide. Armbian Bookworm, Klipper and Moonraker are up to date. I would like to put my old display back into operation for testing purposes. Is it sufficient to copy the Klipper and Moonraker files you provided over the original files and create the symbolic links etc.?
In addition, I would have to copy xindi and the udp_server to root and start the makerbase_client

[CChen616]

@CChen616 Just to be clear. I have completely updated my X-Plus 3 as described in my guide. Armbian Bookworm, Klipper and Moonraker are up to date. I would like to put my old display back into operation for testing purposes. Is it sufficient to copy the Klipper and Moonraker files you provided over the original files and create the symbolic links etc.? In addition, I would have to copy xindi and the udp_server to root and start the makerbase_client

Theoretically it should work, but note that the replacement files I provided are based on different versions and models, and they might not be universally compatible. You should back up your current files, then try replacing them. If it doesn't work, you can provide the relevant logs, and I will do my best to help you identify the problem.

Edit: The modifications to Moonraker mainly involve the generation of preview images, integration with Qidi Slicer, and disabling component updates on the fluidd interface (included in the update_manager.py file. If you still want to keep auto updates, you can choose not to replace this file)

[NightHammer1000]

Nice! Thanks for the changed moonraker files. Should be a breeze to merge these to a fork of upstream now that I know what exactly changed. Makes for a nice weekend project. Can you also tell me the changed klipper files?

Another Question. @CChen616 do you have an Stock Firmware Image you could share for flashing back to EMMC for recovery purposes?

[leadustin]

Stock Firmware Image you could share for flashing back to EMMC for recovery

X-MAX-3/X-Plus-3 EMMC Image Stock https://drive.google.com/file/d/169c8aaMe8YdqOP-cswjxlOCQqbp_6HrL/view?usp=drive_link
And for Smart 3 https://drive.google.com/drive/folders/1rzzRVYacc5VQminsbCvWeUuSeN6h4WpU?usp=drive_link

All stock images provided by Qidi. You can check also here
https://qidi3d.com/products/x-max-3-x-plus-3-x-smart-3-emmc-32g?variant=41743651930252

[leadustin]

Can you also tell me the changed klipper files?

klipper files
#27 (comment)
direct link: https://github.com/QIDITECH/QIDI_PLUS3/files/15087211/files_to_replace.zip

[fran6p]

@NightHammer1000
If you should have to revert back to recovery, you'll have to make firmwares (mcu, rp2040, rpi) with the version of Klipper from the recovery image (0.10.x).
:-)

[NightHammer1000]

Great. I will start a klipper and Moonraker fork and merge these in.
With the Git Tree intact it should be easier to merge in future upstream changes.

[billkenney]

I was able to get my max 3 to run Debian bookworm with the latest fluidd, klipper, moonraker running on my max 3, with a working screen, by following these steps: https://github.com/billkenney/update_max3_plus3. Not sure all of the steps are necessary, but it seems to work.

[leadustin]

What about the xindi server? Is it no longer needed?

[nessex]

I also managed to get this to work, using a combination of the instructions above from @CChen616 and @leadustin's excellent guide over here:
https://github.com/leadustin/QIDI-up2date-english/blob/main/Klipper-Update/update+upgrade.md

In my case, I avoided the debian bookworm and eMMC updates for now. Some notes:

• There are many issues to do with certs and time if sticking with debian buster. Start chronyd to sync clocks any time you need: systemctl start chronyd. systemctl enable doesn't work here. timedatectl will tell you the current system clock time.
• Instructions above do not cover backups nor kiauh. kiauh includes a simple copy-based backup function, just run the /home/mks/kiauh/kiauh.sh script and choose the backup option from the menu. Backup everything you can before starting. Backups are saved to /home/mks/kiauh-backups.
• For kiauh etc., you need to run as a non-root user, user: mks password: same as root exists, use sudo su - mks to switch from root to mks user
• after running kiauh backup (or manually backing up directories), clean up git state in /home/mks/klipper with git reset --hard HEAD && git clean -fd before git pull. Note: this'll permanently delete the modifications made by qidi, which is why you need the backups above.
• Git pull etc. will probably fail if you are using the included wifi adapter, because it's absurdly slow. A direct ethernet connection, or ethernet via an access point is very helpful (e.g. TP-Link TL-WR802N)
• After cleaning up git state, use kiauh to update all components as-per @leadustin's guide
• Fluidd UI tells you when you access it which devices in your printer haven't had their klipper updates applied in a big red / orange notification. Use this to check if each update was successful before proceeding.
• The files_to_replace in the instructions above had some issues with the latest version of klipper. I patched them manually, but found that in the end they just weren't necessary, so ended up just not using those files.
• Instructions above (and kiauh) assume you want the latest commit from the klipper repo.
• In /home/mks/klipper_config/printer.cfg I needed to change all instances of printer.probe["x_offset"] with printer.configfile.settings.probe.x_offset and the same for y_offset
• Also in printer.cfg, due to deprecation I replaced max_accel_to_decel: 10000 with minimum_cruise_ratio: 0.5, IIUC this is equivalent, but you can also just delete the old one as 0.5 is the default cruise ratio.

So far, printing, z-offset and input shaping all work via the screen. But need to be careful of all those when run via fluidd, print head crashes etc. are still easy to cause.

[leadustin]

Thank you for your explanation. Would you like to make your files available here?

[billkenney]

What about the xindi server? Is it no longer needed?

The firmware update (step no 5 in my guide) installs the xindi files, and the xindi services are installed in step no 8. I wasn’t able to get the screen to work without them.

[nessex]

@leadustin My files are mostly as-per the various instructions. And the changes I made to the code (which I ended up reverting and ignoring) look very similar to what @billkenney did. I've put together a script that does pretty much everything I actually used to get mine working. I've tested most of it piece-by-piece, but not the whole thing together (I'd need to reset my machine from backups but it's currently printing...successfully!).

If anyone is feeling adventurous and is quite comfortable fixing up any problems that appear along the way, please try it and let me know if it works for you!

https://gist.github.com/nessex/7b574fbe6d965439b773d922ca1b9e05

As with my comment above, this updates everything except the OS distro / EMMC. So should end up on latest Klipper, Moonraker, Fluidd, KlipperScreen and also any dependencies and distro packages. Most of the upgrade happens via KIAUH.

The fact that the base OS + extras didn't change might be why the screen still works in my case. Though armbian completely dropped buster a couple of months ago with little / no notice, so the OS upgrade would be nice if I can get it to play well.

I'd like to try @billkenney 's upgrade for the OS starting from this point once I get a chance (and an EMMC flasher). In my mind, it'd be great to make this available without the EMMC portion because most people can do it with the hardware on-hand. But for those with the EMMC flasher, they can go that step further. I can't see any reason it wouldn't work after the fact just as well, especially given most of the /home/mks directory can simply be copied across post-OS upgrade.

[NightHammer1000]

As soon as my EMMC Reader arrives I plan to build a flash ready, up to date Image.

[nessex]

Minor issue: I occasionally get this error now.

Movement beyond range of provisions

I noticed it when moving the Z-axis manually via the screen. Z height was shown as negative at that point. Had no issues when printing, but it's possible there could be an issue with taller prints.

And also, thumbnails aren't working occasionally. I guess the patch to support jpg thumbnails that was in the qidi changes is needed for that.

[billkenney]

I'd like to try @billkenney 's upgrade for the OS starting from this point once I get a chance (and an EMMC flasher). In my mind, it'd be great to make this available without the EMMC portion because most people can do it with the hardware on-hand.

I tried multiple times updating from buster to bookworm by changing buster to bookworm in the sources.list, but never got it to work. So I decided to install a fresh OS, which does have the benefit of an updated kernel.

@nessex so you didn’t overwrite any of the klipper files or moonraker files?

[nessex]

I tried multiple times updating from buster to bookworm by changing buster to bookworm in the sources.list, but never got it to work. So I decided to install a fresh OS, which does have the benefit of an updated kernel.

Yeah understood! Armbian docs say essentially as much, upgrades aren't tested and aren't guaranteed to work :(

@nessex so you didn’t overwrite any of the klipper files or moonraker files?

Nope. Well, I started off by overwriting them as-per the instructions, but after looking at them briefly and fixing a couple of the issues with them (the same ones you found I think), I rolled all the repos back to upstream commits and kept them there. Hitting a couple of minor issues because of that (thumbnails, z-height issue).

I did also just find that the UI to load filament doesn't appear when filament runs out, but if you hit the "stop" button on the print, it does then show the load filament UI. I didn't have replacement filament, so didn't test if the print could still be resumed after that point, but it probably can't. I suspect it could be caused by the thumbnail patch that I'm missing, as that reports an error on the broken UI with the stop button.

I'll probably take another look at those patches over the next few days and try to redo them on top of latest Klipper or something.

[billkenney]

Here's something that's interesting @nessex. You and https://openqidi.com/books/upgrades-updates/page/updating-and-flashing-the-the-toolhead-mcu change printer.probe to printer.configfile.settings.probe in the printer.cfg file. I tried making that change, but got a dict object error that probe has no attribute value. Must be one of the files from qidi. My z offset is also still being saved in config.mksini.

I have noticed that, regardless of the z offset in config.mksini, it seems like the printer forgets it sometimes.

[CChen616]

I have noticed that, regardless of the z offset in config.mksini, it seems like the printer forgets it sometimes.

Regarding the z-offset, if you adjust it using the display button, the value will be saved in config.mksini. However, if you make adjustments through Fluidd by sending commands, it will be saved in printer.cfg. To ensure consistency, please stick to using one method only.

[nessex]

@billkenney Yes you're right, it's in klipper/klippy/extras/probe.py. Don't see why printer.configfile.settings.probe doesn't work for your version though, nothing related to that appears to be removed 🤔

This is a breakdown of the changes that Qidi made to klipper, as-per the files_to_replace.zip file.

Breakdown of patches

CLOSE_MCU_PORT

These changes relate to adding an additional command and exit condition called CLOSE_MCU_PORT. It seems to be an alternative "reason" / status when restarting Klipper etc.

Seems to be used on firmware updates?

QIDI_PLUS3/src/mks_update.cpp

Line 199 in a76432e

close_mcu_port();

Relevant changes in:

• gcode.py
• klippy.py

Relevant changes

gcode.py: 'CLOSE_MCU_PORT' handler

handlers = [[...], 'CLOSE_MCU_PORT']

def cmd_CLOSE_MCU_PORT(self, gcmd):
        self.request_restart('close_mcu_port')
    cmd_CLOSE_MCU_PORT_help = "Close the port of mcu"

gcode.py: self.gcode_handlers

Qidi commented out the following:

def _handle_shutdown(self):
    [...]
    # self.gcode_handlers = self.base_gcode_handlers

Seems to reset the set of gcode handlers which are registered as status commands. Not sure exactly what that means.

klippy.py: close_mcu_port

def run(self):
    [...]
        try:
            [...]
            if run_result == 'close_mcu_port':
                for n, m in self.lookup_objects(module='mcu'):
                    m.microcontroller_close_port()

klippy.py: printer run loop close_mcu_port

def main():
    [...]
    while 1:
        [...]
        printer = Printer(main_reactor, bglogger, start_args)
        res = printer.run()
        if res in ['exit', 'error_exit', 'close_mcu_port']: # 'close_mcu_port' added
            break

TRSYNC_TIMEOUT

This timeout was changed from the hardcoded 0.025 to 0.10.

An explanation for why you might want to do this is here:
DangerKlippers/danger-klipper#88

Unfortunately it's still hardcoded in Klipper.

We will see issues in the logs as Communication timeout during homing z if these timeouts are happening.
Related PR: Klipper3d/klipper#3956

Relevant changes:

• mcu.py

SET_KINEMATIC_POSITION

Qidi has enabled SET_KINEMATIC_POSITION command by default. This is already configurable in Klipper via the config enable_force_move.
We could ignore this patch and simply change the config, however this also enables the FORCE_MOVE command.

Edit: Actually, this is enabled by default in printer.cfg. Therefore, this patch is redundant I think.

SET_KINEMATIC_POSITION is used at least here:

QIDI_PLUS3/src/event.cpp

Line 4028 in a76432e

ep->Send(json_run_a_gcode("SET_KINEMATIC_POSITION Z=130\n"));

Relevant changes:

• extras/force_move.py

Probe status details

Qidi added status outputs to probe.get_status()

• last_z_result
• x_offset
• y_offset
• z_offset

This is referenced once over here:

QIDI_PLUS3/src/mks_printer.cpp

Line 205 in a76432e

if (probe["x_offset"] != nlohmann::detail::value_t::null) {

It's also used in some gcode macros in printer.cfg.

In mks, the main use seems to be to make moves that center the probe on the build plate:

QIDI_PLUS3/src/event.cpp

Line 2920 in a76432e

int xtemp = (printer_toolhead_axis_minimum[0] + printer_toolhead_axis_maximum[0]) / 2 - printer_probe_x_zoffset;

Kind of curious how much difference this makes versus just centering the print head, given we're adjusting based upon the nozzle more so than the sensor.

But changing this either means modifying Klipper as Qidi did, or modifying mks... Both options kind of suck.

Relevant changes:

• extras/probe.py

Reset of z_offset

After calibration, Qidi replaced the part where the probe z_offset is saved to the config file, to instead just save zero each time.
I presume this is related to what @CChen616 mentioned in the previous comment?

Not quite sure why mks needs it's own value. Given Fluidd etc. also mess with this value, it might be good to find a way to unify it in mks?

Relevant changes:

• extras/probe.py (probe_calibrate_finalize())

Modified temperature multiplier for the thermocouple

MAX6675_MULT = 0.25 * 0.95 # Changed from: 0.25

Changes the hardcoded multiplier for the probe ADC values to 0.2375. Doesn't seem this is something that can be configured in Klipper...

Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6675.pdf
Related issue: Klipper3d/klipper#1664

Seems like the multiplier is set based upon the resolution of the output. Did the commit that resolved that issue also fix the numbers here?

Related changes:

• extras/spi_temperature.py

Changed encoding for virtual_sdcard

import [...]

reload(sys)  # Added
sys.setdefaultencoding('utf-8')  # Added

This is a fix for the default ASCII encoding in python2. With python3 utf-8 becomes the default anyway.
Specifically, this is for the encoding when reading lines of gcode from the local filesystem. I presume the main issue is with comments outside the ASCII range. Both the gcode macros in printer.cfg and the output of some programs (apparently Autodesk Fusion?) have unicode characters (e.g. comments in Chinese).

I presume the better fix here is to update klipper's python env to use python3. Klipper itself seems to be compatible with it, but this specific patch is not. So if we ignore this patch and migrate to python3... should be fine?

In summary, there are a few things which may not work correctly with upstream Klipper alone:

• Temperature may or may not be reported incorrectly by ~5%
• Gcode files containing unicode may not work correctly
• z_offset config won't be reset to zero in printer.cfg after calibration (this might be the cause of some of the weirdness around z_offset config both before and after these changes)
• mks centering the z probe on the build plate will instead center the nozzle on the build plate (assumes offset is zero) during certain operations
• mks may not handle firmware upgrades correctly, as they have logic expecting a different exit condition from Klipper (CLOSE_MCU_PORT)
• Homing the Z axis may encounter timeouts in individual movements (TRSYNC_TIMEOUT) if the various MCUs don't talk to each other in time

Some of the changes could have further reaching effects as well, particularly the parts that interact with mks. But these are the ones that I could see.

[nessex]

Based upon that, ended up migrating my Klippy to python3. No issues yet, but will see... Script is updated as well:
https://gist.github.com/nessex/7b574fbe6d965439b773d922ca1b9e05

FYI: The greenlet step above is no longer required since this change: Klipper3d/klipper#6525

Python3 still isn't the main supported version of python for Klippy / Klipper, but it seems to be well accounted for over the past few years by the developers.

In my opinion at least, the most serious issue above was the gcode incompatibility, so it's worth the switch to resolve that while also keeping the benefits of latest Klipper without a fork.

[NightHammer1000]

Today I learned you can USB Boot from that Board.
Just flash Armbian to an USB Drive and stick it in one of the Free USB Ports.
Sooo. Basically no need to touch EMMC

Aaand you can flash EMMC without an USB Adapter

USB Boot has Priority over EMMC. So you can plug a USB in Up top in the External USB Boot and the Printer will boot from there each time. That one is USB3 only tho.

So if you want to go that route I recommend plugging into the USB 3 Port where the USB Wifi Dongle is in and switching over the Wifi Dongle to USB2

[billkenney]

I just reverted to vanilla klipper, and I got complaints about the printer.probe["x_offset"], so I replaced it with printer.configfile.settings.probe.x_offset, but I still got complaints about dict object having no attribute probe. I have the bltouch, so I changed it to printer.configfile.settings.bltouch.x_offset, and it seems to be working. Something to take note of, because I could see it being a tricky issue to troubleshoot for a lot of people.

[nessex]

Today I learned you can USB Boot from that Board.
Just flash Armbian to an USB Drive and stick it in one of the Free USB Ports.
Sooo. Basically no need to touch EMMC

Nice! I wasn't aware of that. Will play with that in the next couple of weeks.

I took a deeper look at the moonraker changes. They are much harder to separate out, particularly because they seem to be at least partly used by software that I don't know anything about (maybe xindi or xinwangka?). For now, I applied the patches to a more traditional fork of moonraker over here: https://github.com/nessex/moonraker-qidi-patched

It'd be great if https://github.com/QIDITECH/moonraker could be updated to be a true fork, with history maintained. That would make it much easier to keep moonraker up-to-date (even if only on branches or forks of QIDITECH/moonraker).

Some more details on the changes to moonraker are over here: nessex/moonraker-qidi-patched#1
And my script has been updated to automatically change over to this fork for the moment, because without these patches the UI is quite broken: https://gist.github.com/nessex/7b574fbe6d965439b773d922ca1b9e05

I saw this thread pop up in a few places like Reddit, so thought it would be better to get rid of a few of the big UI issues that you'll get if updating via that script. No guarantees it all works though, still finding little rough edges.

[billkenney]

@nessex I’ve been running the mainline version of moonraker for like a week now without issue. Based on your notes about the patches, it seems as if the main purpose of Qidi’s patches is thumbnails? Which only ever worked for me if I printed a gcode file directly from the display. What UI issues have you noticed without the moonraker patches?

[nessex]

I think the thumbnails were the main broken thing in the UI.

Outside of thumbnails themselves, I also had issues with the print UI getting stuck during prints, requiring me to hit the back button a couple of times to get back to the main menu view after the print finished. This UI also didn't show the typical stats on temperature, fan speed etc. during the print. Not a huge issue, but it certainly made it look more broken. I suspect this was broken because of the thumbnails, as nothing else on those screens seems related to any of the patches.

Since moonraker is also the API that some of the other bits of software use, I'm not 100% certain if any of them (say xindi) also check the machine name which includes the model name (X-Plus3 etc.) for some variation in their behavior. Maybe @CChen616 can you confirm if that machine name or any of these other patches are used outside of the UI / fluidd?

[CChen616]

For 3-series printers, the device names are typically only used for detection purposes by Qidi Slicer.

Xindi subscribes to printer object information from Moonraker, and once there's any change, it receives messages.
From my experience, if the screen cannot display fan speed, temperature, etc., it's likely because you've modified the printer.cfg, changing the names of fans or heaters, causing Xindi to not retrieve the corresponding object names. Alternatively, it could be due to changes in the message format returned by the newer version of Moonraker, resulting in parsing failures.

Regarding Fluidd, the only changes we made were swapping the Z-axis direction and changing the default port (from 80 to 10088).

[NightHammer1000]

I ran into many of the Issues too and just ended up going full stock klipper all around and replacing the Screen.
Used an Banana Pi P2 Zero and a cheap 5" HDMI Touch Display of Amazon and 2M long cables to route them back into tech compartment.

The changes QIDI made are not very clean and a pain to maintain upstream.
The only Solution would be to Adapt the Display Firmware to an self - written Service that can work with stock moonraker.
But given that the Editor for the Firmware is only Chinese, I won't tackle that.

So if you want to update, you better go the full route, or you will always have small Issues and general unreliability.

For Future Reference QIDI, If you build a Printer, please stop modifying the Open-Source Firmware. Klipper, Fluidd, Moonraker and KlipperScreen bring everything we need. Even more than your own Solutions.

My Solution of BananaPi P2 Zero 2, a Screen and Cables cost about the same as the Nextion Screen Equivalent you used in the Printer fyi
If you subtract the Time spent on Building the Screen Firmware, a KlipperScreen Solution would have been overall cheaper.

[billkenney]

Outside of thumbnails themselves, I also had issues with the print UI getting stuck during prints, requiring me to hit the back button a couple of times to get back to the main menu view after the print finished. This UI also didn't show the typical stats on temperature, fan speed etc. during the print.

The only issue I've noticed is the thumbnails, but those never really worked anyways. The stats and everything else seem to work fine. The only time the screen has frozen and I've had to restart the printer is when I'm loading filament, and I press the "Retry" button.

I am running a different OS with python 3.12. I wonder if these issues have to do with the python version or the outdated OS?

[stew675]

My Solution of BananaPi P2 Zero 2, a Screen and Cables cost about the same as the Nextion Screen Equivalent you used in the Printer fyi
If you subtract the Time spent on Building the Screen Firmware, a KlipperScreen Solution would have been overall cheaper.

I was able to find a more fully featured version of the shipped TJC clone screen online for US$34 here. I'd would not be surprised if Qidi were paying less than $20 for the screen they're shipping, especially when purchased in bulk. Additionally the main board doesn't need to have a more expensive HDMI port than the serial port that the TJC-clone is using. The stock screen only requires a single very cheap cable. I doubt that the total cost of the screen solution is much more than $20 all up, which is WAY cheaper than a full KlipperScreen implementation, which I think would be difficult to get it much under $50.

[NightHammer1000]

TJC Screens can only be flashed with the Chinese Editor.
So they are pretty much useless outside of mainland china. And the Nextion are up to 50% more expensive. But honestly. Just with the Google Pixel. I gladly pay an additional 100 Bucks if I don't have to deal with badly done OEM Customizations to the firmware.

I now see that the Changes to the Firmware Itself are what keeping the Firmware from being Updated. Thus, this Issue is pretty much solved for me.

Thanks for the Input.

[stew675]

So they are pretty much useless outside of mainland china. And the Nextion are up to 50% more expensive. But honestly. Just with the Google Pixel. I gladly pay an additional 100 Bucks if I don't have to deal with badly done OEM Customizations to the firmware.

I think that there would be a good number of users who would like the option of a Qidi developed "Vanilla Klipper Pack" that converts the printers into a full mainline Klipper with a Qidi supplied capacitive touch screen with a minimal Pi-clone device running Klipper Screen, and mounted in the frame somewhere, possibly drawing power from the same cable that drives the stock screen with some adapter. That would arguably be ideal given the current limitations of the main-board design.

Thing is, from a business perspective, Qidi would need to provide support for that, which they may not want to do. Still, it would definitely be nice to have.

I now see that the Changes to the Firmware Itself are what keeping the Firmware from being Updated. Thus, this Issue is pretty much solved for me.

I believe this to be perhaps the singularly most important thread for the wider Qidi community who want a more vanilla experience. I am sad that you chose to close it while there's still good work, development, and discussions happening.

I believe it would serve Qidi well to polish up the work here and let certain of the more technical focused Youtubers know that there is a vanilla Klipper solution available. That would solve arguably the single biggest gripe that I see brought up constantly online that the current Qidi printer OS/firmware is holding them back from considering purchasing one. The community driven X1Plus firmware for BambuLab X1 printers would be a good model to follow. With the release of the Sovol SV08 as well that runs vanilla Klipper as stock, I believe that Qidi, now more than ever, need to advertise that there is a way to use vanilla Klipper on their printers should users choose to do so.

Just my 2c.

[leadustin]

I believe this to be perhaps the singularly most important thread for the wider Qidi community who want a more vanilla experience. I am sad that you chose to close it while there's still good work, development, and discussions happening.

I believe it would serve Qidi well to polish up the work here and let certain of the more technical focused Youtubers know that there is a vanilla Klipper solution available. That would solve arguably the single biggest gripe that I see brought up constantly online that the current Qidi printer OS/firmware is holding them back from considering purchasing one. The community driven X1Plus firmware for BambuLab X1 printers would be a good model to follow. With the release of the Sovol SV08 as well that runs vanilla Klipper as stock, I believe that Qidi, now more than ever, need to advertise that there is a way to use vanilla Klipper on their printers should users choose to do so.

I think it would be easy for Qidi to upgrade their existing hardware to native Klipper. The problem, as so often, is the cost of support. Warranty claims for failures. Xindi would have to be available as documented source code in order to be able to react accordingly to updates. Likewise the software for the display. I have the editor from Qidi and I have access to the corresponding HMI. But it is difficult to work properly on a Chinese-language editor. I can understand anyone who gets a Pi and a display and runs Klipperscreen.

But I also hope that the community will continue to work on the display and provide a usable solution at some point.

[CChen616]

I've received all your feedback and suggestions, and I'll propose to the team that future developments on Klipper should aim to add features on top of the original version rather than modifying it.

The Series 3 machines were launched before I joined the company, so there might be gaps in my understanding when responding to your questions. However, I am responsible for the Klipper, Moonraker, and Fluidd components for later models. If you have any ideas or suggestions, please feel free to share them with me.

The discussion atmosphere in this post is excellent, but I believe it has become somewhat lengthy, making it difficult to extract useful information. Discussions in git repositories are now open, and I encourage everyone to initiate discussions there.

[stew675]

I've received all your feedback and suggestions, and I'll propose to the team that future developments on Klipper should aim to add features on top of the original version rather than modifying it.

Thank you so much for taking this all on board @CChen616

After thinking and sleeping on it, arguably the best solution for existing machines would be to move all Qidi specific items into Xindi, and for Xindi to communicate to a vanilla Moonraker. This allows Qidi the freedom to provide OS and Klipper updates without breaking everything, and addresses the commonly raised issue that Qidi printers are stuck on a 3yo OS + Klipper version. When done this way Qidi still gets to keep the stock UI and the Qidi-way of driving the printers from the on-screen UI which can still be developed as Qidi sees fit.

The stock display as it is offers pretty much all the functionality that a user needs when standing at the printer. The g-code model scrolling is super-slow though, and I would presume that's because of the slow serial bus speeds between the HMI screen and the main-board. At the very least, providing a few buttons to change between an alphabetical or time-descending sort order would solve most gripes people have.

For those who really want a Klipperscreen experience, that can be achieved with a separate smartphone/tablet/whatever and just connect to Moonraker over the network. Actually, this is already possible today, just that it isn't advertised. Perhaps add that to your shop feature page so as to make it clear that Qidi printers do support interfacing with Klipperscreen as stock.

Then as part of the press package that Youtubers receive, explain that the stock screen is intentionally a minimal experience that still provides the most commonly used basic functions in order to keep costs down. Most Youtuber's seem unable to grasp that it's a pricing decision, and it is okay to explain this to them. Also explain that users can purchase a separate Klipperscreen tablet if they want that user experience, and the Qidi printers are already able to support that.

Overall it seems that Qidi is currently very close to being able to tie this all together in a neat way that keeps the existing functionality, as well as detangling the current implementation that is preventing a clean upgrade path. It just requries a small amount of effort at Qidi's end to clean it up, and also refresh some of the marketing material.

[NightHammer1000]

@CChen616 Your help is the most help I ever got out of a 3D Printer Company PERIOD.
The Best experience overall. Huge props for that and I am very grateful.

You guys should definitely strive to be the Google Pixel of 3D Printers. Your Hardware is overall great and keeping software as close to stock is, at least in my eyes, a huge selling point only a select few have even done until now.

[billkenney]

The discussion atmosphere in this post is excellent, but I believe it has become somewhat lengthy, making it difficult to extract useful information.

@CChen616 In my opinion, the easiest way to allow customers to update their systems is to create system images with the updated software, and provide those images along with instructions on flashing the MCUs. The flashing process can partially be scripted, like @nessex has done. And the only changes that need to be made, I believe, are to moonraker for thumbnails. You could create a script that checks the necessary moonraker files on every restart and patches them if they do not contain the necessary changes. This would allow customers to keep all of their software updated, while still maintaining the full functionality of the software.

Given how many people have engaged in this discussion, I would imagine some of us would be willing to create those images/scripts if Qidi would be willing to host them and provide instructions on updating.

The only question is whether Qidi is willing to offer support and warrant printers that have updated software. On the one hand, it would reduce the number of issues due to people accidentally updating software or issues caused by outdated/modified software. On the other hand, it could potentially increase the number of issues due to software that hasn't been used/tested nearly as thoroughly. Having the latest software would also be good from a marketing perspective.

[CChen616]

Integrating changes to Klipper, Moonraker, and Fluidd into Xindi technology is not feasible. Therefore, my current thinking is to keep future modifications to Klipper lightweight and non-invasive, such as developing them into separate, plug-in-and-use modules and providing detailed documentation (this is still up for discussion as some parts can be hard to seperated and it might not be competitively advantageous).

For the Series 3 machines, the primary steps for thumbnail display are as follows: Gcode files are uploaded, and Moonraker reads the base64 code within the files to generate PNG images of various sizes. Xindi then converts these images into JPG format and transmits them to the screen via serial port. The most time-consuming step indeed is the serial transmission due to the larger size of JPG files, and the fact that the serial screen only supports JPG images.

As for the integration and sale of Klipper screens, the team currently has no plans in this direction :(

Providing images based on the new software version seems to be a viable solution. An automatic detection and patching script is feasible but not reliable, as it could easily lead to file corruption or conflicts.

Regarding warranty after software updates, I cannot provide a definite answer at this moment, this is for the team to decide. However, apart from issues caused by updates that lead to crashes or armbian system not booting , I can help resolve minor problems, such as Klipper not starting, as long as the relevant logs are provided.

[stew675]

I assembled all of the functional diffs between Qidi's versions of Klipper and Moonraker with reference to the specific mainline hashes that they were pulled from. I also eliminated all white-space only changes. These diffs can be found here:

https://github.com/stew675/qidi-diffs

We're talking about 200 lines of changed code in total, and much of that just seems to be text fiddling for which the functionality could be moved into Xindi

KLIPPER CHANGES

• tmc2240.py is already there in later versions of Klipper, so this file was likely back-ported into Qidi's Klipper version, and so isn't essential for a later version.
• x-twist-compensation.py, which is a self-contained file and so would work as an addition to regular klipper, and be made accessible as a custom added g-code, rather than being called directly from within the python code. EDIT UPDATE: it looks like modern klipper has generalised this with AXIS_TWIST_COMPENSATION
• StealthChopHelper is in modern Klipper here: https://github.com/Klipper3d/klipper/blob/434770eaf9d382cccba203a3475ace2dc0653d7b/klippy/extras/tmc.py#L595
• Force_move is also supported in modern Klipper
• the logging character set changes looks like mainline Klipper already supports setting that
• the close mcu-port changes look like a Qidi only thing, but I do see code in modern Klipper for auto-closing the serial port to the MCU. I've not looked closely enough to see if they are doing the same sort of thing. In any event, it looks like this could be implemented in a modular fashion.
• For the timing changes, this looks like it could be separated out into a new variable that could be configured via printer.cfg, and perhaps file a PR against mainline Klipper for it, or maybe just modularize it?

MOONRAKER CHANGES

• For the image handling, it looks like xindi could process all that stuff itself with some added code instead of asking Moonraker to do it
• The rest of it looks like code added to Moonraker to account for things that could instead be done in QidiSlicer in a more portable fashion

FLUIDD CHANGES

• There are none. I did a file by file check, and the Fluidd install my stock Qidi printer (X-Max 3) is a vanilla Fluidd v1.19.0 install

I'm not going to say that I've looked into all this super-deeply, but at a surface level it looks like most of the Qidi mods to Klipper are simply back-ports of newer Klipper features, with almost nothing there at all that can't be ported simply through some adjustments to printer.cfg

For Moonraker, I'm not really seeing anything there that couldn't either be pulled out and done in xindi, or fixed with some patches to QidiSlicer so it less reliant upon custom changes. If every other slicer can do it, then surely QidiSlicer can as well. The most Qidi specific thing there appears to be some file name munging.

For anything left over that absolutely MUST be there, consider filing a PR's against upstream Klipper and Moonraker to get them included. I'm sure if these changes are discussed with the developers that they would be more than happy to advise on a way to incorporate any changes in a consistent manner.

[CChen616]

In later models like the Q1, we've made more changes to software components like Klipper and Moonraker, which is why it's challenging to integrate all these modifications into Xindi.

In Klipper, some changes might seem unnecessary or strange. Some indeed can be optimized, while others have been made in response to less common issues that have arisen since the machines were first launched. Moving forward, maintaining a Qidi-specific Klipper repository might be a better approach.

As for Fluidd, the version on the printers is compiled from Vue source code, and it might be difficult to discern any differences. I'm not sure about the Series 3 machines, but the Q1 model definitely has modified Fluidd.

Given that these machines have been updated for a while now, we're likely to avoid incorporating these changes into the mainline updates for stability reasons. However, adjustments will certainly be made when creating new system images based on the latest software versions.

Currently, I am busy developing the system for a new printer model. I will revisit and work on these updates afterwards.

[NightHammer1000]

One of my Main concern is the wildly outdated Linux Version.
It's a real security concern if you use any kind of Network connectivity.
The Image on my X-Plus 3 was open to multiply critical RCE and Privilege Escalation CVEs.
Believe me. You don't want to be responsible for Hackers turning on the Heaters and burning peoples houses down.

Using some markes I already managed to find a few printers that are open on the Web.

[cptcl]

@NightHammer1000 u may provide a smal guide how you put (setup) the banana pi with the new screen? Maybe this is a good solution. With that u have the possibility to update linux (kernel) and stay up to date with klipper, moonraker and fluidd? (per kiauh?)
Edit: nvm will go and try the guide from leadustin

[NightHammer1000]

Its as easy as setting up any other Raspberry Like board. Flash Armbian to SD Card, install Klipper Screen and point the config to the IP Address of the Printer