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

No check for Z level before homing X and Y #669

Open
RRudi92 opened this issue Jun 27, 2023 · 4 comments
Open

No check for Z level before homing X and Y #669

RRudi92 opened this issue Jun 27, 2023 · 4 comments
Assignees
Labels
area: openpnp change to openpnp, or openpnp config

Comments

@RRudi92
Copy link

RRudi92 commented Jun 27, 2023

Version Number

Marlin bugfix-2.1.x(May 19 2023)

Bugfix or Enhancement

Bugfix

Description

The Homing Command issues the machine to home first X, than Y and Z last.
If the Z-Axis is not in a safe position -> CRASH!!! (This happened to me at least 5 times now, and the machine is only a few days here)

Suggested Solution

Z MUST be homed first. G28Z Command does only issuing a whole Home Command. G28X or G28Y work as expected and only home the respective axis.

@RRudi92
Copy link
Author

RRudi92 commented Jul 6, 2023

In Addition, it might be a good Idea, to do a Z-Axis homing after Nozzle-Change. Best would be a warning, if Z has lost Steps after Nozzle-Change, but I don't know if this is possible at all.

@G-Pereira G-Pereira added area: openpnp change to openpnp, or openpnp config area: marlin change to marlin, or marlin config and removed area: marlin change to marlin, or marlin config labels Aug 30, 2023
@andrewortman
Copy link

If I understand correctly homing Z on v3 requires one of the heads to extend all the way down while the other hits the limit switch. This will also cause a crash in the Z direction (although, probably not as serious because of the spring mechanism of the nozzle..) - I found a workaround was to go to the last known midpoint in the HOME_COMMAND gcode under GCodeDriver:

G1 Z32;
G28;

Use at your own risk, of course

@RRudi92
Copy link
Author

RRudi92 commented Sep 23, 2023

Well, this will be of no use if the z-Axis has lost it's position.

The good solution would be to use an inductive Sensor for Homing at Midpoint. Depending on the state of the sensor, you can determin in wich direction the axis has to move.

Another option might be to use the motor torque / current to determin a crash in Z -> revert to about half way, do homing X & Y, and repeat Homing Z.

Another way might be to determin if the machine was disabled correctly (e.g. disconnect button, OpenPnP closed), or if the homing appears out of nowhere -> user saw a crash -> pressed Homing button -> assume Z-Axis lost steps and therefore do Z-Axis Homing first.

@sphawes
Copy link
Member

sphawes commented Feb 19, 2024

we very intentionally home Z after X and Y, because a nozzle plunging into the pick area can be quite a bit worse for PCBs and components in trays/strips than an X gantry crash.

if we have homed before, @andrewortman's solution works wonderfully as it ensures the Z axis is level before homing. if Z is not trusted, marlin thinks that it's at Z0, but it's actually at Z31.5, that G0 Z31.5 command can cause N2 to crash.

the full solution here is to know if marlin trusts its Z position. in marlin source, it becomes a "trusted axis" which effectively means it's been homed before. i've been looking into a way to pull this out via serial so openpnp could prompt a user to manually level the nozzles if Z is untrusted.

@sphawes sphawes changed the title Z-Axis Homing must be first on Homing No check for Z level before homing X and Y Feb 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: openpnp change to openpnp, or openpnp config
Projects
None yet
Development

No branches or pull requests

4 participants