Klipper on the BIQU BX V3

biqu_bx_klipper_v3.md

Klipper on the BIQU BX V3

NOTE: If you have a V2 board/screen(HDMI),click here

First, a few requirements:

1. You need Klipper setup on your Raspberry PI ( borad that support DSI) with your favorite control interface (Octoprint, Fluidd, Mainsail, etc..).
   • I recommend installing official Raspberry Pi OS
     • Download this file https://downloads.raspberrypi.com/raspios_armhf/images/raspios_armhf-2023-05-03/2023-05-03-raspios-bullseye-armhf.img.xz and use the Raspberry Pi Installer and select custom image.
2. Install the Drivers for V3 screen https://github.com/bigtreetech/BIQU-BX/tree/master/Firmware/RPi-Linux-RPi-7inch-DSI
3. You need your favorite Touchscreen UI installed (unless you just want to run headless).
   • Use this to install all you need https://github.com/dw-0/kiauh
     • If you have a issue with the screen is black, press the smal button under the turn knob
4. You MUST have removed the Z endstop physical switch. Not disconnected, but completely removed.

NOTE: CAN will not work on this board due to a hardware mis-configuration
NOTE: I2C is not quite working yet!

Ok, so let's get started.

---

Klipper firmware configuration

When configuring the klipper firmware to run on the BTT SKR SE BX board, there are a couple things to know about.

1. Use the main klipper branch.
2. In order for the toucscreen to work, you will need to set GPIO pins PB5 and PE5 to an initial state during the config
3. Use the config/printer-biqu-bx-2021.cfg file for your intial printer.cfg
4. Once you are setup, you will need to calibrate your sensorless homing: https://www.klipper3d.org/TMC_Drivers.html?h=sensorless+ho#sensorless-homing

A note on connection methods:

There are 4 different connections you can make from the Raspberry Pi to the mainboard, 2 Serial and 2 USB.

• Serial (on UART4 PA0/PA1) <--- For v3 board/screen you need to use this

To use serial connections, you have to enable the serial port on the raspberry pi and compile the correct serial port for the BX mainboard. Once you have the serial port enabled on the raspberry pi, it will show up as /dev/ttyAMAx, with x being the port number.

Once you have it setup, your printer.cfg should then contain the following under the MCU section: serial: /dev/ttyAMAx, substituting the x for your port number.

---

HDMI configuration

As v3 uses DSI you don't need any HDMI settings

Drivers for V3 screen

• Go to and follow the guide https://github.com/bigtreetech/BIQU-BX/tree/master/Firmware/RPi-Linux-RPi-7inch-DSI

Config.txt

Example on /boot/config.txt

Make sure this are in the config.txt file, some wil be added by the drivers installation skript.
[all]
dtparam=i2c_vc=on
dtparam=i2c_arm=on
enable_uart=1
dtoverlay=disable-bt
dtoverlay=vc4-kms-dsi-btt-bxv3-7inch
disable_splash=1

Slicer configuration

For your slicer, you need to call the PRINT_START macro instead of any preliminary gcode. The NOZZLE and BED temps get passed in as arguments. Some examples for the more popular slicers:

• Cura: PRINT_START BED={material_bed_temperature_layer_0} NOZZLE={material_print_temperature_layer_0}
• PrusaSlicer: PRINT_START NOZZLE=[first_layer_temperature] BED=[bed_temperature]
• Ideamaker: PRINT_START NOZZLE={temperature_heatbed} BED={temperature_extruder1}
• Simplify3D: PRINT_START NOZZLE=[extruder0_temperature] BED=[bed0_temperature]
• Kiri:Moto: PRINT_START NOZZLE={temp} BED={bed_temp}

---

Klipper Functionality

Here are some notes on how I have Klipper setup and working quite well for my machine.

Touchscreen Sleep

The Touchscreen will go dark when the printer idle timeout occurs. This happens when there is not a print job in action and currently set for 5 minutes. Pressing the Menu Knob on the display will wake up the Touchscreen.

LEDS

The Neopixels are setup and will cycle through colors on bootup. I have the idle timeout set to shut off the LEDS when the printer is inactive. The LEDs automatically come on when a print is started or when the LCD is wakened.

