[SomeWhatLost]

as someone who buys lots of end mills and such (not because I break them.... really... well maybe...) I have a question:
why does every cam/controller/etc need its own unique tool library?! why can't everyone just get together and come up with a single basic standard tool library format?
sure, I get that MACH may not care about helix angle/etc but still, why do some things use XML files, others use CSV, and even others use TXT, or even their own "custom" format crap?

I once had this great idea to create a Database type thing that used 'post processors' of sorts to have it poop out the tool info in the right format for MACH/CAM/gwizard/hsmadviser/whatever that needed tool info... unfortunately I ran into a slight road block on that idea... the minor detail that I couldn't program my way out of a paper bag kind of killed it...

anyway, does anyone know of a good all purpose Tool Database type tool?
something where you can keep track of all your tools and then have it poop out a MACH/CAM/gwizard/hsmadviser/whatever Tool Lib type file when needed?

[BAMCNC.COM]

That is a good idea, I have a spreadsheet with all the info, then copy and paste. Most of the time, to get a simple program done, I just write in tool diameter and that's it, CAM doesnt care what the stickout is unless you are checking for crashes, or shank diameter, etc. Simplify things, it will simplify your life.

[TurboStep]

I had also started a spreadsheet early on but I found it to be just one more table to maintain. It was useful at the beginning to get an idea of how I wanted to group and number the tools but I don't maintain it anymore. I found that as changes to my tools became less frequent it wasn't really a big problem to add one more tool.
I agree that the CAM doesn't care about a lot of the data but I find crash detection to be a useful feature. Having paid for a CAM with this capability it would be foolish not to use it. I prefer to detect as many problems in the CAM as possible, before going onto the machine.
Of course, detecting crashes when they happen is the simplest way. I can't argue with that
Step

[BAMCNC.COM]

So far I've never seen a need for Crash Detection, I know how deep I machine, so I make sure the endmill is long enough for that and any fixture screws. I don't do complex machining though, I'm sure when I do, then I will thank the crash detection.

[rlockwood]

So far I've never seen a need for Crash Detection, I know how deep I machine, so I make sure the endmill is long enough for that and any fixture screws. I don't do complex machining though, I'm sure when I do, then I will thank the crash detection.

It comes into play a lot more when the programmer and operator are two separate people.

As for tooling databases, this should be a large consideration when choosing CAM software. I lived for years without any sort of tool database\library and always assumed it was too much work to be worth the benefits. Once I started building an (ACCURATE) tool library, complete with flute length, stick out length, managed speeds and feeds, etc. Its made my life a million times easier.

I was just considering bugging Zero_divide about making an import function for importing different tool libraries into HSMAdvisor the other day, so I think its an excellent idea. Now who do we talk to about making an industry standard?

[SomeWhatLost]

yea, its kind of like what rlockwood stated, it not really so much about crash detection, so much as it is about convenience, tool#1 is always tool#1 (at least on a per job basis) Mach needs to know that tool #1 is x" long, your CAM of choice needs to know that tool #1 is y" diameter (and there is some benefit to knowing length of flues/overall length/etc...), both Gwiz & HSMadvisor also support keeping a tool table/crib/whatever you want to call it, since it really makes those programs much quicker/simpler to use...
so why cant we just have one database of Tools to rule them all? (and in the darkness bind them?)
seems it would make life much easier than keeping track of 1 tool in 3 different places...

[kevinro]

so why cant we just have one database of Tools to rule them all? (and in the darkness bind them?)
seems it would make life much easier than keeping track of 1 tool in 3 different places...

Getting individuals and companies to agree on a standard like this is a LOT of work when they all share the same product category. Each have their own formats because they needed to fill out their tool databases to match the way they were thinking when structuring their individual programs. Having to agree with your competitors on what is and isn't important in a tool crib is not an easy task. There is little incentive to do it.

Getting individuals and companies to agree on a standard across different product categories (CAM programs, Calculators, Simulators, CNC interpreters, etc) would be really really hard since they are all interested in different aspects.

