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

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

Permissions for saving a copy seem to be restricted.

Bring up the Share dialog under the file menu and check the advanced options.
Make sure "Disable options to download, print, and copy for commenters and viewers." isn't selected.

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

Ok, try again.

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

Here's a thought (from a lazy guy):

If we can see (via some MCODE or on the LCD) the current PINDA distance from build plate, then we can simply do one z calibration at a known temperature, then change the PINDA temperature and read the level again. That way we will have an initial value to tweak, and its offsets by changing the PINDA temperatures. Then we can add it to the Gcode.

I tried to find such a command with no luck... would appreciate it if someone can assist here...
What do you think about this suggestion?

Cheers

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

I am sorry but I don’t get it:-)

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

If we can see (via some MCODE or on the LCD) the current PINDA distance from build plate,

I have a hard time getting how the software should know the distance when trigging, it just knows it triggs.
If this was possible live-z should always be correct, i think anyway ??

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

Note to self: drink 2 cups of coffee minimum before posting something 🙂

Thanks for your replies! I totally missed the fact that its a digital signal. When I messed around with the probe I saw that the led light has a range and not on/off when I put it close to metal.

I'll try again with the required changes since the probe simply detects a known gap value:

The gap between the bed and nozzle should be fairly constant (I think :))
Pinda is on when triggered.

Gap between nozzle and bed = PINDA trigger height + Live Z + temp compensation

Now assume we have on the same screen the PINDA status and live Z (and this is what I need...)

Perform auto home and go to z=0.
If we have an initial value of live Z that works well, we can heat up the PINDA to a known temperature (by raising the bed temperature), and now we can see (by adjusting live Z) when the PINDA is triggered.

Once PINDA is triggered:
Temp compensation = Live Z (the one we obtained with increasing bed temperature) - Live Z found on an actual printing calibration

Does this make more sense?

Thanks again for your patience 😎

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

Hey folks,

first off: cudos to you Stahlfabrik, you've done a lot of people a great service with your efforts. Thank you very much for that 🙂

I - of course - also have reoccuring shifted first layers on different temperature settings and tried to follow your instructions and those on the github page. Btw I'm using the MK2.5

As my bed appears to be a little skewed (left side seems lower than the right side) I tried using this to my advantage for the perfect replication of results tor the "gaps between lines just disappearing"-factor. Meaning as the print would start from the right hand side and move over to the left side I could easily tweak the live-z in such a way to get gaps only in a confined area of about a square centimeter of my ellipsis (roughly 80mm x 50mm total size) every time.

Everything looked peachy until I tried to double check my newly determined offsets by simply printing previous temperature tests again. What I found was that after doing the 55°C and 60°C gcodes I get a reference layer shift, i.e. my initial live-z height for the 35°C test is offset to a higher value (e.g. if it was -0.975 in the beginning I end up around -0.940 afterwards).

At first I thought maybe the system had to cool down more between two tests, but letting the printer rest until extruder, bed and Pinda temps are below 30°C still showed this effect. Luckily most of the determined offsets stayed in a similar ballpark relative to the new reference height, but this effect kinda worries me... the way it looks it seems that even with the manual calibration I still would have to readjust live-z every time I switch from high temp to low temp materials... I thought the point was to mitigate this...

To me this suggests that either I am doing something wrong still or that these variations are within a tolerable margin or there is a technical issue that hinders the precision of my values.

Does anyone have any ideas what my problem exactly is or might be? 😀 Is it man or machine?

Regards
-DerBierBaron

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

Hallo der Bier Baron;-)

Have you disabled temperature Calibration in the menu and by M861 Z when you did the temperature levels a second time? Because then with the same gcode, the same live adjust z Value SHOULD be right.

If you have already programmed your eeprom and enable temp calibration in the menu then you set live adjust z to the value that is optimal at 35C.

The idea is that if your pinda is hotter then when you do a print the offsets will compensate for the higher temperature.

And do not start a print with pinda colder as 35C

Hilft dir diese Information?;-)

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

Hello again,

leider nicht ganz 🙂

Yes, I actually reset the EEPROM values with Pronterface and M861 Z and disabled temp calibration in the settings (actually tried everything the first time around and forgot to turn off temp calibration in the settings befor I redid everything twice 🙂 )

