Allin1Chris wrote: ↑Mon Jan 13, 2020 3:16 pm
With this it should be possible to fully list out the bins for each tool without needing to change them all the time. For example if you have 8 tools bins but 16 tools, u can assign 1-8 as bins 1-8, and then tools 9-16 as bins 1-8 as well, i had no issues in my testing.
Chris,
I initially thought that I would simply have tools 1-10 assigned to 10 locations and for tools 11-20 I would edit the X and Y coordinates for tool 11 to match tool 1 etc... Bin numbers clean this up, but what if I needed to use tools 2,12 and 22 that were all were assigned to bin 2? I would have to manually edit the bin numbers to not all be bin 2 and keep up with it, for me a large potential for eventual error.
Hebs macro handles the bin number management real-time and reflects what is physically in the bins. The macro doesn't allow you to have more than one tool assigned to the same bin number since there can't be two tools in the same physical bin location. If you need a tool that currently isn't in a bin it prompts you for the location you want to place the tool and assigns the replaced tool to a non-assigned bin, keeping everything in sync.
I may not be seeing the forest for the trees, but to me, using bin numbers wasn't as important as managing what tool is currently in a bin and the ability to re-assign tools to other bins.
Clint in NW Arkansas
The more I learn, the more I realize I don't know...
(Note: Liking will "up vote" a post in the search results helping others find good information faster)
Clint....
As long as the human (usually the only error producing component of CNC) can keep up, my example will work. Just have the XYZ coords of 2, 12 and 22 be the same
Gary, what you are suggesting most definitely works using the existing capabilities of CNC12 but with a few drawbacks: As Clint says, if I need to use tools 2, 12 & 22 in the same job, I will have to mess around changing/transferring tools in the tool library, offsets and other settings, its a bit of a pain to do that and every change increases the risk of human error. As you say, human error is the majority cause of CNC errors, so I want to minimise those chances. I could try to setup my tools to minimise the likelihood that a single job will use those tools allocated to the same bins but there is no guarantee. My rather inelegant 'hack' creates a very user friendly solution to try and stop me from making mistakes.
Its great that Centroid are helping but sadly their solution does not get around this problem completely yet. CNC12 is a tried and tested system which was not designed for garage hobbyists like me and I really appreciate them taking the time to even acknowledge my problem (its my problem not Centroid's) let alone offering a solution so quickly. I hope that they will consider making this possible in future versions of the software. I am really looking forward to V4.22 when the VCP will be customisable - I have some ideas of things I'd like to try.
(Note: Liking will "up vote" a post in the search results helping others find good information faster)
Hebs…
You may have misunderstood what I was saying. Using your scenario above you would not have to mess around with the tool library, offsets or other settings. You would simply have to place the correct numbered holders into the forks manually. Of course I assume that all tools, once installed into the holders, have been measured.
This may in fact be much easier than the manual entry of which tool is in which bin location. This would be especially true if you placed a couple messages in the M6 macro for second or 3rd tier tools that paused while the change was being made. I can see that having the system store the fact that tool 22 is in BIN 2 is a plus.
This discussion makes my decision to setup 40 tools look better every day!
40 tools! I’m jealous! I wanted to build a carousel but I don’t want to lose the ability to run a 4th axis. My 11 tool rack only cost £60 to build in less than a day (took 4 days to understand the software). I’ve finished building a simple device to change the height of my fogbusters for each tool change - consuming none of the outputs from my Acorn board!
In your setup, how would you deal with a job that needed to use both tool 2 and tool 12? They would both be assigned to bin 2 wouldn’t they?
(Note: Liking will "up vote" a post in the search results helping others find good information faster)
Allin1Chris wrote: ↑Mon Jan 13, 2020 3:16 pm
For Bins to work, Parameter 160 must be set to 1, otherwise they cannot be used. Bins are a Enhanced ATC functionality. Enhanced ATC for our software is mainly used for carousel or umbrella style tool changers, and requires some PLC to work correctly.......
....Let me know if you guys come across any issues with this. Simply extract the Zip into your cncm directory and overwrite files, or if you have your own PLC already, Extract the M6 and M18 macros, and make the necessary change to your PLC and recompile. The PLC in zip is v4.20.
Thanks Chris, it works great! I am now able to use my tool rack how I need to. When I wrote my 'hacky' version I learned quite a bit about macros and built some functionality in to them that was really useful - nice to have but not vital (the ability to deal with tool library errors not just highlight the error and stop the job. e.g. if the 2nd tool on my job is a tool number that isn't in a bin, then it gives me the chance to correct it then continue).
I am trying to replicate it again but when parameter 160 is not zero, tool changes clearly go though some processes (tool library check etc..) before they get to mfunc6.mac. I am happy with how to write the macro (I already have).
Is it possible for me to catch this pre mfunc6.mac? or is the code relating to parameter 160=1 (containing library check etc..) built in to the main program?
(Note: Liking will "up vote" a post in the search results helping others find good information faster)
side note....parameters 700 - 799 are for reserved for general purpose user use. cnc12 will never use a parameter from 700 to 799 for a built in function of CNC12, now or in the future, guaranteeing that a custom macro using a 700 - 799 variable will not be broken by a future software update.