Need a solid POST for an OKUMA GENOS or Captain Mill-Turn Lathe

[Japazo]

Hey everyone,

I have been using CAMWorks to program an OKUMA GENOS L300-M mill-turn lathe for a few years now and I have been dealing with a lot of flaws in the POST that I can't seem to eliminate by myself. The machine is a single turret, single spindle, 12 station VDI live tool setup, with a manual tailstock. No sub spindle, no y-axis, not really any frills.

What I am looking for is a set-it and forget-it post that is as reliable as my mill posts. I can output a simultaneous 4-axis program using 10+ tools for my mill and not have to examine it for errors at all, I trust it that much. My lathe post has a bad habit of making drills rapid into the face of the part and any type of C-Axis milling is awful. Values exceed the machine limits, rapids do not retract far enough or go to the incorrect spots on occasion, depths of cut can be wrong, etc. I have to constantly monitor the programs I output for potentially dangerous errors.

In addition, my VAR refuses to assist us at all unless we pay someone to come to our facility and customize a post from scratch. I would love to do that, but we can't really afford the ridiculous rates they want us to pay. I'm not unwilling to pay for a post that works, however, if that makes it worth someones effort to send one to me. Just send me a PM if you have one that you're confident with and we can discuss payments. I may also have to compare CWx machine setups, etc, so we can discuss that as well.

Let me know if you're interested or if anyone has anymore questions. Thanks!

Similar Threads:

• Problem- Good MasterCam post for Okuma Captain, and LB4000
• Anyone have an Okuma GENOS lathe post?
• Tool Life Management on Okuma Captain Lathe?

[acannell]

Hey everyone,

I have been using CAMWorks to program an OKUMA GENOS L300-M mill-turn lathe for a few years now and I have been dealing with a lot of flaws in the POST that I can't seem to eliminate by myself. The machine is a single turret, single spindle, 12 station VDI live tool setup, with a manual tailstock. No sub spindle, no y-axis, not really any frills.

What I am looking for is a set-it and forget-it post that is as reliable as my mill posts. I can output a simultaneous 4-axis program using 10+ tools for my mill and not have to examine it for errors at all, I trust it that much. My lathe post has a bad habit of making drills rapid into the face of the part and any type of C-Axis milling is awful. Values exceed the machine limits, rapids do not retract far enough or go to the incorrect spots on occasion, depths of cut can be wrong, etc. I have to constantly monitor the programs I output for potentially dangerous errors.

In addition, my VAR refuses to assist us at all unless we pay someone to come to our facility and customize a post from scratch. I would love to do that, but we can't really afford the ridiculous rates they want us to pay. I'm not unwilling to pay for a post that works, however, if that makes it worth someones effort to send one to me. Just send me a PM if you have one that you're confident with and we can discuss payments. I may also have to compare CWx machine setups, etc, so we can discuss that as well.

Let me know if you're interested or if anyone has anymore questions. Thanks!

Have you done any troubleshooting to identify the root cause of the various crashes? How do you know its the post and not the camworks toolpath?

[Japazo]

Have you done any troubleshooting to identify the root cause of the various crashes? How do you know its the post and not the camworks toolpath?

Well, for starters, the CWx toolpath looks correct and simulation functions as it should without showing any of the problems described. It also isn't my own neglect to recognize that the path will collide between the rapids from one operation to the next, as I have double checked that several times. I'm not claiming that the problem isn't my own and may very well be. In order to find the problem I need to start with a POST that works, otherwise I have no idea if the problem is me or the post.

Also...the fact that I can't get the post to output c-axis values between -360 and 360 is certainly not a CWx problem, but a post problem.

[acannell]

Well, for starters, the CWx toolpath looks correct and simulation functions as it should without showing any of the problems described. It also isn't my own neglect to recognize that the path will collide between the rapids from one operation to the next, as I have double checked that several times. I'm not claiming that the problem isn't my own and may very well be. In order to find the problem I need to start with a POST that works, otherwise I have no idea if the problem is me or the post.

Also...the fact that I can't get the post to output c-axis values between -360 and 360 is certainly not a CWx problem, but a post problem.

When it crashed or had some problem, did the code match what the toolpath appeared to be doing or was there some anomaly.

