Tweaked Probe Basic UI fails to launch

Andy - I'm certainly no expert here, and I've no idea how the new tool database behaves or interacts with LCNC bits-n-pieces.  I probably won't be able to explain this properly.

But the existing tool table pocket field is ignored if INI file has RANDOM_TOOLCHANGER = 0

This doesn't affect carousel.comp's calculations and moving to a commanded pocket, but it caused all sorts of issues when I was trying to figure out why my remap never worked.  Carousel behaved properly when given a pocket number directly through halshow or digital-out MDI command, but the pocket number was never passed to carousel during an M6.

Specifically, the self.current_pocket and self.selected_pocket parameters will not return values in a nonrandom ini remap.  If you M6T1, LCNC will change to the first tool in the tool table (first line number in the table) regardless of what the tool number or pocket number is.

The end result is that the tool table tool line number is effectively the pocket number.  Fine if you only have tools #1-#n in the ATC, but if you want tools with numbers greater than the number of pockets in the ATC you have to edit the table.  Re-number the tool you don't want to a higher number, then edit the new tool number so it's in the correct line sequence.

To test my theory if you have a sim with a tool changer, please edit the tool table pocket numbers.  You can set them all to "0" or "-1" or "XXX" or leave them empty - doesn't matter.  Call an M6TN, and LCNC will install whatever tool is in the table on line 'N'.

I've been wrong rather frequently, but I don't think so here.  And I haven't seen any pull requests/updates that would have changed this behavior.

I think the issue we had, and correct me if I am wrong, it was in the subroutine load_spindle_safety.ngc

Where it would randomly populate the toolchanger when a tool was removed from the spindle? Is that what you are referring to?

TLDR: Not what I was referring to, but that may (possibly) be a result of the PB devs working around underlying problem.

As I touched on earlier, the PB devs seem to have dealt with the pocket number issue by using parameters in the .var file and storing the tool number in those parameters.  If you look at load_spindle_safety.ncg, you'll see that #5190 through #5201 (for a 12-pocket ATC) are checked to see if they contain values.  The parameters represent pocket numbers, and the values represent the tool numbers.  Values are assigned to the parameters at the end of toolchange.ngc sequence.

In load_spindle_safety.ngc those values are checked against the intended new tool number as a safety to make sure you don't load a tool number twice - which would then screw up the tool number to pocket number accounting.  i.e you can't have tool 1 in pocket 1 [#5190 = 1] and then also load tool 1 in pocket 10 [#5199 = 1].

If you have an ATC with pocket positions greater than 12, you have to create new, additional parameters in the .var file and toolchange.ngc macro (as well as a couple others) so the macro choreography knows where to assign tools when put in pockets >12.

If you don't create the new parameters and then map them in toolchange.ngc (and others), a tool installed in pocket >12 will 'disappear' or throw errors.  Or you could load the same tool multiple times in pockets >12 because there's nothing in the safety-check that's violated with parameters >#5201.

On my 18-pocket ATC I had to create parameters #5203-#5207 in the .var file, and also add those parameters to toolchange.ngc and load_spindle_safety.ncg (and may some other places).  If you have >20 pockets, you wind up haveing to use non-sequential numbers to find a free persistent parameter.

All of the above complexity is simply a response to the pocket number issue in LCNC, not a deficiency in PB.  Fundamentally, the issue is that LCNC ignores pocket numbers, and the outcome of that is that it doesn't pass #<selected_pocket. or #<current_pocket> through a stdglue.py remap in the way that you think it should.  What LCNC does is pass through the tool table line number the desired tool is on. 

I struggled for ages getting errors with my supposedly 'stock' stdglue.py remap.   What finally clued me in was reading through toolchange.ngc a million times and writing out (longhand) what everything was and what it was supposed to do.  When I got to this part:

;assign the variables passed by M6 to some parameters
#100 = #<selected_tool>
#110 = #<tool_in_spindle>
#120 = #<_selected_pocket>

I wound up searching all the other macros for <#_selected_pocket> and it's nowhere.  Then I poked through stdglue.py and found these:

# REMAP=M6  modalgroup=6 prolog=change_prolog ngc=change epilog=change_epilog
# exposed parameters:
#    #<tool_in_spindle>
#    #<selected_tool>
#    #<current_pocket>
#    #<selected_pocket>

And  kept trying to test out why stdglue wasn't passing the right values.

• Assign a pocket to a tool in the table, save table.
• Assign a numbered parameter to equal #<_selected_pocket> (or #<selected_pocket> or current pocket, etc.)
• Call a tool number and check the numbered parameter in the .vars file or use the magic DEBUG statement...
• Pocket number did not pass through.

And it dawned on me that the "#120 = #<_selected_pocket>" parameter was a legacy thing the PB devs copied from somewhere else, didn't use (because it doesn't work) and never cleaned out.  It was only this year that the slightly snarky comment # this is probably nonsense was removed from the stdglue.py change_prolog example in the official LCNC github config folder.

