Tool has multiple usages with conflicting geometry

[ltomuta]

Hi there!

I'm generating a program "successfully" but I would have trouble running it on a machine because two of my tools have the same tool number yet Fusion 360 does not warn me about this. 

If in post process I give an invalid program number (lots of digits) the post fails and an error log opens in the code editor with the first line being Warning: Tool 11 has multiple usages with conflicting geometry.

That's exactly the info I would like to see in the tool, either immediately after adding the tool to an operation or immediately after post processing. So, how can I see this information without forcing an error to see where the error log is generated and whether it has any relevant warnings?

[Anonymous]

Error messages in Fusion don't have high priority in terms of explaining problem or making user aware of potential problems.

Think of "empty tool path" and other messages as ........ "you missed something and you need to figure out what".

[stephen.irvine]

Hi Itomuta,

I'm a developer on the team currently working on a set of improvements to the tool library and tool experience in Fusion360. One of the things we are currently looking at is how we deal with Tool Numbers. We have plans to warn the user if the same tool number is used for two different tools for the same setup in the future. At the moment it's just a matter of prioritization!

If you did have two tools on the same setup with the same tool number, what would you like to be able to do about it? Would it be helpful if you could automatically re-assign one of them, or would you rather manually set the tool number for the conflicting tool?

Thanks

Stephen

[ltomuta]

Hi Stephen,

I'm new to all this so maybe others work in a different way but here we have a fixed set of tools (frequently used) which should remain on the set position. Conflicts arise when two or more of the less frequently used tools are added so in that case we would prefer (in order of priority):
- a visible warning -> manual reassignment 

- automatic reassignment to a number not locked for a tool in the fix set

Until your team gets this sorted out, can you suggest a way to make sure I identify this problem using the current logs?

Best regards,

Lucian

[christopher.cooperVHK2N · Accepted solution]

Hello Itomuta,

I am the product owner within the development team that work in this area.

Using a fixed set of tools is common for both milling and turning operations (especially turning).

In recognition of this, the development team have started to complete the initial work that aims to prevent the use of duplicate numbers when creating a new tool within a set up. It is possible that this functionality will be available for the February release.

I have noted your suggestion of preferred actions and will create a task to reflect this in further developments.

To my knowledge, at present there is no way to make sure that you can identify this problem using the current logs.

Regards

Chris

[ltomuta]

Hi @christopher.cooperVHK2N @stephen.irvine 

The new tool library is now out of preview and there's still no trace of a duplicate tool detection feature. It is true that with the per-setup tool list filtering it is easier for me to spot duplicates but that's about all, I can still add duplicates and post process them without any warning issued by Fusion.

[gtprototype]

I also use a predefined set of tools; I run into the same problem when I'm adding job specific tools because my control only accepts tool numbers 1-24. 

When I experience problems such as this I try to alter or add a step to my workflow to prevent a crash. Printing a setup/tool list sheet for every job has helped me discover this problem without disastrous consequences.

[christopher.cooperVHK2N]

@ltomuta We did complete work prior to release that prevents duplicate numbers when creating new tools. Originally when you posted, the library would give a default tool number of 1 every time you created a new tool. The work completed ensures that every new tool created will be assigned a number that is not in use. I guess this does not work though if you are copying existing tools into a document. In this case I am not sure if you would want the warning in the tool library or the post? I will discuss with the product manager.

Thanks

Chris

[ltomuta]

I have a library of fixed tools and one with all the rest. In the later, tools have predefined numbers for the few empty slots where I would prefer to put them, if possible without removing the "fixed" ones. All of my HSS drills are defined on either T7 or T9 since on T7 and T9 I have drill chucks. Adding a 2nd drill to my program would likely cause a T9/T7 conflict. Which I can try to solve by moving it to T7/T9 if empty. Or to T21. 

On T4 I'd have either my 6mm mill or my M4 reamer. But if a program needs both ...

I definitely need to move tools around but until I do so Fusion should make the problem visible to me: in operations browser, in tool library, in post-processors, in setup sheets. Everywhere. Failing to do so means a ruined part and/or a broken tool.

The tool library could do smart things to help solve the problem, like "learning" where I placed the tool in my most recent programs and suggesting that tool number when I pick the tool again. Chances are the tool is still loaded on machine in that position and no additional work would be required.

[ltomuta]

As I was writing this I told myself "let's see what happens if I try to define a new drill tool assigned to T9".

So I hit the new tool button, use all the defaults except it suggests tool number 8 (empty in this library as only used in my "fixed" one) but I don't want 8 so I put 9 there. Save and all looks good.

Until I try to open the library again, now the library is red, it cannot be loaded.

Luckily the workaround for this problem is well known and at least on Windows I don't have to restart Fusion to apply it.