Good Optimizing Progress
I just finished testing today’s optimizations on the “Jeff Demand Reference Model.” Jeff sent me a 27MB STL file with >500k triangles over a very small area about 60mm x 20mm. With the parameters that he initially provided the toolpath calculation time was over 3000 seconds- obviously way too much. After a lot of optimizing I’ve gotten it to about 1200 seconds (about 20 minutes). It’s still too much but it’s a great improvement and if I can cut it in half again then I’d be happy. Once I get everything as tight as I can then I can enable multitreading to take advantage of the multicore CPUs that everyone has not. The ZMap-based code did not lend itself to multithreading but the new code is perfect for it.
Expect a new test release in the next few days with the more correct and faster code in it.
Robert,
Thanks !!! I did actually complete one test, 5300 seconds and the only reason it finished was that I had forgotten it was running. Code cut just fine and similar in size to 5946. Too bad I decided a slight model change was required. 200 seconds with 5946 and I’ll take a close look at the milled results from the two versions.
Do get the code close to stable, shutting down a errant program using both cores is not much fun.
I was going to ask about multithreading. I use the task manager CPU Usage History a lot to monitor intensive tasks, and it seemed to only be using one core. (yours isn’t the only program I push
Jeff
I’d be curious if you could get a similar quality toolpath to that in 5946 using a larger tolerance. The .025mm tolerance value leads to an initial forward step value of .118mm compared to .05mm based on the older versions with an oversampling value of 0. However, the new code will subdivide each step by a factor of 10 if a corner is detected. This means that you have an effective forward step of .0118mm- quite an improvement over the old ZMap releases. Your desired tolerance of .0025 would be even finer but not by a factor of 10.
I agree that it’s annoying to be waiting on a program when the CPU meter is pegged at 50% (maybe 25% if you’re really lucky with a quad core) and you have half a computer doing nothing. I’ll try to put an end to that.
Robert,
I hadn’t been paying enough attention to your descriptions of how the 65xx versions would subdivide steps by 10 if a corner was detected. My bad. Coupled with setting modeling and milling tolerances 10x what I can mill (old habit) I can see where the seconds have gone. Since you are determined to keep improving MeshCam I’ll just have to keep adjusting old habits and thought sets to keep up. Still a happy camper.
Regarding the almost identical files milled with 5946 and 6512… almost the same but vertical (technically tapered since I was using a tapered bit) Y surfaces with at a low angle off axis came out much smoother with 6512. (Y finish pass) I know this is an inherent problem with step drives but you seem to have helped compensate.
Jeff