Tool Override Home Position - Turning

[Steinwerks]

The single Home Position in Turning is too limiting. We frequently have three turning tools, an insert drill, a boring bar, etc. in the turret, and prefer a 10" retract from the face to change tools to the insert drills (which are up to 5" long), but only a 1" retract to change to the finish turning tool from the rougher.

Instead of the "Go home" options currently I'd like to see a Home Override checkbox and distance field so a finishing tool can retract to 10" on "Go Home at End" before calling the insert drill and the Setup can have a standard Home position of 1" (or whatever is preferred) for the turning tools and cutoff.

[cj.abraham]

@Lonnie.Cady To tell you the truth, it's still in the backlog. CAM-2871.

[Lonnie.Cady]

@Steinwerks you can modify the post to break up the X and Z for the initial movement.  I have done this in the past.  This helps add some safety.  Especially when changing from a stick tool to a long drill.  To be honest it has been so long since I tried it, they may have already added it to the standard post.  If not shame on them as it is dangerous.

I also found it use full for making sure z moved to just off then end of the part after drilling and inserting the tailstock so it would not cause a collision with tailstock positioning on small diameters.

Are you using the G53 home position available from the post dialog for the z axis?   It can be handy but since it is positioning from the machine coordinate system it can still cause issues when an operator uses tooling from a previous job that is longer than you anticipate or uses tall soft jaws so the part is in a different location.  I have been contemplating make that a macro variable and allow the operator to edit it once in the top of the program after he has established a good tool change position for their current setup.  That macro variable would be used in all future tool changes.

[Rob.Lockwood]

I don't see this as something that can be effectively implemented through post. I can see a temporary solution being viable in post processor, and generally nothing is more permanent than a temporary solution 🙂

As @Lonnie.Cady mentions, I did provide some screenshots of how NX handles this, or a Screencast or something. It effectively works by having a default solution defined as part of the job, but allowing you to override home position/start/retract etc, both the strategy and the position. I'll try to jump in there and post it again, as it's fairly elegant. I still think this is only half of the solution, and that the reason theirs is generally effective is because it's also tied to reliable machine simulation that can include the turret and it's tools, etc.

[Lonnie.Cady]

@Rob.Lockwood

" generally nothing is more permanent than a temporary solution :)"

got to remember this one.

[Rob.Lockwood]

[cj.abraham]

@Rob.Lockwood Given the two examples tool change steps in my previous post, and also that the automated selection between the two modes worked correctly when going from a short->long or long->short tool, in what scenarios would you override the machine motion to one of the modes in that drop down?

Also, are you referring to the approach from the home position onto the part, or from the tool change position to the home position?

[Rob.Lockwood]

@cj.abraham stay with me, i'm having one of those days where coffee just doesn't seem to be doing the trick, so the snark is real..

The two primary issues I see with fixing it in the post are..

• You'll fix it in the Haas post, and every non-Haas user gets to go pound sand
• You and I won't find that scenario, a (pissed off) user with a crashed machine will

All of this is about workflows, handling risky situations via a conglomeration between manual-NC and post modifications is just sub-par.

The same logic that applies here also solves the classic 'transitioning between work-offsets without returning to clearance' issue in milling; the one that's always been "handled" via an assumed-risk user post modification, only it's ACTUALLY safe.. so can kind of kill two birds.

[cj.abraham]

The reason I suggested using manual NC to select the tool change Z position is that I can give @Steinwerks a solution today that would do, from a programming standpoint and in the context of this idea, exactly the same thing as having a manual tool position in the operation that would be not delivered today (likely for a while). It doesn't matter if the Z position is chosen in a manual NC operation or a field in the operation...the chance for a crash is the same and totally depends on the user.

So this wouldn't be "fixing" the Haas post, this would be "I can give you a solution to the title of this idea station post in the next hour."

That's a separate idea from what I'm suggesting for automating the selection of the Z position, which I have some ideas that would hopefully remove the chance, as you said, for a machine crash.

[Lonnie.Cady]

"The trick is deciding which method to use, which would be nice to automate. In order to automate it, the post needs to know which tool is longer. If it can be automated, you get the shortest safe Z retract for a tool change without having to think about it."

You are relying on the post to determine which method should be used. 

1. People don't always set up the tool length correctly for boring bars.

2. Boring bar lengths are adjustable and will need several lengths setup in library to send the right length to post so it can make the correct decision.

3. When it does not work people are not going to be thinking they need to adjust a tool length, they will be looking in the operation settings.

4. You again create rules to automate, no one knows all possible situations.  Look at leads for example.  Internal rules violate the very settings a programmer chooses.

5. Handling it in the post will not simulate correctly.  Showing some one thing in simulation then providing them something different in code is not a good practice.

[Rob.Lockwood]

@cj.abraham - I'll just say, I first "solved" this problem working on my citizen post something like 4 years ago, and I've "solved" it a few other times since then, each for individual applications in post processors that required slightly different "solutions." I'm not alone in this, i'm sure @Lonnie.Cady has come up with some "solution" and @Steinwerks likely has one as well, along with other users.

And that's why the Idea-station exists; not because an individual users needs a solution today, but because individual users solving software shortcomings on their own does nothing to better the software. It's simply a bad policy to approach the Idea-station from a place of solving an individual users' daily struggles, even knowing your intentions are probably coming from the best place in the world..

Rather, it's a suggestion that there is a shortcoming, and you guys should look at figuring out the best way to solve the issue.. To which i'd add, if your suggestion is that the best way to solve this issue is through automation within the post processor, I disagree.

[cj.abraham]

I concede that my idea was not well received.