Homing Routine

I have programmed a reliable homing routine that works well for me, however you can adjust or setup your own to taste. My routine will do the following:

1. Raise the Z axis
2. Home the X axis
3. Home the Y axis
4. Move the probe to the center of the bed (different than the nozzle at center)
5. Home the Z with the probe.

• When starting a print, additionally:

6. After the bed reaches temp, the printer waits for 90 seconds with the probe close to the bed to warm up the probe.
7. Steps 1-5 are repeated with a warm probe
8. Move to the origin to start the print.

What happens when you run this command ? DISPLAY=:0 xrandr

Mine looks like this Screen 0: minimum 320 x 200, current 1024 x 600, maximum 2048 x 2048 HDMI-1 disconnected primary (normal left inverted right x axis y axis) DSI-1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x600 38.40*+

DISPLAY=:0 xrandr
Can't open display :0

I checked the flat cable continuity with a multimeter, board-to-board, and it's ok. Since I have 2 sets of TFT70 and PI I tried the second set with the sane result !

You are sure the printer has klipper? Try to flash it again.
I tried to flash it many times, at start-up it displays firmware update 0%-100% and then rename the firmware.bin into firmware.cur so I suppose it was flaseh correctly.

Hmm, and it's a RPi and not a BTT Pi ? That would explain the screen. But the communication with the MCU should be the same.

the cable is like this on the board

Yes, it's a RPi4 B / 2018, the red wire on the 5V.
Using Octoprint to control the printer flashed with Marlin it used to work, so I guess the connection through the TFT70 is functional

I am wondering if it could be possible to bypass the TFT70 board and connect the PI to the printer using the USB ports ?
I am also considering switching to a Manta board, may be easyer to get working with Klipper ?

I am now able to connect to the MCU using using pin 6-8-10 of the PI and the TFT pins of the SKR-SE-BX-V3.0 (crossing Rx and Tx).
The TFT display is useless (just to confirm that the MCU is flashed correctly).

and configuring serial USART1 PA10/PA9

I am now able to connect to the MCU using using pin 6-8-10 of the PI and the TFT pins of the SKR-SE-BX-V3.0 (crossing Rx and Tx). The TFT display is useless (just to confirm that the MCU is flashed correctly).

Strange that you need to do that.
Well it's not the best screen. I have issue that it's all white until it's "warm"

I had problem connecting to the printer even after following the step described. My settings are the original as varazir adviced. After some research i found that my problem was fixed after removing the section "console=serial0,11520" from '/boot/cmdline.txt' with a text editor.
Now i am able to see the printer using

Здравствуйте, столкнулся с проблемой при установке Klipper.
На сайте когда водишь IP Raspberry pi 4, первым делом появляется вот такое сообщение:

mcu 'mcu': Unable to connect
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Error configuring printer
Много чего перепробовал.

У меня возникли проблемы с подключением к принтеру даже после выполнения описанных шагов. Мои настройки являются исходными, как и советовал Варазир. После некоторых исследований я обнаружил, что моя проблема была решена после удаления раздела «console=serial0,11520» из «/boot/cmdline.txt» с помощью текстового редактора. Принтер использует

Вы смогли решить проблему?

Hello everyone,

I have recently acquired this printer and "reverse engineered" the modified drivers.

The device tries to present an interface similar to the official RPi 800x480 7" touchscreen, but it's larger and weirder. The display panel can actually be declared as a "panel-dpi" and there's no need to add it to the simple panel driver (and that works even in mainline Linux).

Tthe touchscreen works as a "edt,edt-ft5506"… sort of. First of all, only the raspberrypi/linux version of the driver has the necessary polling mode support for now. Then, the hardware nonsense here: the coordinates wrap around weirdly beyond the 800x480 rectangle, so the modified edt-ft5x06 driver they compiled includes a quirk to handle that.

The DT overlay is just this:

dtso source, compile like so: `dtc -O dtb -@ -L biqu-bx.dtso >biqu-bx.dtbo`, USE WITH `dtovelay=upstream` (even with the rpi kernel), I'll try to make a non-upstream overlay too

