Developer Feedback: Tool Library Architecture — Redundant Tool Definition Storage

Developer Feedback: Tool Library Architecture — Redundant Tool Definition Storage

alexmclean
Observer Observer
321 Views
4 Replies
Message 1 of 5

Developer Feedback: Tool Library Architecture — Redundant Tool Definition Storage

alexmclean
Observer
Observer

I had a chat with the built in AI about the tool library, Below is the response it gave me to share, not sure where to put feedback so i hope this is in the correct place. I'm sure this is a complaint by others as well but here is my take on it. The Cloud library is great but there is no control on tools after its copied into a new file. This is particularly frustrating when introducing a new tool. For example you use this newer tool on 5 or more different parts across multiple programmers. The job is rushed and the next one hits and these programmers don't collaborate to update the cloud file. Having one source of truth mitigates this issue because each programmer is now forced to use the same truth, and see each others changes. This increases ability to standardize the tool between multiple people without having to create a meeting about it to get everyone together to specifically tackle the issue.  My take is the Tools should have the speeds and feeds preset, linked to a master "truth" if the programmer decides its not going to work based on the part geometry, setup, ect. They can edit the variables in the toolpath directly (Custom) or if that speed and feed is perceived to be one that will be used often update the cutting data for the "truth" tool, directly from the file the programmer is currently working in. 

Only downside i see is if the truth is changed this will update any file using the truth, and maybe that could have consequences. But maybe there just needs to be a parameter check and warning that says something like "Cutting data has changed from the intial data, Cutting data will be set to (Custom) for x toolpath" or something like that. Basically any legacy file would throw that i would assume. Obviously i don't know how difficult this is to change but im just spitballing my feedback.

 

I feel like this would be a huge quality of life improvement.

 

Developer Feedback: Tool Library Architecture — Redundant Tool Definition Storage

Submitted by: User feedback via Autodesk Assistant Date: 2026-06-18 Domain: Manufacturing / CAM — Tool Library & Data Management


Problem Statement

When tools are used in CAM operations within a Fusion document, a full copy of the tool definition is embedded in the document file, rather than storing a reference to the Cloud Tool Library. This occurs for every operation, every template, and every file across the platform.


Impact

 
Level Description
UserTool definitions drift out of sync with the Cloud Library; updates must be manually propagated across all files
WorkflowContainer template workflows are undermined — every new template duplicates the entire tool set
PlatformRedundant tool data compounds at scale: tools × templates × files × companies

Technical Analogy

"It's like a program with an intentional memory leak."

The current architecture is a data normalization problem — tool definitions are stored denormalized at the document level, when documents should store only a reference/pointer to the Cloud Library entry. At platform scale this becomes a distributed memory leak.


Proposed Solution

  • Documents store a tool reference ID pointing to the Cloud Library master entry
  • A snapshot of the tool definition is only captured at post/output time for traceability and reproducibility
  • Cloud Library acts as the single source of truth
  • Optionally: a diff/sync mechanism to flag or update stale embedded tool copies

Benefits

  • Reduced redundant storage at platform scale
  • Tool definition changes in Cloud Library propagate automatically to all referencing files
  • Cleaner container template workflows with no tool duplication
  • Improved data consistency and version traceability
0 Likes
322 Views
4 Replies
Replies (4)
Message 2 of 5

adrian8B2L2
Advocate
Advocate

@alexmclean I would love to see your change implemented, consistency across all setup is a big deal for tooling, but something tells me that a lot more people would hate it, The moment that a quick and dirty edit no longer on the table, especially for those who work in low resource, high pressure environments would probably mutiny. 

But props to you for raising the subject. 

0 Likes
Message 3 of 5

a.laasW8M6T
Mentor
Mentor

I have been wanting something like this for ages.

 

the tools should be linked back to the Main library but if you didn't want changes to propagate to a particular file you would be able to break the link.

 

The big issue I have is say for example right now I have several feed mills where the inserts are no longer being made so need to switch to a newer design, now I have hundreds of files with an out of date tool and have to manually pick the up to date one every time i open an old file

 

Andrew Laas
Senior Machinist, Scott Automation


EESignature

0 Likes
Message 4 of 5

seth.madore
Community Manager
Community Manager

Well, as luck would have it, this topic is also on our mind and we're working on a solution to this exact issue. Obviously, there's no timeline I can give for when this will be solved (and released to the public), but it's certainly something we need to do.


Seth Madore
Customer Advocacy Manager - Manufacturing


Message 5 of 5

alexmclean
Observer
Observer

I'm Very happy to hear that! Thank you seth!

0 Likes