Help with ATC Widget

**PROBE BASIC** I am going to add a button to the UI that will run M28. I made the M Code to re-sych the ATC to the proper tool if something goes wrong like, but not limited to a power outage. It simply sets #5170 to be tool #1. This does work if I rotate the carousel to be on actual tool #1 and run M28, but until a re-start of the UI the ATC Widget will not re-reference the new position. What is the code to rotate the ATC sim to tool #1? Or simpler maybe, what gets ran on startup to rotate the ATC Widget to the proper tool, maybe I can simply recall it.

I looked at M10-M13, but found no joy in my approach to swiping their code to rotate the ATC Widget.
I felt their might be a function other than .rotate or .store_tool that performs just this, but I can't find it.

This may be quite useful for the many who do not have an index sensor for their ATC. Of course one could set #5170 to be any tool they want, or perhaps use an input text box to just use the misaligned tool as the current position. May be over-complicated to do the latter though.

Any help is greatly appreciated.

Are you not using the random ATC functionality?

Nope, I keep it ordered

Why would you want that?

seems to me that is causing a bunch of your headache, not to mention a ton more to keep up with. it is much more efficient to use the random pocket method and forego pocket numbers and call the actual tool number you want which is happily stored as one of every tool in your entire tool library matched to your cam software.

I have north of 150 tools and each is called by its actual tool number. no pockets or order to worry with, when i load a tool i load it by its number, if i want the order to be setup for a job to minimize tool change time I simply load the tool int he order they are needed in consecutive carousel pockets. as long as there are no gaps in the carousel pocket order the tool is always returned to the lowest numbered available pocket which is the pocket it was previously stored in. this is so much more efficient than trying to force a maintained order. in this sense there is no worry with what you are trying to fix mentioned above. I would strongly recommend using the random ATC method its just a no brainer really. it solves you creating all of these problems and fixes.

Really, I take tool 1 out of pocket 1, when I am done it goes back into pocket 1, if I need tool 2 it rotates to tool 2, I get it, I use it I put it back in pocket 2. Maybe when I grow up and get rich I can have more tools than I know what to do with, but for now that is not the case, and I am 54, so likely ain't happening.

Once again, can the the ATC be reloaded like on startup, or where do I need to look for the code to rotate it to #1?

We have far too many power failures in my neck of the woods, and this is a problem that a loss of power can create.

P.S. I have been writing this response for almost an hour because my flesh says for me to tell you what I really think of your response, but my Christ given Spirit tells me to forgive your in-ability to answer a simple question.

What happens when you have tool 17?

the graphic requires a restart and reference to synch, it needs this because it uses the referencing of the carousel to know that the physical platter is at pocket 1. you cannot resynch without a restart which reloads the file call in the ui background. so the short answer is you will have to restart linuxcnc and perform a reference of the carousel in order to bring everything to the correct working synch in software and the physical world. from there you can manually issue M10 P# (where P# is the pocket you would like to move too P1-16 in your case) to have it move the best direction to the required pocket alignment for your missing tool still residing in the spindle. I do not know if this is what you are trying to accomplish in your system as it is somewhat unclear.

As to my inability to answer a simple question, I did answer it in the form of a way that wouldn't require all of these forced fixes and that would not box you in a corner in the future. but from your previous answers in other posts it is clear you are set on tracks and not willing to change things even if it will better serve you in the future. this inflexibility is going to bite you, I can see it because i have already trudged this road you're on and spent more time banging my head against a wall than i care to remember, but It is your machine and if you prefer to personally uncover every issue you will come to face for yourself because this is a hobby and you enjoy the tinkering, I completely understand, I have hobbies like that myself and enjoy the adventure of it. If that is the case and I misunderstood my apologies and good hunting!

I have 20+ toolholders. ATC on the machine is BT40 except for a single pocket which is #8, don't ask how it is possible but someone must have changed the retention clip. I keep a chip clearing fan in that pocket and just load it by hand into the spindle, as it easiest to store in the carousel because is long with plastic fan blades. Most of the tools above 16 (are Caterpillar 40) I never load as they are face mills or drill chucks, and I usually just touch them off on the top of the part and never actually "load" them into the spindle for the sake of the UI. Of course they must be installed into the tapered tool holder to be used and clamped, and this I do, I just don't programmatically load them into PB.

So even if I have 150 and stick them in whatever pocket up to 16 at a time. I still need to know what pocket they are in random or ordered. OR am I missing something that is a magical process to make sure no tool ever gets out of phase when the power goes out during a tool change. Because what you think can't happen will happen, and most coders are pretty narrow minded when it comes to idiot proofing their own work. It is easy to invent a protective scenario, and throw all kind of reasons why someone else should conform to YOUR state of mind.

I am just trying to make an issue that has caused me extra work easier to deal with, by not having to shut down the UI and go to the .var file to update the tool.

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.

Then one might say, it sure would be nice if I could simply press a button and change #5170 to what is lined up to the spindle on my Geneva wheel. And rotate the ATC sim around to it, without having to shut it down again. But we live in a perfect world, with perfect ideas, and this could never REALLY happen, could it?

Yeah, like the extra probe length accepting a negative number idea. Was that a good idea? I had a need because I encountered something maybe others have not. It helps to keep an open mind when dealing with others, and not ridicule them. 

Advice...Never think your code is bulletproof, or your error handling is always sufficient. It will bite you every time.

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.