My favorite camworks "surprise" is that it doesnt show rapids from one toolpath to the next, so if the rapid plane is too low you get a rapid directly into the work and it wont show up anywhere in camworks. Not in the sim and not in the edit toolpath. Thats what cutviewer is for!

[Japazo]

The machines actions match the tool path, no problem there. The CWx simulation does not match the posted tool path, big problem. The machine does what its told unless the problem throws an error code, which is pretty common. Here are some examples of regular problems I run into and cannot seem to solve.

G85 roughing cycles for turning AND boring don't start where they are told to in CWx. I have to manually modify the rapid moves to the correct start point. Sometimes it is close enough to ignore, sometimes it does things like starting a boring cycle at X0 instead of at the drill bore size. Adjusting the canned cycle start position values in CWx can solve this problem, but when I tell it to do it one way I want it done that way. I don't want to have to change it to suit CWx's mood that day.

When using an "X then Z" approach for a drilling cycle, the code will output a rapid to X0. Z30. for clearance then start the drilling cycle without doing a final Z move to bring it to the face of the part. This causes the drill to want to peck through roughly 20" of air before even touching the part. Using a "direct" approach sends it to the correct position but has always seemed like an unsafe method. I shouldn't have to compromise, should I?

When posting any type of milling or drilling operation using live tooling, if the operation makes more than one revolution around the part (or subsequent operations make additional revolutions around the part) then the C-Axis values will exceed the machines allowable limit of -360 < C < 360. The values just keep climbing in one direction or the other and I have to manually adjust the values to make it run. I have spent hours trying to find the .LIB section to adjust this and can't make ANYTHING I try work.

(EDIT)
Another fun one is that during live drilling, the 'K' value always seems to be roughly (not exactly) the same depth as the hole, so the drill wants to rapid into the part then drill a little bit and retract. This obviously doesn't work when there is no clearance hole or area for the drill to rapid into. Can't seem to find the code to adjust this either, nor any Cwx settings to fix it.
(/EDIT)

These are a few of the problems. There are many more that I would like to solve. Once I have a good solid post, I want to start adding things like bar pullers/feeders, tailstock commands, etc but I don't see the point in spending the time on that when I don't know if my post is any good.

[acannell]

The machines actions match the tool path, no problem there. The CWx simulation does not match the posted tool path, big problem. The machine does what its told unless the problem throws an error code, which is pretty common. Here are some examples of regular problems I run into and cannot seem to solve.

G85 roughing cycles for turning AND boring don't start where they are told to in CWx. I have to manually modify the rapid moves to the correct start point. Sometimes it is close enough to ignore, sometimes it does things like starting a boring cycle at X0 instead of at the drill bore size. Adjusting the canned cycle start position values in CWx can solve this problem, but when I tell it to do it one way I want it done that way. I don't want to have to change it to suit CWx's mood that day.

When using an "X then Z" approach for a drilling cycle, the code will output a rapid to X0. Z30. for clearance then start the drilling cycle without doing a final Z move to bring it to the face of the part. This causes the drill to want to peck through roughly 20" of air before even touching the part. Using a "direct" approach sends it to the correct position but has always seemed like an unsafe method. I shouldn't have to compromise, should I?

When posting any type of milling or drilling operation using live tooling, if the operation makes more than one revolution around the part (or subsequent operations make additional revolutions around the part) then the C-Axis values will exceed the machines allowable limit of -360 < C < 360. The values just keep climbing in one direction or the other and I have to manually adjust the values to make it run. I have spent hours trying to find the .LIB section to adjust this and can't make ANYTHING I try work.

(EDIT)
Another fun one is that during live drilling, the 'K' value always seems to be roughly (not exactly) the same depth as the hole, so the drill wants to rapid into the part then drill a little bit and retract. This obviously doesn't work when there is no clearance hole or area for the drill to rapid into. Can't seem to find the code to adjust this either, nor any Cwx settings to fix it.
(/EDIT)

These are a few of the problems. There are many more that I would like to solve. Once I have a good solid post, I want to start adding things like bar pullers/feeders, tailstock commands, etc but I don't see the point in spending the time on that when I don't know if my post is any good.

Hmmmmmmmmm

Have you considered looking into the post yourself? If you haven't done it ever it can be intimidating, but it only took me a couple days to get the idea and end up adding the features I wanted and also making some changes that I had been wanting to do for months. It was really satisfying, as I am sure you can imagine.

