Delta Printer Bed Crash Issues

General Discussion
1

Basic Information:

Printer Model: Custom Delta Printer
MCU / Printerboard: BTT SKR3
Host / SBC BTT-CB1
klippy.log

klippy.log (5.5 MB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

Delta printer is crashing into the bed after 2nd print

Related build info:
Custom delta (manufacturer is me)
No Z probe, manual probing only
BTT SKR3 + BTT CB1 Just reflashed with Debian 12 and did a clean install of Klipper/mainsail/moonraker
Using Orca Slicer

This printer has been working fine for 2 years, decided to upgrade to get Debian 12 as the repos were discontinued for Debian 11 and I couldn’t update some things.

I copied my printer.cfg and restored it after full firmware reinstall. All kinematics, settings, etc seemed to be restored and working well.

I added a PRINT_START macro that lowers the hotend to Z25 before the print starts due to orca making a horizontal move as a first move, which is not possible for a delta when the hotend is raised to the top.

Now, I can turn the printer on, print something, and it completes fine. If I then start a second print, it will heat, then move to the bed and crash into it.

If I turn the printer off, then back on, I can start another print and it will print fine.

Additionally, my END_PRINT macro has G1 X0 Y0 Z230 F3000 because if I don’t move the effector back to the top at the end of the print before I run G28, the hotend gets sent down into the bed full force. this issue was present before I reflashed, but may be a clue as to what may be going on in the backend?

[homing_override] was added so steppers dont skip when running G28 at the homed position for tmc2209 sensorless homing.

Is there something that may have been added in an update of Klipper/mainsail/orca/something else that would cause a probe/bed/offset to be changing at the second print like this? Or did I mess something up?

Here is the GCode file: https://pastebin.com/dbM6SCUA

I have not found a single thing that seems like it could be related to these issues anywhere in the printer.cfg, or slicer/gcode. I’m at a complete loss here.

2

Hi

I did look at your klippy.log - I did see there 16 startups of a klipper, 11 Attempts to print something.

Also I did try to look at your sample GCode file - but it’s already absent on pastebin, archive it and upload it in this chat.

In General, if analyze last 2 attempts to print something (log line numbers 13252 and 13536 ) I see that during those attempts your klippy configuration didn’t have “PRINT_START” and “PRINT_END” macros at all, also I didn’t see any errors about those commands are unknown - so I’m assuming your GCode file is not invoking them at all.
In this scenario only “homming_overide” have some meaning - but it contain normal commands which shouldn’t produce described behavior at all, so most probably your GCode file contain some kind incorrect starting and ending sequence of commands.

So I would suggest to do following:

  • Prepare desired config and save it
  • Do full restart of a printer
  • Fully Reproduce issue
  • Collect klippy.log file and used GCode files
  • Upload fresh data to this chat

When fresh data will be collected and presented - probably we can solve this issue.

Good luck.

3

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