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

Isn't the whole point of the Pinda to measure the bed at a given temperature to exactly take into account the shape of the bed at that given temperature at that particular time to give the mesh bed leveling the data it needs to compensate for the bed shape via adjusting the Z height to be a constant distance from the bed while laying down the first layers?

When actually performing bed leveling then this is true of course. However when calibrating the PINDA's temperature variation, you need the reference to be absolutely stable, otherwise there's no way to know how much variation was caused by PINDA thermal characteristics vs. how much was caused by the reference (heat bed) physically moving.

As Lukas said I think the only way to go is to pre-heat the bed to a single temperature while the PINDA is far away, letting the bed settle into a stable temperature and shape, then move the PINDA to the bed and take your calibration measurements as the PINDA warms up.

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

To calibrate the Pinda temp offsets, then yes, the bed needs to be at a constant and stable temperature. The Pinda would not have to do an entire array of measurements all over the bed, but just in one spot; say the center. Measure this one spot repeatedly and take the average. Repeat this measurement at the same spot when the Pinda has reached the next temp you need for creating the offset table.

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

So vincento says +1 that the sign error is real, right?

Who else compared the stock firmware to my „fixed“ firmware? What is your verdict?

I would like to get a better feel for that.

Edit: and what we all could do: compile a version of Lukas firmware and compile a second version of his firmware and the „potential sign error“ fix.

Edit2: I not fully understand the new method yet. There is the 50C reference. Does this mean the new function gives negative values for values lower than 50C? That is also something I need to find out.

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

(suggestions of constant temperature bed calibration)
The issue with bed expansion is addressed in my version of the fw and it is solved (hopefully) in exactly the same way you suggest. I have already written all that in my previous post.

As for stahlfabrik, I have many comments.

I am still not sure though, if you are aware of the severity the problem has (with stock firmware, with or without automatic temperature calibration performed) for me and other users.
Trust me we are aware of the severity of the issue. We too happen to have several printers over here:-)

The stock MK3 firmware is hyper temperature sensitive and ... it works "catastrophically"
Like I said, the default calibration table may not fit your probe and current automatic calibration has major flaws. It is not necessary to repeat it does not work correctly, that's not the point now. If it had, we would not have this discussion.

... my „fix“ really fixes that same issue for them ...
But that still does not prove your fix is completely correct. It comprises of several steps and has to be analyzed in detail. It's not a matter to vote about, we must fully understand it. It's not enough if it seems right (or it shouldn't be). It's not that I'm not open to discussion or unable to acknowledge a mistake. I just need to understand first, and I don't understand it just yet.

my 35C live adjust Z value is -0.822 and for 45C it is -0.795
I think I may start to understand. You made me reread your first post once again and I now fully realized that the reported values of offset are directly the values taken from live-z adjust. However, if you check the code of automatic calibration, the temperature offsets the fw works with are actually the heights at which the PINDA triggers! If you use the z-adjusted values in place of "our" offsets, you inverted the meaning of the offset variable. And in that case, you would indeed need the sign inverted to compensate. That's why I incorrectly accused you of contradicting yourself (sorry) - I'm used to work with "our" offsets, meaning that higher values mean higher PINDA triggers - and I saw rising values. I did not realize the values are not recalculated into fw language. So I'm afraid I have to insist - the sign in the fw is correct (as long as you don't change the meaning of the offset variable). Not only it makes sense, it is also verified by actual fw developers (and if you acknowledge what I'm saying, then that's the very sign that you want there).

What bothers me now is this. 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. Either it is another batch of PINDA probes that is somehow overcompensated internally, or there is something else on the PINDA attachment/printhead, that's subject to thermal expansion and contributes to the measured offset in the opposite way. I think the latter is more likely, but it needs more investigation. I however checked that thermal expansion of the PINDA housing itself should by far not have such great influence. It could as well be something inside the probe itself (if the decrease proves linear, it is a strong reason to suspect it's something close to the thermistor). I'll try to investigate. What do you think, john.n13 "the heat-transfer guy"? Any ideas about what may be going on here?