Problems 1) and 2) seem reasonable to try and fix yourself. Problem 3) seems like it might be difficult, I'm not sure.

I dont know if you have done any post processor editing yet or compiling, but you might only be a few hours away from fixing your problems if you are willing to dive in. Try this:

-go into "edit toolpath" in camworks and make absolutely sure that problems 1) and 2) are not appearing as problems in camworks..

-look at the NC code and confirm that the problem is in the NC code where you expect. I.e. for problem #1, go to the offending G85 and make sure it has the wrong value (wrong start point).

-turn on the "DEBUG" option in the post processor so it tags all the NC code with the location in the post processor where it was generated. this will help you locate the "bug" in the post processor. debug option is turned on by editing two lines of code in the post processor with notepad, then recompiling and reloading your post processor in camworks. you recompile in UPG. its really easy. literally just open the post processor in UPG then go to file-compile and select the .SRC file. then reload your post processor in camworks.

-now post process again and go and look at the NC code. see what the debug tag is for the offending G85. now go hunt down that debug tag in the post processor files and see whats going on. note that not all post processor sections have debug tags so you need to go to the debug tag previous to the G85 command then follow its execution until you come to whatever outputs the actual NC code

all in all its no more complex than debugging a program written in BASIC

[Japazo]

Hmmmmmmmmm

Have you considered looking into the post yourself? If you haven't done it ever it can be intimidating, but it only took me a couple days to get the idea and end up adding the features I wanted and also making some changes that I had been wanting to do for months. It was really satisfying, as I am sure you can imagine.

Problems 1) and 2) seem reasonable to try and fix yourself. Problem 3) seems like it might be difficult, I'm not sure.

I dont know if you have done any post processor editing yet or compiling, but you might only be a few hours away from fixing your problems if you are willing to dive in. Try this:

-go into "edit toolpath" in camworks and make absolutely sure that problems 1) and 2) are not appearing as problems in camworks..

-look at the NC code and confirm that the problem is in the NC code where you expect. I.e. for problem #1, go to the offending G85 and make sure it has the wrong value (wrong start point).

-turn on the "DEBUG" option in the post processor so it tags all the NC code with the location in the post processor where it was generated. this will help you locate the "bug" in the post processor. debug option is turned on by editing two lines of code in the post processor with notepad, then recompiling and reloading your post processor in camworks. you recompile in UPG. its really easy. literally just open the post processor in UPG then go to file-compile and select the .SRC file. then reload your post processor in camworks.

-now post process again and go and look at the NC code. see what the debug tag is for the offending G85. now go hunt down that debug tag in the post processor files and see whats going on. note that not all post processor sections have debug tags so you need to go to the debug tag previous to the G85 command then follow its execution until you come to whatever outputs the actual NC code

all in all its no more complex than debugging a program written in BASIC

I started with a rather generic FANUC post for my mill and have refined it to work perfectly for the work we do. The thing that bugs me, is that the mill rapids where CWx tells it to. It feeds to where CWx tells it to, it doesn't EVER need to be manually adjusted. Literally every program I output for my lathe needs to be scanned over and edited to correct these little hiccups.

I'm pretty comfortable editing the post myself, even so far as editing the .LIB files to change the way calculations work, but if I cant find the culprit I cant fix it. The debug option works well but I don't think it is supported for the mill portion of mill-turn operations. Please correct me if I'm wrong.

When you say "edit toolpath" in CWx, what exactly do you mean and how do I get to that option? I'm not familiar with any options or GUI's with that name.

[acannell]

I started with a rather generic FANUC post for my mill and have refined it to work perfectly for the work we do. The thing that bugs me, is that the mill rapids where CWx tells it to. It feeds to where CWx tells it to, it doesn't EVER need to be manually adjusted. Literally every program I output for my lathe needs to be scanned over and edited to correct these little hiccups.

I'm pretty comfortable editing the post myself, even so far as editing the .LIB files to change the way calculations work, but if I cant find the culprit I cant fix it. The debug option works well but I don't think it is supported for the mill portion of mill-turn operations. Please correct me if I'm wrong.

When you say "edit toolpath" in CWx, what exactly do you mean and how do I get to that option? I'm not familiar with any options or GUI's with that name.

in the operations tree in CWx, if you right clock on a feature, you get an "edit toolpath" option that lets you see each step of the toolpath and make manual changes. itd be nice to confirm that there is no G85 problem there.

