QtPyVCP / Probe_basic - Changing tool table entries from macro or script

Hi everyone,

I am in the process of migrating to 2.9pre and probe_basic. Thanks to various documents and scripts this went reasonably smoothly. Besides getting to know various buttons and checking their functionality (I have been years with gmoccapy - leaving mostly due to probe_screen lack of compatibility with python3), it is now time for the nighty gritty - the majority of this is related to ATC.

Background:
I have built a 16 pockets carousel tool changer with pulse and index, driven by a cl stepper in velocity mode. It is currently controlled using carousel.comp which I would like to keep with regard to future changes. Making this work with probe_basic's macro structure appears to be some work, but it is straightforward.
In the past, I have used a rack-style magazine and managed the static pocket number using the pocket number entry in the linuxcnc tooltable. While there (at least at the time) was a bug regarding change_epilog export of the current_pocket variable, a work around with a numbered parameter fixed that. Using the pocket number with a rack allowed me to easily change the tools in the rack and edit the tool table accordingly without additional coding. Furthermore, based on the pocketnumber I used to differentiate between different tool pickup locations (e.g. any Pakcetnumber > number of slots: pick up/ drop off tool at a previously defined location for manual tool change). Since I do not want to put all my tools into the new carousel (probe and facemill + extended drills won't fit), I will need to work with the pocket number in the tool table again.

I am thus wondering, what would be the best way to access (read and write) the tooltable from a macro (e.g. write pocketnumber to tooltable). Alternatively, I guess I could write a python script to handle the entire remapping for the toolchange. However, I am a lot more comfortable with ngc macros, as my python knowledge is limited at best.

Do you guys have any pointers?

Side questions to how qtpyvcp and probe_basic work:
-Looking at the code of probe_basic and the way the macros for probing are created with numerous #parameters:
How are these parameters handled and passed on? In the *.ui file, all I see is a reference to the macro.ngc file, but not to a call command specifying which parameters to pass on from input prompts. I guess I am missing something;).
 

ok so for the atc question I'm not sure I completely follow, but if it is just to not have certain tools be stored in the carousel because of fitment, you could easily add a check in the macro that pulls in tool use entered tool numbers that are not to be stored from the UI, or you could manually enter them in the macro if you wanted a quick and simple solution.  just have the macro check if any of the tools in the spindle are in the non store tool number list and if so have it prompt for user to manually remove the tool and then click to proceed once tool is removed.  as for the carousel comp thing i think spumco was using that and finding his way through it, im not familiar with it but am interested to see it once its up and working and maybe play around with it some then. 

for the macros parameters, if you look at the top of the macro file you will see the parameters it is pulling in, they have a:

#<parameter_name> = #1 for example

the #<parameter_name> corresponds to a entry widget container/box/lineedit in the UI with the same exact name that is inside the <>

So in the probing section in the UI for the "PROBE TOOL #" box you will see that in the ui, that lineedit box is named the same as the probing macros parameters that use it.

  

is this what you were looking for?
 

I think I answered your more basic question in the other thread.

You can't work with pocket numbers in LCNC unless you manually edit the tool table each time you install a new tool in the rack.  If you have 16 pockets, you will have 16 'active' tools: #1-#16, and many 'inactive' tools: #17-#nn

The problem with this is that if you update your tool table... say you want to install the probe tool.  It's currently #99 for the sake of argument.

You manually take old #1 out of the spindle and load the probe in the spindle.
You open the tool table and change #1 to T99/P99, and change (probe) #99 to T01/P01.  Save, reload.
Then M6 T00, and it will put the probe in pocket #1 because its tool #1 (and LCNC doesn't care about pocket numbers)

However... you still need to rememeber to update the Probe Basic screen so that "Probe Tool" = 1.  Each. Time. You. Load. The. Probe.  (yuck)

Or... you can use the persistent variables the PB devs have created and everything is taken care of.  Tool table stays unedited, you can leave the probe as tool #99, and PB will figre out that if T99 has been associated with one of the pocket variables then set "S" speed to '0" when the probe is loaded in the spindle.