/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2835";

	fragment@0 {
		target = <&i2c_csi_dsi>;

		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";

			ts@38 {
				compatible = "btt,btt-ft5506";
				reg = <0x38>;
				vcc-supply = <&reg_display>;
				reset-gpio = <&reg_display 1 1>;
				touchscreen-size-x = <1024>;
				touchscreen-size-y = <600>;
				touchscreen-inverted-x;
				touchscreen-inverted-y;
			};

			reg_display: reg_display@45 {
				compatible = "raspberrypi,7inch-touchscreen-panel-regulator";
				reg = <0x45>;
				gpio-controller;
				#gpio-cells = <2>;
			};
		};
	};

	fragment@1 {
		target = <&dsi1>;

		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";

			port {
				dsi_out: endpoint {
					data-lanes = <1 2>;
					remote-endpoint = <&bridge_in>;
				};
			};

			bridge@0 {
				// Actually a chipone,icn6211 inside… controlled by an STM32G0 though.
				compatible = "toshiba,tc358762";
				reg = <0>;
				vddc-supply = <&reg_bridge>;

				ports {
					#address-cells = <1>;
					#size-cells = <0>;

					port@0 {
						reg = <0>;
						bridge_in: endpoint {
							data-lanes = <1 2>;
							remote-endpoint = <&dsi_out>;
						};
					};

					port@1 {
						reg = <1>;
						bridge_out: endpoint {
							remote-endpoint = <&panel_in>;
						};
					};
				};
			};
		};
	};

	fragment@2 {
		target-path = "/";

		__overlay__ {
			panel_disp: panel_disp {
				compatible = "panel-dpi";
				backlight = <&reg_display>;
				power-supply = <&reg_display>;

				width-mm = <154>;
				height-mm = <86>;
				bus-format = <0x1009>;

				panel-timing {
					clock-frequency = <25979000>;
					hactive = <1024>;
					hfront-porch = <2>;
					hback-porch = <46>;
					hsync-len = <2>;
					hsync-active = <0>;
					vactive = <600>;
					vfront-porch = <7>;
					vback-porch = <2>;
					vsync-len = <21>;
					vsync-active = <0>;
					de-active = <1>;
					pixelclk-active = <1>;
				};

				port {
					panel_in: endpoint {
						remote-endpoint = <&bridge_out>;
					};
				};
			};

			reg_bridge: reg_bridge {
				compatible = "regulator-fixed";
				regulator-name = "bridge_reg";
				gpio = <&reg_display 0 0>;
				vin-supply = <&reg_display>;
				enable-active-high;
			};
		};
	};
};

and the basic diff for the driver module is basically:

download the file, rename, apply the following with `patch` and compile like any out-of-tree kernel module, install, run depmod, reboot

--- og-ft5x06.c 2025-05-04 01:58:23.684680853 -0300
+++ btt-borked-ft5x06.c 2025-05-04 01:40:18.597591216 -0300
@@ -14,6 +14,12 @@
  *    http://www.glyn.com/Products/Displays
  */

+/*
+ * THIS is a quirky version for the Biqu BX gen3 display "btt,btt-ft5506"
+ * that has very strange wrap-around coordinates between 800x480 and 1024x600
+ * Recreated by Val Packett, https://val.packett.cool
+ */
+
 #include <linux/debugfs.h>
 #include <linux/delay.h>
 #include <linux/gpio/consumer.h>
@@ -369,6 +375,11 @@

                x = get_unaligned_be16(buf) & 0x0fff;
                y = get_unaligned_be16(buf + 2) & 0x0fff;
+
+               /* WTF: The Biqu BX Touchscreen has misaligned coordinates outside of the 800x480 range */
+               x += (x > 1024) ? -3872 : 224;
+               y += (y > 600) ? -3976 : 120;
+
                /* The FT5x26 send the y coordinate first */
                if (tsdata->version == EV_FT)
                        swap(x, y);
