Tool table in CAM, LinuxCNC & pockets in a non-random tool changer

More
09 May 2019 21:03 #133295 by bevins

Is your DB interface working? Can I query it, write to a record and read a field within python during a remap?


In a word, "No"

I didn't manage to persuade anyoen else to even try the experimental branch, so it has been fallow for several years.

github.com/LinuxCNC/linuxcnc/commits/andypugh/tooltable

Look for commits around July 2013 for the files that were changed.

Looking back at it I think that there might be a sample config, but not a lot of docs. (any, in fact)

That version attempts to have a user-editable python interface interacting with a usr-defined tool database.
I don't think any of the samples there actually use the proposed schema.


I see that pocketID is a unique key. This would not be pocket#. slot_pos would be pocket#? I's not a unique field so that should work.

Please Log in or Create an account to join the conversation.

More
20 May 2019 08:40 #134342 by mydani
Hey guys,

just wanted to let you know I understood a scenario in which different tool id same pocket makes sense.

Sorry, took some time. Scenario as follows: Different operations (milling, drilling, facing, etc...) in CAM are done with the same tool but different feeds/speeds, and the tool gets a different tool id per operation, so the operator is later able to change stuff at the machine per operation. E.g. tool diameter or offset adaptation. In this case a tool change would not be physically required, just the change of the tool offset data. I have implemented this acc. in my branch.

Regards,
Daniel

Please Log in or Create an account to join the conversation.

More
19 Nov 2019 14:55 #150653 by mydani
May I just summarize once more:
  • The tool table should be able to contain several different tools (tool ids) mapped to the same pocke. Reason: different cutting values in the CAM can lead to different tool ids for the same physical tool.
  • If a tool is changed, the important info is the pocket of the current tool in spindle and the new pocket of the new tool. If the pocket is equal (tool 1 and tool 5 are in pocket 2 as per the tool table), no tool change has to happen at all.
  • If a tool is changed and the new tool pocket differs from the current tools' pocket, the current tool needs to be placed back in the current pocket, then the new tool is taken out of the new pocket.
  • Special behaviour for pocket 0 could be - manual tool change. Means if the current tool has a pocket >0 and the new tool has pocket 0, the current tool is put back into it's pocket, and then the user is requested to insert the new tool manually. Same the other way round, if the current tool has pocket 0 and the new tool pocket > 0, the user is manually requested to remove the curren tool, then the changes grabs the new tool from the corresponding pocket.

Please give some feedback whether this applies.

Please Log in or Create an account to join the conversation.

More
19 Nov 2019 15:22 #150657 by andypugh

  • The tool table should be able to contain several different tools (tool ids) mapped to the same pocke. Reason: different cutting values in the CAM can lead to different tool ids for the same physical tool.

  • I am not sure I follow this. I would think it is more likely that the same T-number in the G-code could map to more than one physical tool.
    As I see it, the G-code would call out a T-number, then the database would be searched for all "magazines" associated with the current spindle, then each pocket of that magazine would be searched for a tool with the required tool number.
    (You need to start at the T-number, that is all that G-code is capable of requesting).
    At that point you know which tool changer to use and which pocket contains a tool with the required tool number.
    Whether the tool-in-spindle goes in to a random slot or a home slot is implementation specific, but I think it makes sense to treat a fixed position toolchanger as a special case of a random toolchanger, rather than the current system which treats the random toolchanger as a special case.
    A fixed-relationship tool changer would leave the tool-ID entry in the pocket after a tool change. A random toolchanger would clear that entry.
    At machine switch-on, a fixed toolchanger would search the pockets for the one allocated to the tool-in spindle. A random changer would not care until it was time to put the tool away, at which point it would simply find any empty pocket.

    Please Log in or Create an account to join the conversation.

    More
    20 Nov 2019 07:02 #150721 by mydani

    I would think it is more likely that the same T-number in the G-code could map to more than one physical tool.

    Is the use case that you have a big magazine and several tools of the same kind and same measures (identical tools) in it?


    As I see it, the G-code would call out a T-number, then the database would be searched for all "magazines" associated with the current spindle, then each pocket of that magazine would be searched for a tool with the required tool number.
    (You need to start at the T-number, that is all that G-code is capable of requesting).


    Also my understanding. Search each pocket for the tool no, if found, return pocket for tool change.

    ...it makes sense to treat a fixed position toolchanger as a special case of a random toolchanger...
    At machine switch-on, a fixed toolchanger would search the pockets for the one allocated to the tool-in spindle. A random changer would not care until it was time to put the tool away, at which point it would simply find any empty pocket.


    Totally agree!

    Please Log in or Create an account to join the conversation.

    More
    20 Nov 2019 09:55 #150730 by andypugh

    I would think it is more likely that the same T-number in the G-code could map to more than one physical tool.

    Is the use case that you have a big magazine and several tools of the same kind and same measures (identical tools) in it?


    Not identical tools, just "near enough". So you might have several 10mm flat end mills. Your G-code would ask for "T3" if that was your code for a 10mm end-mill. At that point any one of several would be fine (if you wanted one in a long holder, then you would use a different T-number).
    The database would be searched for any tool with a T-number of 3, and then the offsets for that particular physical tool would be applied.
    The tool changer code could either choose the fastest-to-find T3, or the one with the lowest hours, or any other criterion.

    (Note that in the proposed database the Tool-ID is a unique key, but is independent of the T-number_

    Please Log in or Create an account to join the conversation.

    More
    20 Nov 2019 10:11 #150732 by mydani
    Ah ok. This is sth. which in my neighbourhood would not be wanted. Guys here use their tools to the 1/1000mm in diameter and lenght, end therefore even if it's the same 10mm end-mill it is actually not the same. If you would use for one part finish pass one of the 10mm end mill and for the next part another 10mm end mill, it could already lead to a difference in the final measurement and/or looks of the part.

    Therefore the identification is different there, T1 might be the 10mm end mill used for roughing already with wear or chippingg, and T2 might be the same end mill, but for finishing (less roughly used).

    Regards,
    Daniel

    Please Log in or Create an account to join the conversation.

    More
    20 Nov 2019 11:06 #150735 by andypugh

    Ah ok. This is sth. which in my neighbourhood would not be wanted. Guys here use their tools to the 1/1000mm in diameter and lenght, end therefore even if it's the same 10mm end-mill it is actually not the same


    I think you are misunderstanding what I am describing. Every physical tool has its own set of offsets (mainly diameter and length)
    So two different T3 tools would have two different sets of offsets.

    But this would only ever matter in a situation where a tool database was set up with duplicated T-numbers. (and, where there were more than one tool with the same T-number available to the active spindle)

    Please Log in or Create an account to join the conversation.

    More
    20 Nov 2019 11:13 #150736 by mydani
    I got it, it's clear. Still, attributes like sharpness and the surface finish quality, is also important and depending on a tool but not configured like "normal" infos like offsets. But for this anyways another tool id can be used, so it still fits your description!

    Now I am really interested how it works currently in 2.8.

    Please Log in or Create an account to join the conversation.

    More
    20 Nov 2019 11:28 #150737 by andypugh

    Now I am really interested how it works currently in 2.8.


    The way it always did. The tool database stuff dead-ended years ago when nobody bothered to test or review it.

    If I was to resurrect it I might not even start with that experimental branch, I have had second thoughts about some of the implementation details.
    On the other side of the coin, I now know enough Python that I could consider the tooledit changes that would be needed to hide the new way of doing things.

    Please Log in or Create an account to join the conversation.

    Time to create page: 0.223 seconds
    Powered by Kunena Forum