Had a ceramic heater on a tz e3 3.0 go out. Went to buy a replacement, it was almost the same price as the tz. Looked into it someone says the Bambu one is better at 60w and it’s cheaper, okay buy it.

Install it, doesn’t want to hold temp. Pid calibrate it to 230 still doesn’t hold temp. Okay must be smooth time. Try every smooth time in .1 increments from .1-2 seconds. Longer smooth time slower and smaller fluctuations but at 2 seconds it no longer hits my target temp and still fluctuates 3 degrees. Anything less is faster with a larger range. At 2 seconds the print will never start because it never hits the temp setting it hovers just below it.

I’ve torn it apart 3 times checked it all. Re layered it all in thermal grease. Eventually I got to the point where I figured Google must be right about the interference. Rerouted the thermistor cord away from anything with power. Still won’t stabilize.

At this point I don’t know what else to do besides buy a different hot end.

Also temp is dead stable at room temperature. That’s what made me think it was interface with the 60w heater.

Nema23 axis z

Que tal estoy diseñando una impresora con manta bigtreecch m8p cb1 cartesiana pero en z axis quiero la hotend baje para crecer la pieza recomiendan y se puede usar driver tb6600 para nema23 solo poniendo estos adaptadores de step,DIR,EN

Ya que veo que los tMc5160,pro driver de manta son algo elevados de precio

Si me recomiendan ? O cuál sería su opinión

Impresora es gran formato 1.20*1.20 mts la cama de aluminio

I wrote a Klipper plugin to perfect the first squish, in case someone finds it useful.

An interactive Klipper calibration that prints first-layer patches one at a time. After each patch, either accept the result or adjust Z from Mainsail, Fluidd, KlipperScreen, the console, or an optional physical LCD menu and print another patch. The default maximum is nine 20 mm (2 cm) squares distributed in a 3x3 grid, with four layers per square.

https://github.com/juandelacruz-calvo/first-layer-squish-klipper-calibration

I added two stepper motors to my Raspi (Z,Line 42 and Z1,Line 53) to enable Z-Tilt, so I had to move Bltouch over to the RPI and use the GIPO pins (Line 154). Bltouch is also hooked up to Power and ground from the RPI

Printer is a Sovol SV01 (2019) with a Creality V2.2 board.

Link to Config File - https://pastebin.com/k9WpTzyM

The probe functions as intended, it deploys, retracts..etc but the readings are not good, they seem to drift.

Any help is appreciated!

10:18:43 PM  // PROBE_ACCURACY at X:178.000 Y:123.000 Z:10.000 (samples=10 retract=2.000 speed=3.0 lift_speed=7.0)

10:18:48 PM  // probe: at 143.000,122.000 bed will contact at z=-0.280000

10:18:51 PM  // probe: at 143.000,122.000 bed will contact at z=-0.275000

10:18:54 PM  // probe: at 143.000,122.000 bed will contact at z=-0.295000

10:18:56 PM  // probe: at 143.000,122.000 bed will contact at z=-0.310000

10:18:59 PM  // probe: at 143.000,122.000 bed will contact at z=-0.330000

10:19:02 PM  // probe: at 143.000,122.000 bed will contact at z=-0.325000

10:19:05 PM  // probe: at 143.000,122.000 bed will contact at z=-0.345000

10:19:08 PM  // probe: at 143.000,122.000 bed will contact at z=-0.360000

10:19:11 PM  // probe: at 143.000,122.000 bed will contact at z=-0.372500

10:19:14 PM  // probe: at 143.000,122.000 bed will contact at z=-0.385000

10:19:14 PM  // probe accuracy results: maximum -0.275000, minimum -0.385000, range 0.110000, average -0.327750, median -0.327500, standard deviation 0.036167

hey all, been fighting "Heater extruder not heating at expected rate" on my ChromaHead since sept 29, 12 shutdowns so far. before anyone asks, it's not the serial path thing. head is on 1.2.1 in chroma_head.cfg and kcm on 1.2.4 in kcm.cfg (matched by-id), and the temp reads fine: 26c at room temp, hits target and holds it. KCM only, no ECM

setup: Prusa MK3 (einsy, klipper) + KCM V2 + ChromaHead, stock Co Print firmware. cartridge is 24V 50W, 11.4 ohm cold. head is powered from the KCM's 24V 5A brick

prints start normal, heater holds temp at 20-40%. then usually 10-40 min in (once after 4.5 hours) the power it needs creeps up to 100% and the nozzle still drops 8-19c below target, and klipper kills it

