Will not x-home if you cancel a print and then restart about advi3pp

[andrivet]

I am able to reproduce this bug in the case of a print from the SD card. Is it correct or do you also see this bug during an USB print?

[andrivet]

From my latest tests, the bug is still there (USB print)

[Arsoth]

I can confirm this bug is still occurring on 2.0.1 through USB (at least when using Cura 3.1.0 to print).

[TTVert]

FYI, this occurred for me w/ stock firmware using repetier host as well.

Dave

[TTVert]

Curious if this will be something that can be resolved? This also occurs if you queue up a job in repetier-host before printer is on. It will start right where the printhead was last left. It does home Z however.

[andrivet]

The fix is planned for version 3.0.0

[TTVert]

I see you had screenshots of screen brightness, how close is 3.0?

[Martin-Dolan]

This is probably the same thing, but I was doing a print in ABS and just laying down the first layer. I realised it was going to turn to crap as the bed wasn't level enough so I stopped the print, went to the bed level menu, started the level option however it seemed that it thought the x axis "0" was the point on the bed where I had pressed stop.

[TTVert]

Yep exact situation I run into often. I have to turn printer completely off and manually home w/ G28 Reset doesn't fix for me.

Dave

[Martin-Dolan]

I did notice after I had turned it off and on, when I went and started the level process again I saw a screen that said something about "waiting for homing to complete" or something like that. It was only there for a few seconds. I am 99% certain that it did NOT do that when I did the level process after aborting a print so that might help narrow it down? It is skipping that homing process part of the code when a print has been aborted.

(and I was printing from SD card - I see you asked that of someone else)

[TTVert]

It's an issue w/ the marlin FW. Stock also. andrivet said he was going to resolve it in 3.0.

Dave

[SureshotM6]

The workaround I have been using so far (which I found on another forum and did not discover myself) is to disable steppers with M18 before homing. Seems to be working so far, easier than power cycling everything, and is easy enough to put into the generated gcode or octoprint.

[andrivet]

Is someone able to reproduce this bug is a reproducible way? Is see this but many times, but when I try to reproduce it, I can't...

[SureshotM6]

Is someone able to reproduce this bug in a reproducible way?

Yes. A M17 alone should trigger it (at least on my printer). For example, run the following after moving the extruder somewhere in the middle of the bed where the homing issue is more easily visible:

M17 ; enable all steppers including the extruder
G28 X ; Try to home X.  Won't work

I did some measurements and it appears to be a hardware issue. I've been using this code I wrote as a fix: 5da26d6 "i3plus: fix X homing when extruder is enabled." There are more details in the commit message, but basically, there is noise from the extruder stepper on the X_MIN pin that is causing the AVR to detect the limit switch as closed when it is actually open. Feel free to cherry pick that if you agree with the fix.

[andrivet]

@SureshotM6 I confirm that M17 / G28 X does exhibit the problem. I will try to see the signals with an oscilloscope

[andrivet]

Fixed in Beta 3