I understand how it is supposed to work, nontheless I had issues following your instructions. But I have an idea what it may be:
The new firmware 3.2.1 is out already and has a bugfix for resetting live z adjust in it. In this bug after setting the live z adjust directly after initial height calibration changing live z would reset the original value.
For some users this meant that the nozzle was moving way past expected values and even crashing into the heatbed. I wonder if that is the problem I am seeing as deviations I see are more pronounced after the higher calibration temps 55°C and 60°C which in turn both have a larger offset from the 35°C value.

So what I did was upgrade to 3.2.1 and due to issues with my XYZ calibration - xD fixed by now xD - I couldn't test the Pinda calibration again. I'll try again soon and report my findings 🙂

Regards
-DerBierBaron

P.S.: Dein Thread ist wirklich super Stahlfabrik 🙂 genau wegen solcher Community-Arbeit mag ich Open Source so sehr 🙂

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

A little update on my issue:

I still have the live-z fluctuations with the 3.2.1 firmware. So to maybe get another view of the problem I tried printing the various temp-gcodes after redoing the 35°C-reference each and every time beforehand. As my previous values suggested that the offset for the 50°C calibration was close to 0mm I started with that one. Here I'll show you what live-z values I got for each gcode:

So it seems except for the step from the 3rd to the 4th round my live-z from the higher temps is kept as the new live-z for the next 35°C even though I initially changed the live-z back to its starting value and adjusted back until the first layer looked good.

The offset distances now line up as follows:

35°C -> n/a
40°C -> +40 microns
45°C -> +37 microns
50°C -> -17 microns
55°C -> -15 microns
60°C -> -100 microns

To me these values make little sense as they stray far from any 1st or 2nd degree function, even further from linearity... or am I wrong?

Lastly I thought about this finding a bit and maybe it is traceable to me resetting the printer after each round... but not doing that would mean that 1 out of 3 prints will fail for me, because my machine appears to be quite glitchy... e.g. ignored gcode or unpreditcable movements happen more often if I don't reset more often. Unfortunately my code-fu is not good enough to figure out what's causing such problems.

Regards
-DerBierBaron

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

Sooo.... just a short update -

I was able to calibrate temperature compensation without printing (validated it by printing 🙂 )

What I did was trying to implement what I had in mind a couple of posts ago - calibrating first layer at 35degC, and then finding the correlating point where the PINDA is triggered when temperature changes. I then used M861 to store my values.

I used pronterface to see when the Z axis is triggered, and used live Z to change z axis position. Temperature increased via bed and nozzle heating. I assume this can be turned into an automated tool sequence, I will try to think about it some more, but not sure if I can do it with my limited knowledge with the gcode...

DerBierBaron - out of curiosity (and I apologize if I missed it) - do you have a grey or black PINDA?

Cheers

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

Grey or black as in color of the head of the PINDA?

The head on mine is black. Are there functional differences between delivered PINDAs?

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

Grey or black is the cable, not sure about the head. Its suppose to be a different vendor.

I saw in this thread (I think in page 7) the two graphs for these PINDA's one looks linear and one is not.

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

Cool info thanks!

Yeah black cap and black cable here... looked up the graph and the black PINDA is the one with the local maximum.

Might be worth calculating the usteps for these values after all.

I guess I'll sleep better trying to get the values without resetting the printer in between steps though 🙂

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

From the manufacturer I have learned that the cable color can change based on what they have in stock, so the cable color is definitely not the way to tell them apart…

The tip seems like a better way. Black is the one that came with the first few weeks of MK3 deliveries, and gray since then. Gray is more linear in response.

Btw: the manufacturer is now shipping pindas with a gray tip and black cord.. but they are working the same as the all gray ones.

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

Der Bier Baron!

Danke für die netten Worte. Ohne Open Source wäre ich nicht in der Lage zur Selbsthilfe gewesen und hätte das Teil irgendwann aus dem Fenster geschmissen:-)

I think maybe you have a bad pinda. I have the newer grey one. The changed from black to grey because the grey one is more linear and I think the quality and consistency might be better on average.

So I would propose to contact chat and tell ask them if they can help with your problem.

