Lurking Bugs
It always seemed a little odd to me that I had to set the tolerance below .001" to get a toolpath that I liked. A thousandth of an inch, in general, should be more than enough accuracy for almost any "normal" application. It wasn’t until the last batch of updates that I came to my code to reduce the number of vertices in a polyline and found old code that I thought had been updated long ago. There was potential for the polyline to be eroded away beyond the tolerance setting specified that needed to be fixed- or so I thought. I rewrote it to work properly and found almost zero improvement. Oh well, at least it’s correct now.
I making this change I was led to an error in the last release where the finish path is reduced by a factor of about 25 more than it should be. It should only be present in the last 2 test releases- never in a download from the main page.
That led me to the toolpath refinement code. It turned out that there was a massive bug that led to toolpath points being put in non optimal places. This meant that you needed to move the tolerance way down to get a really accurate toolpath. This can be seen in highly concave corners where the exact corner is not found. This could be what some have seen when they noted a problem with the pencil toolpaths.
The point here is that the next release should have greatly improved accuracy for an equal tolerance value. I’ll mention it again in the announcement for when I post it but you will almost certainly have to adjust your tolerance values up to hold your old toolpath quality and calculation time. For the tolerance freaks reading this, and you know who you are, this should be a great fix. I hope to get it out in the next week.
UPDATE
Ok so it turned out to be easier to complete than I thought so I’ve posted a shot below of the results. The corners show the benefit of the changes.
I also realized that the waterline paths should be more accurate too. People with homemade routers may not notice the changes but I think it’ll be a big deal for those with a more rigid machine.
I’m not sure what this will do to calculation time overall so I’ll have to test more. I suspect that the calculation time for a given quality of toolpath will go down. The good news is that the changes to the refining code should make it very feasible to make it support multicore for that step as well.
Comments
5 Responses to “Lurking Bugs”
Very nice, Robert. Your “Old Code” illustration is exactly why I have had to leave the tolerance very tight–for those inside corners. I’m looking forward to the next release. I’ve been laid off from a job of 15 years and promised myself that I’ll take a couple of months and concentrate on my own projects before looking for a new job so I’ll have some “quality time” to really put MC through its paces.
Randy
Robert,
Another thanks. I thought that I was needing to use insane tolerances. A job using the latest release even with 10x the tolerance was dismal when compared with an almost identical run with 6737. Really looking forwards to the new improved version, I like what you are doing but the bad finish paths forced me to fall back to earlier releases for critical work. Sorry I didn’t find the time to do a detailed test before you found this bug(s), it was high on my list.
Jeff
Robert, I have discovered a problem in the Geometry Scaling routine. For the first time, I needed to scale the incoming geometry, and lost the geometry zero relative to the
newly-scaled geometry. Where is the origin of the scaling? All things being equal, I’d like to request that geometry scaling be relative to the geometry zero. Thanks!
P.S. Just loaded a 95MB STL file and MC was handling it fine, even to toolpath generation!
Randy
Randy -
Sorry to hear about the job. I know lots of people that got laid off back when I worked for a Fortune 500 company. All that I’ve spoken to end up being relieved, and some very happy, after getting over the shock of it all. Good luck going forward and enjoy your quality time.
The geometry scaling command scales around the center of the part. I wrote that a long long time ago so I can’t tell you why it’s that way. I suspect that it’s not been much of a problem because people who carefully place the part relative to the origin are the types who make sure they don’t have to scale anything. Next time I review that dialog it would be worth putting a scale around origin or scale around center radio button.
-Robert
Robert, thanks for the sentiments. I am looking forward to “onward and upward”!
This part happens to be a steam locomotive driving wheel. Thus far, I had been applying a scale factor in Solidworks but the geometry became too complex for SW scale factor to handle (go figure…) Ironically I was laid off in the middle of a Solidworks training class, which I was allowed to finish out since it was paid for already. The SW instructor confirmed that the scale factor was intended specifically for a small percentage (casting shrink allowance etc.) and advised to do the major scaling in the CAM program. Since the only references I have to work from are the full-size drawings, rather than scale each dimension I figured I would model it at full size and scale as a last step. That way I could also use the same CAD model for varying scales.
All of that to say yes, I would appreciate the option to scale around origin.
Randy