This would also explain the behaviour you observed when (un)commenting the line of code. The default values were not only off in magnitude, but also had opposite sign to what your PINDA would have needed. When you commented the line out, it got better (your PINDA is not that temp. dependent, so just disabling the calibration helps). When you uncomment AND change the sign, it gets worse again, but not as bad as the first time. The compensation is still too high, but at least it now compensates it the direction your PINDA needs. Would this make any sense to you? Is this theory consistent with what you were doing?

I would be very interested to hear what my version of fw would do on your setup. If you decide to experiment with it, run the automatic temp calibration (before printing, see below why) and tell me what happened. And if you managed to also capture serial line output during calibration and sent it to me (PM), I would appreciate that. But it case you have better things to do, I will obviously try to find a printer with similar behaviour somewhere around (actually, I'll do that anyway).

And one more thing. If I see it correctly, commenting the line out not only disables temp. calibration, it also prevents updates of mesh bed levelling data. You thus bring another variable into play. You also have not commented on the warping bed issue, which in my experience is the single most important problem the current automatic calibration has. I take it as an indication that you have not been playing with it either, so untangling your situation is quite difficult for me. I suspect there might be many contributing factors that are unaccounted for.

Are you testing with the PEI stickers sheet?
As mentioned, my calibration is done without any sheet on the bed, to reduce any error it might induce. I understand it is not possible to do your manual calibration that way, because it relies on watching the printer print, which you can't do without a sheet on.

I would so much like to invite you over to show you how my MK3 performs with the stock firmware and the slightest temperature changes.
I probably wouldn't be surprised. There are flaws in the current method of temp calibration, we know about it (as repeatedly mentioned). Finding them and fixing them for good is more complicated thing though.

There is the 50C reference. Does this mean the new function gives negative values for values lower than 50C?
It does, but I'm not saying it will not conflict with any other part of the code and won't have to be changed back - that has to be decided when it is being merged into the official branch (it seems to work, but like I said, it is not always enough). And again, the values saved in EEPROM are not the same as they were before, your manual implantation of custom values will not work with my fw (unless you modify it to supply coefficients of line/parabola, that my fw expects to find there).

Having said that, I better explicitely write this DISCLAIMER (though the issue is implied from my previous post):
In case anyone tries to use my firmware - it is preliminary with no guarantees, several things are unfinished, there are possible conflicts with the main branch. I should mention that the fact that only coefficients of the fit are saved into EEPROM has consequences. After you flash the firmware, you should do temp. calibration before attempting to print. Same after you reflash whatever you had installed before. If you attempt to print directly, the values stored in EEPROM will be misinterpreted with undefined results. In case you don't understand what's happenning here, I suggest you don't flash unofficial fw (and my fw IS unofficial as of now, you therefore use it at your own risk).

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

Hi Lukas,

thank you very much for your fast reply! And thank you for going into even more detail about the upcoming changes.

I really cannot imagine what my PINDA or setup makes so special. The quality of my build of the kit should be quite decent, so if temperature expansion comes into play at the extruder I really do not know why it should be so special here. I am sure my kit is well build and I hope that my components are quite average in their quality:-)

Thank you also for fighting against my repeated attempt to make you switch the sign:-) I do not want to have the "last word" or "be right" about it - I just can tell you what I found out and what seems to solve the problem for me and my machine. I also do not want to "vote" about it - yet I understand that impression might have developed. I just wanted to know how many people, who faced the problem, did not have the problem anymore with my firmware. Really, I am all for science process and not for "who screams the loudest"!

I am also really happy, that you are working full steam on this subject - not only on a better calibration but also with the observed problem in mind. So that is great!

I need to comment on a few things to make it right:

my 35C live adjust Z value is -0.822 and for 45C it is -0.795
I think I may start to understand. You made me reread your first post once again and I now fully realized that the reported values of offset are directly the values taken from live-z adjust. However, if you check the code of automatic calibration, the temperature offsets the fw works with are actually the heights at which the PINDA triggers! If you use the z-adjusted values in place of "our" offsets, you inverted the meaning of the offset variable. And in that case, you would indeed need the sign inverted to compensate. That's why I incorrectly accused you of contradicting yourself (sorry) - I'm used to work with "our" offsets, meaning that higher values mean higher PINDA triggers - and I saw rising values. I did not realize the values are not recalculated into fw language. So I'm afraid I have to insist - the sign in the fw is correct (as long as you don't change the meaning of the offset variable). Not only it makes sense, it is also verified by actual fw developers (and if you acknowledge what I'm saying, then that's the very sign that you want there).

Yes you have understood now my testing method. I still am not sure that I understand why the sign is correct - I really wanted you to reflect on my change and why it seems to help here with my problem. But I currently see no need to argue about it anymore. Your new process and data structure change a lot of that whole part of the system. In the end it is the result that counts. I really hope that the MK3 will become the rock solid work horse that it could and should be.

This would also explain the behaviour you observed when (un)commenting the line of code. The default values were not only off in magnitude, but also had opposite sign to what your PINDA would have needed. When you commented the line out, it got better (your PINDA is not that temp. dependent, so just disabling the calibration helps). When you uncomment AND change the sign, it gets worse again, but not as bad as the first time. The compensation is still too high, but at least it now compensates it the direction your PINDA needs. Would this make any sense to you? Is this theory consistent with what you were doing?

Yes that is absolutely spot on. I have no experience with other PINDAs with my method but the behavior that I observed is just like you describe here.

I would be very interested to hear what my version of fw would do on your setup. If you decide to experiment with it, run the automatic temp calibration (before printing, see below why) and tell me what happened. And if you managed to also capture serial line output during calibration and sent it to me (PM), I would appreciate that.
Of course I will try it out and send you the feedback - depending on my spare time it MIGHT take until Sunday though. I am happy to send you feedback - it is time well invested for me:-) If you need any more tests done just let me know.

And one more thing. If I see it correctly, commenting the line out not only disables temp. calibration, it also prevents updates of mesh bed levelling data. You thus bring another variable into play. You also have not commented on the warping bed issue, which in my experience is the single most important problem the current automatic calibration has. I take it as an indication that you have not been playing with it either, so untangling your situation is quite difficult for me. I suspect there might be many contributing factors that are unaccounted for.
No, no, I disabled the line were the offset is set from 0 to the return value of the temperature compensation function. NOT the line after it were the mbl is updated.

Are you testing with the PEI stickers sheet?
As mentioned, my calibration is done without any sheet on the bed, to reduce any error it might induce. I understand it is not possible to do your manual calibration that way, because it relies on watching the printer print, which you can't do without a sheet on.

My question with the sheet variant was about if maybe the PEI sticker steel sheet version shows inconsistency in first layer height more, making the problem more visible. So when you would test with only the powder coated version the problem might not be obvious. But from your latest post it is obvious that you also see the problem in your lab.

THANK YOU!

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

This thread is bringing tears to my eyes. Community and Prusa collaboration happening on the Prusa forums. We are entering a new age of peace and tranquility. 🙂

Thank you Lukas for your work on this.

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

Hi,
New MK3 user here (for 6 days), I bought this machine purely based on reviews by youtubers 🙁
But after getting sporadic results with the pinda probe, I installed this firmware and did the calibrations as described and its getting better..but now i'm running unofficial firmware...

I need a reliable machine, I work as a mechanical designer and does alot of prototypes and was thinking of just disconnecting the probe and just go old school manual adjust, is there any firmware I can use that does not have any pinda stuff in it ?

Maybe I can flash the 'youtube' version of the firmware? ...I feel the machine I got and assembled doesnt match the excitement these youtubers have.

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

New MK3 user here as well (6 days too I believe). I must admit I am getting a lot of inconsistencies with the 1st layer. Hanging on for the next firmware upgrade, fingers crossed! Great work so far everyone!

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

