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!)

What are the implications of storing off the results of the mesh bed leveling used when calibrating z height, then not doing it again before prints? It would be easy enough to disable in the start g-code, just not sure if there are reasons why it needs to be done before each print. What are the things that could cause the leveling data to change (moving the printer, etc)?

I'm guessing there are good reasons, but it would be more convenient than pre-heating before every print.

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

As far as I understand you need to do it before the print - otherwise there is no mesh bed leveling data active - the bed level would not be adjusted for.

Alternatively one could patch out the temperature compensation to "downgrade" the PINDA of the MK3 to the abilities of the MK2.

But what really helps is getting the right compensation values by a good calibration and then - depending on the results - choose the sign of the operation (as explained earlier).

to conclude: if done right, the MK3 PINDA works GREAT - it just sucks that the firmware still has to be manually modified to achieve satisfaction.:-)

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

Looking to GitHub with a big smile on my face:-)

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

Looking to GitHub with a big smile on my face:-)
stahlfabrik, sorry -but for a newbie- where on GitHub?

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

Looking to GitHub with a big smile on my face:-)
stahlfabrik, sorry -but for a newbie- where on GitHub?

Don’t be sorry:

https://github.com/prusa3d/Prusa-Firmware/commits/MK3

Two of my three pull requests have been incorporated.

So now I am curious how they decide on the third one.

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

Looking to GitHub with a big smile on my face:-)

If I knew what "mad props" were, I'd give them to you:

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

😆

So great!

Looking to GitHub with a big smile on my face:-)

If I knew what "mad props" were, I'd give them to you:

Screen Shot 2018-04-11 at 10.37.59 AM.png

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

😆

So great!

Crazy detail compiling instructions on the Firmware landing page too, that's new. Feels like they're both pre-emptively answering support questions and enabling people without much experience to screw up their printer...

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

Good work Stahlfabrik!!
Makes me wonder if its time for a change of the guard at Prusa firmware team....
Cheers,
Jon

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

Looks like they are turning PINDA temp compensation off by default, setting all the default offsets in EEPROM to 0, and only enabling compensation after the user has run the calibration. This will help with the default offsets being wildly inaccurate for many users. They still don't allow negative offsets or offsets for temperatures under 40C yet. Maybe that will come later.

Although preheating the PINDA to 35C helps with repeatability, it adds a lot of time to the start of a print, so I hope that isn't the final answer.

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

Looks like they are turning PINDA temp compensation off by default, setting all the default offsets in EEPROM to 0, and only enabling compensation after the user has run the calibration. This will help with the default offsets being wildly inaccurate for many users. They still don't allow negative offsets or offsets for temperatures under 40C yet. Maybe that will come later.

Although preheating the PINDA to 35C helps with repeatability, it adds a lot of time to the start of a print, so I hope that isn't the final answer.

Yes for my printer ALL offsets must be negative - that is why I proposed and need to switch the sign around.

I think it is a good idea to set all zero right out of the box. The behavior is quite good then just as a MK2S.

So let’s Hope for negative offsets or switch in sign whatever meets the real demands.

I still think it should be possible to also add lower temp steps to the whole compensating game.

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

Although preheating the PINDA to 35C helps with repeatability, it adds a lot of time to the start of a print, so I hope that isn't the final answer.

So much this!

I'm really not a fan of band-aid solutions. If worse came to worse, I would rather have an option to just turn off temperature compensation altogether. My MK2S works fine without it and I have not run into any situation yet where temperature drift has affected my print on it... or at least that I can see.

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

Good work Stahlfabrik!!
Makes me wonder if its time for a change of the guard at Prusa firmware team....
Cheers,
Jon

based on commits, it's like there is just one dude doing 90% of the work.... i think team is a bit of a stretch. i don't think there is one.

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

Agreed...
Jon

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

Compiled the latest firmware, this is my gcode. The printer is not waiting for the heatup of the PIDNA, any idea why? 😥

G28 W ; home all without mesh bed level
G0 X50 Y50 Z0.15 ; this is a good PINDA heating position
M660 S40 ;wait until PINDA is >= 40C
G80 ; mesh bed leveling
G1 Y-3.0 F1000.0 ; go outside print area
G92 E0.0
G1 X60.0 E9.0 F1000.0 ; intro line
G1 X100.0 E12.5 F1000.0 ; intro line
G92 E0.0
M900 K30

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

Wow, just burned something like 3 hours reading through this whole thread and figuring out the basics of github.

The following is mostly on topic:

Seems the M666 and M667 have been replaced with M860 and M861, respectively.

Marlin_main.cpp shows:
// M860 - Wait for PINDA thermistor to reach target temperature.
// M861 - Set / Read PINDA temperature compensation offsets

stahlfabrik ,
Before, it was:
M666 Sx
M667 z ? !

Right?

lukasmatena , does that all carry over to the M860 and M861?
--> Sorry, I know enough code to be dangerous, but not enough to be confident, haha.

