Z axis homing inconsistent on UM2: workaround and patch

[illuminarti 18]

Steve - I know my way around the Marlin Source pretty well; I'll take a look at it this evening and see if I can figure out what it's doing/not doing.

[stevegt 1]

Okay, I got some measurements. Not going to analyze them right now, because I should be asleep. I'll just paste them here and we can all look at them tomorrow in the cold light of day. George, I wasn't able to cleanly count steps, because the weight of the bed makes it tricky to feel them while rotating -- and if my finger slips, the bed falls back down. That should give you an idea of how different our leadscrews are. What I was able to do is move .1 mm at a time in pronterface, and listen for the click. I was measuring this at the front left corner, so the springiness of the buildplate and stickiness of my caliper's slide made it tricky. Next time I'll either measure at the back or rig up a dial indicator instead.

Simon, that limit switch trigger screw looks hard to get to -- have you ever tried adjusting it without removing the white cover plate? Is it even adjustable? Looking at its reflection in the back wall, I don't see any jam nuts or anything else in there that would cause it to hold if it were loosened -- it looks like it's just screwed through the bed plate until the screw head is firmly seated. I think I'm starting to see why George is suggesting that people bend the switch tab, even though the very idea makes me cringe. :wink:

All measurements are in mm, as measured from the floor to the top of the glass:

 

firmware 14.03:
===============
bed height grounded: 27.4
bed height after first G28:  30.1
bed height after second (and later) G28: 29.4
firmware 14.04.1-stevegt1:
==========================
bed height grounded: 27.4
bed height after first (and later) G28:  29.4
bed height when switch opens (moving upward):  30.1
bed height when switch closes (moving downward):  29.4
Am able to G28, then M18, push bed down, M17, then G1 F10 Z205; e.g.
limit switch closed doesn't prevent Z move.

 

[stevegt 1]

Okay, right after I posted those numbers, I started staring at them. I'm not even going to say what I'm thinking right now -- I'll leave that as an exercise for tomorrow. There's one piece of information I'll add to this, and that is a reminder that I was measuring at the front edge, and that the front of the bed droops once it's off the floor. So, in this universe, 30.1 - 27.4 is probably going to turn out to be exactly equal to 3 mm. :-P

G'night,

Steve

 

[Daid 306]

(Just got back from vacation in NYC)

Ok. First of, this is great. It's great that we've found a cause of something that is really plaguing users. It's also easy to fix. So that's perfect.

I have a few other minor firmware changes lined up. So this fits in there perfectly, and was planning to do a maintenance release this week. So that all fits fine in the release schedule.

It's also a safe patch, it won't break anything. The only thing I will do extra is measure the actual maximum travel distance of the switch (in CAD and real life). Just to check if 5mm is enough now (Would kinda suck if 5mm would be enough for 95% of the printers) and make sure there is a nice safety margin on it. Getting on that right now.

(Moving up till the switch is unpressed is a bit of a difficult thing to do in the code right now)

 

[Daid 306]

Just measured. In the CAD model it's 4.9mm of maximum travel. And I'm measuring about the same on a real limit switch. So I rather put this move-back value at 7mm to be on the safe side.

 

[Anders Olsson 136]

I have noticed a few other bugs in the firmware lately, which are not related to this topic. What is the preferred way of reporting these?

Should we have an official bug report thread for each upcoming release of the firmware?

 

[Daid 306]

Best place to report them in a way that garantees that I see them is:

https://github.com/Ultimaker/Ultimaker2Marlin/issues

 

[stevegt 1]

Just measured. In the CAD model it's 4.9mm of maximum travel. And I'm measuring about the same on a real limit switch. So I rather put this move-back value at 7mm to be on the safe side.

 

Hi Daid!

If the model shows 4.9, then yes, 7 makes more sense. I also saw you changed the other switches as well. I've just tested that, looks good as far as I can tell right now without doing any real-world printing.

Steve

 

[stevegt 1]

Just a followup from those measurements I posted last night, and what I was saving to mention until I had time today... What it appears is happening on my particular printer is that the 3 mm retract distance in 14.03 almost exactly coincides with the point where the switch opens when the bed is moving in a upward direction. If my switch were opening a fraction of a millimeter earlier, I may never have seen this bug myself. That helps explain why the reports of this bug have been so cryptic -- even some people with falling beds may not see it, or may only see it intermittently.