Hi,
New MK3 user here (for 6 days), I bought this machine purely based on reviews by youtubers 🙁
..., is there any firmware I can use that does not have any pinda stuff in it ?

Maybe I can flash the 'youtube' version of the firmware? ...I feel the machine I got and assembled doesnt match the excitement these youtubers have.

I know exactly what you mean - but I also know a MK3 user that uses the standard firmware and NEVER has to change live Z - I have no idea why it works for him. But I think maybe the Youtubers are just lucky that their MK3 just works perfectly with the standard firmware. I give them the benefit of doubt.

Let us not use this thread for aggressive or negative stuff about the current MK3's shortcomings - there are enough other threads for this. Let us talk about solutions and ways to improve things. That is the idea of this thread.

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

part of it could be the you tubers are working in a room with a constant stable ambient temperature and moisture control.
if the environment is very stable then any variation in the PINDA would maybe not be 100% noticeable or the issue is smaller and isn't a problem.

my printer is in the basement where the temperature and moisture is not easy to control even though my basement has cooling and heating it is not stable at all especially this time of year.

also while lukas is here, there are still issues with the extruder with ringing and moire patterns. it seems like something is miss counting steps still as you get layers that appear to get thick and narrow like a wave. if you look at a flat vertical wall dead on you see a moire pattern diagonally, if you shine a light from above at an angle on the face of the wall you can then see the layers are changing in thickness along the level.

when my Live Z goes badly with the current PINDA issue and my first layer is too close to the bed you can see the line for the nozzle is Wavy just like at the higher levels where it is going narrow and thick and messing up the Quality of the finished part. this issue Throws off your bench marking of materials and you cannot fine tune because the machine seems like it is bouncing between 2 different places that it wants to be at the same time (thin/thick)

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

What do you think, john.n13 "the heat-transfer guy"? Any ideas about what may be going on here?

Well, my kit will be here Monday according to UPS - in the meantime I am looking at PINDA's (right now trying to find patent documents on them as they typically have good descriptions of prior art that helps understand the conceptual and functional landscape) and want to study the stahlfabrik/lukas to and fro some more to be sure I grasp the nuances. I have been hung up on the issue of the best starting condition for testing - from a high bed temperature down or a low one up. Not sure I can appreciate it until I have the hardware in front of me.

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

part of it could be the you tubers are working in a room with a constant stable ambient temperature and moisture control.
if the environment is very stable then any variation in the PINDA would maybe not be 100% noticeable or the issue is smaller and isn't a problem.

my printer is in the basement where the temperature and moisture is not easy to control even though my basement has cooling and heating it is not stable at all especially this time of year.

also while lukas is here, there are still issues with the extruder with ringing and moire patterns. it seems like something is miss counting steps still as you get layers that appear to get thick and narrow like a wave. if you look at a flat vertical wall dead on you see a moire pattern diagonally, if you shine a light from above at an angle on the face of the wall you can then see the layers are changing in thickness along the level.

when my Live Z goes badly with the current PINDA issue and my first layer is too close to the bed you can see the line for the nozzle is Wavy just like at the higher levels where it is going narrow and thick and messing up the Quality of the finished part. this issue Throws off your bench marking of materials and you cannot fine tune because the machine seems like it is bouncing between 2 different places that it wants to be at the same time (thin/thick)

From where I sit (no printer or printing experience, but lots of very large scale machine and thermal control experience) sounds like at least two possibilities in play to produce these kind of "pattern disturbances" - mechanical vibration and/or control "hunting". I recall at least one thread a month or two ago on the vibration issue and I'd say there have been comments about control loop tuning constants - or at least inferences about them. I need to look at the firmware files to know more about that I suppose ...

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

If I might interject with a slightly off topic post...

While I am waiting for my printer kit to arrive, I read through these forums regularly to keep up with what is happening. Reading through the various threads can leave a person a little leery about what to expect. But this thread is a solid example of why I bought the MK3 instead of one of the dozens of cheaper printers. The community here is excellent and I want to thank you all for the efforts you are putting forth. Stay positive.

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

