Error during homing contact on repeated prints
I am receiving an error message "Error during homing contact" inconsistently. In this case, I printed two objects and the third gave the error. In particular, the second and third object are near identical (extrusion multiplier tests). I also ran into this issue yesterday under similar circumstances. (Three prints succeeded and all after the third failed like this)
The carriage is parked in the extreme front left position every time. The nozzle tip is beyond the range of the bed magnet. It happens after rehoming after z tilt.
This is using a beacon and on ratos 2.1
69 Replies
I can take more pictures if the position is not illustrated enough
is it beacon based printer it looks like? If so do you have performance mode enabled (assuming RatOS 2.1). It can sometimes error out like that on homing if the Z does not come up quickly enough. Performance mode makes it home quicker and typically takes care of it. Otherwise just start the print again and you should be fine.
It is beacon based,
right now I did not enable performance mode in the configurator. don't currently have cooled drivers
I can retry the print, but yesterday this happened consistently after the first few two prints
Though now I wonder if I can work around it by turning off the motors in between each print
which isn't really a "fix" but a way to narrow down the cause
Without turning off the motors, but letting it cool down, it worked
Immediately trying again it failed in the same way
third time right way also failed same way
fourth time: cut power to motors, did not let cool down. failure
I do not think keeping exact track of the temps will matter but this is right after the fourth failure
So for starters, you'll want to fix this
That's what's causing the error (there's no contact event detected when it is expected)
I assumed as much, but toying with the value of
[beacon] y_offset: 22.5 didnt seem to move where it probed
and it only tried to move that far on the prints that failed. the ones that did not fail tested within the range of the magnet on the build plateIt will move the toolhead so that the coil is over the nozzle coordinates, that's what the offset is used for. That is not the problem here though. You're homing in a bad spot. It's just poorly (or not at all) calibrated x/y limits.
you want 0,0 to be 5mm within the print sheet (it's 10cm wider / longer than the build area)
Just noticed someone posted a guide to doing this, you can give that a shot: https://discord.com/channels/582187371529764864/1261800913547558964
I will test this in just a moment, thank you
I think those steps exactly are incorrect for the y axis on vcores
Setting the position_endstop and position_min to the negative values as they describe causes it to move forward (away from the y endstop) during homing
e: may have figured it out, if the nozzle tip was inside the plate at 15mm, then I think i want to set
[stepper_y]
position_endstop = 485
(that is, 500 - 15)Yes on V-Core 3 you home at the back which naturally is a positive endstop value near position_max
how did you know that i just started the next test print litterally One minute ago
But yea, I think those instructions linked assume the endstop is at 0 for both X and Y,
the same process can be used for Y, just modifying a different value
It's assuming everyone uses a voron š
Huh, first two prints after changing that worked fine. but just as before, the third failed with the carriage parked in the corner
This time within the bounds of the sheet, but same corner
Still getting failures in the same way unless I let it sit for a long time
I dont think the offsets were directly the issue
why is it homing in the corner?
Interesting question, watching it fail just now:
it checks the three corners for Z tilt,
moves to the center to home after tilt,
move to the corner to gently press the nozzle into the bed. "Error during homing contact: No trigger on probe after full movement"
maybe my macro got weird?
e: "start g code" for printer in sclicer is
START_PRINT EXTRUDER_TEMP={first_layer_temperature[0]} EXTRUDER_OTHER_LAYER_TEMP={temperature[0]} BED_TEMP=[first_layer_bed_temperature] TOTAL_LAYER_COUNT={total_layer_count} X0={first_layer_print_min[0]} Y0={first_layer_print_min[1]} X1={first_layer_print_max[0]} Y1={first_layer_print_max[1]}I'm going to need a debug-zip for sure
Before reproducing the problem next time write DEBUG_ENABLE in the console.
Then reproduce the issue and download the debug zip and send it to me
I'll do that now while its still warm
oh no i wont
sec, i may be remembering wrong
Try ENABLE_DEBUG while i look š
bingo lol
Ah yes it's
ENABLE_DEBUG
šIt's still running and not failing, you know just to be difficult but, I did take note of when it moves to the front left
In particular, the nozzle wipe looked like this
(The smallest gash, formed before my very eyes lol)
Now I've run into the failure with enable_debug, where do I find the debug zip?
247.5 x 250 is not the front left
Something is very wrong here.
Oooh.. "-inf" on Z measurement..
That's really bad.
Are there strong magnets in those custom Z arms?
(not sure why there would be, but who knows what people come up with)
This is the cause of your troubles
fucks over the beacon, you have a massive no-scan / no-contact zone around that arm.
I can't type today
huh, interesting
I can try them without magnets shortly, but why would that make it try to z home in the corner?
It doesn't home z in the corner, it probes for the prime blob because of the adaptive mesh.
You can disable the adaptive mesh.
but keep in mind your mesh results near those arms are going to be unreliable
oh that makes sense, yeah
but wouldnt disabling the active mesh not fix the issue? actually I can generate a bed mesh to see how wack it is in the corners and see
Disabling the active mesh would stop probing for the prime blob, but yes your z would still be fucked near those arms
hm seems i cant manually run a bed mesh
e: either way, I'll try non adaptive stuff in a moment
V-Core 3 yeah? You have to adjust your bed_mesh min/max to use beacon
default probe offsets, z_tilt and mesh assume superpinda on eva 3
that may explain why the rear most probe of z_tilt is slightly to the side
yes
I must have overlooked that
and why you're probing so close to the edge of you plate
you would have had to read the klipper documentation.
There's no way for me to know how to adjust coordinates when people use custom toolheads.
For sure. I didnt even think to check
took me way to long to figure out that mesh_min needs to be greater than beacon offset values š
and this isnt a "good" bed mesh, but it does look better than I'd expect if the front two corners were black holes of undefined data
eg, these four are different meshes
It doesn't get as close to the edge after you fixed the mesh coordinates is my guess š
Nope, still does in the nozzle wipe. And I still ran I to the same error as before when actually printing
Later today I'm going to try a much more aggressively small bed size min and max before taking out the front left magnet
And when I check for z tilt, the rearmost point is still not lined up with the middle,
But
[probe] x_offset gave an error when I set it in printer.cfg
I may still be configuring the macros wrong
E:but unfortunately now I must be back in the office so I can't grab the exact erroryou'd still need to disable adaptive_mesh
Oh yeah, got that set to false too
Removing the front left arm magnet did nothing
and trying to set probe_x so the rear most z-tilt wont be off center results in this error
you are using beacon, so that would go under
[beacon] not [probe]Yeah, got that too as
[beacon]
x_offset: 0
y_offset: 22.5 Yeah, so get rid of the
[probe] section you can't have bothI did, but the z tilt is still off on the back section
Which is probably not directly related to the probing issue in the front left corner
yes you'd need to adjust your z_tilt points to fix that, not your beacon offsets
z_tilt points uses nozzle coordinates and ignores your probe offsets
because klipper logic...
Huh, def gonna chalk that one up to klipper as well lol
well that did fix the off center z-tilt, but not the error during homing contact
maybe something is mis conifgured on the beacon for the z axis?
There's nothing to configure
the problem is the reading you're getting in that corner is bad
when using contact, the toolhead moves forward to place the coil over the nozzle area, so it's further forward than your mess would be. But it's not supposed to do that when probing the prime area..
Even with the magnet removed?
I'm not sure
Might just be too close to the edge to get a proper reading
@Helge Keck any idea here? nozzle keeps digging into the build plate when priming, and it fails after a couple of prints.
I'm also rerunning beacon_ratos_calibration right now,
don't know if that needs to be re run after changing the bed and mesh variables though
Shouldn't have to, but doesn't hurt
And to confirm, still happening and it's about this far in now when it does
at x = 5, y = 5
Might be too close to the edge in X
it might BUT
I tried turning off all motors after last failed print, printing right away, and now it's working. I will attempt this again after the print completes
What does
BEACON_RATOS_CALIBRATION report?
There are several checks in there that might give us a clue
Because if turning off the motors work, that tells me something is loose and one or more axes are drifting over time.These were some of the final numbers
but in the process of me taking these, failed the same way even with the motors off
these all seem perfectly reasonable
hmm
according to the beacon doc you shouldnt have any metall near the beacon on your toolhead, and you should have the beacon much closer to the bed than this
idk if this is a problem, but this setup should be checked by matt maybe, i suggest to ask in the annex discord to make sure it can be used like this
other than that i have no idea whats going ont tbh
i could also move the contact wipe move more to the middle isntead of doing at at the corner
just to avoid any reading errors so close to the edge of the bed
for the contact wipe the nozzle shoul dbe at Z0.1
i suggest to turn it off for the moment with:
@miklschmidt i moved the contact wipe to
X50 Y10
i also raised it to Z0.2mmLooks like a significant angle too š¤
The first thing I plan on printing post calibration is fixed up carriage parts, including the duct. So if it is a design issue, that'll be the top priority.
I was worried about getting the printer "up and running" before starting to swap out the parts.
In the meanwhile, I will try turning off contact wipe tonight
Oh also it's not "supposed" to be slanted like that, but the spacers I printed were too thick and I didn't notice until mid assembly
Quick update: turning off the wipe before calibrate does let me consistently print. So thank you for that. At least 3 in a row so far
Next plan is to fix the actual beacon placement to see if that was the cause of the issue. I'll report back after those with wipe, adaptive mesh, and the arm magnet back in place to see if those still have an effect for future reference
But again, thank you very much for the help
Wanted to give this one last update:
Problem was entirely the angle of the beacon.
- The magnets in the arms had zero impact on the mesh generation.
- The wipe before probe and adaptive mesh have since been re activated with no further issue.
- The distance of the probe may have technically been an issue, but that is a consequence of it being angled
- The end stop position being set incorrectly did lead to issues (in that it was trying to wipe too far away), but that was a misleading symptom to a different problem.
So again, thank you for helping me figure out and correct my own mistake