Feature request for X9?

[Bob W.]

One thing that would be a huge time saver is the ability to keep the tool down during transforms. I have recently reworked several production programs and I was able to save a ton of time eliminating transformed operations and manually drawing in the linking geometry to keep the tool down to avoid all of the retracts and plunge moves that go on when a toolpath is patterned. That change alone reduced my cycle times by over 10% but it was a lot of work. The ability to keep the tool down and feed from one instance to the next would be fantastic.

 

By simply restructuring these programs and making the linking improvements I reduced cycle times by about 15% and these were very efficient to begin with.

[crazy^millman]

Bob, have you looked at Ref Points or Point operations when doing this type of work? I normally will program parts like you are saying with no clearance moves and then at the start of one operation that is my approach operation I have my Ref Point for approach and then at the last operation I have my ref point for my retract. Downside is yes there is no automated way in transform to control this behavior and does require the programmer to plan out operations a little more, but I have have 40 or 100 parts on the face of a tomb and only have 1 Approach and 1 Retract move per face with no problem and yes it does save time. My Rapids to depth scare most operators, but when I am programming production jobs every second counts and whatever I can do to make it fast as possible and I know id safe with my programming is well worth the effort. Small batch jobs not worth the effort production job then well worth the effort.

 

 

Been a lot of talk about Mastercam stepping up this process and maybe it will get some much needed love soon.

[slyym]

What I would like to see in a future version is when doing a dynamic toolpath, not have the reposition moves try and hug the part geometry so much. If it could just have a big sweeping type arc it would run so much smoother on lower end machines and not be so herky jerky. Know what mean. This would be on the dynamic core type paths. Not sure if dynamic area pocketing paths would benefit from this at all.What do you guys think.

[brandon b]

If I understand you correctly what your looking for is the min toolath radius box. It's under th step down box

[slyym]

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.

[Guest]

Honestly, designing tool paths for low end/low performance machines is not where I personally want them spending development time.

 

CAD/CAM programming is NEVER going to be as efficient as manual programming/editing. It's just not. A lot of it could probably come down to a healthy amount of post tweaking, buffers, etc... Honest question; Bob, you get into your post much? That may be where the solution lies. Not because of a software deficiency but because of how operations process in the post I believe is why we see the behavior we see when transforming ops.

[Bob W.]

Honestly, designing tool paths for low end/low performance machines is not where I personally want them spending development time.

 

CAD/CAM programming is NEVER going to be as efficient as manual programming/editing. It's just not. A lot of it could probably come down to a healthy amount of post tweaking, buffers, etc... Honest question; Bob, you get into your post much? That may be where the solution lies. Not because of a software deficiency but because of how operations process in the post I believe is why we see the behavior we see when transforming ops.

 

I have done a fair amount of post editing relating to probing and custom drill cycles but not much in the way of tweaking toolpath outputs. What section would I have a look at regarding operation transforms? I'm not sure how I would even approach that. I'd love some ideas because it sure is something I would implement. We haven't run that much production, and what we were running was plenty fast for what we needed. We are getting so damn busy though that we have no choice but to really nail down every production part that is running through the shop. These are cycling at a few hours so for the first few cycles we have a new and improved program ready to go until it is really nailed down. We are shrinking cycle times by as much as 40% on some of these by going over them with a fine tooth comb and looking at every aspect. Very satisfying (and rewarding) to say the least.

[crazy^millman]

We are shrinking cycle times by as much as 40% on some of these by going over them with a fine tooth comb and looking at every aspect. Very satisfying (and rewarding) to say the least.

 

Think of it as getting 80% more profit. The 40% you gain is 40% more percent of time over what you had giving you a 80% return on investment.

 

Good show and thanks for sharing that Bob. If you were in So Cal I would stop by and say hey like do other members on this board. I get up that way I would love to stop by and see the place.

[Newbeeee™]

Wow Bob - I really wouldn't have thought that a few ups and downs make that much difference.

You've got me thinking now...

 

Ron - great approach by using ref points with no clearance. Again I wouldn't have even considered that.

 

[crazy^millman]

Ron - great approach by using ref points with no clearance. Again I wouldn't have even considered that.

 

 

Cannot take full credit for that one. Gcode, Foghorn and a couple other people taught me that one.

 

[Guest]

@ Bob, I'm thinking that Ron's idea will be WAY easier. I've been going through the null tool change section and it might be an 8 or 9 on a 1 to 10 difficulty scale.

 

It won't get you 100% what you're after, but it'll get you at least 50% there. I don't think anything short of buffering the hell out of the null toolchange section will get you any closer than 75%.

[Mick]

I have to admit, as Foghorn pointed out, I've gained the most efficiency in manually editing unnecessary moves. Once edited, I put it through Vericut, and check the time difference between the old and new.

 

I worked on several big parts/programmes on a FMS and used the posted code to get the base programme created, and proven. Then, working through it I noted the areas to tweak between transforms/transitions. I saved a huge amount of time.

 

If there were any design revisions, it was a case of posting out the revised blocks and merging them in, as the transitions were unaltered. Vericut is a handy tool there

 

I do like the idea of those reference points though. Certainly seems like some major post editing though.

[crazy^millman]

I do like the idea of those reference points though. Certainly seems like some major post editing though.

 

Not really once you understand how and why you are using them pretty much easy. Give it a shot you might be surprised how this little trick will save you reasonable amount of time and give you predicable results time and time again.

[Mick]

Not really once you understand how and why you are using them pretty much easy. Give it a shot you might be surprised how this little trick will save you reasonable amount of time and give you predicable results time and time again.

 

Thanks Ron, I will check it out

[Jeremy Herron@DBS Solutions™]

I have used Ron's method and the post handling of null changes method. Both work well. If some of the logic is not already in your post it might be a bit of bear to add though.

[Bob W.]

I played around with Ron's suggestion yesterday and it seemed to work pretty well. In the actual operation I set all depths (top of stock, feed plane, etc...) to the same value as the final cut depth (no depth cuts needed) and created point toolpaths before and after the transform. The machine would rapid to the first point toolpath (located at my desired clearance plane location), then proceed to do the transform which would rapid at full depth to the next instance, then rapid to the final point which is at a height where I would want my clearance plane. This seemed to work pretty well for the parts I am currently running since the transform is in the Y direction only and the transform is clear when doing the rapid moves. Does this sound about right? Am I missing anything?

[gcode]

have you tried using Reference points to replace the point tool paths

[Bob W.]

have you tried using Reference points to replace the point tool paths

 

Not sure how to do that. Is there an input to use the reference points in transform operation? If they are used in the individual toolpaths the tool will want to go to them in every transformed instance, correct?

[gcode]

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

[CJep]

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.

 

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.

[Newbeeee™]

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

For our vice on a 4th axis (poor man's hori) set-up, we program A0 as per normal with clearance set at 25mm and retracts set at 10mm. Then for an index move, we'll add a ref point retract of Z150 for the index. This works real well.

But I'm amazed at the time difference Bob saw and you guys program 'as standard' to get efficient paths. With high acc/dec and rapids on macines, I really didn't think it would make that much difference.

I think we may be lowering our clearance and retracts to 5mm going forward as a new standard...

[crazy^millman]

have you tried using Reference points to replace the point tool paths

 

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.

[djstedman]

Wow.. just wow.. I get stuck using transforms all the time for rotational patterns and this is awesome..

 

Thanks for the amazing heads up .. been wanting to do this for years.. !! Reference points FTW!

[Thee Rickster ™]

This sounds like a great tip for my production CNC shop.

Any chance there is a video for using reference points i

could send to them?

[Bob W.]

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.

 

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?