Tool importing: key field

All topics related to RhinoCAM
Post Reply
MS1555607536
Posts: 1
Joined: Thu Apr 18, 2019 10:13 am

Tool importing: key field

Post by MS1555607536 »

It appears that RhinoCAM uses the tool name as the key field in the tool browser for the purposes of updating tools when importing from a tool library. It is a perfectly respectable choice to have made - something needs to be the key field after all, and maybe there are a lot of users who would see this one as the natural one. However, I suspect that many (most?) users would actually think of the tool number as the natural key field. In fact RhinoCAM gives a nod towards this by asking users to confirm if they *really* want duplicate numbers if they attempt to create them. Furthermore, the only way of referencing a tool from the output code is by number, suggesing that it is the natural way of uniquely referencing it.

The main problem we have encountered is if a tool's name is changed and it is subsequently imported, it is very easy to miss the fact that a tool in use has not been updated but a new tool with the same number has been created instead, leading to incorrect toolpath calculation. (This is particularly an issue when the name change is slight - even an invisible trailing space will cause duplication).

On the other hand of course, if the number was key, you may get the situation where a tool number is re-used for a completely different tool, and you would not want programs to silently acquire the wrong tool altogether when doing an update.

I would like to make an enhancement request, but I understand that simply changing the key field from name to number would probably upset as many people as it pleased, and it would be much better to catch *all* potential duplication/overwriting issues, regardless of one's point of view on this. So here are my suggestions:

1. When importing tools, warn the user that a tool with a duplicate number is being brought in as an extra tool, not overwriting the existing one (because of differing names), and give them the choice of what happens: replace or duplicate.

2. Similarly the other way round - when importing a tool with a duplicate name but different number, warn the user that an exisitng tool is just about to be overwritten by one that has a different number. Again, a choice should be offered to replace or duplicate (munging the name as necessary e.g. like Windows does when copy-&-pasting files).

3. In both cases above, a welcome further refinement would be an 'always do this' tick box (though of course I recognize that you then have to have some way of letting the user change their mind!). Even if a remembered conflict resolution option is executed, there should still always be a warning.

For us, we would breathe a HUGE sigh of relief if we knew that duplicate tool numbers could NEVER occur, and we would ALWAYS opt for (munged) duplicate names to be tolerated in cases where the numbers differed.

Is this something you would consider implementing?

Does anyone else have opinions on this?
Post Reply