I’m working on a new screen tab for setting up ATC tool fork positions and orientation. It saves and loads them from a new file adjacent to the ToolTable.tls, and the M6 routine will just look up positions here. My plan is to have each tool store it’s current ToolFork position, so any tool number could be used in any particular tool fork.
Currently I have the UI worked out, and I need to do some testing on my actual machine.
That is very cool, thank you for sharing.
You know the S30 is grounded, right? All you have to do is connect a magnet and wire between your touch plate (not the ground wire already attached to it from the factory) and the tool you want to locate and then you just do a boss probe of the HSD.
Much quicker and nearly perfect location mapping.
Of course if you have a real probe its even better but the S30 will complete the circuit without the ground wire from the plate.
Really glad you are here @corbin. I saw this thread over on the FB user group too. Really nice looking work. I assume you know Jason Parker too? He’s done a ton of work on ATC/Mach setups.
Thanks Eric! Yeah, I have chatted with Jason a bit over on FB, and I read through his ATC setup document – he did a great job!
I’m hoping to create something generic enough to allow anyone to easily setup and use an ATC without having to edit code. I’d be more than happy to give it to Avid to use when I’m done.
Currently I’m working on a Tool setup tab. It’ll allow one to map which tool fork has which tool, and easily load, fetch and (eventually) touch off the tool height when needed.
Corbin
Oh, that’s a good idea!! I’m using a HITECO spindle - I’ll have to check if it is grounded (it probably is) and see if this works. I think that could help with automatic tool height setups. I’m not sure how it could help with the tool fork setup though.
I’d love to see this develop and help where I can. We could make a Wiki here if you wanted too.
I’ll definitely post updates - particularly when I think it is ready to be released. Thanks!
(Posted to the FB group too, in case you are over there).
The second tab here is the Tool Setup; this is where you map the tool forks to the actual tools. The UI is dynamic; there will be a row for each tool fork that you previously setup. The current tool (in the spindle) is in green. The tool description can be updated inline. The “fetch” button will fetch to a pre-determined location – I need to add UI to set that. “Touch Off” will allow you to re-touch it off the height of the tool. I haven’t worked out quite how I want that to work – it would be nice if it worked with a permanent touch off spot, and it would be nice if it also worked manually with the Avid Touch Plate but adds some assistance to doing it.
Anything I’m missing that I should add?
I haven’t done testing on my actual machine yet…but soon.
I do plan to add some manual touch off abilities to this page. That’s what the empty right side will be for
I am a bit confused, sorry. Maybe it’s calling them “forks” that is confusing. Mach4 uses the industry term “pocket” to represent the tool holder in the Tool Table.
In Mach4 we then query the pocket for the tool by doing the following;
local currentPocket = mc.mcToolGetData(inst, mc.MTOOL_MILL_POCKET, currentTool)
Are you doing something different? I do apologize if I missed something.
Really!!?? I can’t find anything about the industry calling them pockets. Do you have any info on that?
(hit reply early)
I do see that field in Mach 4 - documentation is a bit light, so I had no idea it was there, and what it was for. I’d much rather use something that is industry standard. I picked the name “tool fork” because I thought that was what people called them.
Problem with the tool table is that someone could set Tool 1 and Tool 2 to both use Pocket 5. What happens then?
Yeah, its a thingy you learn after being around enough CNC machines. Just to get a fence around the nomenclature;
Tools go into “Pockets” for storage. A pocket is a “place” and not the thing that holds the tool. If its a static setting or location like in your project, there will be a “Post” or “Column” (or even “Mount”) which will have a “Tool Holder Clamp” attached to it. I have heard people use the term “fork” to refer to the clamp which is why I had to ask. The clamp is what adapts the post to a particular “Tool Holder.” An example of a “Tool Holder” would be a ISO30 or a BT30. From there you have collets and the rest which I am sure you already know.
No problem! I am kind of a stuffy individual and maybe spend a little too much time on nomenclature if you didn’t notice 
Mach4 Hobby documentation is sparse at best… Industrial isn’t any better.
Yep, fun stuff! This is referred to as “breakage/verification.”
You pick up the tool and you move over to the tool length sensor and you measure it. This is to A) check if the tool is broken and/or B) if you have the wrong tool in the pocket.
This is also why tool length sensors have two stops (triggers). One being the length and one being the error or overdrive (e-stop usually so you don’t break the machine or sensor).
This is to show you I didn’t just make it up 
Here is a nice example ATC system for an industry standard machine like the Haas, a 30 pocket carousel;
Awesome - thanks for the info - I’ll have to rename it to “Pocket” in the UI, but I’ll probably leave the code using the Fork terminology, just because I don’t feel like do a bunch of global renames. I picked “Tool Fork” because that is what the “Tool Holder Clamps” seem to be called, and Tormach called them forks in one of their videos on setting up the ATC.
Breakage/verification - yeah, I was thinking of adding in something exactly like what you are talking about, as I have seen that before on other systems.
Lacking verification, I’d have to enumerate all the tools use to see if another tool uses the same pocket. It’d be bad if an M6 T5 happened when T4 was in the pocket already or the user forgot to swap them out. I could probably mange it in UI, by doing it in code whenever a tool was removed from a pocket.
I can understand.
In your defense, you were working from that awful tool changer scripting from the “Mach4 Scripting Guide’” which when you started the tool pocket position lookup and it just went downhill from there 
You rightfully were like, “wait a minute, this doesn’t make sense as I have more tools than just the ones in the pockets!”
It is a good example of reading in a file but not a good example of a M6 and it never even considers pockets.
And now you are committing the cardinal sin in UIX 
What’s the saying? “Make it idiot proof and somebody will make a better idiot.”
Until you can figure out a way to stop people from walking over and moving tools around you are just creating more work for yourself.
Remember that most systems return the last tool to the pocket it just pulled the new tool from. So the tool will migrate around the carousel as it is used. In my carousel I do not have a loader arm and the tool holder clamp is what captures the tool holder directly so I did not implement that function.
Now, that said, the chain-magazine design I started with does in fact operate in that manner. But it also had a loader function. In that case (kind of like the Doosan) you actually load the tool by hand into the spindle and it places it for you in the magazine. Since you can’t access the magazine directly accept by take the housing off you can keep those silly humans from blowing themselves up.
Out of interest, have you started an M6 and then hit the e-stop yet?
Try the M6 and then Free Hold, Stop and disable the machine as well. So start the M6 and as soon as the machine starts moving hit any of those buttons.
I wrote an M6 script; most the logic is in a module. I’m working on setting up my tool rack right now, so I haven’t done any testing. I’ll be testing those things though…I don’t want to e-stop and drop a tool because I didn’t handle the result code right.
I have to admit that after 5 years of working on this very problem there are still edge cases where I would be happy just dropping a tool.
Good luck.
PS. Do feel free to ask me questions. I don’t have “all” of the answers, obviously. But I can help with some of the odds and ends that I have already discovered.