@@ -1594,37 +1605,19 @@
 };

 static const struct i2c_device_id edt_ft5x06_ts_id[] = {
-       { .name = "edt-ft5x06", .driver_data = (long)&edt_ft5x06_data },
-       { .name = "edt-ft5506", .driver_data = (long)&edt_ft5506_data },
-       { .name = "ev-ft5726", .driver_data = (long)&edt_ft5506_data },
-       { .name = "ft5452", .driver_data = (long)&edt_ft5452_data },
-       /* Note no edt- prefix for compatibility with the ft6236.c driver */
-       { .name = "ft6236", .driver_data = (long)&edt_ft6236_data },
-       { .name = "ft8201", .driver_data = (long)&edt_ft8201_data },
-       { .name = "ft8719", .driver_data = (long)&edt_ft8719_data },
        { /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(i2c, edt_ft5x06_ts_id);

 static const struct of_device_id edt_ft5x06_of_match[] = {
-       { .compatible = "edt,edt-ft5206", .data = &edt_ft5x06_data },
-       { .compatible = "edt,edt-ft5306", .data = &edt_ft5x06_data },
-       { .compatible = "edt,edt-ft5406", .data = &edt_ft5x06_data },
-       { .compatible = "edt,edt-ft5506", .data = &edt_ft5506_data },
-       { .compatible = "evervision,ev-ft5726", .data = &edt_ft5506_data },
-       { .compatible = "focaltech,ft5426", .data = &edt_ft5506_data },
-       { .compatible = "focaltech,ft5452", .data = &edt_ft5452_data },
-       /* Note focaltech vendor prefix for compatibility with ft6236.c */
-       { .compatible = "focaltech,ft6236", .data = &edt_ft6236_data },
-       { .compatible = "focaltech,ft8201", .data = &edt_ft8201_data },
-       { .compatible = "focaltech,ft8719", .data = &edt_ft8719_data },
+       { .compatible = "btt,btt-ft5506", .data = &edt_ft5x06_data },
        { /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, edt_ft5x06_of_match);

 static struct i2c_driver edt_ft5x06_ts_driver = {
        .driver = {
-               .name = "edt_ft5x06",
+               .name = "btt_ft5x06",
                .dev_groups = edt_ft5x06_groups,
                .of_match_table = edt_ft5x06_of_match,
                .pm = pm_sleep_ptr(&edt_ft5x06_ts_pm_ops),

I'll… look into sending a PR to the raspberrypi kernel I guess? But this is such a strange quirk, I'm not sure how to even generalize it (something like btt,touchscreen-relative-wraparound-x = <800 1024>; btt,touchscreen-relative-wraparound-y = <480 600>; ???)

I guess I can also make an easy packaged installation script like the original, but source-based, without blobs bound to a particular kernel build.

Hello everyone,

I have recently acquired this printer and "reverse engineered" the modified drivers.

The device tries to present an interface similar to the official RPi 800x480 7" touchscreen, but it's larger and weirder. The display panel can actually be declared as a "panel-dpi" and there's no need to add it to the simple panel driver (and that works even in mainline Linux).

Tthe touchscreen works as a "edt,edt-ft5506"… sort of. First of all, only the raspberrypi/linux version of the driver has the necessary polling mode support for now. Then, the hardware nonsense here: the coordinates wrap around weirdly beyond the 800x480 rectangle, so the modified edt-ft5x06 driver they compiled includes a quirk to handle that.

The DT overlay is just this:

dtso source, compile like so: dtc -O dtb -@ -L biqu-bx.dtso >biqu-bx.dtbo, USE WITH dtovelay=upstream (even with the rpi kernel), I'll try to make a non-upstream overlay too
and the basic diff for the driver module is basically:

download the file, rename, apply the following with patch and compile like any out-of-tree kernel module, install, run depmod, reboot
I'll… look into sending a PR to the raspberrypi kernel I guess? But this is such a strange quirk, I'm not sure how to even generalize it (something like btt,touchscreen-relative-wraparound-x = <800 1024>; btt,touchscreen-relative-wraparound-y = <480 600>; ???)

I guess I can also make an easy packaged installation script like the original, but source-based, without blobs bound to a particular kernel build.

Cool, I have been thinking of doing got some help to start and I could get more if I needed but never got around to it as It's working on my printer.

@valpackett can this be scripted? Just to make it easier for most using this printer ?

Hi everyone!

I have a BIQU BX with a V3 board and a Raspberry Pi 3B+, currently running Marlin with OctoPrint since 2023. I'm planning to switch to Klipper and, after thoroughly reviewing the documentation, I feel confident about the process.

However, I’d like to ensure I have a rollback option in case something goes wrong. Does anyone know if the binary available in the following repository is compatible with the V3 board?

🔗 https://github.com/bigtreetech/BIQU-BX/tree/master/Firmware/Copy%20to%20microSD%20to%20update

Any help is greatly appreciated!

Rollbacks would to have the the old firmware and use a new sdcard for your klipper.

Rollbacks would to have the the old firmware and use a new sdcard for your klipper.

That's exactly the problem: I'm not sure if the firmware available in the BIGTREETECH repository is the V3 version that's compatible with my printer.

It worked! I followed the instructions and now Klipper is installed on my printer.

Thanks a lot for your help!

Rollbacks would to have the the old firmware and use a new sdcard for your klipper.

That's exactly the problem: I'm not sure if the firmware available in the BIGTREETECH repository is the V3 version that's compatible with my printer.

You can use the community version.

Hi everyone!

I managed to install Klipper and set everything up, but I'm still not satisfied with the print quality. I'm getting an accelerometer to enable input shaping and see if that improves the results.

I also miss having a working filament change macro. I haven’t been able to create one that works as well as what I had with Marlin. On top of that, I'm getting overheating errors on the Z-axis drivers:

TMC 'stepper_z' reports error: DRV_STATUS: c0170103 otpw=1 (OvertempWarning!) ot=1 (OvertempError!) t120=1 cs_actual=23 stealth=1 stst=1

Can anyone help me properly set up sensorless homing for the Z axis? Also, is it necessary to physically jumper the DIAG pin to PB13 on the board for this to work? If so, could someone explain exactly where those pins are located on the Biqu BX and how to wire them?

If anyone could share their printer.cfg, it would be really helpful so I can compare and see what I can improve in my setup.

I really appreciate any help!

can you access this ? https://github.com/varazir/KlipperBXBackup/tree/2727dc40ea7f8b8fa28e30c6faf9d3aba017192c/config

can you access this ? https://github.com/varazir/KlipperBXBackup/tree/2727dc40ea7f8b8fa28e30c6faf9d3aba017192c/config

No, error 404.

can you access this ? https://github.com/varazir/KlipperBXBackup/tree/2727dc40ea7f8b8fa28e30c6faf9d3aba017192c/config

No, error 404.
I added you as colab on the repo

can you access this ? https://github.com/varazir/KlipperBXBackup/tree/2727dc40ea7f8b8fa28e30c6faf9d3aba017192c/config

No, error 404.
I added you as colab on the repo

I was able to access it now, thank you!

Did you have to jumper the DIAG pin to the stepper driver for the Z axis? I checked your configuration and it’s identical to mine, but I keep getting frequent overheating warnings on the Z stepper driver.

can you access this ? https://github.com/varazir/KlipperBXBackup/tree/2727dc40ea7f8b8fa28e30c6faf9d3aba017192c/config

No, error 404.
I added you as colab on the repo

I was able to access it now, thank you!

Did you have to jumper the DIAG pin to the stepper driver for the Z axis? I checked your configuration and it’s identical to mine, but I keep getting frequent overheating warnings on the Z stepper driver.

Never change that. Maybe check on the Facebook https://www.facebook.com/groups/1012996125813700 forum or https://discord.gg/zBnEGScT you can find pinouts here https://github.com/bigtreetech/BIQU-BX

Now that I've noticed, the 5020 fan on the board isn't turning on.

Any tips?

Now that I've noticed, the 5020 fan on the board isn't turning on.

Any tips?

it should be on when you start printing.
I guess you can map the port in the config.

Now that I've noticed, the 5020 fan on the board isn't turning on.
Any tips?

it should be on when you start printing. I guess you can map the port in the config.

After a thorough check of the wiring diagram, comparing my settings to yours, and even swapping out the fan port and testing with another 24V fan, I finally pinpointed the problem: the 5020 fan had died. I'm still unsure if it was an existing issue that Marlin simply didn't report, or if something went wrong during the Klipper migration. A new fan is already on its way. I appreciate your patience throughout this process.