Printhead crashes on bed on second print

Vertex Delta Discussion
#1

I’m having this weird issue where if I attempt to print a new model right after another one finishes, the print head comes crashing down on the bed with enough force to tear a gash in the buildtak and dislodge the support rods. It happens during the “Leveling bed” phase, on the first, lower left coordinate. But only on the second print, the first one calibrates and prints successfully. If I run a calibration between the prints it does not seem to happen, but I shouldn’t have to do this every print, right?

Any ideas what might be causing this?

#2

This is happening to me too - It’s very frustrating! I’m still yet to figure out what it is, and have already ruined one sheet of BuildTak before making any successful prints.

It also happens on the lower-left coordinate. @Support_Team, is it possible @Renzan and I have faulty piezo sensors?

Before a print:

I calibrate the printer (and save the calibration)
I clean both sides of the Print bed (using BuildTak) and the piezo pads using isopropanol
I tap (with the large, blunt end of a screwdriver) all over the bed to ensure the red light comes on, which should theoreticaly stop this issue (my printer is set to maximum sensitivity for this reason)

Then I attempt to print, and cringe as the nozzle inevitably rams into my second BuildTak sheet. :frowning:

I have checked the tension of the belts, ensured the height of the stops is calibrated correctly (height calibration has no problem)

I have also shaved down the print bed detents because they gripped the bed too much, which seemed to help at first, and was very careful to trim off all of the excess BuildTak.

#3

Just one thought @Renzan - Are you using OctoPrint? I was just thinking it might be good to eliminate that from the possible causes (EDIT: It’s not OctoPrint, this happens even when using SD cards and printing directy from the printer), what do you think?

I’ve uploaded a video to demo what happens when printing again after a successful first print

#4

Video is exactly what happens to me too, same coordinate, same horrible sound (from both machine, and me :D)

Im not sure I think the piezos are to blame for this, they detect the nozzle just fine during the calibration phase (I have my sensitivity close to midpoint and reliably detects a gentle tap with my finger).

No, its not OctoPrint, I’m having this issue both with standalone from sd card prints and prints from serial connection.

#5

Nice to hear we’ve got the same issue

I think I agree it’s not the Piezos. However - I’ve just made sure the heights and gaps between the height sensors/idle bearings(?) are correct, still having the same issue :-1: So I don’t know what to check any more! Starting to thing about refunds sadly.

It’s a shame, I’ve had some good prints! But having to constantly calibrate/save/repeat - and even that fails catastrophically more often than not now!

And crossing my fingers and watching the printer with intent each time anticipating failure is giving me anxiety :cry:

#6

Hmm maybe I’ll try a firmware flash/upgrade

#7

I’m running Marlin 2.0.7 from @SusisStrolch and don’t have this issue.
On the other hand, every other print it pauses and unloads the filament, as if I requested a filament change, which I didn’t :frowning:

#8

That is probably the filament runout detector glitching. I had that too soo many times. Try unplugging it and see if the issue remains.

2 Likes
#9

That’s exactly what I had to do, give it a try @Devrope!

1 Like
#10

I had the same problem with the runout sensor. In my special case it’s because I have the filament in a filament drying box beside the printer.
If the LED is flashing you can be sure it’s a hardware problem (filament angle) of the sensor.
Maybe something like https://www.thingiverse.com/thing:3068419 helps.

#11

Just chiming in to say that the firmware upgrade has solved my bed crashing problems! Many thanks to @SusisStrolch for providing the K8800 firmware flavor and @Devrope for suggesing

I think it’s still a good idea to calibrate before each print, as that provides a mechanical check before printing (especially before a long print!).

The latest Marlin firmware is much gentler on the build surface during calibration; it seems more accurate, and quieter too.

I don’t know why this is has not been recommended by Velleman or their resellers yet - (if it’s because V2 it’s too new, I understand) but I expect Velleman would fix a lot of new/newbie (cough, myself) K8800 user’s issues instantly if they begin to support and roll out new printers with V2 or higher IMO

1 Like
Raise Z start - K8800
Vertex Delta issues
#12

Same issue here. I just assembled the printer last night, calibrated like 10 times, and my buildtak already has grooves in that same fashion, all happening during the bed leveling. The only time it didn’t crash, the nozzle was hitting the model hard while printing, so after about 10 minutes it detached the print from the buildtak and started shuffling it around. :sob:

Will upgrade the firmware and see if this solves it, else it’s pretty unusable…

#13

If you’ve eliminated all mechanical issues - definitely try it out @acbellini.

Mechanical issues checklist (simplified, see post for full details from Velleman support, or follow the manual again)

At least now, having upgraded the firmware, I can print and finally focus on learning how to tune prints!

(Let me know if I can help, as I’ve just done this recently myself)

Good luck!

1 Like
#14

Thanks wamwam!
Upgrading the firmware resolved that problem with the head drilling a hole and carving a canyon in the buildtak. I’ll just add that it’s not possible to build Marlin 2.0.7 on Windows, I wasted a couple of hours fighting with Arduino IDE and then VS Code - and a ton of misleading info - befor finding this video. Built and uploaded from a Mac and it all went smoothly.
Still some issues to solve, but making progress towards completing a first print :smile:

Thanks again!

#15

I’m hopeful for this myself, but new to the process… once I get to a built .hex/.elf from VSCode, do I just connect to the printer via USB and perform the ‘upload’ task from within platformIO/VSCode?

(I can’t see a non .exe version of the official Velleman firmware programmer to try anything else.)

Thanks to everyone for their work with this.

#16

I also took the plunge and replaced the stock firmware, but I went with Klipper. Everything works much much better, I haven’t had a single mishap with the bed yet and every single print has completed successfully since (as opposed to 7-8 failures out of 10).

Edit: Happy New Year to all of you!