New Property: Feed Rate Factor [Canceled]

[Russ4262]

I closed the PR.

Thanks to everyone for the feedback. I appreciate the time and perspectives.

With one hand over the E-Stop,
Russ

[memfis]

I am for the proposed parameter and that's why - this version is more convenient (and even better - so that you can set the changed speed at some last passes in pcs or mm).


Competing approach - a task of the tool with its own feed settings. But when generating the final file of the program in this case, the code of tool change will be called - the machine will process it and wait for the operator to act. And this = redundant. So, the variant of changing the feed of the same tool is more advantageous.

[chrisb]

I don't think the proposal was meant for individual speeds of single step downs.

In general I'm against putting everything for which a sensible usecase exists into the operations. That would make the operations too complicated.

There is always the possibility to add things afterwards, with a dressup or an individual macro.

[RatonLaveur]

Even professional CAM (Siemens NX, HyperMill...) generally will be implemented in a company's operations by a retailer or the company itself. Money, time, emails and meetings will be spent to adapt it to special operations and their peculiarities (such as the case presented in this thread). In general everything occurs in the Post-processing or with a custom macro as Chrisb suggests.
Very rarely will the feature be back propagated to the generic core.

[chrisb]

Another possibility to place such a factor could be an additional argument to the postprocessor.

[memfis]

no, no and no. It's been a month (or two?) of almost daily use of two different tools (one real tool with two different feed values). And this is a bad solution - in the version that I proposed (earlier), the logic was like this - here is an operation, in it you can clearly specify a step in depth and feed rate in a separate field for the last 1 or 2 passes. Using instead two different tools (competing logic) is worse - the fact that this approach automatically creates the rise and fall of the tool. In my case (woodworking at rather high speeds and loads), there is always a deflection (bending) of the cutter (under load) and there is always a trail when lifting and lowering. There is little or no trace of the final lift - the cutter is gradually straightened in the finishing passes (up to 0.4). As a result, I have to find a piece of code with the Lift/Down and remove it in the ready code.

[sliptonic]

Is the issue that the tool change code is being inserted even if no actual tool change is occurring?

It should be easy to fix the post-processor to suppress those unnecessary moves.

[RatonLaveur]

no, no and no.

Yes,

In my case (woodworking at rather high speeds and loads), there is always a deflection (bending) of the cutter (under load) and there is always a trail when lifting and lowering.

So...in the specific case of woodworking. That sounds like a specific post-processor to me when considering a generic CAM package like FreeCAD Path.

As a result, I have to find a piece of code with the Lift/Down and remove it in the ready code.

So, you would like a finishing operation to be seamlessly integrated into your cutting/pocketing that uses different feedrate. Thats another tool controller. In your specific case of woodworking you do not want retracts, lift-ups and frog-leaps to happen, that's a specific post-processor.

I would love to have half feedrate in all my rounded corners using a water jet cutter, but that's specific to my application and i would not necessarily ask for a modified function of freecad.

Please bear in mind i am not denigrating your request, but simply offering that there is another way than changing the core functionality of Path. Perhaps someone from metal milling could chip (heheh) in? There may be a more broad reaching interest here that would warrant further GUI functionalities. But I do not see it personally.

To other more versed people: is there here a subtlety i am missing that would be difficult to amend via post-processing?

[chrisb]

Placing such a factor in the postprocessor would reflect that the same object could be milled on different machines at different speeds.

[memfis]

Is the issue that the tool change code is being inserted even if no actual tool change is occurring?

It should be easy to fix the post-processor to suppress those unnecessary moves.

The postprocessor has nothing to do with this, there is no tool change - I made (for example) the tool "cutter 3.175 feed 5000" and the tool "cutter 3.174 feed 2000". Yes, and the code I "take out" not making a conclusion in the file (where the postprocessor already plays), and from the window View the code (because still need to be corrected later in the editor).