Zigzag does not give complete toolpath.

[GoogleCodeExporter]

Open the attached .heeks file.  Note that the toolpath covers the entire part. 
http://img218.imageshack.us/i/screenshot001ko.png/ This operation was created 
by selecting the solid and adding a 3d zigzag operation.  The minimum and 
maximum XY values are unchanged. 

Change the minimum and maximum Y to -90 and 90 respectively and post-process 
again.  

You should see a toolpath like this: 
http://img249.imageshack.us/i/screenshot002gs.png/

Other values for min/max Y give dramatically different results.

Original issue reported on code.google.com by shopinth...@gmail.com on 10 Feb 2011 at 3:47

Attachments:

• lidbug.heeks

[GoogleCodeExporter]

I see this all the time too. Trying 0.16.0 under Win7 I see python process 
eating a LOT of memory rapidly before dying. Running py script manually shows 
it dies suddently during second stage.

Original comment by tha_krea...@hotmail.com on 11 Feb 2011 at 8:14

[GoogleCodeExporter]

Hi all,

This is probably because of how Python treats your input numbers. If you set 
-90 and 90 as the limits it will recognise these as of type *int*, and proceed 
to do int division, multiplication etc. downstream.
The immediate quick-and-dirty fix is to specify limits -90.0001 and +90.0001 
which are clearly *float* and will be treated as such.
The better fix is to identify where these numbers go into python and use 
*float(90)* and *float(-90)* which will give more predictable results. 

Original comment by anders.e...@gmail.com on 12 Feb 2011 at 3:58

[GoogleCodeExporter]

OK, I think I've fixed this by adding "float()" around many of the numbers ( 
change is in ZigZag.cpp ). Thanks Anders.
shopinthewoods, please check to see if this is fixed for you.

Original comment by danhe...@gmail.com on 12 Feb 2011 at 5:15

• Changed state: Fixed

[GoogleCodeExporter]

Fix confirmed.  Thanks guys.

Original comment by shopinth...@gmail.com on 12 Feb 2011 at 6:41

[GoogleCodeExporter]

I am testing this .001 add now.  Wonder if this is relating to issue 273?
I am seeing this as well, and python gobbles up it's max mem in a few seconds.  
If the code is simple it finishes, if not I get incomplete nc as result.

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

[GoogleCodeExporter]

It changed the behaviour of python a little bit, allowing more to be generated 
before python bombs out with memory error for me.
Without the ,0001 settings I get only 1 pass. (See picture with mem use graph 
too.)
I think it's definately related to issue 273.
Since I do not have a build environment for heeks I can't test the ZigZag.cpp 
changes though. I do suspect there is a massive memory-leak in one of the heeks 
dll's containing functions for python.

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

Attachments:

• fw58_4.png

[GoogleCodeExporter]

I instrumented ocl_funcs.py with garbage collector function to dump objects to 
see if there was something happening in python. I print out the objects on the 
start of each cycle in the i-loop. The memory is said to be used by python, but 
I could find no objects lingering. It seems the for-loops for zigzag is 
well-behaved. That's atleast an indication. Hope it helps.

Original comment by tha_krea...@hotmail.com on 13 Feb 2011 at 11:18

Attachments:

• py_obj.txt