Y axis is homing with Z and with X when homing axes separately from PC

[dmmedia]

Not relevant any more I have uplugged extruder cable, which contains the following wiring:

• extruder stepper;
• extruder heater;
• extruder fan;
• extruder thermistor;
• part fan.

After that I issued the command G28 Z0 by pressing Z home button in Repetier Host and Z axis started to home with Y axis. I have QUICK_HOME enabled if that helps, but it should not interfere here. Wrong sentence When extruder is plugged in, then all axis are homed one at a time when I press appropriate axis home button.

[alexborro]

Try pressing just the X homing button and check the behavior. The try just the Y Homing button.

Cheers.

Alex. Em 28/03/2015 11:49, "Denis" notifications@github.com escreveu:

I have uplugged extruder cable, which contains the following wiring:

• extruder stepper;
• extruder heater;
• extruder fan;
• extruder thermistor;
• part fan. After that I issued the command G28 Z0 by pressing Z home button in Repetier Host and Z axis started to home with Y axis. I have QUICK_HOME enabled if that helps, but it should not interfere here. When extruder is plugged in, then all axis are homed one at a time when I press appropriate axis home button.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1719.

[dmmedia]

X homing button triggers X and Y homing. Y homing button triggers only Y homing.

Also I have updated to the latest version and behaviour observed is the same. But MINITEMP now triggers requirement of M999 to be sent to reset the printer which causes another issue in communication between Repetier Host and the printer. I will probably create new separate report about that after testing.

[AnHardt]

If this cable is still unconnected - then your thermistor is unconnected and therefore 'Err: MINTEMP' and the requirement of M999 the expected behavior. Please tell us more about your machine. Is it a coreXY?

[dmmedia]

Printer is RigidBot, CoreXZ (UPD: wrong, non Core printer)

Home all behaviour is correct: X and Y first (QUICK_HOME), then first finish X, next Y and at last Z.

[alexborro]

Where did you see Marlin has support for CoreXZ kinematics??

2015-03-28 18:22 GMT-03:00 Denis notifications@github.com:

Printer is RigidBot, CoreXZ.

Home all behaviour is correct: X and Y first (QUICK_HOME), then first finish X, next Y and at last Z.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1719#issuecomment-87315576 .

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[dmmedia]

I have commented out define COREXY.

So everything else seems to work properly, except for homing behaviour.

I have performed more tests and it seems that extruder thermistor (and MINTEMP error) do not interfere with this issue.

I have plugged extruder in and still observe strange homing behaviour.

[alexborro]

Sorry but a CoreXZ bot will not work on a CoreXY kinematics.

That is exactly the reason you are having this issue.

Try moving the axis X, Y and Z each a time.

Cheers

Alex Em 28/03/2015 19:20, "Denis" notifications@github.com escreveu:

I have commented out define COREXY.

So everything else seems to work properly, except for homing behaviour.

I have performed more tests and it seems that extruder thermistor (and MINTEMP error) do not interfere with this issue.

I have plugged extruder in and still observe strange homing behaviour.

From: alexborro [mailto:notifications@github.com] Sent: Saturday, March 28, 2015 11:53 PM To: MarlinFirmware/Marlin Cc: Denis Subject: Re: [Marlin] Y axis is homing with Z when extruder assembly is unwired and MINTEMP is triggered. (#1719)

Where did you see Marlin has support for CoreXZ kinematics??

2015-03-28 18:22 GMT-03:00 Denis notifications@github.com:

Printer is RigidBot, CoreXZ.

Home all behaviour is correct: X and Y first (QUICK_HOME), then first finish X, next Y and at last Z.

— Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/1719#issuecomment-87315576

.

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

— Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/1719#issuecomment-87317318> . < https://github.com/notifications/beacon/ABc9hMhBpjX8jW-BOaARzVBzUqfuMPeZks5n5xo2gaJpZM4D2Xxr.gif>

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1719#issuecomment-87323337 .

[thinkyhead]

CoreXZ isn't really supported in the current Marlin, is it? Not without some major tweaking.

[dmmedia]

Hey, I have line // #define COREXY left commented, so CoreXY kinematics should not be the case.

I have tons of prints and many many hours of printer work. Everything was working properly until recently issue Issue #1605 occurred after one of commits. And that was minor issue.

Current issue occurred after I have pulled commits made over last seven days.

So if I properly understood, support for CoreXY advanced kinematics is a configurable Marlins feature and if it is switched off, then any conventional 3-axis printer is supported. And deltas also have own configurable support which can also be turned on or off.

[dmmedia]

Sorry, my mistake of understanding what is CoreAnything. Thought it is simply which axes are tighten together, but it turned out to be complex mechanical system. So my printer is not CoreXZ at all. And issue still present.

[thinkyhead]

@dmmedia #1736 fixes the bug.

It also adds a note in the code comments about the home_offset being applied possibly incorrectly when setting positions. For example, currently if you do…

G28 X Y

…or…

G28 X0 Y0

…the current position will be set to X = 0 and Y = 0. But if you do this:

G28 X0.0001 Y0.0001

The result will be X = home_offset[X_AXIS] + 0.0001 and Y = home_offset[Y_AXIS] + 0.0001. We recently took these home_offset values out of G92 and I think that if G28 is supposed to be consistent with G92 then we should remove them here also.

Another thing I noticed is that the Z_RAISE_BEFORE_HOMING values are being applied only after the X and Y axes are already homed, and just before homing the Z axis, which would seem to defeat the purpose. But note that the Z_RAISE_BEFORE_HOMING value only applies if ENABLE_AUTO_BED_LEVELING is active.

So I wonder if that needs to be changed also, or if this is somehow intentional.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.