part of it could be the you tubers are working in a room with a constant stable ambient temperature and moisture control.
if the environment is very stable then any variation in the PINDA would maybe not be 100% noticeable or the issue is smaller and isn't a problem.

my printer is in the basement where the temperature and moisture is not easy to control even though my basement has cooling and heating it is not stable at all especially this time of year.

also while lukas is here, there are still issues with the extruder with ringing and moire patterns. it seems like something is miss counting steps still as you get layers that appear to get thick and narrow like a wave. if you look at a flat vertical wall dead on you see a moire pattern diagonally, if you shine a light from above at an angle on the face of the wall you can then see the layers are changing in thickness along the level.

when my Live Z goes badly with the current PINDA issue and my first layer is too close to the bed you can see the line for the nozzle is Wavy just like at the higher levels where it is going narrow and thick and messing up the Quality of the finished part. this issue Throws off your bench marking of materials and you cannot fine tune because the machine seems like it is bouncing between 2 different places that it wants to be at the same time (thin/thick)

From where I sit (no printer or printing experience, but lots of very large scale machine and thermal control experience) sounds like at least two possibilities in play to produce these kind of "pattern disturbances" - mechanical vibration and/or control "hunting". I recall at least one thread a month or two ago on the vibration issue and I'd say there have been comments about control loop tuning constants - or at least inferences about them. I need to look at the firmware files to know more about that I suppose ...

(Slightly off topic so sorry about that)
The loop constants - Kp, Ki, and Kd specifically - are usually used for the hotend and bed heaters. They get turned on/off with a duty cycle determined by that PID loop. Better tuning ==> more constant temperature. Movement is just constant-acceleration up to target speed, so there isn't much in the way of control loops. Except maybe acceleration and jerk settings?

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

i guess i should of said the problem seems to be the extruder pressure. as the head moves the feed has to keep in sync with the movement speed
right now it is not. it is out of sync so you get a build up (Thick) followed by the extruder pressure going too low (narrow) and you get a wavy layer not a nice straight line.

there was a big problem with running the mk3 in higher resolution as it was under extruding badly. there is still something wrong in this, like missed counts with the loading of the filament into the extruder. this would cause like a pulsating pressure in the extruder and cause thick and thin to occur.

this also effects Live Z as you have 2 problems going on, PINDA reads incorrectly so your distance is wrong and extuder pressure is uneven coupled with a higher temperature on the first layer you usually set to get more into the PEI BED to stick then you have this wavy inconstant extruder pressure and so you end up backing off LIVE Z even more during a test benchmark.

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

Guys could we stay on topic please?

The moiree problem is in the works as far as I remember did I see a pull request about that. I guess next week with the next release?

It is gonna be a big release:-)

So here, let’s talk pinda, it’s calibration and potential bugs there in...

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

Guys could we stay on topic please?
...

So here, let’s talk pinda, it’s calibration and potential bugs there in...

Good idea.

Anticipating what is going to need to happen for users with the new version it might also be helpful to rename the 'Temp. calibration' menu to 'PINDA calibration' since that's what it is. And hopefully calibration will be automatically run with the new version and the current z-offset will be set to 0 unlike 3.1.3 which caused my nozzle to dig further into the bed during the recommended 'Wizard' auto setup after a version change.

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

I know exactly what you mean - but I also know a MK3 user that uses the standard firmware and NEVER has to change live Z - I have no idea why it works for him. But I think maybe the Youtubers are just lucky that their MK3 just works perfectly with the standard firmware. I give them the benefit of doubt.

So I'm one of those users who were monitoring the forum while waiting for their mk3 (and considering cancelling the order at some points).
When I got my shipping notice I was getting ready to apply this firmware fix/change when my printer (assembled version) arrives, but... 2 days into printing with various filaments/temps (included pla- some random cheap pla - abs - tpu - tpe/ninjaflex) I am yet to adjust my live z for the first time, the factory calibration is still fine, I only did the z calibration. Latest firmware 3.1.3 + grey PINDA here.
We will see how it evaluates with more usage, but currently I am very happy with my purchase.
P.S. Not a newcomer, 4 years printing with a clone of Makerbot Replicator 1 Dual

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

