New Property: Feed Rate Factor [Canceled]

[freman]

I see a definite need for this and maybe Russ' introduction about damaged tools was humorous but a bit of a distraction.

I don't see a hobbyist or damaged tools being a necessary part of the problem. There are parts of any pocket op which will end up cutting with 100% tool width. This will require a different feed rate to that which is suitable for say 50% over step.

I have been working mainly on ali recently and there have been several cases where none too aggressive feed/speed setting ends up clogging the tool due to over-heating when cutting a full tool width segment. Not only is there more load on the tool but chip removal is a lot less efficient.

Conceptually, I agree with Slip's idea that this could be treated as a dress-up, except that a dress-up has a lot less information to detect where this is needed since it only has the path to go from, none of the geometry of the model. [ We won't even go into the bat-crazy, piecemeal, to-and-fro paths that are created sometimes and how even a really cleverly designed dress-up is supposed to detect when this is cutting full width or not. ]

It seems to me that from a problem solving point of view, this has to be dealt with from within a path tool, unless someone can explain conceptually how a dress-up could do this with the limited information contained within the Gcode of a path.

[GeneFC]

This discussion has mutated from a convenient method to change the feedrate for an operation to some sort of 3-D adaptive path capability. That may be useful in some cases, but it is enormously more complex than the original proposal and draft PR.

Gene

[freman]

This discussion has mutated from a convenient method to change the feedrate for an operation to some sort of 3-D adaptive path capability. That may be useful in some cases, but it is enormously more complex than the original proposal and draft PR.

Gene

You are correct.

we need to slow the rate for the profile operations that engage material at 100% tool diameter

I had read that to be the main objective and that applies to parts of an operation, as Chrisb said he has a manual button to do this. I had not understood this initial PR was just to provide a reduced for ALL of one operation at at slower speed. That does not seem that useful, since I would just dupe the TC.

However, misunderstood use most seem to be discussing would be very cool, if it can be done.

[memfis]

In favor of the argument about the correctness of the logic proposed by (me) - everyone has long agreed that when processing a plane or a pocket it is necessary to provide a separately specified finish passage? = yes, and it is implemented. So why do you refuse this possibility for a path along the contour?

Or the same pocket - here we do a pocket, leave on finishing passage 0.1mm. But agree to cut 100 layers with a step of 3 mm and overlap (step over) 1-5% (main pass) + one final pass with an overlap of 75% and twice the feed is much faster (and most likely better) than the same 100 passes with a step of 3 and overlap 50% (yes, I would suggest for the final pass to set a separate feed rate and overlap percentage).

Moreover, I would suggest to set the depth step for the whole job (by default) not as a property of the whole job (= diameter of the tool), but as a property of a particular tool in the job.

[freman]

So why do you refuse this possibility for a path along the contour?

Because no one suggested that, so how can I "refuse" it?

You are taking a trivial example and presuming it is generally valid.

ZigzagOffset does a contour ( but not always first ) . Zigzag not at all so there is an initial full width cut. Try a mill facing op on an elliptical shape and it will jump all over the shop according to some unfathomable algorithm. Good luck on working out what part(s) of that will be full width cut.

The only solution I can see at the moment is creating a second 3D model which has paths designed to mimic the full width parts and pre-cut them with different parameters, or down grade the entire process to safe speeds for the heavier cut sections.

2.5D ops are even more challenged since they have no awareness of the 3D model ( what is air and stock ) just a wire frame to work from. This causes other limitation in those path ops.

3D ops are the only one which have the potential to add this feature in their current form, though I would suggest that getting correct and predictable cutting convention is probably more important.

[geant]

Bring it back!
Why shouldnt I be able to do what my machine controller does MANUALLY (like chris i think said)? Que verdad!
Now, I babysit some jobs and do this manually.
If you have no use for such factor, dont use it, and leave at default: 1.0.
Conceptually, it sounds very useful; practically, I would like to see an example of how/where it would be implemented before I could put such a useful sounding feature to death!

Long live the Russ!!!

BTW: I have dozens and dozens of mills, but change mill speeds and depths many more times than time-costly, dialing-in, indicating, and then proceeding with making chips.

[sliptonic]

