search

elliotf / heekscnc

Automatically exported from code.google.com/p/heekscnc
Other
1 stars 0 forks source link

Python Crashes during execution of script. #273

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. bring up iges file
2. define roughing
3. Python crashes after 45seconds of running with a memory failure.
4. about 2700 lines of g code are generated prior to the crash.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
version 0.15.1 Windows 7 ultimate 64bit

Please provide any additional information below.

Original issue reported on code.google.com by paulk...@pacbell.net on 11 Jan 2011 at 12:46

Attachments:

GoogleCodeExporter commented 8 years ago 
Definately a memory leak relating to zig-zag.
I see it too. As long as the number of passes is low it finishes. Increase the 
complexity and it fails. Watching memory consumption shows it bombs out when 
it's process has reach the limit.

Original comment by tha_krea...@hotmail.com on 13 Feb 2011 at 2:23

GoogleCodeExporter commented 8 years ago 
Attached is heeks file and plot showing mem use...
It ether bombs out on the setSTL(s) part or the .run() part of the operation.
Modifying ocl_funcs.py to change setSampling(0.1) to setSampling(1.0) makes the 
memory leak happen much faster. (In case this helps anyone understand where the 
issue is...)

Original comment by tha_krea...@hotmail.com on 13 Feb 2011 at 3:50

Attachments:

GoogleCodeExporter commented 8 years ago 
Modifying the stl-file used in the process to a simple 2-triangle square, 
allowed the tight finishing toolpaths to be run (single pass), and memory 
consumption only reached 230MB. Stl orginally had 4978 triangles and get's 
about 1/3 of the way eating up 2GB. The number of triangles is definately 
related to the leak-rate.

Original comment by tha_krea...@hotmail.com on 13 Feb 2011 at 1:09

GoogleCodeExporter commented 8 years ago 
Here's the original stl too...
It was edited in k-3d and exported. Then re-read in FreeCAD and exported in 
binary form.

Original comment by tha_krea...@hotmail.com on 13 Feb 2011 at 3:22

Attachments:

GoogleCodeExporter commented 8 years ago 
on 64-bit Ubuntu 10.04LTS with the "About" box saying 0.16.0 and all software 
taken recently from svn it looks like this:
http://imagebin.org/137704

Original comment by anders.e...@gmail.com on 13 Feb 2011 at 3:30

GoogleCodeExporter commented 8 years ago 
Then I think it's confirmed that this issue is really resolved but that the 
windows build of ocl is lagging in the 0.16.0 installer.
Date of the ocl.pyd is 2010.09.28 and according to issue 30 on opencamlib ( 
http://code.google.com/p/opencamlib/issues/detail?id=30&can=1 ) a major cleanup 
was done 2010.11.12 and 13'th. If someone could build a recent version for 
windows users that would be welcome.

Original comment by tha_krea...@hotmail.com on 13 Feb 2011 at 4:58

GoogleCodeExporter commented 8 years ago 
I will make a new Windows installation of HeeksCNC tomorrow, if I can get zig 
zag operations working OK.

Original comment by danhe...@gmail.com on 13 Feb 2011 at 5:09

GoogleCodeExporter commented 8 years ago 
ok, I have made a new installation of HeeksCNC. I can't believe it needs to be 
doing these things for every pass of the zigzag.
         dcf.setZ(z0)
         dcf.setSTL(s)
         dcf.setCutter(cutter)
         dcf.setPath(path)
( see "c:\Program Files\HeeksCNC\HeeksCNC\ocl_funcs.py" )
I have made the latest Windows build show the console window while 
post-processing, like it used to, so you can see the progress.

Original comment by danhe...@gmail.com on 14 Feb 2011 at 12:01

GoogleCodeExporter commented 8 years ago 
I have considerably speeded up the zigzag operation by no making a new 
PathDropCutter for each zig. I made a new Windows installation 0.17.1

Original comment by danhe...@gmail.com on 14 Feb 2011 at 4:17

GoogleCodeExporter commented 8 years ago 
Yes, I was wondering about that too.
I was just not sure if the variables and objects needed by run() would be 
initialized correctly by each call, or if distroying the object was the only 
way. I did get some odd results with the 0.16.0 release in windows when I 
played around with this part of the script, but there was memory leaks that 
probably caused those issues.

Original comment by tha_krea...@hotmail.com on 14 Feb 2011 at 5:34

GoogleCodeExporter commented 8 years ago 
Tested 0.17.1 on Windows 7 x64 and it now runns the operations in very short 
time. It also displays the python window which is very helpfull. Great work!

Original comment by tha_krea...@hotmail.com on 14 Feb 2011 at 5:51

GoogleCodeExporter commented 8 years ago 
Just loaded the new installer and rand the same part that was failing.  Post 
process ran without Issue. Ran fine on Win 7 x64.  Seeems faster as well.

Great work!

Original comment by paulk...@pacbell.net on 14 Feb 2011 at 6:09