New Roughing Progress
I have the roughing simulation code working pretty well and tested to the degree that I can so far. I’ve updated the display code to let the color of the toolpath vary depending on the feedrate so the new data can be visualized. Now I just have to redo the roughing code to take advantage of all of this.
Just to set expectations early, this is not going to be a complete 3D simulation of the machining process so no attempt is made to find the “optimal feedrate”. This new code is an attempt at solving 80% of the roughing feedrate problem with the least computing time and memory required. Once I get it running we’ll have some idea how good it will be.
Based on all of your feedback I’ve made the last release an “official release” available on the main download page. Thanks for all the help getting to this point.
New Roughing Preview
Just to prove that I am working on new V3 features I’m posing a preview of the updated roughing algorithm.
You can see that the cutter will now cut the area between two Z levels to leave an even skin of stock for the finishing algorithms. This is something people have been requesting for a while so I made it the first major feature that will be released.
I am also investigating code to dynamically vary the feedrate depending on how buried the tool is in the stock. There’s no code for this part yet- it’s still in the design stage right now.
My real motivation to show this is to encourage feedback on the last release. The quicker I get that one done the quicker I can move on to releasing V3.
Build 7283
Christian K. has finally given the latest build a clean bill of health- all of the waterline problems seem to be gone. Run a "Check for Updates" and update now.
This was one of the more difficult bugs to find. It took about 10 days of deep digging to find two bugs. One was in a previous optimization that I had to partially undo. The more difficult one involved a bad interaction between the multiple threads and the Microsoft compiler optimizing part of my code away. The random waterline gouges that Christian found happen to be perfectly laid out to cause this rare bug almost every time. If have ever gotten gouges that move around each time the toolpath is calculated then this build probably a fix for it.
When MeshCAM generates a toolpath the "Analyzing Geometry" section is actually dividing the model up so it can be checked against the cutter more quickly. The toolpath is then divided between several threads, each with a separate section of the model to check. Some triangles will overlap multiple sections and can be checked by more than one thread at a time. There are some shared flags that are used to avoid conflict. Unfortunately I found that Visual C++ assumed that only one thread would ever access these flags and changed the code drastically when optimizing the output to run faster. This probably never showed up much before because users tend to have large models with lots of triangles. This would usually mean that the threads stay far enough away to not interfere with each other. Christian was the opposite- his files might only use a few dozen triangles so the potential for conflict was increased. I can say this is the first bug I’ve ever had to look at assembly code to find.