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

Update endstops before reasoning about z probe #632

Open
wants to merge 1 commit into
base: development
Choose a base branch
from

Conversation

martinschulze
Copy link

Hey,

on my delta printer I have to update the endstops before reasoning about the z probe. Otherwise the error message "did not untrigger" is printed though the z probe definitely untriggered (it has a LED and manually checking z probe status returns untriggered as well).
I put it in twice in a row because I found it done this way some lines 547 and 548, but I don't know if it is necessary here.

Would be nice to find this in the official development branch so that I don't have to fix it manually before each update.

Martin

@repetier
Copy link
Owner

repetier commented Feb 4, 2017

After checking the code I see that it should not be necessary (which would also explain why I never needed it). See for example this part where you added it:

        PrintLine::moveRelativeDistanceInSteps(0, 0, shortMove, 0, HOMING_FEEDRATE_Z, true, true);
        if(Endstops::zProbe()) {

the second true in moveRelativeDistanceInSteps tells to check and update endstop status in the move. So as long as move is long enough to have 2 steps without triggered endstop it must reset the z-probe (unless you have problems with cross talk).

Could it be that your moves up are too short?

@martinschulze
Copy link
Author

In fact, the line you mention, that I got with the firmware from the configuration tool on 2017-01-03 looks
PrintLine::moveRelativeDistanceInSteps(0, 0, shortMove, 0, EEPROM::zProbeSpeed(), true, false);
In the firmware I downloaded form that tool last friday, the relevant lines changed in both places. I did not test this firmware without my additions. After that test is done, I will close this pull request.

@repetier
Copy link
Owner

repetier commented Feb 6, 2017

Ok, might be that I switched to false for a short while and that of course would make your changes required. So bad timing in that case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants