UM3 X/Y calibration AA/AA lowering right head

[kfsone 5]

Half the time I try to print a calibration sheet, my UM3 insists on first lowering the right head, and then totally failing to extrude anything during the print. Or, on the rare occasion I can get it to print the left head's chart, it will then attempt to *raise* the right head and end up doing this:

 

https://drive.google.com/open?id=1KY-CuhyAt7FI4ShHEz7ieyVXQ3sM9yY3

 

A reboot of the machine often convinces it to stop doing this.

 

Sometimes it will say it's doing an auto-level but immediately continue with the calibration; when this happens, the print head gets pushed hard against the bed and nothing prints unless I manually pull the bed down.

 

About 1 time in 6 I get a successful print of the left-head's calibration, but then it fails for one of two reasons:

 

a- About half the time so far, it actively tries to raise, instead of lower, the right head. So, of course, the right head doesn't print anything.

b- There seems to be a retraction that occurs resulting in the right head not extruding any material until the last half of the upper scale.

 

Could probably be fixed by having a G280 or skirt line before the calibration print.

 

Anyone had similar problems and managed to overcome them?

 

[kfsone 5]

I got down to my last spool of PLA for the left head, but I managed - after 3 days - to get a calibration chart printed. In the end, stopped adjusting anything and just kept rebooting the printer and starting a new calibration print. On the 9th run, it printed this:

 

(I'd run out of the other PLA so I had to use black...)

 

After I'd entered the values, without doing anything else, I asked it to print another calibration print: it did the entire print without extruding anything, when it was done I went straight into Material 1 and moved it, and it instantly extruded some material...

 

*shrug*

 

[kfsone 5]

Here it is not-printing. I have no idea why, I primed it before starting this print, you can see the residue on the left nozzle.

 

https://drive.google.com/open?id=1sHU1varPzn2ZhSmLYm0944waA3W3S2Rj

 

It did, though, print the very last line of the y chart:

 

https://drive.google.com/open?id=1pfEOWTcIpbX7_dKPMpPN_HNFPY5rrKcS

 

And then the right filament also failed to be extruded.

 

I've manually leveled the printer and printed a successful 1-layer test print, now I'm going to try printing a calibration print again.

 

Edited May 9, 2019 by kfsone

[gr5 2,210]

Note that there is a known bug in the XY Calibration procedure for both UM3 and S5 where it does not extrude at all out of the second head.  100% of the time.  This is not intermittent.  This is not some users.  This is all users with the latest (as of today 5/8/2019) firmware which is 5.2.something.

 

So I would avoid XY Calibration as much as possible until the next version of firmware comes out.

 

[kfsone 5]

41 minutes ago, gr5 said:

Note that there is a known bug in the XY Calibration procedure for both UM3 and S5 where it does not extrude at all out of the second head.  100% of the time.  This is not intermittent.  This is not some users.  This is all users with the latest (as of today 5/8/2019) firmware which is 5.2.something.

 

So I would avoid XY Calibration as much as possible until the next version of firmware comes out.

 

 

@gr5 Please see above: it refused to extrude the second head on 18 of my 21 attempts to print the calibration chart today.

 

The pattern of behaviors I saw today was entirely consistent with the C/C++ concept of "Undefined Behavior".

 

I was beginning to suspect this earlier today, so I sat and repeatedly power-cycled the printer, asked it to print a calibration chart, and observed the results. Multiple behaviors were random. And yes, a 100% fail rate *is* a legitimate random sequence, if taken from a large enough sample of samples. It's also why you have a smattering of users who can't get auto-level to work at all, a majority of users for whom it is presumably working N/M times and a bunch for whom it works every time.

 

Undefined Behavior often "works in dev" - in my experience it often works in qa and staging, too. UB is frequently non-deterministic 

 

If you want - I can take a look at the change log on github of the commits that went into this firmware and see if I can spot anything that would introduce a UB issue? I'm happy to trawl the code, but I'd rather not have to find it in the first place 🙂

 

-Oliver

[kfsone 5]

1 hour ago, kfsone said:

 

<< This was supposed to be an edit, not a quote

Edited May 9, 2019 by kfsone