I forgot to ask in the other thread: what is your reluctance to using the PB variable array... why use the tool table (pockets) when it's effectively broken for semi-random ATCs?

Lcvette wrote:

ok so for the atc question I'm not sure I completely follow, but if it is just to not have certain tools be stored in the carousel because of fitment, you could easily add a check in the macro that pulls in tool use entered tool numbers that are not to be stored from the UI, or you could manually enter them in the macro if you wanted a quick and simple solution.  just have the macro check if any of the tools in the spindle are in the non store tool number list and if so have it prompt for user to manually remove the tool and then click to proceed once tool is removed.  as for the carousel comp thing i think spumco was using that and finding his way through it, im not familiar with it but am interested to see it once its up and working and maybe play around with it some then. 

From my point of view, using toolnumbers to check is not entirely practical due to having a tooltable with >>100 entries. I could technically blacklist some, but that becomes cumbersome. In the past I have used the pocketnumber in a non random TC setup. I will explain in further down in answer to spumco.

I'll be happy to document the process. My config is stored in a repository anyways (and has been for previous machines).

Lcvette wrote:

for the macros parameters, if you look at the top of the macro file you will see the parameters it is pulling in, they have a:

#<parameter_name> = #1 for example

the #<parameter_name> corresponds to a entry widget container/box/lineedit in the UI with the same exact name that is inside the <>

So in the probing section in the UI for the "PROBE TOOL #" box you will see that in the ui, that lineedit box is named the same as the probing macros parameters that use it.

  

is this what you were looking for?

 

Thank you very much. This is precisely what I was looking for. Missed that connection - makes things all the more convenient:).


@Lcvette:
Another thing I am not entirely sure about is how probe basic decides where to place a tool. Is this done by the user manually through the GUI? The macros and python seem innocent enough;).

spumco wrote:

I think I answered your more basic question in the other thread.

You can't work with pocket numbers in LCNC unless you manually edit the tool table each time you install a new tool in the rack.  If you have 16 pockets, you will have 16 'active' tools: #1-#16, and many 'inactive' tools: #17-#nn

The problem with this is that if you update your tool table... say you want to install the probe tool.  It's currently #99 for the sake of argument.

You manually take old #1 out of the spindle and load the probe in the spindle.
You open the tool table and change #1 to T99/P99, and change (probe) #99 to T01/P01.  Save, reload.
Then M6 T00, and it will put the probe in pocket #1 because its tool #1 (and LCNC doesn't care about pocket numbers)

However... you still need to rememeber to update the Probe Basic screen so that "Probe Tool" = 1.  Each. Time. You. Load. The. Probe.  (yuck)

Or... you can use the persistent variables the PB devs have created and everything is taken care of.  Tool table stays unedited, you can leave the probe as tool #99, and PB will figre out that if T99 has been associated with one of the pocket variables then set "S" speed to '0" when the probe is loaded in the spindle.

I forgot to ask in the other thread: what is your reluctance to using the PB variable array... why use the tool table (pockets) when it's effectively broken for semi-random ATCs?
 

I am sorry for having split my questions onto two different places. For future reference and for users that may look for similar solutions later on:
The principles and reasoning behind my toolchange setup and extravaganza is explained here .

