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.
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.
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.
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 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).
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.
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.
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.