Simon, without looking at the code again myself, based on those measurements it looks to me like the homing algorithm as written is not the one you and I would expect, but is instead The Simplest Thing That Could Possibly Work:

 

1. move in a direction that would take us away from the switch
   
2. stop after traveling Z_HOME_RETRACT_MM
   
3. move toward the switch until it's closed
   
4. stop, consider homing complete
   

I haven't yet tried to check it electrically, but I think my limit switch really and truly might never be opening when homing from the full-down position. This is causing no movement in step 3 above -- it looks like we're skipping 3 and jumping right to step 4. That theory is consistent with what I'm seeing the printer do -- it just moves up from the floor and stops.

A good refactoring might, I think, replace all of the *_HOME_RETRACT_MM constants with a seeking algorithm similar to the one you described:

 

1. move away from the switch until it's open
   
2. move towards until it's closed
   
3. stop
   

That would keep the same build volume that we have now, and get rid of these magic numbers. If I understand Daid correctly, we may not be able to detect switch opening while moving, but maybe we can do that move iteratively.

Steve

 

[Daid 306]

Your new proposed algorithm doesn't change the build volume.

What normally should happen is that the bed is moved towards the endstop at high speed. Due to this high speed, it cannot stop fast enough when hitting the endstop and thus moves a bit passed it. This is why there is the HOME_RETRACT_MM. It moves back this distance, and then moves into the endstop again at lower speed. Getting the exact position where the endstop is triggered.

The problem that we are facing is that on some machines, the bed is so well assembled and calibrated, that it drops down beyond the end-switch point. And then it currently only travels up 3mm, which is not always enough. If it travels up 7mm (as I just configured for the new firmware) and then move slowly into the endstop, we'll find the proper switch point again, consistently.

No build volume is lost, as the build volume is measured from the switching point.

 

[Daid 306]

For those with this problem and not wanting to venture into firmware building themselves.

I've uploaded an RC5 with this firmware fix:

http://software.ultimaker.com/Cura_closed_beta/

If nothing is wrong I will make this an official release tomorrow (I really need to do this maintenance release, also to fix the quality bug)

 

[conz 0]

Thank you Daid (and stevegt),

I have installed cura RC5 on win7 and the new firmware on my UM2. Leveled the bed and the first print looks promising.

Will test some more prints later.

 

[conz 0]

Sorry for the doubble posting.

I started a 2nd print without releveling, and it is looking good so far.

I think that this patch has fixed my leveling problem. \o/

Thank you again, stevegt and Daid!

 

[DidierKlein 729]

Yes very happy to know that it's correct, i love this community and this is why. Thanks to Stevegt and to Daid for the patch great work guys :cool:

 

[stevegt 1]

For those with this problem and not wanting to venture into firmware building themselves.

I've uploaded an RC5 with this firmware fix:

http://software.ultimaker.com/Cura_closed_beta/

If nothing is wrong I will make this an official release tomorrow (I really need to do this maintenance release, also to fix the quality bug)

 

Daid, when I install http://software.ultimaker.com/Cura_closed_beta/cura_14.06-RC5-debian_i386.deb, I do get Cura 14.06-RC5, but when I run that and "Machine|Install default firmware" it installs Marlin 14.04 from April 24th, and I get the old behavior.

Conz, Didier, hang in there, we'll have you running in a bit. :wink: If there's any doubt (maybe it's only the .deb that's behind), just check "Advanced|Version" on your LCD. It should have a build date of June 4th or 5th, with a more recent version number (github shows 14.06.01 right now).

Steve

 

[gr5 2,177]

A good refactoring might, I think, replace all of the *_HOME_RETRACT_MM constants with a seeking algorithm similar to the one you described:

 

1. move away from the switch until it's open

2. move towards until it's closed

3. stop

 

I think this sounds great at first but sometimes other things need to be considered. If the switch is broken and shorted it will always report closed so step 1 may be an infinite loop plus you might break the glass. 7mm is a good compromise.

 

[conz 0]

Daid, when I install http://software.ultimaker.com/Cura_closed_beta/cura_14.06-RC5-debian_i386.deb, I do get Cura 14.06-RC5, but when I run that and "Machine|Install default firmware" it installs Marlin 14.04 from April 24th, and I get the old behavior.

Conz, Didier, hang in there, we'll have you running in a bit. :wink: If there's any doubt (maybe it's only the .deb that's behind), just check "Advanced|Version" on your LCD. It should have a build date of June 4th or 5th, with a more recent version number (github shows 14.06.01 right now).

 

