By therookie
Option to "Lock" Parameters, Ballnose Corner Radius Calculations
It would be great if we had the ability to lock certain parameters when adjusting DOC/WOC/RPM/Feed.
For example: Locking the DOC parameter and adjusting the Feed parameter and see how the WOC changes relative to the Feed change.
Every time I change something it seems like everything else changes, so it is very difficult to compare different parameters.
Also, when using a ballnose endmill and the WOC is small the "Tool Drawing" only shows the corner radius of the ballnose partially coming into contact with the material.
But when if have many WOC step overs, the corner radius of the ballnose will eventually have full contact with the material. Same thing goes for many DOC passes.
I assume based on the "Tool Drawing" that the Speeds/Feeds aren't taking that into consideration.
Eldar Gerfanov (Admin)
Hello,
You dont really need to have a special lock.
Simply enter a custom field value and it becomes non-default (regular, non-green coor). This means it will not be re-calculated when something else changes.
Ballnose material display is not 100% correct - the calculator correctly assumes subsequent cuts passes have full engagement with the cutting edge and it needs to show it like so:
_image.png)
But the tool display module does not represent that exactly.
I will try to fix it tin the next update.
Best regards.
therookie
If I enter the DOC and WOC then the RPM and Feed, then I go back and change the WOC then my RPM changes when I really don't want it to change.
So then I have to go back and change the RPM back to what it was originally.
Or if I enter the RPM and Feed first and then enter the DOC and WOC then the RPM and Feed changes.
It's always changing something and I am constantly having to re-enter values into the RPM and Feed.
For example I enter the following values:
DOC: .050
WOC: .250
RPM: 23600
Feed: 100.00
-------
Then when I change WOC to WOC: .050 I get:
DOC: .050
WOC: .050
RPM: 29499
Feed: 171.29
-------
Then when I change RPM back to RPM: 23600 I get:
DOC: .050
WOC: .050
RPM: 23599
Feed: 137.03
-------
Then when I change my WOC to the original WOC: .250 I get:
DOC: .050
WOC: .250
RPM: 18880 (Should be 23599)
Feed: 80.00 (Should be 100.00)
------------
Also, I can be a tad annoying how if I enter RPM: 23600 it either says RPM: 23599 or RPM: 23601
Just my thoughts.
Eldar Gerfanov (Admin)
Updated by: Eldar Gerfanov (Admin)
Hello,
Thank you for the detailed example. I think I understand what you're trying to accomplish now.
The way HSMAdvisor currently works is that RPM and Feed are considered result values, while DOC, WOC, tool, material, machine limits, etc. are the inputs used to calculate the recommended cutting conditions.
If you manually change RPM or Feed, HSMAdvisor doesn't actually "lock" those values. Instead, it calculates the equivalent spindle and feed override percentages and continues using those overrides as you make further changes. This allows your preferred operating margin to be maintained when other cutting conditions change.
For example, if you manually reduce the recommended RPM by 20%, HSMAdvisor assumes that's intentional and will continue recommending approximately 20% below the calculated optimum as DOC/WOC or other parameters change.
I do understand the workflow you're describing, though. There are certainly situations where you want to keep RPM and Feed fixed and simply explore how changing DOC or WOC affects the rest of the cut. That's a valid use case.
The challenge is that a true "lock" is more complicated than it sounds. Since RPM and Feed are normally outputs of the calculation, making them fixed inputs changes the entire calculation flow. The software then has to decide which variables should remain optimal, which ones are allowed to deviate, and how to resolve those constraints. In other words, it becomes a different solving mode rather than just another checkbox.
I'll see if there is a place I can insert this into for a quick win, but I don't want to promise anything at this point because it seems it would require fairly significant changes to the calculation logic.
Thank you for the suggestion and for taking the time to explain your workflow - it definitely helps me understand where you're coming from.
@ForumAutomation, create ticket.