VzBot 330

[TitusADuxass]

I've just had a belt clip failure mid print! Messy!

Ladies & Gentlemen - if you've got em, check em! 

[mvdveer]

7 hours ago, TitusADuxass said:

I've just had a belt clip failure mid print! Messy!

 

I do NOT like the VZBot belt attachments for the metal print head and carriage. Especially the part where it uses a piece of filament to wrap the belt around. Had a failure on the front left belt due to that. 

I used the belt clips just to tidy the ends. The belts are secured with a small zip ties, then the belt clip to tidy it up.

[TitusADuxass]

6 hours ago, mvdveer said:

The belts are secured with a small zip ties, then the belt clip to tidy it up.

Good idea!

I shall adopt the same approach. 

[ErickSaint]

I'm happy this post popped up in a google search. I've scanned thtough this board before, but this made me join.

I'm running a btt kraken on a vz330 and haven't been very lucky with it. So many little issues, I can't even get it to prime correctly, despite a .08 variance after a mesh, with cartographer. If I use adaptive mesh and purge I get a "timer too close" error the second it moves to do the purge after the mesh.  I thought I was doing a good thing by "organizing" my configs into individual files and using includes. But I think I need to get back to basics with one big long printer.cfg and go from there. Next step is to get a new SD and start from scratch I think. I grabbed the cfg posted here to compare to my current one.

[TitusADuxass]

2 hours ago, ErickSaint said:

I'm happy this post popped up in a google search. I've scanned thtough this board before, but this made me join.

I'm running a btt kraken on a vz330 and haven't been very lucky with it. So many little issues, I can't even get it to prime correctly, despite a .08 variance after a mesh, with cartographer. If I use adaptive mesh and purge I get a "timer too close" error the second it moves to do the purge after the mesh.  I thought I was doing a good thing by "organizing" my configs into individual files and using includes. But I think I need to get back to basics with one big long printer.cfg and go from there. Next step is to get a new SD and start from scratch I think. I grabbed the cfg posted here to compare to my current one.

I'm glad it helped. 

It works really good the this Start_Stop.cfg

You need to tweak this setting to suit your printer  SET_GCODE_OFFSET Z=0.4 ; add a little offset for hotend thermal expansion
                          

[Penatr8tor]

7 hours ago, TitusADuxass said:

You need to tweak this setting to suit your printer  SET_GCODE_OFFSET Z=0.4 ; add a little offset for hotend thermal expansion

That's a lot for thermal expansion... Are you sure you didn't mean 0.04?

[ErickSaint]

I'll look into that once I can get the basics working properly. But the thermal expansion as a whole isn't something I had thought of with the goliath. I was trying to get orcaslicer to pass gcode offsets based on material in my bedslinger config, but never did get it working properly. 

I'm going to go back and read through this whole post. Because I feel like I missed something small in my configs. I'm just using cheap stepper online motors at 24v for my awd, but dedicated PSU for the awd, because it's what I had. I didn't really do a "kit build" vzbot, I kinda went rogue with things i had on hand. With the exception of the toolhead, that's mostly BOM, but with a printed mount and EBB36.

[mvdveer]

2 hours ago, ErickSaint said:

I was trying to get orcaslicer to pass gcode offsets based on material in my bedslinger config,

I got this from Chat GP:

 

In OrcaSlicer, setting a per‑filament Z‑offset (i.e. adjusting how “squished” the first layer is based on which filament you’re using) isn’t natively supported yet—but you can achieve it using a clever workaround with conditional start G‑code.

Current State: No Native Per-Filament Z Offset

A recent feature request was posted on GitHub asking for filament‑specific Z‑offsets in the filament settings menu. The OrcaSlicer developers have not implemented this yet  .

There is also discussion calling for this functionality (similar to what Cura offers), especially to avoid manual babystepping when switching filaments  .

So, as of now, OrcaSlicer does not offer a built‑in option to adjust Z‑offset on a per‑filament basis.

Workaround: Use Conditional G-Code in Start Script.

Here’s how to do it:

1. Open Printer Settings → Customize G‑Code → Start G‑Code in OrcaSlicer.

2. Add something like this:

{if filament_type[initial_extruder]=="ASA" } M206 Z0.05 {endif}
{if filament_type[initial_extruder]=="PETG" } M206 Z-0.02 {endif}

 

This instructs the printer to apply a +0.05 mm offset for ASA, or –0.02 mm for PETG, etc., depending on the filament selected  .

Save and test. At print start, the correct offset will be applied automatically based on the filament profile you chose.

 

You can add logic to your start G‑code to apply different Z‑offsets based on the filament type chosen for the print. This is done by inserting an if statement that checks the filament and then issues an M206 (or equivalent Z-offset) command.

 

Don't know if it will help, but I thought I'd post it anyway.

 

[ErickSaint]

Oh, I never thought of chatgpt. I was trying something similar by adding this into my advanced filament settings, but it wasn't passing through to my klipper start macro properly by filament_type, so I gave up. Lol. I had other ideas too that I never got working right, like a gradual cooldown macro to run at print end for different filaments, because every ABS print on that machine wants to warp as it cools down. But I absolutely suck at coding, so bashing it together didn't work either. Then I started putting all my time into this Vz build.

; Filament gcode
;SET_GCODE_OFFSET Z=-0.020 MOVE=1

 

[TitusADuxass]

16 hours ago, Penatr8tor said:

That's a lot for thermal expansion... Are you sure you didn't mean 0.04?

That's what is in my Stop_Start.cfg. I think I've misunderstood the use of this, and this is probably why my Z height is too high when the printer is hot. Time to review my settings.

[claudermilk]

I have a couple of filament-dependent items in my macros. I just have the slicer pass what filament is used and the Klipper macros take it from there. 

I haven't seen a need to change Z offset based o filament myself. For my setup, if the print_start sees "ABS" passed from the slicer it forces a wait until the chamber temp hits 30C. In print_end, if it sees "ABS", it activates the chamber exhaust fan until the chamber temp comes down to 25C. 

[ErickSaint]

1 hour ago, claudermilk said:

I have a couple of filament-dependent items in my macros. I just have the slicer pass what filament is used and the Klipper macros take it from there. 

I haven't seen a need to change Z offset based o filament myself. For my setup, if the print_start sees "ABS" passed from the slicer it forces a wait until the chamber temp hits 30C. In print_end, if it sees "ABS", it activates the chamber exhaust fan until the chamber temp comes down to 25C. 

I may touch back on this with you when I figure out my issues on this build, that sounds like exactly what I was looking to do. With my Elegoo n3+ running a stealthburner head, certain material just seemed to work better with a slight heavier or lighter squish, thats what I was trying to accomodate for with a filament offset. But having it do certain things based on the slicer passing filament type info seems way easier than what I was trying. I was trying to do the gradual cool down because that machine is in a tent and when it's not runnin the temp evens out pretty quickly in the cooler months. And everthing abs eventually bowed on me, thinner stuff worse than heavier.

[ErickSaint]

After starting completely over from a full scratch fresh install, and leaning heavily on this post, it lives and breathes again. So thank you again for this thread!

I'm still gun shy about adaptive purge, because of the klipper timer errors it was throwing at me before. But I have a succesful purge line for the first time ever! I have to restart tuning all over again, but this gives new hope. Everytime I have tried getting this thing working properly I always gave up. Not saying there won't be headaches, but this has me opptimistic.

[claudermilk]

Adaptive purge is just leveraging on adaptive bed mesh and placing the purge line just outside the print job area. I long ago moved away from the fun Voron logo purge to the plain old line.

[Penatr8tor]

2 hours ago, claudermilk said:

I long ago moved away from the fun Voron logo purge to the plain old line.

Yup, Me too. Although I'm using a self-made blob purge but... no real need for an adaptive purge that moves around the bed IMO. It was cool tho so there's that. 

[ErickSaint]

I got adaptive working after I posted this. I wanted the big fat purge line that the kamp purge gives. Last thing I do of all my startup steps is heat up the goliath, and it oozes pretty good with pla, that fat purge seems to pick up the blob before it prints the skirt.

Before I got this working correctly I couldn't get a standard purge to work without digging into my PEI, I've got the grind marks to show for it. Even with a full bed mesh, which got me in the mind to have the purge close to the object using adaptive mesh/purge. I've still got a ton to learn about this printer, but this is the closest I've gotten to "working" since I first saw it move in January. Hoping to get the plexiglass panels cut, drilled, and mounted this week, then move it to is final home and get it dialed in. 