Oh, that is strange. Hmmm...

My firmware is 14.04 from April 24th, too. (Installed with the RC5 WIn7 exe)

I have printed some parts of roberts feeder. No releveling was necessary. Before that update I have had a lot of leveling problems.

Maybe the version tag is wrong? Or there must be something different that has been fixed with this update.

I'm a little bit uncertain now.

 

[stevegt 1]

Oh, that is strange. Hmmm...

My firmware is 14.04 from April 24th, too. (Installed with the RC5 WIn7 exe)

I have printed some parts of roberts feeder. No releveling was necessary. Before that update I have had a lot of leveling problems.

Maybe the version tag is wrong? Or there must be something different that has been fixed with this update.

I'm a little bit uncertain now.

 

Maybe you're just lucky today. :wink: No worries, we'll figure it out.

Can you try something for me?

 

1. turn off your printer

2. press down on the back of the bed until it moves all the way down to the floor

3. turn the printer on

4. hit "Maintenance|Advanced|Lower buildplate", and watch how the bed moves

If the bed only moves up 3 mm and stops, then you still have the old code. If the bed moves up 7 mm, then down about 4 mm, then stops, you either have the new code, or your printer is one of those whose switch is opening right at 3 mm, which means sometimes it'll work with the old code and sometimes it won't.

Occam's Razor says you have the old code. I've been watching and working among Daid's recent github checkins, and I can't see any way the version string would still say 14.04 but be the new code. He incremented it to 14.04.1 later in the day on Apr 24th, and then 14.06.1 today, Jun 5th. The copy I downloaded has the 14.04 version number, and it behaves like 14.04. The difference between building either of the two is only one git command.

Just hang in there -- I'm pretty sure he'll wake up in the morning, read all this, whack his forehead and then sort it out. :wink:

Steve

 

[stevegt 1]

I think this sounds great at first but sometimes other things need to be considered. If the switch is broken and shorted it will always report closed so step 1 may be an infinite loop plus you might break the glass. 7mm is a good compromise.

 

Agreed. Simon, in his earlier algorithm description, added a 20 mm travel limit to handle the case of a stuck switch.

Assuming 7 mm works for the UM2 (and I think it will), refactoring the homing code falls into the category of "risks breakage, but will get rid of three of the many magic numbers that have to be tuned for new printer models". Magic numbers bad, autodiscovery good. Not urgent, but worth thinking about for the next time someone has to touch that section of code.

I'm still thinking about whether that 20 mm can be replaced with (Z_MAX_LENGTH / 10), for instance.

(BTW, I'm used to seeing CNC mill and other machine limit switches open on contact, not close, because that catches more failure modes. Are we backwards in our conversation here, or did someone back in the depths of reprap time decide to make them close on contact instead?)

Steve

 

[illuminarti 18]

I just double checked with a multimeter - all three endstop switches on a Ultimaker² close the circuit when the switch is triggered.

 

[conz 0]

Can you try something for me?

 

1. ...

If the bed only moves up 3 mm and stops, then you still have the old code.

 

Hmm... it moves only 3mm up.

So it seems that I'll still have the old firmware. :(

Maybe it was luck, that the calibration was always correct yesterday.

I have printed six parts of roberts feeder without releveling or finetunig with the bolts. That was not possible before for me. Maybe I have hit a sweet spot on calibration.

Sorry for the confusion with my test and for making hope with the leveling fix. :(

 

[Daid 306]

Ah, blarp, forgot to push the firmware. BRB

 

[Daid 306]

Updated the windows version:

http://software.ultimaker.com/Cura_closed_beta/

Will do the linux/mac version as soon as I get to the office.

 

[conz 0]

Thank you Daid.

I have installed the new version RC6 (win 7).

Version says now: 14.06.1 (June 5th) and the bed is moving up and down with the test mentioned by stevegt.

Will do some test prints ... but since the calibration was ok yesterday, my observations regarding the leveling won't tell that much now. :(

 

[stevegt 1]

Thank you Daid!

I quick touch test of the 14.06-RC6 .deb works for me. I'll print a minical or something and report back.

Conz, thank you. That sounds much better now. I think you'll find over the next few days that you're spending a lot less time adjusting the bed. :-) Don't worry about first observations -- it took me a while to figure out what the heck I was looking at too. And if you want to see me floundering around myself, just google for "umforum linux usb reset". Still working on that one.

Steve