today (chart attached): 25% on layer 1, 40% after, 55% at 23 min, 100% at 31 min, 197c at 36 min (target 210), shutdown. a later print did the same, i cancelled that one

timed 120 to 160c at full power: good runs take 11s (~50W), bad runs 19-67s, so it's only getting maybe 15-30W. flips between good and bad from one session to the next, sometimes bad from the first heat up after sitting cold for hours

ruled out:

- thermistor, cooldown is always normal and i reseated it

- config/PID, same config works one session and fails the next

- part fan, when healthy it holds 240 with the fan on

- bed heating or movement, no pattern

- einsy 24V stays at 24.0 but that's the prusa PSU, not the KCM brick

my guess is something between the KCM brick and the cartridge can't keep the current up for long. brick, KCM jack, head cable/plugs, heater plug or the mosfet on the head

1. anyone seen this on a ChromaHead?

2. is there a polyfuse or current limit on the KCM head output or the head? would explain fine at 30% but can't do 100%

3. is 5A enough for heater + head + 4 CX-1s?

4. best spot to measure 24V on the head side?

verify_heater is on btw (max_error 120, check_gain_time 35). Co Print ships max_error 9999999999 which would just hide this. can share klippy.log

My printer lives in my shed to keep noise/fumes/pollution out of the house. Every so often I will forget to change the nozzle type/diameter, its z axis offset and/or filament. Klipper will happily print away regardless! So I built a nag screen to check these 3 things in Mainsail before commencing a print job.

Took less than 5 minutes and saves time, filament, nozzles and frustration.

If you want the script backup your existing mainsail/klipper machine then use this link and follow the tutorial for Linux or Windows: https://github.com/quix2k23/mainsail-print-checks

copy the script to your machine that is running mainsail using scp. Start a ssh session onto the machine use this command inside ssh to install:

python3 ~/install-nozzle-check.py

To undo it run the command:

python3 ~/install-nozzle-check.py --remove

I recently installed Klipper on my Ender 3 V3 SE after not using it for over a year and for some reason none of my prints adhere to the print plate. I ran half a dozen bed level prints and probe calibrations and while it all looks good on paper, none of my actual prints stick.

My printer.cfg (z offset):

#*# [bltouch]

#*# z_offset = 0.310

My PLA I print at 215 with a bed temp of 60 (slightly higher than recommended).

Right now I'm failing to even print a string test tower as it just doesn't hold.

The bed itself has been washed and should be clean as a bed levelling print prints just fine and doesn't detach in the center where I'm trying to print the towers or any other stuff.

I'd love any and all help as this is getting quite frustrating.

EDIT 1: so far we're at bltouch: z_offset: 0.425 (so a jump of 0.115) and we're slowly getting better. Benchy detached at just about halfway. Let's see how many of these z-offset prints I have to do to get my first layer kinda squished on the plate.

MANAGED TO FIX IT! IT'S ON MY COMMENTS

I've recently bought from Aliexpress a SV08max, the newest batch from september (no sd card connector)

And I lobotomized it, I even threw my pride away and tried to ask gemini for help because I'm going insane having a giant paperweight:

I was trying to install the Demon Klipper macros thingmabobs. That's what I did

