[mmoe]

I totally disagree with you on that point . Most professional mills are set up with limited amounts of read ahead , high speed machining options on the mills themselves do allow for better read ahead and the results are less choppy movements , but without hsm the choppy movements mean that the machine will not necessarily reach the desired speed because the mill simply cannot process the code quick enough . I have a job that I do at work , I've programmed a 1/8 ballnose to run at 80 ipm , with a similar toolpath to equidistance (line segments) . The mill simply won't reach that feed , I can feed over ride to 300ipm and there is no change in the feed rate .
The reduction is code is substantial when changing from line segments to arc which is a huge memory saver as well as much less code that needs to be processed . The programs that I run at home are huge and since I only use mach here , then it is easy to load up whatever sized program that i need . If I were to use these programs on the hass mills that I run at work - they'd need to be dnc or the programs segmented into 5-10 separate programs for one part , simply because the memory is so limited .
Also arc moves where there is an arc in the part is going to be much smoother than an arc being cut with line segments .


I have never seen an option for arc with equidistant offset and all of my code with it is line segments . How is it that you've been able to get arc moves(g02 g03) ?

Yes, real world differences would exist, but when you simulate the part it usually comes out with the same times since it rarely accounts for acceleration/deceleration and read ahead parameters. Smoothness of cut is the real advantage, as you point out, since the motions are continuous with arcs. Here's a video of the part shown being cut with equidistant offset programmed in V24. You'll see that it's obvious that the motions are arc based, even when they are 3 dimensional:

Shinx CNC router cutting Delrin - YouTube

The part did not come out as smooth as I'd like, but the issue was that it was a rapid prototype and did not get fixtured, but rather just double back taped down. There is just enough give in the hold down this way that there is some degree of vibration. If I fixtured it, I'd expect it to be much better, but as a prototype it served it's purpose and has been in testing for some time now.

As for the option for arcs, I sincerely had no idea that others were not getting arcs. I don't recall if "arc-fit" is an option you check, but either way the program is full of G2 and G3 motions. I created the feature the same way I always have, so unfortunately I don't have any insight as to why you wouldn't be getting arcs from it. I'll look into the file later tonight and post what the options are and what options I've checked/selected. I do know that the toolpath preview after you generate the toolpath does not show the arcs, and it concerned me initially that I would be getting a bunch of lines, but when I posted it the code came out with arcs instead and I'd never concerned myself about it since. Again, from the video, I think it will be obvious that I'm getting arcs from the Equidistant Offset feature.

[dertsap]

. Again, from the video, I think it will be obvious that I'm getting arcs from the Equidistant Offset feature.

My experience is that it will cut arc's but it's with a million line segments , no g02/g03 . Your video is cutting the rads on the part , but is the coding all arc (g2g3) movements or a million line segments ? . If I'm missing something then I'd appreciate someone pointing out what I've done wrong , but I've got the latest version of v25 and I don't see arc fit anywhere in equidistant

[mmoe]

After looking more closely at the file, I may have been seeing one of the other features when I saw the G2/G3 movements. You may be correct that it is still line segments, but I have to say I'm surprised given how smoothly they were cutting. I remember thinking, during machining, that the motions were really quite smooth and I was impressed with that even thinking it was arc moves. Often there are still something close to a pause between arc moves on my machine (hardly noticeable, but still perceptible) and I recall being thrilled with just how smoothly the program was running. I was even thinking about upping the feed rate by nearly double since it didn't show any signs of jerkiness at all and I was already at approx. 100 in/min (2500mm/min), which is normally about the fastest I like to run 3d jobs. In the past, small line segments would give me a pretty jerky motion, so it really did not appear to look like anything other than G2/G3 motion, but now that I examine the code more carefully, it does look like you are right. I'll have to look into it a bit more, but I'm not sure how much of a concern I really have about it given how well the code produced cut. That may come down to the specifics of my machine and how it's set up, so I can see how other's mileage may vary and it may be more desirable to have true arcs. I'll try it out a bit with V26 and see what I get.

[mmoe]

So, after going through V26 Equidistant Offset, it appears that it only somewhat uses arc motions. It will produce an arc motion where the motion remains parallel to the XY plane, but will not make a arc motion where the arc would be 3d, as in moving through more than one Z position. Here's the same part run first without the arc-fit function, and then with the arc-fit function. The pink lines indicate a G2/G3 arc motion while the blue lines indicate a G1 motion (red dashes indicates a rapid motion). I guess you'll have to determine just how useful this is for you, but as I said the line motions that I'm getting are quite smooth already, so I'm not sure how much benefit having a true arc motion on such a limited amount of a 3d surface really is. Other than those areas where it's almost more of a profile motion, there really isn't much arc-fitting going on in this example. The file size is reduced considerably, from 4.5mb down to 700kb, but you could also do all the areas that were "arc-fit" with a simple profile cut, by machining to the extents (instead of part bottom as done here) and then profiling from there, which would also result in an even smaller file.



