X axis randomly slams into the left frame mid-print

General Discussion
1

Basic Information:

  • Printer Model: Tronxy Veho 800 Pro (800x800mm cartesian)

  • MCU / Printerboard: Tronxy custom board (STM32H723xx), Klipper V1.2.5

  • Host / SBC: Tronxy custom embedded Linux, Moonraker + Mainsail

(log attached)

klippy (19).log (41.5 KB)

printer.cfg_0528.txt (30.1 KB)

Issue:

Been running this printer for about two months without major problems. A few weeks ago it started doing something really frustrating — the X axis will suddenly shoot all the way to the left and slam into the frame, either during a print or right when it tries to home after a cancel. No warning, just bang.

The pattern took a while to figure out. After the first crash I spent around 5 days trying to get PETG working again — lowered the bed temp, dropped run_current to 1.2A, tried a few different things — nothing worked. Eventually switched over to PLA at 1.0A out of frustration and that’s been running fine. Went back to PETG after that and got the exact same crash. So right now PLA works, PETG doesn’t, and I’m not sure what’s actually different between the two that would cause this.

Pulled the log and found this on the X driver right around when it happens:

TMC 'stepper_x' reports GSTAT: 0000001d
  reset=1(Reset)
  uv_cp=1(Undervoltage!)
  register_reset=1
  vm_uvlo=1

What’s weird is that all four Z drivers (TMC2209 on UART) show nothing abnormal at the same time — no undervoltage, no resets. So it really seems like something specific to the X driver or that socket, not a PSU issue overall.

On top of that, SPI comms to X are completely dead:

spi_transfer_response oid=0 response=b'\x00\x00\x00\x00\x00'
TMC stepper_x failed to init: Unable to write tmc spi 'stepper_x' register DRV_CONF

X is on software SPI, config looks like this:

[tmc2240 stepper_x]
cs_pin: PD7
spi_software_mosi_pin: PC2
spi_software_miso_pin: PC0
spi_software_sclk_pin: PC1
run_current: 1.4
interpolate: False
stealthchop_threshold: 0

To make things worse, a technician came out and swapped the TMC2240 for a TMC2225 thinking it might be a bad driver — which of course doesn’t do SPI at all, so now it won’t init at all. A new TMC2240 is on the way and I’ll swap it back once it arrives.

What I’m trying to figure out:

If the new TMC2240 fixes it, I’ll assume the original chip was just defective and move on. But if vm_uvlo keeps showing up on X even with a fresh driver, I’m not sure where to go from there. A few things I’m wondering:

  • Could a bad solder joint or loose contact on the X socket cause vm_uvlo to show up on just one axis like this?

  • Is software SPI generally flaky enough that noise/interference could cause this? The X signal lines run pretty close to the motor cables. Would switching to hardware SPI (if there’s a usable bus on this board) be worth trying?

  • Any other things worth checking if the driver swap doesn’t solve it?

This board is a custom Tronxy design so there’s no public schematic, which makes this harder to trace.

2

Hello @PaR and welcom to the forum!

Is this

the complete klippy.log? To me, there is missing a lot of stuff.

3

It seems your printer is running a Tronxy fork of Klipper.

It seems they have modified the info copied into klippy.log

The issue you describe is almost certainly electrical/mechanical, NOT software. The higher temperatures for PETG may be overtaxing your power supply. As far as I can tell your machine is a single MCU system so not toolhead board to overheat.

Good luck

4

Yes, it’s my latest and complete log.

Can you tell me more about the missing a lot of stuff?

I mean, What’s the difference between general printer and my printer.

I think my printer’s setting is slightly different with others.

I’m a newbie to 3d printer and this is my first 3d printer.

5

toolhead_numbering
toolhead_numbering1920×2560 788 KB

One more thing I should mention — the toolhead has three fans total: a parts cooling fan, a hotend heater fan, and a third fan located directly in front of the extruder gears. That third fan had two broken blades and was running badly out of balance for some unknown period of time before I caught it and had it repaired recently.

I’m wondering if this could be related. A fan that unbalanced running continuously would generate significant vibration, and I can imagine that gradually working a driver socket loose over time — or putting noise back onto the 24V line. Could prolonged vibration from an imbalanced fan have degraded the X driver socket contact enough to explain the intermittent vm_uvlo? And is it possible the fan was generating enough electrical noise to corrupt SPI communication?

6

That is the problem. No one (besides Tronxy) knows what has been changed.

I ran your printer.cfg through AI to translate the comments. Of note the comments include numerous changes to the X axis driver configuration due to lost counts. It seems they had issues with X axis crashing during development.

As far as I can see the machine has no proprietary hardware so conversion to mainline Klipper is an option.

There are multiple paths to improve your printer. None, however, are simple.

printer_veho800pro_translated.cfg (35.5 KB)

First thing I’d do is contact Tronxy and DEMAND source code under GPL copyright laws.

Step 2 would be to gain access to the Linux OS over SSH.

Chat with Claud AI but get a second opinion before jumping in. All AIs suffer from hallucination and can be quite stubborn about admiting they are in over their head.

Here is a chat with your .cfg and .log already loaded.