Is there a CAM for lathe that doesn't suck?

[Digital Factory]

The potential pitfall of simulation for lathes is that it might not detect collisions caused by adjacent tools if your model doesn't reflect the exact setup of the lathe at that exact time.

It can still help, but there's no substitute for carefully babysitting the first article.

 

[camhead420]

Smartcam might be an alternative, it was good but I haven't looked at it lately

I have been using smartcam for years, The customization is great, along with being able to manipulate the code generator.

 

[escapethewrmhole]

If you don't need simulation Mastercam turning is the fastest, easiest, and easiest to cheat to get it to do just about anything you want.

Esprit turning is more powerful but the workflow is slower because it simulates everything to ensure you're not crashing. Thus harder to do hacky things. But way more capable.

Fusion turning is still horrible.

 

[Ryan at Sparrow]

I just started using CAMWorks for our lathes with Y axis, live tools, subspindle and have been using CAMWorks / SolidworksCAM for milling for years now.

It is definitely not as nice as the milling side of things but I think its decent enough now that we have a workflow figured out. I always say this, but a good post processor is like 50% of the work. The less you have to hand edit after posting the better. I have a Haas post processor for mills that I literally paste in a paragraph at the top of the program and take it to the machine and run. From post to setup in like 3 minutes. We have an Okuma Lathe post now that is probably 60% because our manufacturing engineer is a genius and can edit posts.

One tip I can pass along is to have dual monitors and have an NC editor open on one and CAMWorks open on the other. Since you can't trust the turning toolpath lines in CAMworks like you can for the milling toolpaths I will get the toolpaths looking pretty good and then post the code to see the exact G code. I trust the milling code and don't try to read that because that would take a year, but turn code is typically pretty easy to follow along.

I'd love to discuss CAMWorks' lathe side of things as I am still trying to iron some things out and maybe you have some tips you can give me too.

 

[Marvel]

I just started using CAMWorks for our lathes with Y axis, live tools, subspindle and have been using CAMWorks / SolidworksCAM for milling for years now.

It is definitely not as nice as the milling side of things but I think its decent enough now that we have a workflow figured out. I always say this, but a good post processor is like 50% of the work. The less you have to hand edit after posting the better. I have a Haas post processor for mills that I literally paste in a paragraph at the top of the program and take it to the machine and run. From post to setup in like 3 minutes. We have an Okuma Lathe post now that is probably 60% because our manufacturing engineer is a genius and can edit posts.

One tip I can pass along is to have dual monitors and have an NC editor open on one and CAMWorks open on the other. Since you can't trust the turning toolpath lines in CAMworks like you can for the milling toolpaths I will get the toolpaths looking pretty good and then post the code to see the exact G code. I trust the milling code and don't try to read that because that would take a year, but turn code is typically pretty easy to follow along.

I'd love to discuss CAMWorks' lathe side of things as I am still trying to iron some things out and maybe you have some tips you can give me too.

I would highly recommend paying for a post, not sure who your reseller is, mine is HawkRidge and they've been great with my posts! I haven't hand edited a program in years, if something odd comes up, I send in a request and they edit or fix it.

After a post edit, and I've ran just about every operation and made sure there wasn't anything goofy happening with my post, I almost 100% trust the simulation. I have on many occasions simulated a part, posted the program, hit cycle start and walked away with 0 worry.

 

[Ryan at Sparrow]

I would highly recommend paying for a post, not sure who your reseller is, mine is HawkRidge and they've been great with my posts! I haven't hand edited a program in years, if something odd comes up, I send in a request and they edit or fix it.

After a post edit, and I've ran just about every operation and made sure there wasn't anything goofy happening with my post, I almost 100% trust the simulation. I have on many occasions simulated a part, posted the program, hit cycle start and walked away with 0 worry.

I can practically post and go for milling, but the issue is that CAMWorks doesn't simulate nor backplot what is actually posted on the lathe side of things. It's not really a post issue as much as a CAMWorks.. quirk?

 

[Marvel]

I can practically post and go for milling, but the issue is that CAMWorks doesn't simulate nor backplot what is actually posted on the lathe side of things. It's not really a post issue as much as a CAMWorks.. quirk?

The simulation for milling isn't true to the posted file either. I believe the step thru function is, or it might be the advanced edit toolpath step thru option, one of them is but I know the simulation is not.

 

[Ryan at Sparrow]

