Skip to content
New issue

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

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

Already on GitHub? # 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.

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

Successfully merging this pull request may close these issues.

2 participants