fringe cedar
I calibrated everything and ran the T0 to T3 lane change tests. Configured Orca slicer as per the startup guide, edited my print-start macro. It's like it's only printing half the lines it should be printing. Trident is set up properly and prints fine on its own. Any ideas?
fringe cedar
Try disabling adaptive bed mesh if you have it enabled
Disabling this is done in the bed_mesh section of the printer.cfg right?
drowsy gyro
it may be in your PRINT_START macro or in KAMP settings
fringe cedar
I'm not using Kamp AFAIK
drowsy gyro
what probe are you using, and when you do a bed mesh, does it probe the whole bed, or just the portion near the prinT?
fringe cedar
I'm using a good old Omron inductive probe, the one I got with my Trident kit. When I do a bed mesh, it probes the whole bed, 20 probe points I believe.
I didn't do a bed mesh before starting my print however, just a Z-Tilt. I only do a bed mesh when printing a part with a large footprint.
drowsy gyro
oh
"good old omron probe" = trash IMO ... @bitter glade had similar experiences where Z offset woudl flail wildly around on each print
you will rpobably need to watch every print like a hawk ... I can highly recommend beacon, others like cartographer, tap, revo pz or even klicky probe...
i wish i had an easier solution for you
bitter glade
If it was an LDO kit it should have come with parts for clicky as well
If it was a Formbot, should have parts for tap
fringe cedar
you will rpobably need to watch every print like a hawk ... I can highly recomme...
All right I'll keep that in mind. Thanks for your help.
drowsy gyro
All right I'll keep that in mind. Thanks for your help.
this is nothing you did wrong by the way ... it just seems to be an unfortunate side effect of that probe from what limited experience we have (most of us, do not run it... you may be able to get better support on it from e.g. the voron helper ticket system if they have other ideas)
does this only happen with a particular slicer or when you have a prime tower?
fringe cedar
It only happened this once, part was sliced with Orca of course. I normally use SuperSlicer and the last part I sliced and printed with it printed just fine. I'll do a test print sliced with Orca with the virtual bypass set and see if my Z-Offset is still good.
drowsy gyro
you can also try adding this to your machine start gcode before PRINT_START
; From https://github.com/SoftFever/OrcaSlicer/issues/2167
{ if has_wipe_tower }
EXCLUDE_OBJECT_DEFINE NAME=_all_objects_including_prime_tower CENTER={(first_layer_print_min[0] + first_layer_print_max[0]) / 2},{(first_layer_print_min[1] + first_layer_print_max[1]) / 2} POLYGON={"[["}{first_layer_print_min[0]},{first_layer_print_min[1]}{"]"},{"["}{first_layer_print_max[0]},{first_layer_print_min[1]}{"]"},{"["}{first_layer_print_max[0]},{first_layer_print_max[1]}{"]"},{"["}{first_layer_print_min[0]},{first_layer_print_max[1]}{"]"},{"["}{first_layer_print_min[0]},{first_layer_print_min[1]}{"]]"}
{ endif }
Ok, I did a few tests and like you said Z-Offset was way off even on a virtual bypass print. I checked the config file and the value was still at the value I had calibrated it a while ago (1.500). But for some reason the value was listed as 0.000 in the Toolhead section in Mainsail. So I disabled virtual bypass, re-started the Cereal print and baby-stepped the Z offset while it was printing the purge tower. At -1.555 it seemed to be producing a decent enough first layer so I let it run. It printed the first color OK but when the time came for a filament change, I got an error message and the print was cancelled.
drowsy gyro
Ok, I did a few tests and like you said Z-Offset was way off even on a virtual b...
ok, this is probabgly due to some sort of ramming or tip forming moves enabled still in teh slicer. If you are using orcaslicer please confirm that your settings match teh screens
screenshots in the initial startup guide
if they do, please upload the gcode you are using
fringe cedar
@drowsy gyro Correct me if I'm wrong but aren't those values set by the BT-Cereal.3mf file when you load it into Orca? Because I looked and those values are completely off from the values recommended in the initial startup page. Could I have an outdated version of the 3mf file? Nevertheless, I will change those values after loading the Cereal file and re-slice it.
This is what I get immediately after opening the 3mf file
drowsy gyro
the important one to make sure is disabled is the filament ramming int he printer settings
you can change the filament profile and printer profile to your settings
fringe cedar
Ok got it . But if those settings are wrong, then why are they embedded in the Cereal 3MF file?
drowsy gyro
🤷♂️
definitely disable filament ramming
fringe cedar
Isn't this likely to cause a ton of confusion?
drowsy gyro
probably
fringe cedar
And Manual filament change also right?
drowsy gyro
make it match the docs
fringe cedar
I will thanks
drowsy gyro
then retry and let us know how it goes
fringe cedar
Will do 😁
@drowsy gyro I don't get it. I re-sliced it but now I don't see a purge tower on the build plate.
fringe cedar
@drowsy gyro Something weird is going on here. On my previous attempt, I baby-stepped the Z until it was at a good height for the 1st layer. I saved the value using the Toolhead panel's save to config button. Then on my next attempt, the nozzle started at the same height as it did before my first attempt. It's as if the new position_endstop did not get saved... So I opened the printer.cfg and there it was at the end of the file where it should be. Am I missing something here?
drowsy gyro
it is normal for it to save the configured value in that section
note that the endstop position is for the physical pin you have configured that your nozzle physically hits
can you post your printer.cfg?
fringe cedar
Here you go. I know the value is saved in that section, the problem is that Klipper seems to ignore it and starts printing with the nozzle 3-4mm above the bed instead of 1.705mm above the Z-endstop switch.
drowsy gyro
is this true whether you are doing a mutlicolor print with a prime tower or not?
fringe cedar
I haven't tried printing without a prime tower.
drowsy gyro
ok. i’ll send you something when i get back.
fringe cedar
is this true whether you are doing a mutlicolor print with a prime tower or not?
I sliced a single color part in Orca and sent it to the printer: same deal. Nozzle starts printing about 3mm above the bed. Sorry about the bad lighting on the video, the RGB port on my toolhead board is fried so no nozzle LEDs. This is probably just a coincidence but I noticed that the nozzle hovers at the same height above the bed as when it's performing a Z-Tilt with the inductive probe.
fringe cedar
Sorry I uploaded the wrong video....
drowsy gyro
I really have no insight into why this is occurring ... unless it is just the usual omron probe shenanigans. Have you tried disabling unloading the box turtle, disablign the AFC software, and see if hte same gcode prints succesfully without that setup?
(for a single color print)
disablign the AFC software = comment out the [include AFC/*.cfg] at the bottom of printer.cfg
fringe cedar
add 'G28 Z'
Ok, I added the G28 Z command after Z tilt then I restarted the print. Instead of hovering above the bed, the nozzle just crashed into the side of the build plate causing a ruckus (steppers went into oscillation which caused repeated collisions). A big scare but no harm done, just a few scratches on the side of the nozzle (I'm surprised at how sturdy these things are). But adding that command DID something which was actually encouraging. So I redid the Z_ENDSTOP_CALIBRATE. And just as I was sure it wouldn't work, it did!! 😆 Printed the single color part and it is looking fine.
Ok, retrying the Cereal print. Here goes nothing. It's printing the purge tower now. I suspect the first filament change will be the next hurdle... Keeping my fingers crossed 🤞
drowsy gyro
great. what happens is when you do a Z_TILT_ADJUST, the plate adjusts and thus your Z offset also changes.
going forward, it should be hopefully more stable
fringe cedar
great. what happens is when you do a Z_TILT_ADJUST, the plate adjusts and thus ...
Yeah I think somehow in the update to the AFC-Klipper add-on, the Z-Offset somehow got thrown out of whack. But it's all good now. Started printing the Cereal 3MF, filament changes are working as they should but I notice that the purge is uneven. The colors in Lane 1 and 2 (green and blue) are amply purged before the next color, sometimes to excess but the last 2 lanes (orange and brown) are not purged enough. Is this normal, surely there's a way to tune this right?
drowsy gyro
yes
T[next_extruder] PURGE_LENGTH=[flush_length]
can help
or adjust flushign volumes in your slicer
fringe cedar
Ok thanks. I think I'm almost ready for a serial request here. Thanks for your help @drowsy gyro Couldn't have done it without you!!
drowsy gyro
note that perfect color separation is not a serial requirement
drowsy gyro
we good to close this one out?
fringe cedar
```T[next_extruder] PURGE_LENGTH=[flush_length]```
can help
or adjust flushign ...
T[next_extruder] PURGE_LENGTH=[flush_length]
Is that a console command?.... Do I have to type it every time it's about to change filaments? Flushing volume in slicer... Is this what you mean?
drowsy gyro
T[next_extruder] PURGE_LENGTH=[flush_length]
Is that a console command?.... Do I...
you change it in the slicer machine settings
it would replace the T[next_extruder] line you have there now
fringe cedar
And where do I set flush_length?
drowsy gyro
it is a variable that orca will pass in for the color change, that's defined by the flushign volumes
fringe cedar
Ok thanks. I'm so new to Orca I can barely find my way around. Sorry about all the newbie questions. I see what's going on now, that totally explains the cross-contamination between some colors and not some others. Ok, off I go to push some more plastic 😁