[TitusADuxass]

It looks like the BTT Pi2 has decided to play up again.

This a right old PITA as you have erase the internal memory and complete reinstall everything from scratch.

It started, this time, with a loss of communication with the Beacon. So I removed the link from Beacon to the O2S toolboard and went back to a USB cable- that cleared that problem.

But now it reports a loss of communication with the MCU and fails during homing.

Fortunately, I have a spare Pi 4 doing nothing, so let's see what happens when I install that.

[Penatr8tor]

8 hours ago, TitusADuxass said:

It looks like the BTT Pi2 has decided to play up again.

Is there really any time where one of the many Raspberry Pi clones doesn't develop an issue?

Sorry to hear you're having issues and not to rub it in but... I buy really good quality MX boots... Why? Because when you've ridden 50 miles of trails and you got a big blister on your heel because you bought the cheap boots and now you have to suffer thru the 50 miles to get back with a blister... You think to yourself, I would gladly pay the extra money to not have the blister in the first place. I think you get the analogy. 

Bro, the Pi crisis is over. Get a real Pi and put that BS behind you. Just saying, friends don't let friends buy Pi clones. 

[PFarm]

9 hours ago, TitusADuxass said:

It looks like the BTT Pi2 has decided to play up again.

 

I know the feeling. Ever since I added the Orbiter toolhead and the filament sensor, the CB1 has not liked the additional load put on it. BTT Pi and CB1 were when Raspberry Pi weren't available, but to be honest, they're junk!

[atrushing]

2 hours ago, Penatr8tor said:

Is there really any time where one of the many Raspberry Pi clones doesn't develop an issue?

I am in a similar boat with the CB1. It worked perfectly fine for over a year but now I have to reboot it every third day to clear the system memory. It will just keep climbing until the whole system crashes..

[ErickSaint]

I run two machines on btt pi v1, mostly I run then because they can take 24v direct from my PSU and I dont have to use bucks or another wall wart to power them. I haven't had anything off with them. I did have a weird thing using a canbus hat on one of them, it disabled two usb ports on the pi. Probably some kinda internal bridging to redirect to the hat. I had to run a powered hub when I was experimenting with two cams and a touchscreen, because I only had two ports available. Powered hub worked fine,  but reintroduced thy wall wart I was trying to get rid of, so I just went back to one camera. Running an ip cam temporarily on my vz until I figure out a camera setup. 

[TitusADuxass]

It's back up and running again.

I did have one error message - 

“mcu ‘rpi’: Unable to open port: [Errno 2] No such file or directory: ‘/tmp/klipper_host_mcu’”

Which I fixed by following this - https://www.klipper3d.org/RPi_microcontroller.html

[TitusADuxass]

So the "Lost communication with the MCU" error is back.

SSH in to the Pi.

ls /dev/serial/by-id/

shows me that just the beacon is seen. The Kraken and the Orbitool O2S are not visible.
usb-Beacon_Beacon_RevH_FB12DEC35154354D38202020FF0A2308-if00

Do cold start and the Beacon and the Orbitool O2S are visible.

ls /dev/serial/by-id/
usb-Beacon_Beacon_RevH_FB12DEC35154354D38202020FF0A2308-if00  usb-Klipper_stm32f072xb_Orbitool_O2S-if00

No sign of the Kraken. 

Replace the USB lead from Kraken to Pi - Et Voila!  The Kraken is back.

 ls /dev/serial/by-id/
usb-Beacon_Beacon_RevH_FB12DEC35154354D38202020FF0A2308-if00  usb-Klipper_stm32f072xb_Orbitool_O2S-if00  usb-Klipper_stm32h723xx_080015000C51323532393433-if00
 

The USB works, I think the Kraken's USB C socket is a bit loose.

[TitusADuxass]

5 minutes later and the error is loss of communcation with the Beacon.

But,  ls /dev/serial/by-id/ shows that the Beacon is there but the Kraken is missing.

usb-Beacon_Beacon_RevH_FB12DEC35154354D38202020FF0A2308-if00  usb-Klipper_stm32f072xb_Orbitool_O2S-if00

Is it worth reflashing the Kraken?

 

[Penatr8tor]

6 minutes ago, TitusADuxass said:

Is it worth reflashing the Kraken?

100%, it might even solve your problem. Certainly, wouldn't hurt.