so what's the trick for klicky!
...have tried all four variations of PIN configs
All respond when manually pressing the button or pulling the switch off the magnets.
the problem (to me appears?) there must be a setting I'm missing as both the z-endstop and probe seem to work in unison. HOME ALL, X and Y home and as soon as it heads for the dock I get this error and it shuts down
40 Replies
so what am I missing. printer .cfg attached
probe should be triggered when not attached (normally closed switch)
So change your pin definition to match
z-endstop and probe seem to work in unisonYes that's how it works when you use the probe as your z-endstop. Which all RR machines do
so why the error (deployed) when it starts to go pick up the probe? X and Y home, then as soon as it starts to head over to pick up the probe I get the above errors regardless of which pin config I set in printer.cfg
probe docked
matches the include files for the probe pin
This looks correct yes. And you say it's not working like this?
This is mine with euclid (docked):
Works exactly as it should
yes... see the post this a.m. screen cap error when it starts to go for the docked probe pickup
Be careful with this with the klicky btw:
I'm sorry but it doesn't make any sense that it would throw that error if it's triggered while stowed. That's how it should be.
haven't gottne far enough for that issue but will watch it now
You also posted a pic where it reported open, which indeed won't work
could it be a timing issue? variables as far as positions? EG: this is my 300 bed on a 500 frame... so min/maxs for probing are way smaller than the frame dims and where the prob is located.
No
everything seems to match everything I can trace through the includes. and etc. as as you state.... should work.
that's why it's confusing as heck here for something that should be rather straight forward
Only thing i can think of is that you have a loose connection thats shorting to gnd and thus reporting triggered when moving or something like that
If it reports triggered there's no state change before it has picked up the probe, so litterally impossible for that error
unless you have short 🙂
...should see the light flicker on the probe.... will put one of my tiny o-scopes on the line and see if I can catch a pulse that should not be there
It could be a short elsewhere
Like the signal wire shorts to the gnd wire somewhere in your wireloom
hhhmm... pondering here..... I used the connectorized umbilical wires that was originally going to my BLtouch. So at the octopus board nothing changed. Jut plugged in V+ gnd and PB7 to the klicky at the carriage
(5 wire connector... klicky harness just using three and plugged into same loom)
I don't know. I just know it works as intended as i literally use it all the time 😄
ok...will have to revert back to bltouch.... to test wiring. So only thing that will change is include statements and what's plugged into the umbilical at the carriage.
printer.cfg entris all looked ok?
Or move the toolhead to the dock position and run "QUERY_ENDSTOPS" again
yep, easy test...can query with/without porbe attached as well as move the carriage arounf a bit
thanks again for putting up with me. It just gets VERY confusing when you know better, and it doesn't work as you believe it should.... you start questioning your sanity, or is it improper docs.... or have you just lost your mind completely for playing with stuff that already worked just fine 🙂
@ptegler for more debugging you can do this to verify the exact code that throws that error during homing
To verify state when stowed:
to verify state when deployed:
If it doesn't throw any errors everything is working as it should.
will go try that...be back
with probe stowed
with probe attached
Yeah this further confirms you have a wiring problem because this does what it should do
At some X/Y positions your wires are shorting
just now after doing the asserts.... it head over to the doc as expected! my positions were off, so restarted firmware.... home x and homed y..amd about to manually move x and y to find proper dims for probe positions...but no errors this time.
You prolly didn't press "save and restart" when you fixed your probe pin or something.
Anyways, problem solved i guess 🙂
So possibly... on boot up.... doing an assert stowed resolved the initial issue
?
will see what happens after I get the proper docking positions set
seems so. tnx again
No, it doesn't do anything
I think you just forgot to restart klipper after saving your config
Or you have a loose connection and it'll fail again
good chance
CRAP... Q can you home Y before X?!!!
after setting my docking positions.... restarted...went to home all... and snapped my klicky arm mounts out of the carriage as it tried to move the to X zero (docking was X10) Homing Y first would solve that possible issue in the future if the carriage is way forward on the bed.
sorry... (out from under my rock.....)
@miklschmidt finally went to do my first print (actually the euclid probe dock you linked) with the new (appearing to work right ) dockable probe. Bed heated.... carriage grabbed the probe and did the z-tilt. But then with probe still deployed, the bed came up once again while the carriage was headed towards the primeblob location, but half way there the bed came up a couple millimeters and cashed the probe, partially disconnecting it so it errored.
so went looking through cfg files.... z_hop is still there but set to 30mm (way more than enough to clear) ..couldn't find any reason for the probe to lower enough (bed z- motion) to rub the probe and freeze frame the motion. Any suggestions before I mess up my carriage probe arm again? tia
Increase your bed_mesh horizontal_move_z
wow... ha... perhaps one of the only variables I haven't changed at one time or another! thanks