Closed NightHammer1000 closed 4 months ago
If you have basic knowledge of Linux systems and how to flash klipper firmware, you may refer to this topic: https://github.com/QIDITECH/klipper/issues/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.
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.
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.
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
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.
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.
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?
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.
MobaXterm
(Recommended) or Xshelluser: root
passwd: makerbase
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
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
/home/mks/klippy-env/bin/pip install greenlet==2.0.2
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!
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: https://github.com/QIDITECH/moonraker/issues/1
@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 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)
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?
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
Can you also tell me the changed klipper files?
klipper files https://github.com/QIDITECH/QIDI_PLUS3/issues/27#issuecomment-2073932891 direct link: https://github.com/QIDITECH/QIDI_PLUS3/files/15087211/files_to_replace.zip
@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). :-)
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.
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.
What about the xindi server? Is it no longer needed?
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:
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.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
.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/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.kiauh
to update all components as-per @leadustin's guidefiles_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.klipper
repo./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
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.
Thank you for your explanation. Would you like to make your files available here?
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.
@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.
As soon as my EMMC Reader arrives I plan to build a flash ready, up to date Image.
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.
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?
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.
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.
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.
@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.
In summary, there are a few things which may not work correctly with upstream Klipper alone:
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.
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: https://github.com/Klipper3d/klipper/pull/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.
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
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.
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: https://github.com/nessex/moonraker-qidi-patched/issues/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.
@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?
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?
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).
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.
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?
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.
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.
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.
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.
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.
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.
@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.
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.
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.
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
MOONRAKER CHANGES
FLUIDD CHANGES
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.
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.
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.
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?