Feature request for X9?

[Bob W.]

FWIW, the biggest time savings I see on most of my programs is related to plunge rates and feed plane heights. It is amazing how much time can be saved by dropping the feed planes as much as possible and maximizing the plunge rates. The other area is continuously pushing the tool feeds and speeds until they begin to fail. It is amazing how hard and how far some of these tools can be pushed and still last a long time before failure. We continuously increase speeds, feeds and depth cuts and watch closely how the machine, tools, and tolerances react and this time spent is worth its weight in gold.

[BenK]

I typical use one at the beginning and end of a group of tool paths,

the intent being to keep the tool down at an efficient rapid plane, then use a reference point

to force the z to a safe plane for the transform motion

 

This is how I do it. Works really well.

[crazy^millman]

Right, but do reference points give any control of what goes on before and after the transform toolpath, or just what goes on before and after the transformed operation? For example, if I have a transformed contour toolpath (operation 2) that uses tool 4, and the operations before and after this toolpath (ops 1 and 3) use tool 4, I can't just set my clearance planes for the transformed operation to the final depth so the rapids are at full depth because I will get burned on the transition from op1 to op2, and op2 to op3. If I set reference points it will want to go to them at each instance of the transformed op, correct? In my experience the real time savings occurs by eliminating ALL vertical movement between instances so there is no acceleration/ deceleration, settling time, etc... The tool just stays down the whole time except at the beginning and end of the transform. Can this be done with reference points? If so, how?

 

In this process you have two options.

 

Option #1 The point toolpath where you have back plotted your toolpath to know exactly where the operation you are programming is starting. Then one the last operation same thing back plotted to know where it ends. Then use those to make the correct start and end point toolpaths from. I like this method since if I have 100 parts on the face I make one change and all 100 get changed.

 

Option #2 A start operation by itself using the ref point for approach and an end operation by itself with the ref point to retract. More work and thinking for the programmer, but you can make it work. This method may required 3 or 4 operations, but you do keep it to operations that mean something and do not require back plotting and such. Really comes down to how anal you are with your code. Me and Foghorn had this discussion Saturday. Hand coded stuff can really be dialed down to a level just very hard to do with CAM. It can be done, but are you just better off old schooling it getting into the trenches and going from there?

[Bob W.]

I guess what I am envisioning is the ability to control linking in the transform operation itself, much like the convert to 5-axis toolpath. That toolpath gives the programmer the ability to ignore the original toolpath's linking parameters and have the linking driven by the new 5-axis toolpath. This functionality in the transform toolpath would be very handy and give the programmer a ton of control. It looks like with the current capabilities one can get 90% there but it involves a bit more work to do so.

[Bob W.]

In this process you have two options.

 

Option #1 The point toolpath where you have back plotted your toolpath to know exactly where the operation you are programming is starting. Then one the last operation same thing back plotted to know where it ends. Then use those to make the correct start and end point toolpaths from. I like this method since if I have 100 parts on the face I make one change and all 100 get changed.

 

Option #2 A start operation by itself using the ref point for approach and an end operation by itself with the ref point to retract. More work and thinking for the programmer, but you can make it work. This method may required 3 or 4 operations, but you do keep it to operations that mean something and do not require back plotting and such. Really comes down to how anal you are with your code.

 

Option 1 is what I plan to implement as it will be easier to follow.

 

Hand coded stuff can really be dialed down to a level just very hard to do with CAM. It can be done, but are you just better off old schooling it getting into the trenches and going from there?

 

There have been instances where I drew in the entire toolpath for 3D contours and the results were fantastic. It took a long time but well worth the effort. I am really weak in the G-code/ hand coding area so I have never done anything along those lines. Heck, I still re-post for even the smallest changes, like turning off wear comp in the machine.

[Guest]

Heck, I still re-post for even the smallest changes, like turning off wear comp in the machine.

Bob, that is NOT a bad habit at all. It ensures you have the most up to date data in your CAM file and there iis NOTHING wrong with that. I do the same FWIW. The exceptions would be iif I'm changing speeds/feeds, I'll make note of the change on the machine, then go back to the CAM and update it. I'm downright religious about it. I don't even keep g-code programs laying around. No needs when the CAM file is up to date.

 

 

[Mick]

Bob, that is NOT a bad habit at all. It ensures you have the most up to date data in your CAM file and there iis NOTHING wrong with that. I do the same FWIW. The exceptions would be iif I'm changing speeds/feeds, I'll make note of the change on the machine, then go back to the CAM and update it. I'm downright religious about it. I don't even keep g-code programs laying around. No needs when the CAM file is up to date.

 

 

 

+1000 to that

[Newbeeee™]

Bob, that is NOT a bad habit at all. It ensures you have the most up to date data in your CAM file and there iis NOTHING wrong with that. I do the same FWIW. The exceptions would be iif I'm changing speeds/feeds, I'll make note of the change on the machine, then go back to the CAM and update it. I'm downright religious about it. I don't even keep g-code programs laying around. No needs when the CAM file is up to date.

 

 

1000% agree on keeping the mcam file upto date. But I'd have a proven program separate in the part folder.

And then when the job repeats, I'd use the proven program.

Rightly or wrongly I'd never post and run every time.

[guitar]

X9? lol. No hope for X8, huh?

[Guest]

X9? lol. No hope for X8, huh?

Considering that X8 is in the Public Beta cycle now, I just have to at you for even suggesting X8. You know even less than we feared.

[gcode]

X8 is in public beta.

there will be no more new features

[guitar]

Considering that X8 is in the Public Beta cycle now, I just have to at you for even suggesting X8. You know even less than we feared.

 

