No trigger on probe after full movement, but only rarely
Any idea what would cause an infrequent, but persistent:
See the attached video, this is the last minute of a repeated probe accuracy before it fails
Before this run I'd done a couple 100 sample runs without issue.
41 Replies
Here's the console output for the above run.
here's another attempt, by my count it completed 253 repetitions before failing, in the same way
and the
klippy.og including the most recent attemptI see nothing useful in the log, it goes from a successful probe to a failure
In my case that mostly shows up when the nozzle is not clean enough, even a little crud will trigger it. One person also mentioned he got it due to lose wiring (I always get a different warning for that one). Nowadays I try to clean the nozzle as soon as a print is done before it cools down.
This has nothing to do with the nozzle, it's purely beacon coil probing. If you watch the video you'll see that for several repetitions the bed moves down and fully back up. However for the final failing repetition, the bed moves down but does not move back up the same amount.
The bed just stops short for some reason, but claims it fully moved.
Sorry I don't see a video here but I will say mine did that when I had my beacon upside down by accident :pepehands:
it's an attachment on the initial post
Oh the one it wants downloaded 🤦♂️
I'll try converting it to MP4
Well I would have thought the log would say what RatOS update your on but it doesn't so going to ask if your on the 2.1 RC
Yes, 2.1
All good I got it play once downloaded I didn't know it was the video and ya it's triggering as it lighting up red
Here it is as MP4, if you watch the right hand extrusion you can see that the bed fully eclipses the M6 nuts on a full move. On the final move it stops quite short.
A normal full move ending:
The final move where it stops short:
and again, it works fine for 250-ish repetitions and then just stops short
Ya mine did that with the calibration even when it passed and every time I home the printer it will stop were it's not triggering - like after it triggers it lowers a little again
Does your 3.1 fully power off after your done with it? I ask as VCore 4 doesn't have a power switch anymore after the IEC patch and my minion would get all wonky if I didn't power cycle it if I have done a lot of prints
Mine stays on most of the time, but has been recently power cycled... as I recently upgraded to 2.1
can power cycle it and repro
but that'll be tomorrow
just replicated after a fresh boot:
Console output from the session attached, 236 iterations by my count (
grep -c).
For anyone that would like to try this for themselves, this is the g-code I'm running:
Would also love to know if someone can get the 1k iterations to complete without issue.
Running it now, let ya know what happens
@Jamin Collins [VC 3.1 400mm] Wait, I'm doing this test with the SuperPinda. That probably won't help you
@TheTik I think it still will as I don't think this is a probe issue I believe this is a z motion issue it's simply not moving the same amount back up for some reason if you look at the video
The last iteration it just stops several millimeters short. So there's absolutely no way the probe could trigger
ah, gotcha. I know you know your machine but maybe the z couplings are loose? Missed steps seem like something you'd notice audibly
Interestingly, my probe number has gone way down as it continues. Started at 0.95 and is now down to 0.46
No noise from it. And I'd think something loose would show over one of the previous hundred or so iterations. Like variance in readings, etc.
No heaters on so I dunno what would be making things grow/shrink
I'm doing mine could as well. Just motion
And if you look through the console output, it's pretty consistent
Mine is consistently dropping. Weird
Well, completed the sequence on another triple-z printer.... my tri-zero...
Mine is still running, but the z= is now negative. -0.47 and still falling
Still going, z=-1.87
Where is the console logged so I can save/share it?
I've just scrapped it out of the console tab. It's intermixed in the
klippy.log with all the other entries.
I'm guessing yours has gone beyond the scroll history thoughway past
Glad yours is able to complete the iterations
I can grep it out of the klippy.log
its completing it, despite the z value changing by almost 3mm so far
it just isn't changing much between attempts
Wish I had any lead on what would cause the short move though
How is your pi powered?
double power double ground pins from Octopus
Hmm any under voltage warnings?
And what gauge wire did you use?
Never had any undervoltage warnings. I think I used 20ga
I am getting under voltage warnings. Can't draw a complete logic path on why that might matter, but considering it. I mean moves should be handled by the octopus, stepper drivers, and motors. Pi shouldn't really be involved other than making the initial request to move. And can't see a reason the move request wouldn't be for the whole amount.
Another difference is 2240 drivers vs 2209s. I guess I could go back to 2209s on it to rule that out.
Moving the PI to a dedicated power supply and retrying
259 and counting so far
600 and counting so far
may have found the fix, but don't understand the why
probably another 30 minutes before it'll complete (if it does)
820+ 🤞
well sheyet:
So seems like under-voltage is the cause?!?!?
Will run another 1k for verification
Well, that's 2x 1k iterations without issues
The only change being the RPi power source... would love to understand this more
RC: incorrect messaging, problem is in fact a communications timeout:
https://github.com/beacon3d/beacon_klipper/compare/master...bugfix/comms_timeout_error
GitHub
Comparing master...bugfix/comms_timeout_error · beacon3d/beacon_kli...
Beacon Klipper Module. Contribute to beacon3d/beacon_klipper development by creating an account on GitHub.