Now, if you have good eyes and look at the above, you'll notice what I think RAF was seeing in the simulation. If you do nothing but check the "arc fit" box, meaning that the toolpaths are otherwise identical, the straight line segment portions of the tool path fall apart. I'm not sure why, but it really looks so different (and clearly inferior) as I'd have to say it's a bug of some sort. Here's a closer look where I machined to the extents, and you'll see that the straight line segments of the standard (no arc fit checked) version are much more uniform and smoother than the same sections of the toolpath with arc fit (which is odd since they aren't arcs). With the toolpaths I'm seeing, it's obvious that the arc-fit version would produce an inferior surface to the standard no arc-fit version, and I'd have to agree with RAF that I don't think it's as good of a tool path. If the straight segments were a wash, the arc fit areas would be an improvement, but where there are straight segments in the arc-fit version, they are not as small and well fit to the model as they are normally. I have to wonder if they were meant to be arcs of some sort, but perhaps a setting in the machine set up must be enabled for true 3 axis arc fit?

[RAF.]

Excellent work mmoe

I have to agree that when Bobcad first added Equidistant Offset in the Pro version and I tried it I thought AWSOME and I thought it was a pretty smooth and tight tool path. When dertsap noticed that Bobcad had added Arc Fit to the Equidistant Offset in V26 I thought AWSOME AWSOME how could it get any better.
Hopefully Al or the techs can explain what is going on, maybe just a setting or something that has to be changed.

RAF

[moldmker]

mmoe, Try the arc fit path again but with the Machining and/or Arc tolerance set very fine, like around .000005"

Not saying this will help, but it has helped me when using arc fit in v25.

Attachment 204314

[mmoe]

mmoe, Try the arc fit path again but with the Machining and/or Arc tolerance set very fine, like around .000005"

Not saying this will help, but it has helped me when using arc fit in v25.

Attachment 204314

When you set the tolerance to .0001mm, it does produce a nice toolpath both with or without Arc Fit. In fact, they are nearly indiscernible other than that there are some arcs used in the same places as my original comparison. That said, I have what I'd guess is a pretty above average computer (3.4ghz i7 quad core with hyper threading, 16gb ram, reasonably high end video card, etc.), and it still took about 45 minutes to produce the high tolerance tool path. Comparatively, a tolerance setting of .001mm without Arc Fit enabled appears to be very similar in quality, but only takes 3 minutes to compute. For a mold maker, it may be that the difference between tolerance levels is just enough that the time is well spent, but for most applications I'd bet that it would be unnecessary. Also, the real question is whether or not the Arc Fit provides any real benefits to the tool path. I think the toolpath with Arc Fit enabled has absolutely no benefit to finish quality over the same tolerance level without Arc Fit enabled, based on what I'm seeing. If you have a controller with limited memory, it does save about 60% of the file size on the example I've shown, so it may be of some use in that regard, but it will depend a lot on the specific part being run as to how much savings there really is. Unless I'm missing something, and perhaps more information will come out to show that I have, the arc fit appears to only be used on true circular elements that run parallel to the XY plane, which makes sense when you really think about how arcs are programmed (XY YZ XZ, etc.).

I find that the results I get from Equidistant Offset are already excellent in my V24 release, so I don't think that will be part of what I consider when thinking of upgrading. For me, the main things I was hoping for was faster processing in the standard tool strategies (Slice Planar, etc.) instead of only the "Pro" strategies, improvements to the types of tool available, and I've always wished I had the adaptive roughing option (not in V24 Pro). Slice Planar is the one that could use multicore processing more than any of them since it's the go-to strategy for large 3d surfaces IMHO.

Here's the comparison between Arc Fit enabled and not enabled with the tolerance set high. I had to zoom in a bit to make the comparison visible, where as before it was obvious without zooming in. As before, the blue lines represent lines, not arcs. The only arcs were around the rim of the circle as with the previous examples. Those areas would have been comparable, so this is more of a visual of how the areas not cut with arcs compare (where previously they were quite different).

[BurrMan]

So, after going through V26 Equidistant Offset, it appears that it only somewhat uses arc motions. It will produce an arc motion where the motion remains parallel to the XY plane, but will not make a arc motion where the arc would be 3d, as in moving through more than one Z position.

possible post setting. Not sure though. Lines 64, 65 and 66.

[mmoe]

I have those lines in post set up, so I think the post is good that way. I think that the limiting factor is that Arc Fit will only work when the motion is exactly in the XY, XZ or YZ plane. If it's moving non-planar to those planes, then it's technically a helical motion to fit an arc. So far, I've not been able to generate a helical motion using Arc Fit in any toolpath strategy in Bobcad, so it's perhaps not surprising that it is not well suited for Equidistant Offset. Here's an example using Slice Planar in V24 (ignore the incorrect arcs, not sure why they are there but they appear to be errors in G2/G3 direction I believe which may be somehow post related). Again, pink is arc motion, blue is straight lines. The first example is with a "0 degree" lace angle while the second is a "30 degree" lace angle. Clearly, there are no arcs being produced when they would have to become helical in nature in the "30 degree" version. I imagine it would be very, very difficult to generate that kind of code automatically and I don't know that I think there is any practical advantage to it anyways.

I designed this part to force a XZ and YZ planar motion in Equidistant Offset, which is shown in the third example. There are arc motions generated, but not that many really. I think that this would have been about as close to a best case scenario for generating arcs in E.O. on the XZ and YZ planes, but still not really that successful I suppose. I set the job up to run from the outside to the center, hoping that would further enhance the potential for XZ/YZ arc motions since it would start it's offset from planar faces of the part model. My opinion is that the arc fit concept just doesn't suit Equidistant Offset very well, as I'm just not seeing many conditions where the tool path will run in plane with the XZ and YZ arc motions, and its also clear that Bobcad does not arc fit helical arc motions in any of the strategies that I've been able to produce.

[moldmker]

mmoe...your post #89 covers much of what I thought of when hearing about equidistant w/arc fit.
Thanks for doing the legwork.

Have you inspected your code output to make sure there is not a third axis being introduced to the interpolations?

[mmoe]

mmoe...your post #89 covers much of what I thought of when hearing about equidistant w/arc fit.
Thanks for doing the legwork.

Have you inspected your code output to make sure there is not a third axis being introduced to the interpolations?

Not exactly sure what you mean, but I'm guessing that it's in regards to the errors in the arcs? If so, it's pretty clearly a G2/G3 error when you can zoom in on the tool path. There is basically a missing tool path where the arc should be rather than the arc moving in 360 degrees, with the arc starting at the correct point and moving the opposite direction in Z until it terminates as the other end which is also the correct point. I'm quite certain that if I scanned through the code and flipped the G2/G3 command for those specific instances, it would be exactly the way it should be.

Not sure what the cause is though, as I'm not finding anything in my post that I would think is the issue. Plus, the vast majority of them came out correct. The only option that normally seems to mess with arcs like that is whether IJK are absolute or incremental, but typically they would all be messed up. Plus, checking the post vs. the controller setup shows they are both set for incremental IJK and should be fine (I use absolute coordinates with incremental IJK). The one odd thing is that Mach 3 only says IJ for the absolute/incremental setting, so I have to wonder about the K. I may try it with Mach 3 and the post processor set to absolute IJK and see if there's any difference.

Edit:
Turns out to be an error in Mach 3. As I follow the tool path line by line, the motion shown by the highlighted path is correct even where the displayed tool path is incorrect. From the looks of it, the post is working fine and the code would actually run without the error shown. As I suspected, it's not really an issue with Bobcad's toolpath generation (which is why I suggested it be ignored earlier). Same display error occurs whether I do it in incremental or absolute IJK. White line indicates the path the tool would travel, but doesn't line up with a displayed tool path line.

[Hood]

Can you attach the code please, I have never seen that problem in Mach, will be interesting to have a look and see if its the same here.
.
Hood

[mmoe]

Can you attach the code please, I have never seen that problem in Mach, will be interesting to have a look and see if its the same here.
.
Hood

No problem, Hood. Here's a link to the file:

https://files.secureserver.net/0s1Uhxr1a41BbT

This particular one, which is the same as the image showing the highlighted tool movement, is absolute I,J,K, so you'll need to set that in General Settings. Hasn't made any significant difference though if I do it in absolute or incremental. Both show roughly the same errors (haven't examined close enough to say identical).

[BurrMan]

mach likes the break arc segments settings turned on in your post. Are your's turned on?

[mmoe]

mach likes the break arc segments settings turned on in your post. Are your's turned on?

Good to know. It has not been on, so I've made that change to my post processor. It didn't make any difference in terms of the odd misrepresentation of the arc motions though and looks pretty much identical. Here's the same program with the post processor set to this:

221. Break arcs into quadrants? y
222. Arc center a=absolute, b=incremental, d=unsigned inc., e=radius? a
223. Break arcs into two pieces if greater than 180 degrees? y


https://files.secureserver.net/0s1kzMdo213Iqu

The machine moves the way it should, its just the display of those arcs that is wrong. The G3 is correct since the opposite side displays properly while being G2 and the machine traveling in the opposite direction.

[Hood]

Thanks, have passed it on to Brett, maybe nothing will get done seeing as Mach4 is close but we will see anyway.
Hood

[WILDMAN2]

Tony,all your thread issues,I thought was going to be fixed in V25.Those and other little things.That kind of stuff just rubs me wrong when they just go to the next version and not fix the old version.With all the GOOD VIBE created with V25,which improved their image a ton,if they choose just to leave V25 how it is,not going to good for their reputation.Maybe they will have another Update,but if they follow history,NO.


6 months I asked for bugs to be fixed.There History is getting real OLD

[TonyW]

yeah. And I still have to 'mouse over' all the input boxes to edit a number. Hitting tab from box to box still doesn't work. Except on the lathe side. That's a lot of extra motions. (One of my major pet peeves) Still waiting to see if I will upgrade this time. Will see what a future update brings to V26

[aldepoalo]

Do you want to see V26 in action? Join my meeting now!

The meeting is over....

[fidia]

Has the meeting ended