Yeah, fixing the mastercam bugs we have been working around since the stone age is laughable. Maybe we should be discussing X18.

[crazy^millman]

Yeah, fixing the mastercam bugs we have been working around since the stone age is laughable. Maybe we should be discussing X18.

 

Wow one year is the stone age now that is down right funny. Like I said how about growing up and it will go a long way to help someone take you with some grain of salt. Right now I cannot take anything you say serious.

 

I don't know about the rest of you but I smell Joan all over this name.

[reidmachine]

Wow one year is the stone age now that is down right funny. Like I said how about growing up and it will go a long way to help someone take you with some grain of salt. Right now I cannot take anything you say serious.

 

I don't know about the rest of you but I smell Joan all over this name.

Quite possibly a recreated, duplicated, redundant copy of a certain troll, but the troll started at X2!

 

 

 

Bob, I use the "reference point" almost exclusively, I simply use it at the last operation before I know I will rotate the 4th ax, thus keeping all of the ops for each part down in the cut as close as possible, including using incremental retract and feed planes to keep it even closer.

I have saved a ton of time doing it this way.

[Peter - Avivi CNC Solutions]

Yeah, fixing the mastercam bugs we have been working around since the stone age is laughable. Maybe we should be discussing X18.

 

Yeah, hopefully we don't have to wait so much. But bugs are happens, we are humans. Right?

 

 

[OffTopic]

 

Now I can compete against 97% of you. Lathes, 5 axis mills, multi-tasking lathes, post processors.

 

1, I never OFF topics

2, I never feed trolls

3, You looks smart, which is good, we need this kind of guys like you

4, Houston, we have a problem... Out there: http://www.emasterca...-g13-parameter/

5, Since you dealig with MP, I just curious about your thoughts and comments there.

6, My dude over there begs for a good solution, except CustomDrill Cycles.

7, I just wanna redirect you to there and I hope that 3% is not a big deal

 

[OnTopic]

[Peter - Avivi CNC Solutions]

Bob this what I was referring to than the point toolpaths. Like Gcode said you click on the ref points in the operation set them and go from there. Give it a shot will be surprised how easy it is to control things and get good controllable code.

 

Hmm, after many (many!) things, I feel it's time to dig and play a bit with RefPoints!

THX for mention it!

[Guest]

 

 

Yeah, fixing the mastercam bugs we have been working around since the stone age is laughable. Maybe we should be discussing X18.

The OP called for a FEAURE REQUEST, not bug fix. Reading is fundamental.

[Newbeeee™]

ROR at the editing of Geee-taaaaaaaaaarrrr's name.

[Mick]

ROR at the editing of Geee-taaaaaaaaaarrrr's name.

 

97%... LOL

[K2csq7]

I'm talking about when the toolpath wants to reposition to say the other side of a part it wants to hug the geometry and produces a lot of small lines and arcs that slow down some machines. If it could just make a big arc around the part that might even be just 1 G03 line of code. I guess this is what the vertical retract kinda does now.

 

^^^This!!

 

 

The hesitation in your moves has more to do with acceleration clearances. If you want the tool to stay down in the material in the 2D hspeed tpaths set the retract conditions to never. If you don't want micro lifts set it to zero. If the machine doesn't like repositioning in the cut at 500ipm slow the back feed rate down.

 

You are missing his point.... IMO this is huge.

if your part is shaped like an S, the backfeed move will follow the S, most of the time this is completely unnecessary. Weather you have an old machine or a new one, this is wear and tear on the machine and massive amounts of wasted cycle time...... and hand editing those moves is out of the question.

[CJep]

Well instead of "hugging" the geom I would let it do a retract and then it will reposition using the shortest move.

The reposition moves don't need to be output as G00 rapid, they could be left in G01,2,3 but kick the feed rate up to the highest feed of the machine if the distance will allow it.

With the older machines there also tends to be a lag when shifting from G01,2,3 to G00 and back to G01,2,3 by staying in a feed condition instead of switching to rapid will help to smooth out the movement as well.

 

You are missing his point.... IMO this is huge.

 

Kev, I'm not saying you have to program the way I do, I was just offering up a splaniation,....

 

$0.02

[Joe788]

I must be missing something. Bob, can you post a screenshot of the kind of retract/approach moves you're trying to get/remove?

[Bob W.]

I must be missing something. Bob, can you post a screenshot of the kind of retract/approach moves you're trying to get/remove?

 

They are the retract and plunge moves between instances when a toolpath is transformed. When a contour toolpath is transformed the cutter makes the cut, retracts and moves to the next instances, plunges and makes the next cut. It is these retract and plunge moves I would like to eliminate so the tool stays down during the entire transformed operation if it is possible to do so.

[crazy^millman]

They are the retract and plunge moves between instances when a toolpath is transformed. When a contour toolpath is transformed the cutter makes the cut, retracts and moves to the next instances, plunges and makes the next cut. It is these retract and plunge moves I would like to eliminate so the tool stays down during the entire transformed operation if it is possible to do so.

 

Not when you do not use retract and clearance moves.Set your retract and feed depth the same if it does not need to move up from part to part and you will not get them. Then like it was mentioned earlier use a point toolpath to start and a point toolpath to end and you will get what you are looking for.

 

HTH

[Joe788]

They are the retract and plunge moves between instances when a toolpath is transformed. When a contour toolpath is transformed the cutter makes the cut, retracts and moves to the next instances, plunges and makes the next cut. It is these retract and plunge moves I would like to eliminate so the tool stays down during the entire transformed operation if it is possible to do so.

 

Are you cutting along the side of the parts or something? You can leave the clearance box unchecked, set your feed plane to a negative number, etc. How large are these retracts and plunges you're getting?