Tool Libraries

wayne_sauder

 I wonder if anyone can shed any light on the plans for tool libraries. I find managing the current arrangement clunky. 

 From discussions, I know that more is planned, but I'm wondering if anyone can say when or what. 

 Does someone have an example of an excellent way to manage what has been implemented thus far? 

dave_lapthorne

Hi Wayne. Yes, overhauling the tool library is definitely in the works. Can't commit to a timeframe on when that will be available to our EVP users.
There is a lot of work being done by our core development team right now and that will set the groundwork for our CAM developers to overhaul the tool libraries.

wayne_sauder

I might just comment that creating the tool and then the tool path and having all that info built out on the left seems unnecessary. It seems like the tool path should be able to access the library and not need the tool defined beforehand. These are just thoughts; there is no need to reply to all my thinking.  

Curt_Welch

Yeah, Iwayne_sauder said:

I might just comment that creating the tool and then the tool path and having all that info built out on the left seems unnecessary. It seems like the tool path should be able to access the library and not need the tool defined beforehand. These are just thoughts; there is no need to reply to all my thinking.  

Yeah, I feel the same way.  Though the idea of defining a tool and then using it is very straightforward and logical, it's just too verbose and cumbersome in practice. It clutters up the crowded operation list with wasted space. It creates the feel that this UI was designed for rank beginners who would only want to create 3 tools and 4 paths vs professionals who use 10 tools and 50 tool paths 5 different setups, and we must jump back and forth between the same tools many times in the CAM.  We can't just do all the chamfering in one group, for example.  And, of course, the define-each-time-you-use is redundant.

There is really two table needs.  The first is to define the tooling and the list of end mills, etc, I have for working with but not where I'm going to mount it in the tool changer. This table I generally populate with every tool I own.

Then, there's the tool changer config table for a job, which tells us which tool number gets loaded for each tool.  Then, finally, the operations, which just need to specify the tool number used for the op, which it then gets all the information from the tool changer back to the master tool specifications.

Multiple standard speeds and feeds vs. material should be specified with the tool, whereas the selection of which of the pre-defined values should be specified in the specific operation.  So, for example, I would like to define Aluminum-Profiling (arbitrary name I make up) as one of the table entries for a given end-mill, which has speeds and feeds, and maybe ramp speeds for cutting, or also have Steel-boring set of feeds and speeds.

So when I working on a tool op, I specify which tool number in the tool changer I'm using, and then from that tool, specify which pre-defined speeds and feeds I want to use.

But this is mostly high level UI issues, to foundational core features which is obviously your current focus. But if for example you don't have both a tool table, and a tool-chamgeer table in your core concepts, you won't be able to build the sort of UI I would love to use.

Just food for thought...

wayne_sauder

 Another thought on bringing in new tools: What about connecting to something like Machiningcloud? I do not use Machiningcloud professionally because I cannot justify it at the moment, but I thought the bit I played around with it had some real potential. 

John_P_Desilets

@wayne_sauder Absolutely. We plan to allow users to bring in tools from vendors once tool libraries are refined.