To narrow it down: when you do at stable ambient temperature a mesh bed leveling and then print out the values to serial console those should be quite stable. If the jump like 0.1 or 0.2 you would have easy proof for a bad pinda. Was it G80, G81? Cannot Look Right now.

I never did more than a test print for e.g. 40C and 60C or so and they came out perfect without touching live Z. So I am baffled what is Happening at yours.

Chances are good support will swap your pinda I would guess. When this all started first the changed my pinda from black to grey. Then my whole MK3. Then I started to find a fix:-)

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

Sooo.... just a short update -

I was able to calibrate temperature compensation without printing (validated it by printing 🙂 )

What I did was trying to implement what I had in mind a couple of posts ago - calibrating first layer at 35degC, and then finding the correlating point where the PINDA is triggered when temperature changes. I then used M861 to store my values.

I used pronterface to see when the Z axis is triggered, and used live Z to change z axis position. Temperature increased via bed and nozzle heating. I assume this can be turned into an automated tool sequence, I will try to think about it some more, but not sure if I can do it with my limited knowledge with the

Cheers

Newguy, that Sounds also very promising. Will you share more details how your process works? I have an idea just reading your lines but please elaborate on your method!

I wonder about the automatic calibration ... and how it contrasts to your idea!

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

G80 is mesh bed levelling and G81 is the readout via pronterface or Octoprint 🙂

I just contacted the Prusa tech support and they were so kind to send a new PINDA to try it out 🙂 very helpful as always

They also told me that they get their PINDAs all from one manufacturer, i.e. I suppose the newer grey one is just a new/different model then. I'll see for myself which one I'll receive 😉

Besides your good idea with the G80 - G81 approach (was looking into that for manually shimming my bed even with a mesh bed level heat map 🙂 ) I am now testing my offsets with initial z-calibration, mesh bed levelling, first-layer calibration and then running all PINDA calibrations one after the other with my determined live-z offsets. This will also give me an insight on the validity of my last test.

I presume that everything MIGHT be ok when these turn out repeatable, as the temperature calibration function might not be the culprit in my case, but a wonky live-z save to EEPROM. What I mean by that is that I aslo would only need to set live-z once with the right ustep values and temperature calibration on later, because the temperature calibration algorithm would take over the adjustments ad hoc and maybe that would not result in the deviations for me then.

I'll post my findings when I'm done 🙂

Regards
-DerBierBaron

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

So here's another update:

I've managed to go through 1.5 full calibrations (one being all calibrations from 35°C to 60°C) and found that my issue still occurs and again most predominantly after the 55°C and 60°C calibration gcodes.

Now I'll wait for the new PINDA to arrive, we'll see I guess 🙂

Regards,
-DerBierBaron

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

Hi again,

Long day, I hope I capture everything right...

Basically, I try to find the actual live Z fro 35degC and calculate the offsets caused by PINDA temperatures.

1. Do a "printed" live z calibration at 35degC. Keep the result for later on.
2. Do bed mesh leveling. Your Z axis is 0.1mm high.
3. Move the extruder roughly to the center of the build plate
4. Raise your Z axis to 1mm height. This is important since if you PINDA is a bit low your live Z calibration my be above Z and its currently disabled.
5. Preheat the Pinda to 35degC. Go to pronterface, M119 command should show you if the z axis end stop is triggered. Find the correct live z value that trigger the Z axis end stop and note the value. This is not a real value, but we will use that later to calculating the offsets.
6. Preheat PINDA to 40degC and repeat M119 and raising live Z until the end stop is triggered. Note down the value.
7. Repeat item 6 to all calibration points.

Now you have:
1. Actual live Z value at 35degC.
2. The value obtained in step #5 is your 0 point for PINDA calibration.
3. All other values are the offsets caused by temperature change.

Example:
Actual live Z calibration = 0.500
The value obtained in step #5 (35degC) is -1.000
The value obtained in step #6 (40degC) is -0.9

This means that live Z at 40degC should be 0.400

I hope it is more clear now.

BTW - since I mostly print ABS, my PINDA gets as hot as 75degC where the temperature compensation is huge. Is there any way to put values higher then 60degC to the compensation table in the EEPROM?

BTW #2, my prints are so much easier now with the manual calibration. Once again, great work!