For consistency a short TL/DR:
I disagree with the statement of the tooltable being useless for semi-random tool changers (i.e. toolnumber <> pocketnumber, tools has to return to fixed pocket number).
I agree with the assessment that the tooltable needs to be modified manually. I consider this a viable work around on GUIs like probe_basic oder gmoccapy where this is easy to do. I disagree with having to change the toolnumber (this to me would be unacceptable, as it will lead to disaster sooner or later with tools being mixed up and tool offsets being jumbled). All that needs to be changed is the pocketnumber which, given some handling in the remap macro for m6, works jsut fine (as implemented on my old machine with 2.9pre at the time (Late 2020).

I can understand your disagreement.  My response was provided from the point of view where the integrator does not have the ability to substantially create/edit python or stdglue.  (Me)

Fundamentally, LCNC is not 'set up' for a semi-random tool changer.  I guess my point was that until "TOOLCHANGER = SEMIRANDOM" is written in to LCNC, the integrator is forced to use some sort of workaround.  The workaround could be painful (see below), complicated (Probe Basic), or easy-ish? (your proposed scheme)... but they're all workarounds.

If LCNC was set up for a semi-random ATC, it would be simple.  "Tn M5" and LCNC checks what tool is in the spindle, consults tool table, sees T-spindle is assigned to pocket 9, commands carousel to go to pocket 9, and puts the tool away.  If Tn isn't assigned to a pocket, LCNC throws up a manual tool change prompt.  No back-stage coding or fiddling.  Simple INI file entries for carousel motion scheme and ATC pocket numbers.

But that's not how LCNC is set up now.

I agree with your disagreement .  I offered that option up as a 'last resort'.  It would work, but be painful unless the user rarely switched tools in the ATC.

I eagerly await your experiments with stdglue so LCNC uses pocket numbers appropriately.  If that works, it has implications beyond Probe Basic... other GUI's could use the same scheme and the tool table itself might be what the user consults for figuring out what tool is where instead of the PB ATC widget.  Specifically, the tool table would be displayed sorted by pocket number, not tool number, with the uninstalled tools following the last pocket number (an ATC-focused table, so to speak).

-R

I still don't understand what your issue is requiring pocket numbers.   I imagine you could add a column to the Tool table that was only used by the macros to block Tools from being stored.   But the issue I see here in my circumstance,  I have about 300+ actual tools, they are all stored in my tool table.   I have 12 pockets in my atc.   How would I assign each of them a permanent pocket location?   And more importantly,  why would I want to?   That would begin to overlap the tools' pocket numbers,  meaning I couldn't store two tools with the same pocket assignment.   Which would be a problem.

I can see this being useful if I had a chain conveyor atc with 300 pockets,  but then i could make the pocket and tool numbers the same. 

On my machine it's rare I don't have all pockets filled so the atc tool/ pocket locations never change,  if there are empty pockets,  it will try and store the Tool in spindle in the lowest open pocket number per the macro calculations.   But if you gave a go/nogo check to each tool number for allowing to store in the carousel,  this would eliminate the possible storage attempt of a tool that wouldn't fit.  

So based on that information can you help me to better visualize your requirement?  And why a tool number only wouldn't work? 

@spumco:
Thank for your additional insights. I agree, a semi-random option would be nice, however, with the multitude of possible configurations, coding this would be a nightmare as you would always miss a special case. Personally, I am fine with writing code macros and having a closer look at the python of the remap commands. Thus far, I did not have to modify this at all. I guess toolchangers will be on not entirely off-the-shelf-thing even for Siemens and the like.

@Lcvette
Thank you as well for pointing out your perspective. I guess I was to fixed on my previous solution, using the pocket number from the tooltable (after manually changing) them to make a rack work. This worked perfectly fine and so I thought it might be nice to continue using this. I have always filled the rack manually and since my carousel is sort of open, this would have worked as well. I expect to be changing tools every now and then and it would be faster. However - it is substantially more error-prone!
I guess I will follow your path by using numbered variables to handle everything in macros. It is substantially easier and ultimately makes more sense. The one thing that will remain different is the use of carousel.comp - makes live a bit smoother for me.

Btw: How does PB decide where to put a tool in the toolchanger? Manual input? Lowest pocketnumber that is free? Where is that decided (i seem to have missed that macro)

Lowest free pocket number.

M11 & M12 do the free pocket math.  M10 does the shortest path direction calc and calls M11 or M12 as appropriate.

Damn - missed that one:) Thanks!

I have edited versions of all the macros if you're not going with a geneva wheel mechanism.  I'm using a closed loop stepper connected to carousel.comp in index mode. (not an axis/joint)

Carousel.comp does the shortest-path math internally, so I wound up with macros that tell carousel.comp what tool number, and also let PB keep track of tool-pocket relationship through the persistent variables the PB devs set up.

I haven't posted up a complete config and explanation yet as the ATC widget is still acting up a little.