LIbrary changes not updating the tooling

[Fueler]

I just noticed that if I go into the tool library and change speeds and/or feeds on a tool it does NOT update the tool in the project.

I tried choosing another tool and coming back to the correct one and no joy.

It is supposed to update isn't it? I think it used to.

Just thought someone should know.

[Steinwerks]

No, the tool in your project is not linked to the main tool library.

[cj.abraham]

This is expected behavior. Tool libraries are not linked to other libraries or project tool lists.

However, editing a tool in a project tool list will prompt the user to update feeds/speeds in the operations the tool is used in. (but updating operations will not update the project tool list.)

[Fueler]

Well, why the heck not?   That's just silly.

Makes the library seem more like fluff than substance.

Now, tell me again why I should use the library?

[cj.abraham]

The library tools are simply a template for common tools so that you do not have to completely redefine all your tools every time you need a new tool. For example, there are libraries for ANSI drill sizes, Metric drill sizes, ANSI taps, Metric Taps, Endmills, Even tool holder libraries.

[LibertyMachine]

And on top of that, you can take those tools and build your own cloud or local libraries with the speeds and feeds that you want

[Fueler]

You will have to explain how to work that gearsoup.

My stance is why not have those S&Fs in there?

Do I need to make it an official idea?

If one uses the same tool over and over it should be saved.

I can't use most of the sample end mills without mods as most of them are set up for much faster machines.

[cj.abraham]

"I can't use most of the sample end mills without mods as most of them are set up for much faster machines."

Create your own user libraries with your own feeds and speeds. The samples are just that, samples.

[Fueler]

Been there, Done that.  My point remains if it does not update the project it is not doing it's job completely.

Just took another look. See if I am right.  IF I make a new tool, assign it speeds and feed, etc. it will populate the project correctly when chosen.

Do I see that right?

[Steinwerks]

Yes, if you make a new tool with the parameters you want and save it in the main library you can choose to use it in a project and it will use those parameters.

The tool library is still in constant development, and trust me, it will never please everyone.

[Fueler]

OK, then it's not done.

Add it to the list.

The problem with it not updating the tool in the project is someone, almost me is going to crash something important with too much feed and not realizing this issue exists.

Is the only way to delete the tool and start over or is that not possible?

[martha.deans]

@Fueler I made a quick screencast that goes over how to duplicate Sample Tools and edit them in your own Local Library.

I slightly touch on this in the video, but the reason for the current method of only updating tool feeds and speeds permanently from the Tool Library Manager (the one you get to by clicking the folder in the toolbar at the top of the screen) is that the feeds and speeds you save there should be "utility" feeds and speeds - the ones that you default to for that tool and material. Then for specific or one-off operations that might require a severely different set of speeds and feeds, you can easily adjust them that one time in the Operation.

If you would rather have a workflow where you make a new Local Library for every part where you dial in the feeds and speeds there and then never have to change them in the Operation, we support that workflow as well. What we are trying to avoid is the need to create a new tool for every use case since this would lead to everyone having too many tools to know what to do.

I hope that makes sense and clears up why we do it the way that we do.

(I realized I forgot to show creating a new Local Library in the ScreenCast, so a screenshot of that is attached).

[Fueler]

Martha,

Thank you.

When I got started I was pleased to see the Local library creation. Makes good sense.

I agree with everything you said and the scenarios presented and I do everything you pointed out.

Easy Peasy

I do have my own little local library.

My bone of contention has been if.....

I find an error in my tool setup (saved local library)

I go to my local library

make a change in the previously saved tool

it does not update the same tool in the project.

Concentrated on it this morning.

Step 1

Go to library, choose tool being used in project.

change speed and/or feed and save.

Go to project to check said tool. It is not updated.

Step 2

Change tool in project to something else.

Step 3

Change tool back to the original that was changed in the local library.

The tool now shows the updated/saved changed speeds and feeds.

Repeated it a few times with the same results.

I concentrated on the Speeds and feeds so I can't attest to any of the other parameters.

Just sayin' that this was overlooked and needs addressed before an expensive, needless crash happens.

[Steinwerks]

If I change a tool in the library I do not want it to retroactively change every toolpath I've used it for. Want know why? Because I use one tool for more than one operation. I'd be breaking tools or making scrap parts by forcing a 2D Contour or Horizontal to move at the same feedrate as the previous Adaptive Clearing toolpath.

Now there are ways to fudge this sort of thing by creating duplicate tools wroth the same number but then your tool library gets ugly quick.

Again, won't ever be able to please everyone. The best result IMO will be when single tools can use different cutting parameters set up via choices made in the toolpath definition instead of a hard and fast RPM and Feedrate (and I wish it were linked to chipload instead already).

[Fueler]

Steinworks.

Not disagreeing with your scenario.

Yes, I can change things on the fly which is cool but that is not my point.

I have roughing and I have finishing tools. Certain tools will always be the same speed feed and chip load.

I needed to change the base recipe on one of them due to an input error and noticed it did not update without outsmarting it.

That is what started all this.

It is not a big picture thing, it is a little detail thing.

[Steinwerks]

Yes, your point is that your workflow doesn't work well with the tool library as it is, or as you expected it to be. Mine wouldn't work well in your ideal library setup.

I'd rather have flexibility than tool updates that scrap parts later.

[HughesTooling]

I guess the only compromise would be a checkbox in the tool setup "Force Update In Document Libraries". I wouldn't want to use it as you might have tuned all your feeds\speeds in a design then have them overwritten.

Mark

[Fueler]

IF there are concerns based on other scenarios perhaps a pop up message like: "tool 9 has changed in the library. Do you want to update the tool in the project?"