it should be fairly easy to locate the code in the post processor text files that actually spits out the G85 NC code. once you are there, you can work backwards and figure out where things are going wrong with the start location.

what post processor and what version of camworks are you using?

[Japazo]

in the operations tree in CWx, if you right clock on a feature, you get an "edit toolpath" option that lets you see each step of the toolpath and make manual changes. itd be nice to confirm that there is no G85 problem there.

it should be fairly easy to locate the code in the post processor text files that actually spits out the G85 NC code. once you are there, you can work backwards and figure out where things are going wrong with the start location.

what post processor and what version of camworks are you using?

I'm using CWx 2014 SP1.0. Getting ready to upgrade to 2.1, but I'll wait another week or two for someone else to find the major bugs (CWx releases are unreliable in the past few years). I'm using a post processor from a Captain lathe with the same controller as mine. The captain has some features mine doesn't, but that shouldn't affect the things we're talking about here.

I see the edit toolpath option now. You have to click on the sub feature for the given operation to see it. Using the drill rapid error as an example, CWx SHOWS that it is making a rapid move to Z.025 before drilling, but the posted tool path does not include that move. There is a definite disconnect there.

[acannell]

I'm using CWx 2014 SP1.0. Getting ready to upgrade to 2.1, but I'll wait another week or two for someone else to find the major bugs (CWx releases are unreliable in the past few years). I'm using a post processor from a Captain lathe with the same controller as mine. The captain has some features mine doesn't, but that shouldn't affect the things we're talking about here.

I see the edit toolpath option now. You have to click on the sub feature for the given operation to see it. Using the drill rapid error as an example, CWx SHOWS that it is making a rapid move to Z.025 before drilling, but the posted tool path does not include that move. There is a definite disconnect there.

I asked about the post processor because I wanted to take a look at it, but my CW is 2001 so I probably dont have it.

Thats good news about the edit toolpath. So Z0.025 is missing from the toolpath. I think you are only a few lines of code away from fixing it.

Can you open up the post processor and locate the G85 routines? It might just be a single section. Or, you might have a section something like "FIRST RAPID Z DOWN" or "RAPID Z DOWN" and such that is the culprit..

[Japazo]

I have dozens of rapid sections for different purposes. I don't know how to determine which one(s) need to be edited to get it to match CWx. Honestly, that problem is the least of my worries right now.

I'm doing a lot of mill-turn programs lately and really need to get the C-Axis values figured out. Currently, I output the code then edit each value that is over 360 or under -360 so that it falls within that range. At the end of the day, its hundreds of lines of code, and we do small batch runs of parts so its not like I get to modify the program and run it for days on end while I work on the next one. Any idea how to attack that problem, especially when I can't debug the post to see what is and isn't being called?

[acannell]

I have dozens of rapid sections for different purposes. I don't know how to determine which one(s) need to be edited to get it to match CWx. Honestly, that problem is the least of my worries right now.

I'm doing a lot of mill-turn programs lately and really need to get the C-Axis values figured out. Currently, I output the code then edit each value that is over 360 or under -360 so that it falls within that range. At the end of the day, its hundreds of lines of code, and we do small batch runs of parts so its not like I get to modify the program and run it for days on end while I work on the next one. Any idea how to attack that problem, especially when I can't debug the post to see what is and isn't being called?

just open the various post processor text files with notepad and do a search for "G85" until you find the code.

the 360 problem is more complex. i cant help you as much with that because im not familiar with it.

[hoisee]

I'm doing a lot of mill-turn programs lately and really need to get the C-Axis values figured out. Currently, I output the code then edit each value that is over 360 or under -360 so that it falls within that range. At the end of the day, its hundreds of lines of code, and we do small batch runs of parts so its not like I get to modify the program and run it for days on end while I work on the next one. Any idea how to attack that problem, especially when I can't debug the post to see what is and isn't being called?

You can try to write a macro to correct the angle if you can't fix the post at this moment. Use VBA to open a file then search and replace it with correct value.

[Japazo]

So I guess the offer still stands regarding the POST and TechDB files...

[jame5m28]

Japazo,

Under every rapid section put your own debug in,


SECTION:RAPID_FROM_TC_MILL
:C:<N> ********** RAPID_FROM_TC_MILL *********<EOL>

This will then let you see which rapids need to change,