Memory leak solved

[Pixopax]

Today I made a big discovery: Liteplacer Software often had severe problems with my cams, it worked a while, and suddenly the cams froze.
I could trace that to the memory usage of the software, racing up as high as 1.6 GB Ram sometimes. The garbage collector of Visiual Studio frees up mem in intervals, most of the time that works, but on my machine as soon as it reached >1.6 GB Ram app threw some exceptions and the cam was offline.

In my own version I saw the same behaviour. I worked some days trying to avoid it, but could not do it. Until I found out, that there is a simple command to run the garbage collector:

Code: Select all

GC.Collect();

I added that after the routine where a frame bitmap is given to the camera-picturebox. Et voila, the memory usage stalls at only 56 MB, and no cam connection problems since 4 hours now

Maybe you should add that to the official software too..

I could hit my head now, searched so long for a solution, and it was not far away

[JuKu]

Thank you!!
Although they are getting more rare, I still get reports from users about memory leak, and I have been unable to reproduce those. It looks like there is no leak but keeping threads busy enough that collector doesn’t get a slot to run makes it look like that.
Apparently I trusted Microsoft way too much.

I appreciate your find very, very much.

[Pixopax]

I tested it today, and it really is the trick. My machine runs much better now, all connection problems are gone.
I also had some com problems suddenly it lost connection to the tinyG. It seems that those are gone too, I guess the programm was very busy when memory was full, resulting in missing commands. I had it run for 4 hours in a row without any problems, simulating picks and places for the whole time

Btw, your new settings system is much better, that stupid microsoft system was really a mess.
Now there is a file which can be copied easily, very nice. I added it to my own rmod-fork too.
Thank you for that idea.

Louis

[JuKu]

I did some testing on my setup, too. Forcing the gc to run made no difference, memory use was 56MB with and without the magic sentence. Apparently my development machine is fast enough and/or has enough memory for the program, memory monitor, tools and some. In other words, no way I would have found this solution myself.

[Pixopax]

Strange. My machine is very very fast, 32 GB Ram, M2 SSD, Core I7 8700K, top of the list, could not be faster I think.
But it could not clean the garbage can fast enough

Your latest standard software shows that memory loadup at my machine too, up to 1.6 GB is used. As soon as it comes over 1.6 GB the program is delayed, resulting in loss of commuication with the cams and sometimes with the tinyG.
Maybe there is something else on my machine what causes that, I don't know. I searched for 2 days to find out why it eats up memory, but could not find a cause.

As far as I found out is opencv clean, does not have leaks if used properly. And the routines in the software work ok, they dispose of old bitmaps etc. Somehow the garbage management of c# is too slow.

But with the fix all is good

[JuKu]

You have way more capable machine than I do. Strange indeed. Which os?

[Pixopax]

I run Windows 7 ultimate 64 bit.

[Pixopax]

I assembled 20 boards 100x160 each yesterday, they went through in an hour, and not one error, all smooth.
I added another usb camera to it, as a control cam which shows me the nozzle so I can see what happens while placing.

So with 3 cams running it used only 80 MB Ram, and I did not have any stops or connection losses now. That is a complete change for me, I now track many problems I had with the software to the memory usage problem, which is solved with the fix. It seems to make the system much more stable and reliable, even with many cameras active.


I use an alternative table layout, setting the PCB in the middle of my vertical aligned tapes.
Since this PCB is turned by 90° I created an eagle ulp file which makes me job files which are 90° rotated. So I can design normal up to 160x100 in eagle, but place the board rotated as shown.

That has some advantages: I can put my tape spools all in one line, I have 2 boxes on the low side of the table holding the spools.
This way I also have a fixed top point for all tapes. My tape holders are aligned precise vertically which saves a lot of search moves too.
I have a button in the tapes section saying "Goto Top". If I select a tape and click it the cam drives to the top hole of that tape making recalibration very easy and fast.

This arrangement also allows for my new tape display in the job table, I mentioned that before. It shows me how many parts are left in the tapes and warns me before I start a job when parts are missing.

The most used parts are left and right of the PCB, so the travel way is very short for them.
My nozzles are on the low side of the table.
And a small tray area is also there, where I put my TQFPs for placement, that works very good as long as the parts have a good alignment to the tray.

Louis

[Krzys]

Hello, Yuku ... Could you do a correction in the program regarding this memory problem?
For me, this is a common problem with the program and computer crash.
The computer is DELL XPS with Windows Vista. On the processor and memory monitor you can see how the load suddenly increases and a huge slowdown in the program is created. The system is clean. There is nothing but Windows and Liteplacer.
The only solution is to close the program and restart it. But this is annoying because it occurs in unexpected moments.

Waiting with hope for improvement.
Regards.

Krzysztof

[JuKu]

> Hello, Yuku ... Could you do a correction in the program regarding this memory problem?

Done.

And I do agree it is annoying. I never found out why some systems suffer from this, some don't. (OS version? .NET version? Some installed software replacing the standard GC?) Very frustrating to get bug reports that I am not able to reproduce. Ok, hopefully this problem is gone now. Once more, big thanks to Pixopax for figuring this out!