1st layer problems - in depth look at software PINDA problems (and solutions!)  

1st layer problems - in depth look at software PINDA problems (and solutions!)

Hello my name is stahlfabrik, and I have problems. With my PINDA.

TLDR:
1. There is IMHO a nice bug in the MK3's firmware that combats the possibility to achieve repeatable first layers.
2. You need good temperature calibration. There is no way, that the MK3's firmware currently provides, to achieve good temperature calibration. The stock temperature calibration values are way to high.

This gets technical:-)

So what does this all mean?

Let me introduce you to the technical background. The PINDA probe is an inductive sensor which triggers when a certain distance threshold to the heatbed has been reached. The MK3 uses that information to home it's Z axis and to perform mesh bed leveling. These type of sensors react to heat: when they get warmer, they trigger later/lower. The MK3's pinda has therefor a thermistor inside, so the software can read the temperature and account for the effect the temperature has on the triggering distance. The idea is that you calibrate Z once and then: "Happy printing."

So how does (should!) it work? There is a small table in the EEPROM of the printer where for certain temperatures the offset is stored, that the software needs to add to nozzle height (or the measured mesh bed level compensation values) to achieve the same "Live Z value" no matter what the temperature of the PINDA is.

So the bug that I found, as described in my pull request is easily explained: instead of using the compensation table that is stored in the firmware to counteract the physical effect that the temperature is having on the PINDA's triggering height, the opposite happens: it adds the calculated offset in the opposite direction making the MK3 super temperature sensitive. So when your printer is nice and warm and ( - under pain and struggle - ) you managed to get a decent first layer, let the machine cool down completely. Start a new print and because the PINDA had no chance to reach the old warm temperature, the Live Z value is way off (the first layer hardly sticks to the bed because it is too high).

Here is a link to my pull request for this issue: https://github.com/prusa3d/Prusa-Firmware/pull/514

So that is one big part of problem. Let's all hope that Prusa Research will acknowledge and fix that bug soon.

The second part of the problem is the temperature compensation table. It's values are of course defined in the firmware and are the same for all MK3s. I have got the grey PINDA (I hope Prusa did not switch from black to grey PINDA because of that bug...) and the temperature calibration which are optimal for me (see below) are WAY different then the stock values.

So let's talk about the temperature compensation table.

In the EEPROM there are for certain temperatures (35, 40, 45, 50, 55, 60C) stored the offset the printer has to take into account for doing the compensation of the effect the temperature has on the PINDA's triggering height. The unit of the offset is "usteps". The temperature intervals are "hard coded" and cannot be changed in one place. (Spoiler alert: I absolutely think that my PINDA might be colder than 35C when I start a print so Prusa should possibly grow the temperature range to 30-60 or even 25-60C! More about that below)

So lets see the stock values. These are:
35C - 0um - 0usteps (the lowest temperature offset always must be 0, so it is not saved in EEPROM)
40C - 20um - 8usteps
45C - 60um - 24usteps
50C - 120um - 48usteps
55C - 200um - 80usteps
60C - 300um - 120usteps

So far so good. The basic idea is: adjust live Z at 35C degree PINDA temperature and when you later start a print with 50C PINDA temperature just add 120um to the live Z value internally, so the user does not have to dial up live Z, to avoid the layer to be to squished. Of course - mind the bug which internally subtracts 120um which leads to a very squished first layer. That is the basic idea of how it works. Between the temperature steps the offsets are interpolated.

I hope you see the importance of correct temperature compensation offset values in the EEPROM table.

With my bugfix, printing PLA was quite OK, but when I did ABS (bed at 100C) the PINDA was warmer than while printing PLA (the PINDA cannot get warmer than 45C when printing PLA I would say from the tests). In fact the PINDA indeed reaches 60C when staying over the 100C bed. So the high PINDA temperature now lead to a too strong compensation - so the 1st layers became higher and higher the more the temperature of the probe rose.

So I knew: My bugfix seems to work, but the calibration values are bad. So I looked into the "experimental and optional" temperature calibration routine. Yes, it is experimental. But it is absolutely not optional. The problem is the results suck for me quite a bit! After it was done, ABS was still printing bad and now PLA was bad, too.

I did it 5 times to get mean values for each temperature level, and the results were surprisingly different than the stock values - but as mentioned far from optimal:
35C - 0usteps
40C - -2usteps !
45C - 5usteps
50C - 11usteps
55C - 22usteps
60C - 37usteps

So I needed to come up with my own temperature calibration methodology. So where do you start? The stock software is absolutely lacking everything you need to accomplish this goal: You CANNOT read nor set the temperature calibration offset values in the EEPROM manually.

