# X axis randomly slams into the left frame mid-print

**URL:** <https://klipper.discourse.group/t/x-axis-randomly-slams-into-the-left-frame-mid-print/26040>\
**Category:** General Discussion\
**Created:** [May 29, 2026, 9:53am UTC](https://klipper.discourse.group/t/x-axis-randomly-slams-into-the-left-frame-mid-print/26040 "2026-05-29T09:53:31Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![PaR](https://avatars.discourse-cdn.com/v4/letter/p/839c29/32.png) [@PaR](https://klipper.discourse.group/u/PaR)\
**Post date:** [May 29, 2026, 9:53am UTC](https://klipper.discourse.group/t/x-axis-randomly-slams-into-the-left-frame-mid-print/26040/1 "2026-05-29T09:53:31Z")

</div>

**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](https://klipper.discourse.group/uploads/short-url/cDN6x7SZaIsfprrpa9D22tRno1v.log) (41.5 KB)

[printer.cfg\_0528.txt](https://klipper.discourse.group/uploads/short-url/os6awLm7BqoYOi6bzgEkKNRx5Pi.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:

```auto
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:

```auto
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:

```auto
[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.

---

<div class="post-metadata">

**Author:** ![EddyMI3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/eddymi3d/32/1981_2.png) [@EddyMI3D](https://klipper.discourse.group/u/EddyMI3D)\
**Post date:** [May 29, 2026, 12:28pm UTC](https://klipper.discourse.group/t/x-axis-randomly-slams-into-the-left-frame-mid-print/26040/2 "2026-05-29T12:28:16Z")

</div>

Hello @PaR and welcom to the forum!

Is this

> [@PaR](#):
>
> [klippy (19).log](https://klipper.discourse.group/uploads/short-url/cDN6x7SZaIsfprrpa9D22tRno1v.log) (41.5 KB)

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

---

<div class="post-metadata">

**Author:** ![cardoc](https://avatars.discourse-cdn.com/v4/letter/c/ec9cab/32.png) [@cardoc](https://klipper.discourse.group/u/cardoc)\
**Post date:** [May 29, 2026, 3:24pm UTC](https://klipper.discourse.group/t/x-axis-randomly-slams-into-the-left-frame-mid-print/26040/3 "2026-05-29T15:24:00Z")

</div>

> [@PaR](#):
>
> **MCU / Printerboard:** Tronxy custom board (STM32H723xx), Klipper V1.2.5

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

> [@3D Printers with Preinstalled and Modified Klipper Versions](https://klipper.discourse.group/t/3d-printers-with-preinstalled-and-modified-klipper-versions/20467/1):
>
> Rationale With the growing popularity of Klipper as a firmware option for high-speed, high-quality 3D printing, some Original Equipment Manufacturers (OEMs) have started shipping 3D printers with preinstalled, modified versions of Klipper. These modifications are often made to: Support for the specific hardware configuration. Provide customized features or interfaces. Integrate OEM-specific tools and UI elements tailored to the device. While these preinstalled versions can provide a more seam…

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

> [@PaR](#):
>
> 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 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

---

<div class="post-metadata">

**Author:** ![PaR](https://avatars.discourse-cdn.com/v4/letter/p/839c29/32.png) [@PaR](https://klipper.discourse.group/u/PaR)\
**Post date:** [May 30, 2026, 5:26am UTC](https://klipper.discourse.group/t/x-axis-randomly-slams-into-the-left-frame-mid-print/26040/4 "2026-05-30T05:26:59Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![PaR](https://avatars.discourse-cdn.com/v4/letter/p/839c29/32.png) [@PaR](https://klipper.discourse.group/u/PaR)\
**Post date:** [May 30, 2026, 6:37am UTC](https://klipper.discourse.group/t/x-axis-randomly-slams-into-the-left-frame-mid-print/26040/5 "2026-05-30T06:37:38Z")

</div>

![toolhead_numbering](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/1/b/1b808411c6b2d12ea209de55944e07441a8b626b.jpeg)

**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?

---

<div class="post-metadata">

**Author:** ![cardoc](https://avatars.discourse-cdn.com/v4/letter/c/ec9cab/32.png) [@cardoc](https://klipper.discourse.group/u/cardoc)\
**Post date:** [May 30, 2026, 9:41pm UTC](https://klipper.discourse.group/t/x-axis-randomly-slams-into-the-left-frame-mid-print/26040/6 "2026-05-30T21:41:01Z")

</div>

> [@PaR](#):
>
> Can you tell me more about the missing a lot of stuff?
> 
> I mean, What’s the difference between general printer and my printer.

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.

> [@PaR](#):
>
> I’m a newbie to 3d printer and this is my first 3d printer.

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

[printer\_veho800pro\_translated.cfg](https://klipper.discourse.group/uploads/short-url/cf2kI5JBGfxmM1tUUDXdcsscZUp.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](https://en.wikipedia.org/wiki/Hallucination_(artificial_intelligence)) and can be quite stubborn about admiting they are in over their head.

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

> **[Claude](https://claude.ai/share/984344cf-c075-4aa2-8086-809d45cf3ba0)**
>
> Shared via Claude, an AI assistant from Anthropic

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/klipper/original/1X/64419bf2aac6639e6ef5cef200dcd456b0a01ac3.png) [@system](https://klipper.discourse.group/u/system)\
**Post date:** [July 29, 2026, 9:41pm UTC](https://klipper.discourse.group/t/x-axis-randomly-slams-into-the-left-frame-mid-print/26040/7 "2026-07-29T21:41:56Z")

</div>

Closed on July 29, 2026, 9:41pm UTC

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