So I used Lukas' firmware and used the new temperature calibration method three times.

Has anybody done the same so far? I did not print with the firmware because of his warnings:-)

My results - I honestly cannot interpret them to judge them - are as follows (not very constant)

PINDA temp:29.29 T:73.41 E:0 B:109.8
PINDA temp (C): 29.29 ; Z position (um): 215.00
PINDA temp:29.26 T:72.99 E:0 B:109.6
..
PINDA temp:32.29 T:59.09 E:0 B:109.3
PINDA temp (C): 32.29 ; Z position (um): 230.00
PINDA temp:32.19 T:58.65 E:0 B:109.7
..
PINDA temp:40.14 T:46.75 E:0 B:109.9
PINDA temp (C): 40.14 ; Z position (um): 223.33
PINDA temp:40.11 T:46.67 E:0 B:110.2
..
PINDA temp:43.89 T:45.08 E:0 B:109.4
PINDA temp (C): 43.89 ; Z position (um): 220.83
PINDA temp:43.89 T:45.05 E:0 B:109.8
..
PINDA temp:48.73 T:44.75 E:0 B:109.4
PINDA temp (C): 48.73 ; Z position (um): 224.17
PINDA temp:48.49 T:44.61 E:0 B:109.5
..
PINDA temp:54.65 T:45.09 E:0 B:110.5
PINDA temp (C): 54.65 ; Z position (um): 237.50
PINDA temp:54.73 T:45.06 E:0 B:110.4
..
PINDA temp:57.67 T:46.31 E:0 B:110.5
PINDA temp (C): 57.67 ; Z position (um): 230.00
Measurement finished, fit complete!
Quadratic coefficient ( 10^(-6)* (um/K) ): 0.00
Linear coefficient ( 10^(-6)* (um/K) ): 425710.15
Temperature calibration done. Continue with pressing the knob.

PINDA temp:30.68 T:34.66 E:0 B:109.7
PINDA temp (C): 30.68 ; Z position (um): 204.17
PINDA temp:30.60 T:34.50 E:0 B:109.9
..
PINDA temp:36.56 T:36.98 E:0 B:110.3
PINDA temp (C): 36.56 ; Z position (um): 210.83
PINDA temp:36.67 T:36.79 E:0 B:109.9
..
PINDA temp:41.96 T:39.42 E:0 B:110.3
PINDA temp (C): 41.96 ; Z position (um): 199.17
PINDA temp:42.29 T:39.61 E:0 B:110.4
..
PINDA temp:47.92 T:41.02 E:0 B:109.1
PINDA temp (C): 47.92 ; Z position (um): 193.33
PINDA temp:48.04 T:40.92 E:0 B:109.1
..
PINDA temp:52.51 T:42.27 E:0 B:109.7
PINDA temp (C): 52.51 ; Z position (um): 193.33
PINDA temp:52.71 T:42.25 E:0 B:110.0
..
PINDA temp:56.25 T:44.70 E:0 B:109.7
PINDA temp (C): 56.25 ; Z position (um): 198.33
PINDA temp:56.39 T:44.77 E:0 B:109.4
..
PINDA temp:59.19 T:49.61 E:0 B:110.3
PINDA temp (C): 59.19 ; Z position (um): 210.00
Measurement finished, fit complete!
Quadratic coefficient ( 10^(-6)* (um/K) ): 0.00
Linear coefficient ( 10^(-6)* (um/K) ): -162864.59
Temperature calibration done. Continue with pressing the knob.

I send Lukas also a PM with my results as requested. I have the grey PINDA.

I wonder if the old table method will maybe better suited for my freak MK3:-) With my "bug fix" and my manually calibrated values the issue is really not much present (above 35C) anymore and can be handled. The new method has to be able to beat this or be as good. We will see and I hope to hear back from Lukas how he interprets my numbers.

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

any news update?