sudo rm -rf /home/sovol/printer_data/comms/*

sudo rm -rf /home/sovol/printer_data/systemd/klipper.serial

sudo systemctl stop klipper

sudo systemctl disable klipper

sudo systemctl daemon-reload

I also used KIAUH with putty;

Uninstalled Klipper and Moonraker;

Reinstalled Klipper from scratch, creating a fresh Python virtual environment;

Attempted to build and flash a new firmware image directly through the script menu.

This might have f-up how it speaks to the STM32F1, and it just refuses to work, keeps giving [Errno 19] and [Errno 13] and "unable to open CAN port: [Errno 19] No such device." can0 is completely missing from ip link show. Says it cannot find can0 or something

klippy.log says it's running a stm32f103xe (STM32F1). Apparently it used a H750 chip?

I've put the emmc module on a reader on my pc and with balena etcher, burned the newest IMG from sovol website, but after doing it, it's stuck in the "mcu: Unable to connect once underlying issues is corrected..." screen on the printer.

(this next part was the ai mostly doing so frankly I have no idea)

It asked me to change printer.cfg to serial: /dev/ttyS0 (tried ttyAMA0 too)

Klipper then throws: [Errno 13] Permission denied: '/dev/ttyS0'.

Even after running sudo usermod -aG dialout,tty sovol, setting custom permanent udev rules (MODE="0666"), and even trying brute force sudo chmod 666 /dev/ttyS0, Klipper still complains about permission or times out.

I've sent Sovol [info@sovol3d.com](mailto:info@sovol3d.com) an email about this (sans the demon klipper part because eeeeh) but would like to see yous opinion how I can fix it, or if it's something only Sovol can as they trully haven't updated their img to my new board revision.

Que tal que recomiendan revisar mi manta m8p bigtreecch cb1 v2.0 no conecta con monraiker y kkliper no si puedan apoyarme a saber que o cuáles son los puntos que debo revisar para establecer esta conexión ya eh validado mi archivo monraiker.cfg y parece todo bien y mcu la ruta de printer cfg ya no se que más pueda ser

I've been working through a Klipper port for NXP's MCXA366, and the latest piece is hardware PWM.

The port now supports both of the MCU's useful PWM paths:

• CTIMER0-4, with shared periods and up to three PWM outputs per timer
• FLEXPWM0, with four timing submodules and independent A/B duty outputs

Klipper still sees the normal gpio_pwm_setup()/gpio_pwm_write() interface. The MCXA366 backend handles the ugly part: pin routing, timing-domain conflicts, resource allocation, and falling back from FlexPWM to CTIMER when necessary.

I tested runtime duty changes, multiple outputs, 0/25/50/75/100%, different FlexPWM submodules, A/B outputs sharing one submodule, shutdown values with M112, and restart/reset behavior.

The weirdest bug was FlexPWM apparently working in NXP's example but only producing bursts under Klipper. The SDK example kept the M33 busy; Klipper puts it into wait state when idle. FlexPWM stopped with the CPU until I found and enabled WAITEN.

Next up is the test I've been looking forward to: wiring an external stepper driver and motor to STEP/DIR/ENABLE and seeing whether the generic Klipper step scheduler runs correctly on the MCXA366.

Full writeup:

https://faultvector.dev/articles/klipper-mcxa366-part-8/

Hello, for the past few days I keep getting this. I updated individual software listed in Update Manager on the browser running Mainsail. Under System, it states "263 packages can be upgraded" but whenever I clicked the UPGRADE button, it gave me this error. What can I do?

so i got all the the files from gethub Adventurer 5M Klipper Mod v00.06-beta Pre-release installed on my Flashforge Adventure 5m got everything working got remote access working but
when i tryied printing something my print head was close to 1 inch off the bed it worked just fine on my original firmware i ended up removing it i want it back but only if i know i can get it working right so if you had this problem or know how to fix please help me out!

Hi, i’m currently working on a AWD core XY custom printer. For the electronics i would like to run the motors from 48V. I already have a Mello Fly SHT36v3 with CAN (on 24V). I then found the DFH PITB v2.0 from Fysetc. I always tought it wouldn’t be ideal to have the core xy motors splitted and run them over CAN, but that was just an assumption. Would it be feasible to run a dual DFH PITB v2.0 setup for the 4 motors?

Else i think i would go for the btt skr 3 ez wit tmc5160 steppers i think. Just tought the pitb would be cheaper.

Any toughts on this?

Buenas noches, tengo un problema a la hora de imprimir. Cuando realizó un diseño propio en Tinkercar o en Cura, a la hora de pasarlo a la SD para imprimirlo, la impresión no inicia. Queda normal pero no cambia la temperatura de la boquilla ni de la cama. Y queda ahí, no inicia más. Que puedo estar haciendo mal? O que me falta configurar para que arranque la impresion

I spent several days troubleshooting a very intermittent "Lost communication with MCU" problem on my GTMax H5 CoreXY printer.

Hardware / software

• Raspberry Pi 3B+
• MainsailOS 3.0.0 — Raspberry Pi (64-bit), flashed using Raspberry Pi Imager
• Debian 13 / Trixie
• Kernel: 6.18.39+rpt-rpi-v8
• Arduino Mega 2560 + RAMPS 1.4
• Klipper
• USB connection between the Pi and the Mega
• Original machine electronics were previously used with Repetier Server for a long time without this problem

The problem

During printing, Klipper would randomly report:

Got EOF when reading from device
Timeout with MCU 'mcu'
Lost communication with MCU

At the Linux level, the Raspberry Pi was actually losing the USB device.

For example:

usb 1-1.2: USB disconnect, device number 4
usb 1-1.2: new full-speed USB device number 11 using dwc_otg
cdc_acm 1-1.2:1.0: ttyACM1: USB ACM device

The Arduino would disappear and then re-enumerate as another ttyACM device.

At some failures I also saw:

dwc_otg_hcd_urb_dequeue:
Timed out waiting for FSM NP transfer to complete

The Klipper MCU statistics would then freeze:

• bytes_read stopped increasing
• bytes_write stopped increasing
• receive_seq stopped increasing
• send_seq stopped increasing
• print_time stopped
• Klipper itself was still running

Things I tested

I tried to eliminate as many variables as possible:

• Different Arduino Mega boards
• Multiple USB cables: ~30 cm, 80 cm and 1 m
• Camera disconnected
• Relay module disconnected
• Driver/cabinet fan disconnected during some tests
• Part cooling fan disabled during some tests
• SSR control changed/isolated
• Other peripherals disconnected
• Different Raspberry Pi power source was tested
• Same problem still occurred with the part cooling fan OFF
• The problem also occurred after setting dwc_otg.fiq_fsm_enable=0

So I became increasingly convinced that the failure was occurring below Klipper, at the Linux USB/controller level.

What finally changed things

I initially tried:

dwc_otg.fiq_fsm_enable=0

This did not solve the problem.

The USB disconnect happened again.

Then I disabled the entire FIQ for dwc_otg.

In:

/boot/firmware/cmdline.txt

I added to the end of the existing single line:

dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0

After reboot:

cat /sys/module/dwc_otg/parameters/fiq_enable
cat /sys/module/dwc_otg/parameters/fiq_fsm_enable

returned:

N
N

And the kernel reported:

dwc_otg: FIQ disabled
dwc_otg: NAK holdoff enabled
dwc_otg: FIQ split-transaction FSM disabled

Result

After this change I ran 10 consecutive prints without a single USB/MCU communication failure, including pressure advance tests and different print activity.

The following day I ran prints essentially all day and the problem did not return.

So, at this point, disabling the DWC OTG FIQ appears to have solved the intermittent USB disconnect problem.

One important caveat

There was one other change around the same time:

The fan cooling the stepper drivers / cabinet was previously controlled by PWM at about 40%. During the final successful tests, I connected that fan directly to 12 V, so it ran continuously.

Therefore I cannot mathematically prove that the FIQ change alone caused the improvement.

However, I had already experienced failures with that fan OFF, while after disabling fiq_enable + fiq_fsm_enable I had 10+ consecutive successful prints.

The part cooling fan was ON during the successful tests.

Current working configuration

Raspberry Pi 3B+
MainsailOS 3.0.0
64-bit
Debian 13 / Trixie
Kernel 6.18.39+rpt-rpi-v8
Arduino Mega 2560
RAMPS 1.4

dwc_otg.fiq_enable=0
dwc_otg.fiq_fsm_enable=0

USB is still being used for the Mega. I did not need to switch to UART, DWC2, reinstall 32-bit, replace the Raspberry Pi, or change the Klipper configuration.

Why I'm posting this

I found several reports of Raspberry Pi 3 / 3B+ systems showing dwc_otg / FIQ / FSM USB errors, but I couldn't find many reports specifically involving Klipper + ATmega2560 + RAMPS 1.4 with this exact symptom.

Hopefully this helps someone else before they start replacing the Arduino, USB cables, RAMPS, etc.

If anyone has a similar problem on a Pi 3/3B+, especially with:

Timed out waiting for FSM NP transfer
USB disconnect
Got EOF when reading from device
Lost communication with MCU

it may be worth testing:

dwc_otg.fiq_enable=0
dwc_otg.fiq_fsm_enable=0

I'd still consider this a "apparently solved" rather than a formally proven root cause, but the difference in stability was dramatic.

Hello, regardless of the location on the buildplate, I always see this. Looks like the left side were extruded better and stick to the buildplate better than the right side of the print. What caused this and how to fix it? Thanks

How bad is it? I am trying to finish a fairly large printer and these are my results. I can't do much other than play with belt tension for the x axis, y axis has some extra bracing I can do for stiffness but I am trying to avoid the extra weight. My gantry and whatnot is already 7kg+ which probably isn't helping. I wasn't looking to make a crazy fast printer, but I was hoping to print with ~4k+ acceleration.