Having said that, it would be really great if someone where to implement a specification of a base tool crib that could specified in XML or one of the more portable file formats. At least then, other programs could import the basic information about the tool cribs.

In such a small fragmented market, this is asking a lot.

[zero_divide]

It comes into play a lot more when the programmer and operator are two separate people.

As for tooling databases, this should be a large consideration when choosing CAM software. I lived for years without any sort of tool database\library and always assumed it was too much work to be worth the benefits. Once I started building an (ACCURATE) tool library, complete with flute length, stick out length, managed speeds and feeds, etc. Its made my life a million times easier.

I was just considering bugging Zero_divide about making an import function for importing different tool libraries into HSMAdvisor the other day, so I think its an excellent idea. Now who do we talk to about making an industry standard?

There is no need to bug me with that anymore.
Somebody already did, and I listen to what users want.
Next update that is schejuled in a week will sport import-export functions.
For now it will only have support for my own XML files.
People who are interested in seing their Cam/gwiz/whatever added, please send me your library export files, so I know what kind of data to feed in in each particular case.

Btw next thing will be export of MasterCam tool files.

Edit: it's possible to read files semantically and fill up empty gaps in data, but that would take some clever programming and not sure it would pay off.

[zero_divide]

It comes into play a lot more when the programmer and operator are two separate people.

As for tooling databases, this should be a large consideration when choosing CAM software. I lived for years without any sort of tool database\library and always assumed it was too much work to be worth the benefits. Once I started building an (ACCURATE) tool library, complete with flute length, stick out length, managed speeds and feeds, etc. Its made my life a million times easier.

I was just considering bugging Zero_divide about making an import function for importing different tool libraries into HSMAdvisor the other day, so I think its an excellent idea. Now who do we talk to about making an industry standard?

There is no need to bug me with that anymore.
Somebody already did, and I listen to what users want.
Next update that is schejuled in a week will sport import-export functions.
For now it will only have support for my own XML files.
People who are interested in seing their Cam/gwiz/whatever added, please send me your library export files, so I know what kind of data to feed in in each particular case.

Btw next thing will be export of MasterCam tool files.

[rlockwood]

People who are interested in seing their Cam/gwiz/whatever added, please send me your library export files, so I know what kind of data to feed in in each particular case.

Where would the best place to send be? I'd love to make sure HSMWorks is among the first supported, so it doesnt get left out later

Don't believe I can attach an xml to the PM system here-- though I didn't spend much time trying.

[zero_divide]

Where would the best place to send be? I'd love to make sure HSMWorks is among the first supported, so it doesnt get left out later

Don't believe I can attach an xml to the PM system here-- though I didn't spend much time trying.

Send it here:
[email protected]
Please make sure you got all of the tool types in there, so say a drill will not get left out.

[SomeWhatLost]

For now it will only have support for my own XML files.
People who are interested in seing their Cam/gwiz/whatever added, please send me your library export files, so I know what kind of data to feed in in each particular case.

Btw next thing will be export of MasterCam tool files.

its great that you are taking on this type of project, but I do see one minor issue...
if every 'output' has to be created by you, there are billions of different programs/things out there, and there is only one of you (unless you found some new cloning tech?)... wouldn't it be better to come up with a way to have the end user define the output that they want/need? like a post processor type concept?

like for example, this could be the PP for cambam:

#EXT=XML
#PATH=C:\ProgramData\CamBam plus 0.9.8\tools
#HEADER START
<?xml version="1.0" encoding="utf-8"?>
<ToolLibrary Version="0.9.8.0" NumberFormat="0.00">
#HEADER END
#BODY START
<ToolDefinition Name="{TCToolName}">
<Index>{TCToolIndex}</Index>
<Diameter>{TCToolDiam}</Diameter>
<ToolProfile>{TCToolProfile}</ToolProfile>
<Flutes>{TCToolFlutes}</Flutes>
<FluteLength>{TCToolFluteLength}</FluteLength>
<Length>{TCToolLength}</Length>
<Material>{TCToolMaterial}</Material>
<ShankDiameter>{TCToolShankDiam}</ShankDiameter>
<HelixAngle>{TCToolHelixAngle}</HelixAngle>
<VeeAngle>{TCToolVeeAngle}</VeeAngle>
<MaxRampAngle>{TCToolMaxRampAngle}</MaxRampAngle>
<ToothLoad>{TCToolToothLoad}</ToothLoad>
<AxialDepthOfCut>{TCToolAxialDepthOfCut}</AxialDepthOfCut>
<RadialDepthOfCut>{TCToolRadialDepthOfCut}</RadialDepthOfCut>
</ToolDefinition>
#BODY END
#FOOTER START
</ToolLibrary>
#FOOTER END

