Probe Basic - ATC sim parameter question

[LCNC 2.9 RIP, qtpyvcp master, PB py3]

Still trying to convert PB to use carousel.comp and running in to a few of problems with the toolchange macros.

• toolchange.ngc
  • Parameter #5231 appears to be the tool number in the spindle.
  • #100 = #<selected_tool>
  • #110 = #<tool_in_spindle>
  • ##30 = #110    ; save tool number from spindle in pocket
  • #5231 = 0       ; empty tool in the spindle
  • but later on  #5231 = #100 with the comment:
    • Set persistent variable to remember tool in spindle after power cycle
  • Unclear on the logic here, could use an explanation

 

• Compounding my confusion
  • GUI button "unload spindle" issues the following MDI command: M61 Q0 G49 #5210 = 0
  • However, #5210 isn't referenced in any of the tool change related macros
  • On startup, the tool in the spindle is a random tool from the tool table (usually #48)
  • If I manually edit the probe_basic.ui file and add M61 Q0 G49 #5210 = 0 #5231 = 0 on re-start the tool in spindle is "0" as desired.
    • What is #5210 intended to represent?

 

• stdglue & parameters confusion
  • #100 = #<selected_tool>
  • #110 = #<tool_in_spindle>
  • #120 = #<selected_pocket>
  • Problem is that local parameter #<selected_pocket> isn't passed through from stdglue.  If I change to global parameter #<_selected_pocket> it starts working (i.e. DEBUG output recognized the parameter)
  • Further - #120 and #<selected_pocket> don't appear to be referenced in any of the macros.
    • Is this a legacy parameter that didn't get cleaned up?
  • Any thoughts?

Thanks for any suggestions.

There are numbered parameters at play as well here, you need to reference them for definitions.

linuxcnc.org/docs/devel/html/gcode/overv...:overview-parameters

Thank you, good reminder that #5210 is to cancel G52 or G92 offsets. And the "Q0" sets the spindle tool to 0.

But I don't understand why the persistant parameter #5231 isn't also written at the same time.  If the spindle is unloaded and LCNC shut down and restarted, the last tool that was in the spindle when #5231 was written appears in the spindle.

Just tested it and it's acting as I described.

• Start LCNC/PB
• Home & reference carousel
• change tool (M6) to put a tool in spindle
• unload spindle
• close & restart LCNC/PB
• one the ATC is referenced, the old tool is now showing in the spindle
  • because M13 calls M61 Q#5231 as the last line, and #5231 wasn't set to 0 when the spindle was unloaded before shutdown.

oddly enough i never leave a tool in the spindle on my machine so missed this for years, but i confirmed. i have corrected on my personal machine and it is now working in all situations i could think to test. I will update master after further testing and if you would like to test you can add the following lines in the macros:

load_spindle_safety.ngc:

o<100> else
M61 Q#<load_spindle_tool_number> G43 H#<load_spindle_tool_number>
#5231 = #<load_spindle_tool_number>
o<100> endif


load_spindle_safety_2.ngc:

o<100> else
  M61 Q#<load_spindle_tool_number_2> G43 H#<load_spindle_tool_number_2>
  #5231 = #<load_spindle_tool_number_2>
o<100> endif

M13.ngc
o130 while [#1 LT 12]
    #1 = [#1+1]
    #2 = #[5189+#1]
    (DEBUG, EVAL[vcp.getWidget{"dynatc"}.store_tool{#1, #2}])
o130 endwhile

M61 Q#5231 G43 H#5231 #5210 = 0

o<m13> endsub [1]


In the QTDesigner, change the UNLOAD SPINDLE BUTTON MDI command line to the following:

M61 Q0 G49 #5210 = 0 #5231 = 0


And the same for the UNLOAD SPINDLE BUTTON MDI command on the tooling page

see picture below for example:

 

Thanks for confirming that - I was really getting confused.

I'll make the edits and do some testing, although my M13 is going to be different than the standard one since carousel.comp does all the bidirectional calcs & motion instead of macros.

Have you had a chance to consider the other issue I'm having?
I couldn't find a namedparams.py file anywhere so I don't think the #<selected_tool> & #<tool_in_spindle> parameters are created out of thin air... they're supposed to be passed through from stdglue, right?

The stdglue.py file included with PB and atc_sim are missing updates (since ~2018), but they aren't fundamentally different and should work.

ok, so at the top of the subs is a list of parameters, those are entries from probe basic that are defined at the start of that macro call. we are just assigning them a number in order to create a temporary placeholder for the data entered in the probe basic linedit boxes. you can trace those back in the qtdesigner object tree on the right side. but depending on the macro you are in you can just click on the lineedit box to find the matching name used in the macro header. make sense? or did i explain it poorly(not unlikely..lol)?

I sort of got it, but

Do you mean a separate file with a list of params, or in each subroutine file there's a list?

What are linedit boxes?

This sounds like you're referring to qt designer. As in: click on the button while in qt designer and you can see what it does

I probably wasn't clear in my question. I'll repeat stuff you already know, but it's to keep it straight in my mind - not to tell you how your creation works:

The parameters I'm referring to are in toolchange.ngc (in all the different PB configs), and are not called directly from qtpyvcp or a PB screen button.  The buttons trigger an "M6", which is remapped using stdglue.  Remap takes the "M6" input and causes LCNC to run 'toolchange.ngc' instead of the built-in M6 behavior.

toolchange.ngc contains the parameters in question:
#<selected_tool>
#<tool_in_spindle>
#<selected_pocket>

The values of these parameters are written to local numbered parameters #100, #110, and #120 respectively.  Those local parameters are then used later in toolchange.ngc to calculate various things (is the tool in the carousel, how many steps to move, is the tool in the spindle, etc.).

Remap/stdglue is supposed to 'expose' various parameters and make them available inside subroutines/macros:: the tool number of the currently loaded tool
[*]: the tool number selected
[*]: the selected tool’s tooldata index
[/list]
[/code]

First question: when I query any of the above parameters using (DEBUG, the value of....), I get a result of #####.  This indicates that the parameters aren't being passed through stdglue.  Is this a problem in INI file  [PYTHON] section - i.e. wrong file paths on my end?  Because when I edit toolchange.ngc to the global parameter #<_selected_pocket> I get a numerical result from DEBUG.

Second question: #<selected_pocket> and #120 (the local which is given the value of selected_pocket) aren't used in any of the toolchange macros.  None of the eight .ngc files used (toolchange, load_spindle_safety, M10-M25, store_tool_in_carousel) ever use parameter #120.

Where is it used?  Since PB appears to ignore the tool table pocket numbers (because LCNC ignores pockets when RANDOM_TOOLCHANGER = 0), why is there a parameter in toolchange.ngc which appears to use tool table pocket numbers?

I understand (now) that the reason toolchange macros are so complicated is because LCNC doesn't take in to account the third type of toolchanger: semi-random toolchangers.  Non-random is for lathe turrets: pocket = tool, always.  Random is for double-arm ATCs: tool gets swapped with next tool in to same pocket, always.

In semi-random tool does not = pocket, but has to go back in to the pocket where it came from (all non-arm carousel ATC's).  It's this missing configuration/scheme that results in serious parameter & math gymnastics by the developers/integrators if they want more tools in the tool table than pockets in the ATC.

As you suggested a couple months ago:

The above is why I'm trying to unravel how the PB macros & parameters work (or dont).  The example configs have numerous .ngc files which aren't called/used anywhere and appear to be leftovers from testing (M23, extend.ngc, clamptool.ngc, etc.).  And it appears that #<selected_pocket> might be another 'leftover'.

Thanks again for your time.

ok thats alot to digest, so may be a few replies,

not all parameters will be used but these were the original generic atc macros and can be configured for your own machine as required. in my instance i use the random type which doesn't utilize the selected pocket, however i am configuring a lathe and it will use selected pocket. so this is in there as a starting point to be reconfigured to your individual requirement.

the macros you mentioned above were put in by me as excepts of the main Mxx.ngc macros to perform segments of the atc routine, they are useful if you have a sensor fail for "unsticking" the machine such as if the spindle is down on a tool and the carousel is out at the spindle and you need to untangle everything without running a bunch of individual m6x px code to accomplish that. they take into account safeties such as moving the spindle out of the way to extend if you need to access the carousel with the door open to manually remove tools or add tools etc.

the macros could technically be shaved down for your own application, but since these are examples to be used for both mill, lathe, whatever we did not remove all of the pre-existing lines in them in the event they would be needed for a user configuring their machine.

these were configured to accommodate the vismach simulator so that users could preview the atc functionality without having a machine connected using the atc sims.

in random mode, it does not always return the currently called tool to its previous pocket, it will sometimes move it to another empty pocket, it seems to do this to keep the tools as close to filling consecutive pockets as possible via the math.

yes non random is more for lathe type turrets or rotary head milling machines such as speedios or brothers which eject the tool in the head up move before rotting to the next called tools pocket location.

and as you mentioned arm types have their own requirements depending on single or double.

the parameters you listed above are system parameters predefined in linuxcnc and used in python and remapped m6 calls:

linuxcnc.org/docs/devel/html/gcode/overv...ub:system-parameters

in probe basic I defined what you might consider "pre-subroutines" that add desired functionality to the m6 calls for things such as offset safeties, coolant cannon aiming, probe safety etc.. but ultimately they are just triggering a normal old T#M6 which then is run through remap.

line edits are the entry boxes in probe basic, if you select a box while in designer it will have a name in the properties window to the right, those names can be used to pull the data into a subroutine. so for instance on the atc page when you enter a tool number in the box for the M6 call, it pulls that lineedit box's data into the "pre-subrotuine" m6_tool_call_atc_page.ngc. this sub adds some things used elsewhere in probe basic and pulls in other lineedit box data and runs some calcs etc, and issues a normal T#M6 which initiates the m6 remap and toolchange.ngc subroutine.

i find macros far more powerful than ladder or the component due to their very high degree of flexibility and easy programming, but that is just my own opinion and experience, others may find a complete python atc better suited or a classic ladder driven atc better or the comp better suited. for me its RS274ngc all the way..lol just what i like. beyond that i'm not much help when boring down into the other methods.

That's remarkably helpful.

First thought after reading your response is that I do indeed have an issue with stdglue not passing the parameters to remapped M6.  I'll poke around in the file paths as this is 99.9% an issue caused by my ignorance.

Second thought is that I should NOT start with the ATC sim config but with the 'standard' Probe Basic config and then add in the files/features/INI statements needed to get it working.  There's enough non-relevant stuff in the ATC sim config that it may (does) cause some confusion - especially all the required stuff for vismach.

It took me quite some time to (mostly) unravel how you all are animating/using the ATC widget, but now that I can manually trigger the widget through MDI I should be able to eventually get a tool change scheme worked out that's compatible with carousel.comp and moves the widget so the GUI matches reality.

I'm quite sure I'll be back with more questions, but for now - as you say - there's a lot to digest.

-Ralph

Out of curiosity, is there a reason your dead set on the carousel comp?