[al.whatmough]

@Steinwerks @Rob.Lockwood @Lonnie.Cady @cj.abraham

Thank you all for engaging in an open and healthy conversation about this.

At @cj.abraham it is good to see you growing as a true Product Manager, taking the time to listen to the customer and adjust your understanding of the issue based on the customer's feedback.

I am sure you all agree, open conversations like this are the value of the idea station.  It is good as users you continue to push us, keep us honest and challenge us.  

Together, we are creating a great tool!

[Anonymous]

I'm new to this forum so I'm not sure if I'm allowed to do this, but I'm wondering if this issue has been fixed. 

I'm having the same psychological discomfort as the other commentors when attempting to solve this issue in post processing. My logic for believing this is as follows:

- I would like to be able to visualize the "safe" position that the tool retracts to

- I think that the whereabouts of my tools is something that I would like to have direct and explicit control over. This control does not need to be complicated, it just needs to be clearly understood and then defined by the user.

- I would like to be able to set a distance that forms a sort of "home" where tool changes can take place that is not the machine zero. The turret and carriage weigh nearly 500lbs, so it is extremely illogical to employ a 15HP motor to G28 U0 every time I want to make a tool change, then G0 back to the stock just for safety's sake. This is an enormous waste of time and power, and causes unnecessary wear on all of the equipment involved, so it seems reasonable that there should be some clear and explicit way to establish something like a tool change plane that can be verified by the user to be safe.  

Thanks

[al.whatmough]

I am asked Akash to weight in on this.  Akash is a name you will start to hear more and more as he has recently appointed product Owner of Turning in HSM.  Akash has been leading the PartMaker development team for years and comes to our group with a talented development team that has a rich history in developing turning solutions.  

[akash.kamoolkar]

Hello folks,

My name is Akash Kamoolkar and I'm the new Turning Product owner for Fusion/HSM. Well, new as in a few months old now, but I'm just getting to know my way around the forums so please bear with me. Anyways, down to business.

We are already currently reviewing and discussing a number of enhancements for the home position including the following:

1.> The ability to override the default setup home position with a local home position parameter explicitly set in each operation

2.> Add an X coordinate to the home position

3.> The ability to optionally begin / end the operation at the Z / X / both coordinates of the home position

4.> The ability to parametrically link the home position location to the stock / model limits to ensure associativity

We realize this is a big issue for turning and especially for multi-axis Swiss lathes and we plan to start working on these enhancements soon.

[angelo.juras]

Thanks for the introduction @akash.kamoolkar

Like Akash, I've been tasked with being the new Product Manager for Turning. I will be working with Akash to identify and prioritize current issues, product enhancements and adding new functionality. This information will be passed on to our developers.

I have been on the phone recently with @Lonnie.Cady and @LibertyMachine hearing about frustrations and issues with our product.

We look forward to hearing from the machining community to hear how we can make your machining experience better.

[Steinwerks]

@al.whatmough @akash.kamoolkar @angelo.juras

I'm glad to see this coming up again, as although I realize I have not been on the forums much lately (very busy and haven't even had much dedicated programming time compared to production time on the floor) I still think it's vitally important. Important enough that I've been given permission to log time at home to solve our post issues with turning (and incorporating 2-axis polar interpolation milling - something else I'd like to see addressed but that's for another post/idea).

I still contend that an override position would be optimal to address vastly different tool lengths while also allowing for flexibility in specific use-cases that perhaps only the shop or programmer knows.

[Anonymous]

@al.whatmough @akash.kamoolkar @angelo.juras @Steinwerks @Lonnie.Cady @LibertyMachine

Glad we're on the same page. 

@akash.kamoolkar the list you provided has some great ideas and shows recognition of some of the biggest issues. From those, I think that the ability to define a local home position explicitly in each operation is greatly desirable, as is the ability to begin the operation at the local home. This would save machine time and power, in addition to having more direct control over the actual process. The parametric linking of the home position to the stock or model is extremely important for the specific job that has made me aware of these issues, so that would also be an absolute necessity for associativity.

Beyond those, my machine operators and myself have come up with some options we feel would belong on some sort of "Beginning and End of Tool" tab that would come after the "linking" tab for each turning operation. These options would allow for more manual control over the setup of the tools and their operating parameters:

We would like to see the ability to choose a predefined home to rapid to and from, as well as the option to override this home choice and choose an arbitrary, but user-defined x and z coordinate to rapid to and from before and after cutting.

We would then like to see an option to turn coolant off and on both before and after the operation begins and ends. Currently, I am finding that in some operations an M6 is called at the beginning and no corresponding M7 is called at the end of the operation, which means that a 5hp motor is blasting coolant at 500psi after the machine has stopped for the operator to inspect progress, which I'm sure you can imagine is less than ideal. More control over this would be nice. 

We would also like to see the option to choose what sort of stop is written to the machine after the operation finishes: none, an M1, or an M0. There should also probably be the option to select a spindle stop as well. 

The following option would not affect myself or other users of newer lathes, but on older lathes, tool offsets often have to be cleared prior to beginning a new operation, so something to the effect of a "cancel offset" selection of yes or no that would either include or leave off a T1000 would likely be useful for other users.

A combination of these features and whatever refinements or additions other users have to make would be greatly appreciated. 

[angelo.juras]

@Anonymous - I just had a conversation with @akash.kamoolkar and we are already looking at adding home position overrides for each operation.

The other issues you suggested with regard to when 'M' codes are called and tool offset cancellation can be controlled via your post.

Please send us your current post, current code output, along with a 'marked up' version on how you'd like your code to look, and we can pass that onto our post team.