the #Path would tell it where to dump the file (not sure this is a good idea, maybe make it optional?) so that for local stuff like cad/cam it would automatically put the file where needed.
the #EXT would just be the default file extension.
the #Header crap would just be all the unique[Blah crap] that everyone seems to want to put at the top of the tool file.
the #Body section is where all the fun stuff would happen, you would create a the file using the style or whatever you call it that is laid out in the body, and replace all the {TCToolXXX} with data from the database that matches that field (I just made up the TCToolxxx names as an example) and it would keep looping or whatever until it had processed every tool in the database
for things that the database doesn't track, like say like the {TCToolMaxRampAngle} field, then when making the PP file we could just either place default value there like this:
<MaxRampAngle>0</MaxRampAngle>
or maybe have a {null} option or something?
the #Footer would just be any ending crap that was need to finish off a file, probably only needed on .XML style outputs?
so for the above PP the output would look something like this:

<?xml version="1.0" encoding="utf-8"?>
<ToolLibrary Version="0.9.8.0" NumberFormat="0.00">
<ToolDefinition Name="1/16 SINGLE END 2 FLUTE CARBIDE END MILL">
<Index>3</Index>
<Diameter>0.0625</Diameter>
<ToolProfile>EndMill</ToolProfile>
<Flutes>2</Flutes>
<FluteLength>0.25</FluteLength>
<Length>0</Length>
<Material>Carbide</Material>
<ShankDiameter>0.125</ShankDiameter>
<HelixAngle>0</HelixAngle>
<VeeAngle>0</VeeAngle>
<MaxRampAngle>0</MaxRampAngle>
<ToothLoad>0</ToothLoad>
<AxialDepthOfCut>0</AxialDepthOfCut>
<RadialDepthOfCut>0</RadialDepthOfCut>
</ToolDefinition>
<ToolDefinition Name="1/16 SINGLE END 4 FLUTE ALTIN COATED">
<Index>4</Index>
<Diameter>0.0625</Diameter>
<ToolProfile>EndMill</ToolProfile>
<Flutes>4</Flutes>
<FluteLength>0.25</FluteLength>
<Length>0</Length>
<ShankDiameter>0.125</ShankDiameter>
<HelixAngle>0</HelixAngle>
<VeeAngle>0</VeeAngle>
<MaxRampAngle>0</MaxRampAngle>
<ToothLoad>0</ToothLoad>
<AxialDepthOfCut>0</AxialDepthOfCut>
<RadialDepthOfCut>0</RadialDepthOfCut>
<Material>Carbide</Material>
</ToolDefinition>
</ToolLibrary>

[zero_divide]

its great that you are taking on this type of project, but I do see one minor issue...
if every 'output' has to be created by you, there are billions of different programs/things out there, and there is only one of you (unless you found some new cloning tech?)... wouldn't it be better to come up with a way to have the end user define the output that they want/need? like a post processor type concept?

like for example, this could be the PP for cambam:

#EXT=XML
#PATH=C:\ProgramData\CamBam plus 0.9.8\tools
#HEADER START
<?xml version="1.0" encoding="utf-8"?>
<ToolLibrary Version="0.9.8.0" NumberFormat="0.00">
#HEADER END
#BODY START
<ToolDefinition Name="{TCToolName}">
<Index>{TCToolIndex}</Index>
<Diameter>{TCToolDiam}</Diameter>
<ToolProfile>{TCToolProfile}</ToolProfile>
<Flutes>{TCToolFlutes}</Flutes>
<FluteLength>{TCToolFluteLength}</FluteLength>
<Length>{TCToolLength}</Length>
<Material>{TCToolMaterial}</Material>
<ShankDiameter>{TCToolShankDiam}</ShankDiameter>
<HelixAngle>{TCToolHelixAngle}</HelixAngle>
<VeeAngle>{TCToolVeeAngle}</VeeAngle>
<MaxRampAngle>{TCToolMaxRampAngle}</MaxRampAngle>
<ToothLoad>{TCToolToothLoad}</ToothLoad>
<AxialDepthOfCut>{TCToolAxialDepthOfCut}</AxialDepthOfCut>
<RadialDepthOfCut>{TCToolRadialDepthOfCut}</RadialDepthOfCut>
</ToolDefinition>
#BODY END
#FOOTER START
</ToolLibrary>
#FOOTER END

the #Path would tell it where to dump the file (not sure this is a good idea, maybe make it optional?) so that for local stuff like cad/cam it would automatically put the file where needed.
the #EXT would just be the default file extension.
the #Header crap would just be all the unique[Blah crap] that everyone seems to want to put at the top of the tool file.
the #Body section is where all the fun stuff would happen, you would create a the file using the style or whatever you call it that is laid out in the body, and replace all the {TCToolXXX} with data from the database that matches that field (I just made up the TCToolxxx names as an example) and it would keep looping or whatever until it had processed every tool in the database
for things that the database doesn't track, like say like the {TCToolMaxRampAngle} field, then when making the PP file we could just either place default value there like this:
<MaxRampAngle>0</MaxRampAngle>
or maybe have a {null} option or something?
the #Footer would just be any ending crap that was need to finish off a file, probably only needed on .XML style outputs?
so for the above PP the output would look something like this:

<?xml version="1.0" encoding="utf-8"?>
<ToolLibrary Version="0.9.8.0" NumberFormat="0.00">
<ToolDefinition Name="1/16 SINGLE END 2 FLUTE CARBIDE END MILL">
<Index>3</Index>
<Diameter>0.0625</Diameter>
<ToolProfile>EndMill</ToolProfile>
<Flutes>2</Flutes>
<FluteLength>0.25</FluteLength>
<Length>0</Length>
<Material>Carbide</Material>
<ShankDiameter>0.125</ShankDiameter>
<HelixAngle>0</HelixAngle>
<VeeAngle>0</VeeAngle>
<MaxRampAngle>0</MaxRampAngle>
<ToothLoad>0</ToothLoad>
<AxialDepthOfCut>0</AxialDepthOfCut>
<RadialDepthOfCut>0</RadialDepthOfCut>
</ToolDefinition>
<ToolDefinition Name="1/16 SINGLE END 4 FLUTE ALTIN COATED">
<Index>4</Index>
<Diameter>0.0625</Diameter>
<ToolProfile>EndMill</ToolProfile>
<Flutes>4</Flutes>
<FluteLength>0.25</FluteLength>
<Length>0</Length>
<ShankDiameter>0.125</ShankDiameter>
<HelixAngle>0</HelixAngle>
<VeeAngle>0</VeeAngle>
<MaxRampAngle>0</MaxRampAngle>
<ToothLoad>0</ToothLoad>
<AxialDepthOfCut>0</AxialDepthOfCut>
<RadialDepthOfCut>0</RadialDepthOfCut>
<Material>Carbide</Material>
</ToolDefinition>
</ToolLibrary>

For that to work we need to assume people would actually care to create import/export profiles.

Which I doubt very much.
Still I was thinking of doing it that very way you have described. I just feel like I am gonna have to do all the work anyway.

Thanks for the xml snippet!

[SomeWhatLost]

For that to work we need to assume people would actually care to create import/export profiles.

Which I doubt very much.

I hope your wrong about that...
but I fear you are probably right...
this thread has had ~500 or so views, but only ~10 posts that weren't me...
so it seems there just isn't that much interest here...

but fwiw, I am still interested...

Thanks for the xml snippet!

no prob...