I'm also having terrible adhesion type issues since I updated my FW to 3.1.3 (might have been before, but I had only printed small stuff prior)

Now I can't get anything medium or large to print well. I've run the calibration (I was actually meaning to do a PID tune, but did this calibration accidentally. It could definitely be named better). The bottom right corner of my print bed is always too low compared to the rest after mesh bed leveling, so this is where prints peel up. (I'm basically printing in the air in this one corner when the rest of the print is perfectly laying down. I've even gone through the mesh leveling, and then shimmed this corner just prior to the print starting, but haven't had huge success.)

As CynicalOwl pointed out:
"Crazy detail compiling instructions on the Firmware landing page too, that's new. Feels like they're both pre-emptively answering support questions and enabling people without much experience to screw up their printer..."

My inclination is to download and compile the most updated FW, as I have done in the past with my other printer (monoprice), but one thing has stopped me today: The folder ArduinoAddons, do I need to do anything with this after installing A-IDE 1.6.8, Rambo board and setting the proper configuration_prusa.h file?

JW

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

Wow, just burned something like 3 hours reading through this whole thread and figuring out the basics of github.

The following is mostly on topic:

Seems the M666 and M667 have been replaced with M860 and M861, respectively.

Marlin_main.cpp shows:
// M860 - Wait for PINDA thermistor to reach target temperature.
// M861 - Set / Read PINDA temperature compensation offsets

stahlfabrik ,
Before, it was:
M666 Sx
M667 z ? !

Right?

lukasmatena , does that all carry over to the M860 and M861?
--> Sorry, I know enough code to be dangerous, but not enough to be confident, haha.

I'm also having terrible adhesion type issues since I updated my FW to 3.1.3 (might have been before, but I had only printed small stuff prior)

Now I can't get anything medium or large to print well. I've run the calibration (I was actually meaning to do a PID tune, but did this calibration accidentally. It could definitely be named better). The bottom right corner of my print bed is always too low compared to the rest after mesh bed leveling, so this is where prints peel up. (I'm basically printing in the air in this one corner when the rest of the print is perfectly laying down. I've even gone through the mesh leveling, and then shimmed this corner just prior to the print starting, but haven't had huge success.)

As CynicalOwl pointed out:
"Crazy detail compiling instructions on the Firmware landing page too, that's new. Feels like they're both pre-emptively answering support questions and enabling people without much experience to screw up their printer..."

My inclination is to download and compile the most updated FW, as I have done in the past with my other printer (monoprice), but one thing has stopped me today: The folder ArduinoAddons, do I need to do anything with this after installing A-IDE 1.6.8, Rambo board and setting the proper configuration_prusa.h file?

JW

I think Lukas is not the right person to address, as he works on Slic3r and his attention is focused on Slic3r IMHO:-) His proposed new data model and calibration has not (yet) been adopted in the firmware. I have no insights if it ever will be. I personally think he had a good idea, which might not necessarily be the optimal solution. But as he is working at Prusa he has more data points and insight as I have with my single MK3:-)

Right, my proposed GCODE Numbers were change as you have noticed - to prevent overlap with some other machines out in the wild.

For me personally, I still do run the latest stable release - of course with my custom modification. Because my manual temperature compensation calibration has shown that I NEED to
a) change the sign of the mathematical operation as I propose here in the thread and my Pull Request - OR -
b) it must be possible to store NEGATIVE ustep values in the EEPROM.

Neither a) or b) have been implemented in the current Alpha version on GitHub yet - so I stay with my trusty version that SOLVES my life Z repeatability 100%.

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

Understood.

I have to say, your comment highlighting this thread:
https://shop.prusa3d.com/forum/hardware-firmware-and-software-help-f64/pinda-v2-temp-compensation-graph-t15492.html#p76343

Is really indicative that you're on the right path about the symbol swap, as it directly contradicts a statement earlier:

By:
Lukas Matena
Prusa Research (Slic3r)
"...I'm used to work with "our" offsets, meaning that higher values mean higher PINDA triggers..."

Also, the chart really shows that his other comment is spot on:
"Your values would indeed indicate your PINDA triggers lower at higher temperature. That's opposite to the behaviour of the ones I tested my fw on (another reason why I did not trust you). If what you are saying is true (and is now seems to add up quite well), your PINDA has opposite response to temperature changes than I have seen on "my" printers, which I can't quite comprehend..."

There's more there in his comment "Wed Mar 14, 2018 8:28 am" worth reading again.

OFF TOPIC, but timely:
One concern I have reading the new firmware notes that lead me to the marlinfw.org page on Linear advance is the comment: http://marlinfw.org/docs/features/lin_advance.html
"
New K value required
As the unit of K has changed, you have to redo the K calibration procedure. See next chapter for details. While old v1 K values for PLA might be between 30-130, you can now expect K to be around 0.1-2.0.
"

Has this been taken into account with the new firmware?

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

That is if LA v1.5 has been incorporated. Prusa firmware is still on LA v1.0

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

is there a way to monitor the pinda temp in real time in Prontoface?