Current_pocket and selected_pocket aren't passed through properly, so you can't use them unless your tool table has exactly the same number tools as ATC pockets.  Have a look through all your toolchange macros, and the "OEM" Probe Basic ones.  I bet you'll never find selected_pocket or current_pocket being used anywhere.  Referenced, yes - but the values used to do something?  Nope.

Without those parameters values, LCNC has no way to tell the ATC macros what tool is in what pocket, or which pocket is in what position.  Hence the PB parameter gymnastics.

We had issues with the tool table and var file, and changed our load_spindle_safety file to this for our 16 tools

(load tool in spindle safety macro)

o<load_spindle_safety> sub
#<load_spindle_tool_number> = #1

#[5189 + #<load_spindle_tool_number>] = 0 ; Persist this tool as having been removed
#5231 = #<load_spindle_tool_number> ;Set persistent variable to remember tool in spindle after power cycle
G43 H#<load_spindle_tool_number>
M61 Q#<load_spindle_tool_number>
o<load_spindle_safety> endsub

M2 (end program)

Nice job with the named parameters.

Does that stop you from loading a tool number that's already in the carousel?

andypugh wrote:

spumco wrote:

But LCNC doesn't let you install tool #1 in pocket #5, because you've defined your ATC as a non-random.  Pocket numbers are ignored.

Is this definitely still the case? I really thought that it had been fixed.
 

github.com/LinuxCNC/linuxcnc/issues/970

github.com/LinuxCNC/linuxcnc/issues/1004

github.com/LinuxCNC/linuxcnc/pull/528

Far as I can tell, this never got resolved - or at least the stdglue.py example that just about everyone has based their toolchange remap on is still working the 'old' (broken) way.

spumco wrote:

Nice job with the named parameters.

Does that stop you from loading a tool number that's already in the carousel?
 

No it did not, Had to revamp it. If a picture is worth a thousand words, this must be worth much more...

I feel like I'm hijacking the OP's thread, but I'll plow on...

Andy,

It's certainly possible I'm doing something wrong with an M6 remap.  But in the stdglue.py file the comment under "M6 remap" section indicates it's intended to expose tool_in_spindle, selected_tool, current_pocket, and selected_pocket.

Could you run the rack toolchange sim again and do the (DEBUG, the value of current_pocket is #<current_pocket>)?

What I know is that using the bog-standard stdglue.py (as well as the one in the Probe Basic sim) resulted in the pocket number never being passed to carousel (through toolchange.ngc).  And every time I ran the magic comment to check the value of #<current_pocket> I got a ###### error.

Which would also explain the stdglue file top comment: 

spumco wrote:

I feel like I'm hijacking the OP's thread, but I'll plow on...

 

The intent of the original post was never even addressed, so don't be concerned about that. I appreciate all help, always learning you know.