G-Code generation very slow, not stuck, on alpha1.

[jpcaram]

The G-code generation, as shown in the manual, is very slow (CPU intensive). It may seem that the program is stuck, but it's not. This will be fixed for alpha1.

[jpcaram]

Slow CNC plotting problem should be completely solved in the latest camlib.py.

[vec...@slingshot.co.nz]

Downloaded camlib.py 2 days ago but did not solve problem.   Is there another one ?   CNC generation is slow but I don't think it is the actual calculation that is causing the problem.   Even after it has finished and refreshes the side menu to "Export CNC", it is still hogging 50% of CPU time.   Thereafter whenever Win focus is brought back to FlatCam the CPU usage goes to 50% for several seconds before dropping back.   It is unusable in this state.

Just tried it again and the hogging occurs when the focus is on the FlatCam graphics window with the CNC path displayed.   With focus moved to the side menus, CPU time drops back to normal.   Deleting the CNC object makes problem go away.

Chris

[vec...@slingshot.co.nz]

Downloaded latest camlib.py and now seems to be fixed although first time I tried it plotting did not complete and I had to refresh to see it.   OK, will move on to next step now.   Thanks for fixing that.

Chris

[vec...@slingshot.co.nz]

I have produced Gcode and it seems to pull into another program to view so I'm happy with that but it does not seem to contain any arcs, only straight line segments.   Is that intentional ?

Chris

[jpcaram]

Yes, you won't find any arcs. The geometry processing library that I'm using handles discrete representations of objects, therefore, every object in the program is a collection of points. In practice, how much of a problem could this be? The resulting G-code will be a little longer and some precision will be lost on arcs, but with enough segments in a circle it should make no difference at all in the final outcome. What do you think?

[vec...@slingshot.co.nz]

I am not a fan of this technique.   It produces bloated data files.   Sure, it works, but the Gcode is not just a "liitle longer".   In the case of the pcb job I sent you, the Gcode file was 388kB versus 87kB produced on LineGrinder.   It could be much worse if the job contained a lot of circular pads and few lines and depend somewhat on how many lines you use to approximate the circle.   I have no problem replacing small arcs with straight lines - they will not be seen, but then how do you decide what is small ?   

I know some people who have advocated turning all circular pads into octagons when the job is brought in - you get a simpler job with almost no loss of copper.

Chris