So you randomly loaded your random carousel up with tools in this randomized order : 3, 8, 54, 62, 17, 35, 9, 4, and 22. Why, because it just randomly turned out this way. There are no empty spaces between the tools, somehow you lose power during tool change and when it comes back online, you find that when you called for tool 35 you were given tool 9, and knowing no different because your mind was not trained to keep up with randomness of the random setup, you hit cycle start and low and behold, the tool length is 2" longer on tool 9 than it is on tool 35.
Is it a possibility that this COULD happen, my overwhelming answer is a resounding YES.
no, because each pocket has a var file parameter number assigned to it. in that parameter number resides the tool number stored. the worst case scenario would be if the power outage failed mid tool change and then there is a chance the tool was not recorded. however upon a restart and reference if there is no tool recorded in the var it would remain 0 and show that pocket as empty. it is no different from how your setup works it just doesn't constrain any single tool to a dedicated pocket. I have used this now for 5 years and never had an issue with it except when i had a var file get overwritten by my own mistake. in this event you would need to manually edit the var file to match whats in the carousel, but again you would face the same issue. so no that concern is unwarranted. whats better is if power is lost and say tool 54 from pocket 3 was in the spindle, because the change completed, the var file was updated as pocket3 being empty and tool 54 as residing in the spindle. you would simply restart the machine and reference the carousel, it will show pocket 3 empty and tool 54 in the spindle. just hit the store tool in carousel button and it will return it to pocket 3 providing pocket 1 and 2 are occupied.
this method also doesn't care if you put tool 999 in the carousel, the offset is tied to the tool number and the tool data can reside in your cam tool library as well so it makes camming very easy and you don't have to worry with changing tool numbers around in multiple places. it just works better than a dedicated setup.
you CAN always load tools 1-16 in pockets 1-16 and provided the carousel always holds those 16 tools except when one is called to the spindle, the tools will always be returned to their previous like numbered pocket. then at startup you would simply go about business as usual and regardless of it being on pocket 1 in software and in the real world and say tool 9 being in the spindle and pocket 9 being empty, it will identify pocket 9 as the first open pocket and automatically store tool 9 in pocket 9 with no other requirement except to call a different tool or store the tool with the store tool button. this in my opinion is what makes the random atc functionality much easier to work with and keep track of everything.
now you mentioned having multiple toolholder types and that is a reason to need dedicated pockets if you plan on intermingling BT and CT in the carousel. however, long term this sounds like a recipe for a headache. ***if it were me** I would sell the CT and buy more BT to simplify my life, especially if its only a handful of them. used CT tool holders will bring probably 2-3 times what new replacement BT holders will cost so I wouldn't blink twice doing that and then going forward you eliminate all of that headache.
you are not wrong in your statement that it is easier for me to have you to conform to my design, because it means i don't have to work for nothing to make your design work. if you want your own design, you should be prepared to make that happen on your own. I can tell you that I have been inundated with "must have ideas" from people who in truth really just want it changed for their purposes and where it is truly a very odd situation. there are of course good ideas that will benefit all. and as those are presented they get more scrutiny towards implementation when time is available.
the reality is that many people want things added and only 5 that i know of have actually done something about it and offered up a pull request. which means the core of any changes fall on my or Turboss's shoulders, and its hard to be motivated to fix something that isn't causing an issue for me in my daily use of the software. if its a glaring issue that i can replicate and is just hiding from me because of the functionality i use infrequently then i gladly fix it promptly or if its a safety issue that snuck by us etc, but customizing things is part of the nature of the individual users requirement. many of the changes that have been implements or the design of the functionality have evolved. for instance we started with non random atc, it was much simpler to automate because it didn't have to worry with a mismatch of pockets and numbers, however we quickly discovered its limitations and shifted gears to utilize the random method which has been great. we don't make these suggestion blindly or from a position of speculation.
the probing, your concern with not being able to always probe from from tool change height, if you have tried probing from toolchange height my guess is that you would have quickly stopped trying because there is no way to get a good line up between the probe stylus and the work piece from that far away unless its only for z single touch probing on a decent sized work piece. but trying to hit a corner within a reasonably set stepoff width from 14+" away or getting near to rough center for a boss/pocket/ridge/valley probe your gonna miss as much or more then you hit triggering an error. you stated it seems like a waste of time to jog near the part, but to me it takes all of 2 seconds, and i never miss from those positions and the max z functionality works exactly how i need it too. so why would i want to change that? what data should compel me to change a working setup? is it your constant use of probing and you found a more efficient method or is it an untested theory during setup from speculation alone? these are the things i have to consider before making changes to the master branch of the ui offering. the plus side is that its all macros and the user has full access to make any changes they require even without the need to edit the ui. so for those situations i call it a user customization requirement.
I don't want to discourage input or feedback or issues that get found, but I also cannot make every change every individual would like.. soo lol maybe that sheds some light from my perspective. I know your perspective, because that is what brought around this whole UI build/project and I can gaurantee you it came with a plethora of headaches and frustrations that will be never ending.
just the nature of this monster project.
