Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

probe_calibrate won't allow for accept #430

Open
1 task done
EricZimmerman opened this issue Jan 8, 2024 · 13 comments
Open
1 task done

probe_calibrate won't allow for accept #430

EricZimmerman opened this issue Jan 8, 2024 · 13 comments
Labels
bug Something isn't working need to understand Bug look to be identified but more time need to be involved to understand and solve tracking This issue is tracked and work will be done

Comments

@EricZimmerman
Copy link
Collaborator

Klippain branch

  • I confirm using the main branch

Version

latest

Describe the bug and expected behavior

I believe this was a problem with klicky at one point too and it's reportedly fixed. With dockable probes, after the first probe, the probe is docked and the tool head comes back to where it was. The adjustment dialog comes up and lets you step up and down, but then you click accept you will get an error message in the console and the new z offset is never made available.

Tl;Dr; it says to do the adjust, you click ACCEPT, and then it complains with the following:

Error:
Manual probe failed! Use TESTZ commands to position the nozzle prior to running ACCEPT.

I'm guessing it's the fact that the tool head did not move exactly back where it was, ie x or y is off after the docking.

More info here:

jlas1/Klicky-Probe#8

here was my workaround:

call the ALIASED probe_calibrate which is _BASE_PROBE_CALIBRATE

Now, with this, you will need to

  1. attach probe
  2. go to middle
  3. use the _BASE_PROBE_CALIBRATE macro
  4. printer will probe with probe attached.
  5. MANUALLY remove probe
  6. step down per paper test.
  7. ACCEPT

you now have your probe z offset as a starting point.

Additional information and klippy.log

No response

@EricZimmerman EricZimmerman added bug Something isn't working triage This is a new issue to be sorted (automatic label) labels Jan 8, 2024
@Frix-x Frix-x removed the triage This is a new issue to be sorted (automatic label) label Jan 25, 2024
@Surion79
Copy link
Collaborator

well, how to handle this? Should we start with implementing a verbose block in entry/exit_point to print out the saved coordinates to compare?

@Surion79 Surion79 added the question Further information is requested label Jan 30, 2024
@Frix-x
Copy link
Owner

Frix-x commented Feb 22, 2024

I just merged a commit (wrongly on the main branch oops, but I'll backport it to develop) about a probe retainer management and this commit added a fix in the probe calibrate macro to save the position. Maybe it will work correctly now. Can you try it and let me know?

@Frix-x Frix-x added need to understand Bug look to be identified but more time need to be involved to understand and solve and removed question Further information is requested labels Feb 22, 2024
@Surion79
Copy link
Collaborator

@EricZimmerman Energy! ;) :D

@EricZimmerman
Copy link
Collaborator Author

Someone else just ran into this recently on discord. When you use probe calibrate it will go to the middle of the bed probe put the probleway and then come back to what seems like where it was, but then once the dialogue comes up for you to step down there is no way for you to then accept it and have it work

The only way I found to make this work was to bypass the overridden macro and call the base macro manually take off the probe and do all the normal stuff and then it works

From my understanding based on what people on discord said this can happen if the tool head does not come back exactly to where it was before it moved

If any of that needs more explanation let me know

@Surion79
Copy link
Collaborator

Someone else just ran into this recently on discord. When you use probe calibrate it will go to the middle of the bed probe put the probleway and then come back to what seems like where it was, but then once the dialogue comes up for you to step down there is no way for you to then accept it and have it work

The only way I found to make this work was to bypass the overridden macro and call the base macro manually take off the probe and do all the normal stuff and then it works

From my understanding based on what people on discord said this can happen if the tool head does not come back exactly to where it was before it moved

If any of that needs more explanation let me know

@EricZimmerman Frix asked that you try it with updated Klippain, since there has been a fix introduced :)

@EricZimmerman
Copy link
Collaborator Author

Ah I have a print going but I can try this later after a pull

@EricZimmerman
Copy link
Collaborator Author

Just did the test. it did NOT work:

Manual probe failed! Use TESTZ commands to position the
nozzle prior to running ACCEPT.

after clicking Accept.

@Frix-x
Copy link
Owner

Frix-x commented Feb 22, 2024

As discussed on Discord, the fix was only on the main branch but I just backported it to develop also. Please try again with the latest develop and let me know. I have good hope that it will indeed fix it :)

@Frix-x Frix-x added the tracking This issue is tracked and work will be done label Feb 22, 2024
@EricZimmerman
Copy link
Collaborator Author

pulled again from develop, rehomed, centered, attached probe, probe_calibrate, step down, click accept and:

Manual probe failed! Use TESTZ commands to position the
nozzle prior to running ACCEPT.

@Surion79
Copy link
Collaborator

Surion79 commented Mar 1, 2024

@EricZimmerman could you please try with current 4.3 release? Thanks :)

@EricZimmerman
Copy link
Collaborator Author

Has it been updated since release?

Right now I can't test as my printer is being upgraded. Anyone else available?

@Surion79
Copy link
Collaborator

Surion79 commented Mar 1, 2024

My KlickyPrinter isn't finished yet, so I can't test

@Karolas123
Copy link

Still no work. Can you help me?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working need to understand Bug look to be identified but more time need to be involved to understand and solve tracking This issue is tracked and work will be done
Projects
None yet
Development

No branches or pull requests

4 participants