By Ben
Bug Report: Wrong chamfer tools geometry after import from HSMLIB tool lib format ?
Hi,
I'm struggling to get my tool database (in hsmlib format) imported correctly.
I think you have a bug, where the tip-diameter of a chamfer/countersink mill is not correctly used from tool format file and instead is always set to the main tool diameter, resulting in a wrong tool drawing/geometry and also wrong cut parameters.
Tested also with tool manufacturers official files. (Helical Solutions: Specialty Profiles)
The app also can't handle a tip_diameter of 0.0, while other CAD software like Fusion360 can, which might also lead to issues when using tool libraries exported from such CAD software. Setting the tip diameter in the hsmlib file to 0.0001mm is not solving the problem either.
The minimum tip-diameter accepted in the app is 0.0001, regardless of the unit (mm/inch).
HSMAdvisor version: 3.0.8
Library files:
https://cam.autodesk.com/hsmtools
Used for testing:
https://cam.autodesk.com/tools/download.php?name=Helical%20Solutions/Specialty%20Profiles&desktop=1
Entry from HSMLib file:
<tool guid="09C5BE2E-D8DD-4C37-ADEC-74673741CBEF" type="chamfer mill" unit="inches" version="1.3">
<description>HELICAL - 83872 - CHAMFER MILL - 0.1250 (1/8) SHANK DIA X 90 DEG INCLUDED ANGLE X 1.5000 (1-1/2) OAL X 0.0400 TIP DIA , 3 HELICAL FLUTES, APLUS COATED</description>
<manufacturer>HELICAL SOLUTIONS</manufacturer>
<product-id>83872</product-id>
<product-link>https://www.helicaltool.com/products/tool-details-83872</product-link>
<nc break-control="0" diameter-offset="0" length-offset="0" live-tool="1" manual-tool-change="0" number="0" turret="0"/>
<coolant mode="flood"/>
<material name="carbide"/>
<body body-length="0.1055" coolant-support="no" diameter="0.125" flute-length="0.043" number-of-flutes="3" overall-length="1.5" shaft-diameter="0.125" shoulder-length="0.043" taper-angle="45" thread-pitch="0" thread-profile-angle="60" tip-diameter="0"/>
<motion clockwise="yes" cutting-feedrate="1" entry-feedrate="1" exit-feedrate="1" feed-mode="per-minute" plunge-feedrate="1" ramp-feedrate="1" ramp-spindle-rpm="1" retract-feedrate="0" spindle-rpm="1"/>
<presets>
<preset description="" id="{d961f725-670c-4be0-87e8-778dba18fa00}" name="Default Preset" tool_coolant="flood" tool_feedCutting="25.399999999999999" tool_feedEntry="25.399999999999999" tool_feedExit="25.399999999999999" tool_feedPlunge="25.399999999999999" tool_feedRamp="25.399999999999999" tool_rampSpindleSpeed="1" tool_spindleSpeed="1"/>
</presets>
</tool>
The bugfix should hopefully not be very complex, your parser routine must be fixed to take the tip-diameter variable and if the limit can't be fixed, replace 0.0 values with 0.0001.
Thank you. :)
Fusion360_SameChamferTool.png
HSMAdvisor_wrongGeometry_customChange_TipDiameter.png
ForumAutomation
Thank you for the detailed bug report. This has been logged and will be reviewed by the development team.
Eldar Gerfanov (Admin)
Hello Ben,
Thank you for your bug report.
We have logged your request and i will try to get if fixed in the upcomming big release.
Best regards.
Ben
Hi,
thanks I appreciate it. However I found another wrong value, that can also seen above in the images and in the tool libraries.
The app is parsing <body-length> as parameter for tool-stickout. However, that is not the correct value for it in the hsmlib format, as <body-length> is a value, that often is only set to flute_length + shoulder_length + part of the shaft and is chosen more or less random by the library creator.
It prevents the user from having to zoom in too much to see the flute-geometry in the 3d view and it provides most basic collision detection in the CAM software. For collision detection, it is irrelevant if the shaft is way longer, what counts is the transition from flute/shoulder to the shaft.
The correct value for the tool length is <overall-length> this is always the total tool length. <assembly-gauge length> that also is sometimes used would be the direct representation of stickout length, however, this value is holder specific and also chosen as preset by the library creator.
I would suggest, using the <overall length> as tool stickout and the user can then reduce it manually to the holder they actually use.
That would be imho the safest option, as the feed and speeds would then be reduced and it safer to run with slow values, than to damage the tool or workpieces by too aggressive values.
Thank you. :)
Eldar Gerfanov (Admin)
Hi Ben,
The fix for the import issue you saw is now available in the latest update.
I am going to research this body-length vs overall-length vs gauge-length thing.
But from my observation overall-length seems to represent the total length of the tool. And the body-length is the actual stick-out. At least it was couple of years ago when I initially created the import plugin and played with exported libraries...
I will look into that.
Than you.
@ForumAutomation create an exploration issue on GitHub.
ForumAutomation
Thank you for the bug report! A GitHub issue has been created to track this: #138 - Body-length vs overall-length field mapping for chamfer tools in HSMLib import.
We'll investigate the field mapping discrepancy and update the issue with our findings. Feel free to follow along there for progress updates.
Ben
Hi Eldar,
Chamfer tool:
The chamfer import issue is still there. Tested with v3.1.1 and same tool library.
Also, it seems that the angle value is interpreted wrong:
These tools for reference:
Helical:#59815, and the one above #83872:
https://www.helicaltool.com/products/tool-details-83872 : 45deg (90° Inner angle)
https://www.helicaltool.com/products/tool-details-59815 : 30deg (60° inner angle)
<tool guid="179E4257-0214-47EC-B17C-42BF945566CF" type="chamfer mill" unit="inches" version="1.3">
<description>HELICAL - 59815 - CHAMFER MILL - 0.2500 (1/4) SHANK DIA X 60 DEG INCLUDED ANGLE X 2.5000 (2-1/2) OAL X 0.0600 TIP DIA , 3 HELICAL FLUTES, ZPLUS COATED</description>
<manufacturer>HELICAL SOLUTIONS</manufacturer>
<product-id>59815</product-id>
...
<body body-length="0.289" coolant-support="no" diameter="0.25" flute-length="0.164" number-of-flutes="3" overall-length="2.5" shaft-diameter="0.25" shoulder-length="0.164" taper-angle="30" thread-pitch="0" thread-profile-angle="60" tip-diameter="0"/>
(in this case the manufacturer himself got the tip diameter wrong, according to the product page)
The app interprets the flute angle from the horizontal line, not from the vertical? This is more obvious when importing tapered-mills.
Tool stickout length:
You are right. The body length property is used for the tool stickout, at least in some libraries and for some tools. The problem seems to be that these libraries, even coming from big manufacturers, contain errors and are unreliable in regard to this parameter. e.g. the two tools above, according to the library, the body length barely even covers the real flute length?!
I've searched a bit, see the specific tool from HAAS. In that case, the useable stickout length is known and pre-determined by the tool design for a specific holder type? HAAS also puts the correct values in their library.
https://www.haastooling.com/p/03-0645
It really depends on the manufacturer and the library creator. So far I could not find a specific formula or standard. This might only be a problem for tools with smooth shank and no fixed holder system. Some suggest for min clamping length to be ~3 x tool diameter: => body-length = overall - 3 x tool dia. Not sure how to handle libraries with seemingly random/wrong values.
Ben
Haas tool:
ForumAutomation
Hi Ben,
Thanks so much for the detailed follow-up and for taking the time to test v3.1.1 — that really helps us narrow things down. Here's where each of your points stands:
All three points are now tracked in open GitHub issues, so you can follow progress (and get notified of updates) directly there. If anything else comes up while you're testing, feel free to drop another comment here or reference the relevant issue.
Appreciate the thorough reporting — it makes a real difference!
— ForumAutomation