I recognize that there is an unmet need being expressed here. I'm certainly not opposed to adding a feature but I don't like this particular implementation. (no offense to 'The Russ' who is indeed a rock-star )

In Path you control tool feed/speed through tool controllers. Both spindle speed and feed rate are always expressed as absolute values. But this feature puts part of feed /speed control into some operations and expresses it as a percent of a value set elsewhere. That is confusing and not path-like.

I just think this is important enough to do right. We should look for a better way of meeting this need.

[freman]

Can we be clear about what feature is being discussed. It seem like Russ' original patch did one thing but the need to slow down certain parts of a path is another.

Today I was cutting a part and as often happens a pocket starts with a straight cut using the full tool width. It was shaky , squealed and I would not have wanted to push it any faster. However for the other 95% of the same path operation, I could have been cutting a fair bit quicker since I was using 25% overlap.

This slowed down the whole job a lot.

Now I see this need to speed change to be part of the path since the path knows what segment will be cutting full width. This is not a function of the tool controller unless you are going provide a secondary speed there and let the path tool decide when to use it. However since this ratio would depend upon parameters of the path object ( like overlap ) to determine what ratio to use, it does not seem to be an abstract tool parameter which will be the same for any path using that tool and thus belonging in the TC.

There may be other factors I'm over looking but it seems more pathy than tooly to me.

[sliptonic]

...the need to slow down certain parts of a path is another.

I'm not going to claim to be an expert but based on my understanding this is a red herring. It's a hack. Simply slowing the feed rate, especially as a ratio of the existing feed rate is missing the point. Feed rate, spindle speed, and cutter geometry combine to produce a certain chip load. Too much chip load and you break the cutter. Too little and you create heat and either burn the material or ruin the tool.

Of course it gets more complicated because Depth-of-cut, Width-of-cut, machine horsepower, material type also play a role. And honestly we're just getting started. There are more factors than that.

Now I see this need to speed change to be part of the path since the path knows what segment will be cutting full width.

That's my point. Slowing down is one strategy but so is speeding up the spindle or taking shallower step-downs. Just adding one override value to the operation is putting a bandaid on a much more complicated problem.

This is not a function of the tool controller unless you are going provide a secondary speed there and let the path tool decide when to use it.

That's a possibility. Certain operations could, for example, implement a finishing pass that uses a different TC.

However since this ratio would depend upon parameters of the path object ( like overlap ) to determine what ratio to use, it does not seem to be an abstract tool parameter which will be the same for any path using that tool and thus belonging in the TC.

I don't understand why this keeps coming back to a ratio of the existing feed rate. Stop narrowing this down to feed rate and start talking about chip load. Also, there's a BIG difference between a tool and a tool controller.

[freman]

I don't understand why this keeps coming back to a ratio of the existing feed rate. Stop narrowing this down to feed rate and start talking about chip load. Also, there's a BIG difference between a tool and a tool controller.

I agree that feed rate is just one of the ways to adjust chip load and that is ultimately what it's all about but I rather have one way of adjusting it than none

I think I was using TC appropriately, not mixing the two. I certainly aimed to.

There may be more general, multi-parameter ways of handling this and it may be a good idea to explore it in full even if a single ratio solution is adopted, it would then be a subset of a more general solution which would enable smoother augmentation of such a function in the future than an ad hoc tweak.

So, yes, this would better be expressed in terms of chip load and a parameter of feedrate would be one easily accessible means to that end.

There is real need for something so mapping out a general approach and implementing at least one simple-to-program solution would be a good way to go.

Spindle speed is accessible programmatically on my machine but a lot of simple home routers/mills don't have that.

Halving the depth and repeating the cut would be another approach but it's less flexible than feedrate. I would certainly prefer a binary option to halve the depth and double cut than the current inflexible but inadequate solution.

I had almost a full day of machine time today, that was more than twice what it should have been because of a few, yet to be optimised features wasting huge amounts of machine time.

Just for the record, two of the main other factors are tool ups happening at cutting speed, not rapids and 3Dsurface repeat cutting the same bit of surface on successive passes.

I'm aware 3D is new and honestly, it's already amazing, so I'm not moaning just noting areas where things can improve.