The simulation for milling isn't true to the posted file either. I believe the step thru function is, or it might be the advanced edit toolpath step thru option, one of them is but I know the simulation is not.

Hmm, maybe simulation isn't quite the right term I should've used. I'm not sure how to describe it but visually the toolpath lines in the viewport are just plain wrong on the turning side. The milling is pretty much dead on, at least where it matters.

For instance, some machines move in rapid and end at the same point in XY at the same time, others will hit the Y position and continue rapid in X only until the point is met. That is not shown on the backplot in the viewport, usually it's not a concern in milling but for lathe it is a major concern.

Also the toolpath lines for milling are always the center of the tool (at least all the tools I've used thus far). The lathe side of things draws the toolpath line on the Centerpoint of the corner radius instead of the edge of the tool like I would have thought. Hopefully that makes sense, I'm also fairly new to lathe programming so maybe it makes sense to most people how the viewport shows the toolpaths.

 

[Marvel]

For instance, some machines move in rapid and end at the same point in XY at the same time, others will hit the Y position and continue rapid in X only until the point is met. That is not shown on the backplot in the viewport, usually it's not a concern in milling but for lathe it is a major concern.

Dog leg rapids, these have actually burned me a few times in milling, where simulation or even stepping through shows a direct path rapid in the XY but in the actual machine the shorter traveled axis hits its destination first.

Also the toolpath lines for milling are always the center of the tool (at least all the tools I've used thus far). The lathe side of things draws the toolpath line on the Centerpoint of the corner radius instead of the edge of the tool like I would have thought. Hopefully that makes sense, I'm also fairly new to lathe programming so maybe it makes sense to most people how the viewport shows the toolpaths.

I know what you're talking about, I noticed that when I first programmed a lathe part and actually tried to comp the tool to get the tool path line on the surface until I realized it was based on the corner radius or whatever.

 

[EmGo]

Dog leg rapids, these have actually burned me a few times in milling

Really ? The last machine I had that did that was running an Acramatic 220, an NC control, on a 1967 horizontal. Haven't had to worry about that since, oh, 1975 ?

 

[gregormarwick]

Really ? The last machine I had that did that was running an Acramatic 220, an NC control, on a 1967 horizontal. Haven't had to worry about that since, oh, 1975 ?

Dogleg rapids are usually the default on Fanuc machines, the reason I have seen given is that it's faster, although that argument has never seemed very convincing to me...

Newer Fanucs can be switched by parameter to interpolated rapid, but yes other controls have been doing that for decades.

 

[Marvel]

Really ? The last machine I had that did that was running an Acramatic 220, an NC control, on a 1967 horizontal. Haven't had to worry about that since, oh, 1975 ?

Dogleg rapids are usually the default on Fanuc machines, the reason I have seen given is that it's faster, although that argument has never seemed very convincing to me...

Newer Fanucs can be switched by parameter to interpolated rapid, but yes other controls have been doing that for decades.

My two VFSS machines do it. If your rapids are 1200 IPM and your X is traveling 20" and Y is traveling 5" and they both hit full rapid, the Y is going to get to its 5" a lot faster creating a dog leg rapid. HAAS does have a parameter to change it, I tried it but it seems like it slows the rapid moves down.

There's quite a few discussions about it in the forums.

 

[EmGo]

Dogleg rapids are usually the default on Fanuc machines, the reason I have seen given is that it's faster, although that argument has never seemed very convincing to me...

As far as I know, shortest distance between two points is a straight line

 

[Marvel]

As far as I know, shortest distance between two points is a straight line

It has something do with the way the machine settings read interpolated vs dog leg rapids. I believe most machines if you set them to move interpolated it actually puts it into a max high feed rate rather than a rapid which in many cases the max feed is a lot less than max rapid. My VFSS machines have a max feed rate of 630IPM but rapid feed rates of 1200 IPM.

 

[gregormarwick]

As far as I know, shortest distance between two points is a straight line

It has something do with the way the machine settings read interpolated vs dog leg rapids. I believe most machines if you set them to move interpolated it actually puts it into a max high feed rate rather than a rapid which in many cases the max feed is a lot less than max rapid. My VFSS machines have a max feed rate of 630IPM but rapid feed rates of 1200 IPM.

It's because in any two axis move the interpolated distance is longer than either component distance, but the move will still happen at the same velocity. Think the hypotenuse of a triangle vs the edges.

My opinion is that the cycle time gains from dogleg rapids are not that valuable weighted against the improved usability of interpolated rapids in most use cases. Machines set for high production is a different matter. Also the rapid moves have to be big enough for the axis' to be able to actually reach their maximum velocity before it matters.

 

[Marvel]

It's because in any two axis move the interpolated distance is longer than either component distance, but the move will still happen at the same velocity. Think the hypotenuse of a triangle vs the edges.

My opinion is that the cycle time gains from dogleg rapids are not that valuable weighted against the improved usability of interpolated rapids in most use cases. Machines set for high production is a different matter. Also the rapid moves have to be big enough for the axis' to be able to actually reach their maximum velocity before it matters.

The movements are noticeably slower, at least they were in my VF3SS and you'd be surprised at the cycle time difference, but of course unless you are doing high production and trying to keep button to button time down on 500 parts, it probably wouldn't matter much. I tried it on some parts that had a decent cycle time, hours. I went back to dog leg rapids and adjusted my default clearance planes in my CAM.

But back to the original post about dog leg rapids, I can see how they would be more of a concern in a turning center, they caught me off guard and I almost smashed my turret into my tail stock that was fully retracted with a longer length boring bar.

@Ryan at Sparrow I did just recall, in CAMWorks turning you do have the ability to control which axis moves first on rapids on both sides of an operation and at the end of program home location rapid move as well.

 

[Mud]

Smartcam properly simulated dogleg rapids 30 years ago, I didn't realize that was still an issue these days. It was a menu choice in the code generator. Edgecam does it today for sure. The only simulation issue I've had in Edgecam is at toolchanges, when a boring bar is changed to a turning tool and the CAM doesn't know that the X position has changed because the turret has indexed without moving the carriage - I'm not sure if any CAM has that handled. I deal with that by placing a rapid point right after a tool change before sending a bar down the hole.
I tried Fusion a little and gave up for the time being. You can't even place a rapid point other than entering a pass through snippet of G code.

 

[EmGo]

It's because in any two axis move the interpolated distance is longer than either component distance, but the move will still happen at the same velocity. Think the hypotenuse of a triangle vs the edges.

Doesn't have to be done that way though. If you just took the longer side and ran it full tilt, then interpolated only the short side, the axes would arrive at the end point in the same amount of time as just jacking both to max, except the short move would be extended to match the time required for the long move. I believe controls use reverse time internally anyhow, so shouldn't be a major problem to accomplish.

Possibly my Westinghouse did, because interpolated rapids were definitely not slow.

Luckily, I haven't had to deal with those goofy rapids since the departure of the much-lamented Acc220 (which NEVER went down or cost $$$ to troubleshoot / repair) ... some of ya's should come up to the modern world of 1980, it's good. Real good

I didn't realize that was an issue these days

Surprised me too Even Actrion III's didn't have that behavior.

 

[William Lynn]

Those dog legged rapids can certainly get you into trouble. I've had to use separate lines for G0 X & Z many times to suit the part. Always hand programmed, never wanted otherwise. AutoCad and Notepad.

 

[gregormarwick]

Doesn't have to be done that way though. If you just took the longer side and ran it full tilt, then interpolated only the short side, the axes would arrive at the end point in the same amount of time as just jacking both to max, except the short move would be extended to match the time required for the long move. I believe controls use reverse time internally anyhow, so shouldn't be a major problem to accomplish.

Possibly my Westinghouse did, because interpolated rapids were definitely not slow.

Luckily, I haven't had to deal with those goofy rapids since the departure of the much-lamented Acc220 (which NEVER went down or cost $$$ to troubleshoot / repair) ... some of ya's should come up to the modern world of 1980, it's good. Real good


Surprised me too Even Actrion III's didn't have that behavior.

Yes different controls do it differently, I had a modern fast 5x Fanuc at my old place that did interpolated rapids, and they were fast, but they were also not perfectly interpolated - there were often small errors in the arrival time of each physical axis, like a dogleg but very small.

The majority of my milling experience is on Hurcos, and those do interpolated rapids but as far as I can tell do not limit the interpolated move to the max. physical axis rapid rate (just as you describe it above), however this is hard to prove because there is no way to switch between interpolated and dogleg rapids on those controls that I am aware of.

The majority of my turning experience is on Fanuc, and dogleg rapids are by far the most common in that space, and you have to be very aware of them when lathe programming...