Build 6856
I managed to track down several of the big bugs that were found by users in the last preview build. It’s still not any more complete than it was before but it should be a little more usable.
1) Fixed the no-finish-path bug.
2) Fixed the huge gcode file problem.
3) Fixed the Simple Toolpath command problems.
You can download it here- http://www.grzsoftware.com/file/MeshCAM2-6856.exe .
Preview Build 6852
I managed to get everything pieced back together enough to release it as a preview. You can get it at http://www.grzsoftware.com/file/MeshCAM2-6852.exe . The finishing doesn’t have progress bars yet; that’s going to require a whole lot more code because of the new workflow and the multithreading. It does seem to work though and I’d appreciate the feedback. I’ll warn you now though, I made lots of changes so you are guaranteed to find bugs. Be sure to run everything through CutViewer.
I still have several outstanding bugs to address that have not been fixed yet. I want to get this in a stable place before I move on.
Boundary Clipping
The last few shots I’ve posted show that the toolpaths have not been clipped by the stock boundaries. The shot below shows this problem fixed. The toolpaths are properly clipped by the machine boundaries even though the clipping created new islands in the lower part of the X and in the middle of the C shape. The code also correctly handled the clipping of the existing island in the O.
This clipping task may seem simple when using a rectangle but the code is made to be very generic so that, at some point in the future, the machine region could be defined by a freeform curve imported via DXF or though a dialog. The code below just creates a polyline from the stock shape so it’s pretty simple.
This is very hard code to write if you want it to work with arbitrary polygons so I didn’t write bother- I licensed it from someone that had it worked out. A thin wrapper of C++ and it was ready to integrate into MeshCAM.
Better Surface Angle Detection
Below is a couple of shots of the new surface angle code in the parallel finishing. The angle was set for 45 degrees and it seems much more consistent than the old code. It’s also much faster to compute. There are a lot of retracts but this seems to be somewhat common for this type of path when I’ve looked at the competition. I have two ways to fix this:
1) Use a more complete toolpath linking algorithm that will make additional checks for better linking options.
2) Compute a complete offset surface of the geometry and preplan the path based on the surface angle.
#2 would give better path linking but would take much more time and memory to compute. #1 will be faster but less optimal. In the short term I’ll probably leave it as-is. It seems roughly competitive with the market, it’s still better than the current code, and I need to move on to get something released sooner rather than later. After people look at the speed of the new code they can vote for what they prefer- faster or better.
Finishing Update
Below is a shot of the new changes to the finishing toolpaths. The paths are now projected down onto the geometry and properly subdivided . You can see how the supports are avoided and that a minimum amount of stock (and no air) is cut- a big improvement from before. I have the "Don’t Machine Top of Stock" working and I now need to make the threshold angle work properly. I’ve got some ideas about how to improve that while I’m updating the code. Until now I had been calculating the angle of the toolpath or the offset surface. I’ve been playing with the competition and they seem to use the original surface as the reference angle. I had tried this before but made some bad mistakes that kept it from being reliable. I’ve come up with some new ideas that should make it work much better and, hopefully, faster.
You’ll also see that I have blue supports now. I had to rebuild my hard drive over the weekend and I ended up with a different video driver version that before. Whenever I see a color change with driver versions it usually mean that I did something wrong or borderline that one driver accepted and one driver didn’t. I’ll have to track this down in the near future as well.
Slow Progress
The updates here have not been frequent lately but I’ve been making steady progress on the new finishing algorithm. Below are a few shots that show the current status. Here’s what they show:
1) The new finishing code will preplan the bulk of the path ahead of time rather than building it one the fly like the current versions. This means that the time intensive part, projecting the path onto the model, can be done in a parallel fashion using multiple CPU cores to speed it up.
2) The paths below are fit to the geometry plus a machining margin, .1″ (user definable) in the shots below. It will ignore the supports in this calculation so the minimum area is machined and the supports can be thinner since they don’t necessarily have to support long spans.
3) Preplanning the paths means that there can be much more efficient path linking with far fewer retracts. Note how few blue retracts you’re seeing below compared to the current system.
4) The shots below show that the supports now function for multiple part STL files. The old ones didn’t and would fail completely in a case like the one below.
5) The code to do this preplanning is very similar to a pocket algorithm so I think I can port it to roughing for much smoother paths there as well. This will be a big win because it will unify all of the toolpath code and remove any old ZMap-style code from the program. This eliminates a lot of legacy junk that requires tons of testing anytime I make toolpath changes.
There are still a few visible glitches to work out but it’s finally getting to a point that the whole thing can be tested together.
Note- The skewing of the overhead view is a function of the perspective view in MeshCAM. The paths are actually laid out with a perfect .1″ boundary.