So I came up with the idea that I need two things:
- a new GCODE that waits until the PINDA has reached a certain temperature (Pull request: https://github.com/prusa3d/Prusa-Firmware/pull/542 )
- a new GCODE that lets me read, reset and set and also zero out the temperature calibration offset values in EEPROM. (Pull request: https://github.com/prusa3d/Prusa-Firmware/pull/543 )

I must confess the code quality of these GCODEs could be enhanced for sure. I have not programmed GCODEs before. But they work fine for me! Everybody is welcome to contribute and the devs at Prusa research should have an easy time to incorporate those. Again, lets hope Prusa Research will look into these tools and provide this or equal functionality into the official firmware soon.

So the test took a few hours but was very straight forward but cannot be done without the custom software:

The first step is to deactivate the temperature compensation completely. For that I commented out the buggy line of code. But zeroing out the temperature compensation table in the EEPROM should have the same effect. As a second step I took a .gcode file with a nice big first layer where the print head moves from left to right (so I could see the first layer quickly sitting on the left side of the printer). I pimped the startup code so that the printer homes its axis TWICE: One time at the beginning, the second time when the PINDA has reached a certain temperature. After the second homing the mesh bed leveling is done and the print starts. I added a few movements between the homing actions: First I raise Z 5cm so the PINDA does not heat before the bed has not finished heating. The second movement happens when the bed has heated up. I then move the nozzle to X5cm Y5cm Z0.15mm so that the PINDA gets warm effectively while waiting.
You start a print with using the custom waiting GCODE and dial in Live adjust Z to the optimum value and note the live z value down. You do that with the material of choice. I used Prusa grey PLA because it is easy to dial in live Z - I dialed it in so that the splits between the lines JUST vanish - you need to repeat and achieve that level now a few more times. You repeat that live z tuning now for PINDA starting temperatures of 35C, 40C, 45C, 50C, 55C and 60C (after 45C you need to turn bed heat up to be able to warm the PINDA enough). Note the live Z values down for each temperature. Just for the fun: repeat a measurement and be ASTONISHED that you can directly dial in the noted value it will be perfectly OK (the PINDA is able to deliver repeatability!). I got these values for MY pinda (yours should be maybe different - let's share our values to determine better stock values!!):

35C - -0,822
40C - -0,810
45C - -0,795
50C - -0,795
55C - -0,787
60C - -0,790

So get out your calculators out as you need to compute the ustep values now:
Example:
35C is the reference, easy: ustep is 0
40C the difference to 35C is 0.012mm. Multiply that by 400 (steps per millimeter the MK3 uses) and you will get 4.8 which rounds up to 5 usteps.
And so on.
So I got these ustep values that I stored to EEPROM using my custom gcode.

These are the ustep values I found that work for ME:
35C - 0
40C - 5
45C - 11
50C - 11
55C - 14
60C - 13

Compare these to the stock values - isn't that crazy? It is not even increasing steadily and for 60C the stock values compensate 9-times more than necessary - that is why I still failed to print in ABS! The build in temperature calibration function delivers values that still are 3 times more overcompensating...

So I set the EEPROM values to the manually crafted values and LOOK at my two PLA prints: I did NOT touch live Z - I set it to -0,822 in the settings before I started the first print. I started a print with 35C pinda temperature, came out perfect as expected. So now the GREAT question: does my bugfix even work (I am still waiting for official feedback if I am heading in the right direction!). So I started a print with PINDA temperature of 55C - AND IT CAME OUT PERFECT! So yeah - I prooved myself that the bugfix fixes the bug.

See an example GCODE snippet in my pull request.

What I would hope Prusa Research do now quickly:
- Fix the bug in the offical software
- Incorporate the GCODE to wait for a certain PINDA temperature ASAP in the official firmware as well. Because we need the PINDA to be at least 35C warm at the beginning of each print! The temperature range below is not defined! Also, of course, for manual temperature calibration it is needed very, very, much.
- Incorporate GCODE - and later - EVEN BETTER: A menu - to let the user read and set the temperature calibration offsets in the EEPROM.
- Increase the PINDA temperature calibration range to temperatures below 35 C. My room often is 16C, when the print starts, the PINDA is not much warmer than 20-25 degrees - so the offset is not defined!
- Show pinda temperature on main screen on LCD
- Maybe come up with a better way to do the temperature calibration automatically.

What have we learned:
1. Use a firmware that combines the bug fix as well as incorporates the tool you need to do a manual temperature calibration. Otherwise you will not improve stuff completely.
2. Never start prints with a PINDA cooler than 35C - the provided gcode makes that easy
3. Open source for the win. I would be soooo mad with the machine if I would not have been able to fix this. Finally it works as advertised.

Cheers! And happy printing for real this time.

(I added my last firmware build which contains all three pull requests. Use at your own risk and do not blame me!)