ATC Project - Debug phase

Sorry Andy, I was unclear with my question.

Specifically, the newer LCNC version of stdglue has numerous sections (for lack of a better term) which I believe are intended to be templates for remapping T, S, F, M6, M61 words/codes.  In addition, there's a section on the end which appears to be a template for a pure python remap.

I was curious which of these template sections, if any, I could simply get rid of (or comment out).  I'm not trying to remap anything but M6.
 

Finaly, some tangible progess today.

Tried using the 'standard' stdglue.py from LCNC, and no significant change in behavior.  While fiddlign with it, I discovered that remap is not passing #<_selected_pocket> through to local variable #<selected_pocket>.  It is passing the other global parameters through.

That's what's been throwing me off for days, as I was changing the first one (selected_tool) or all three - but not just the last one.

So this:
#100 = #<selected_tool>
#110 = #<tool_in_spindle>
#120 = #<selected_pocket>

Had to be changed to:
#100 = #<selected_tool>
#110 = #<tool_in_spindle>
#120 = #<_selected_pocket>

Changed it in both my main toolchange.ngc and the m22.ngc (unloads tool from spindle), and some stuff started happening... like the PDB started activating, spindle oriented.  WOO!

Challenge the next is trying to pass through INI values to the remap o-codes.  I have Z-high, medium, and low positions and fast & slow speeds I'd like to have the head move to/at during the process. And I'd really like to have those values in one place, not repeated across 3-4 files (with a high probability of crashy-error).

INI file has this section:
and my two sub-routines have references to those values like so:
I've tried removing the outer "[...]" from the references.
I've tried changing to lower case.
I've tried connecting them to local named variables:
But no dice. I've even added the [RS274NGC] INI_VARS = 1 statement (supposed to be default), but the INI values aren't passing through.

Every permutation of (DEBUG, the value of parameter z_med is #<_ini[ATC]ZMED]>) results in ##### (for all the INI values, not just ZMED).

So close, but still stumped.

PS - don't want to hose up the editing above.

I tried changing #<selected_pocket> to #<pocket>, and that didn't work.  The only positive result was switching to the global parameter.

spumco wrote:

PS - don't want to hose up the editing above.

I tried changing #<selected_pocket> to #<pocket>, and that didn't work.  The only positive result was switching to the global parameter.
 

Comments.

COMMENTS COMMENTS COMMENTS!!!

Take the comments after the values out and it works:
to this:
And it's working.  There are other INI sections/values with comments and those work... but I don't care why right now.

OMG LinuxCNC is so hyper-specific I'm going to cry.

"I'm sorry, Hal, I can't do that."

This is like the worst Easter-egg hunt in the universe. On to the next battle...

It's moving!

Huge step forward last night... all the remaps are being called at the right time and sort-of doing what they're supposed to.

TLDR: I've got (at least) two problems now: one big, one small.

Smaller one is that one of the sequencing moves (Z-up after grabbing tool) isn't happening.  The 'Z-up' line is in the ngc file, and I can see the (print,...) statements before and after it, but it's not executing every time it's supposed to.  Result is that the head stays down when the tool change is complete - not good as this will lead to a crash in certain circumstances.

Bigger issue is that I just figured out (mostly) how Probe Basic is handling tools and pockets.  I finally got the atc_sim working (there's a minor python to python3 bug in a gui file) and watched how everything is choreographed.

Probe Basic doesn't use LCNC tool table pockets; it keeps track of which tool is in which pocket with extra parameters in the main parameters .var file.  The tool table in the sim even has the 'standard' pocket column hidden - now I know why.

I guess the intent was that the user just looks at the on-screen ATC widget and there's your tool in some pocket.  You aren't supposed to care about the pocket number: PB keeps track of what's where and won't let you load the same tool twice, or try to over-load the carousel.

But my carousel.comp-controlled ATC is using the LCNC tool table pocket numbers to move and keep track of where things are.

Further complicating things, I appear to have based my config on the non-ATC Probe Basic sim config, not the sim-ATC config.  Most of the back-stage qtpyvcp and python files are missing from my setup.

I can see the on-screen tool widgets getting put in the ATC widget pockets, but I now understand why tools are getting lost on-screen from time to time.  And, more importantly, why the carousel doesn't stay put when it's supposed to - or it moves to a different pocket than intended.

Example:

• T10 in spindle
• T8 in pocket #8
• Pocket #10 empty and lined up with spindle
• T8 M6
• ATC rotates to pocket #8, puts T10 in pocket #8 (with T8 in the pocket) and loads T8 in spindle.

Not good.  Of course, I don't have any tools installed and I've limited the head to Z-1.000 so there's no actual crashing right now.  But it would have.

Initial conclusion is that I'm going to have to figure out how to control carousel.comp using the Probe Basic scheme.  I suspect this is where I'm going to have to start:

The above is, I think, the reason PB and carousel aren't really talking to each other properly.  It may be as simple as changing the ngc file(s) from
to
But I'm not quite sure yet.  Still have to internalize how PB is reading/writing the parameter values and when.

All suggestions welcome, of course.

The alternative is to abandon carousel.comp and revisit treating the ATC like an axis.  Don't really want to do that, however; starting from square one on stuff I don't understand doesn't appeal.

PS - This is moving in to a QtpyVCP/PB phase of the 'dear diary' thread and less a "General LinuxCNC Questions" thread.  Maybe best to move it? I'll leave that to the moderators.

On further review, I may have been hasty in my earlier speculation about how Probe Basic manages the toolchange process.

Reviewing the atc-sim config (I didn't have before), I found that the sim is loading carousel.comp in index mode - along with the usual carousel.0.pocket-number connection to motion.analog-out-nn.

I'm not going to try editing my last post and mess up the formatting, but I'm sure I haven't really figured out how everything is related.  Still not sure where the pocket numbers are coming from, and I still think PB is ignoring the tool table pocket values, but the conversion may be less painful than I was worried about in the last post. 

 

Thanks Andy.
I've gone dark for the past couple of days, but have been working on this continuously.  I seem to have accidentally 'fixed' the error you pointed out like so:

instead of using the INI values directly in the gcode.

I also found that I was duplicating a numbered parameter in the toolchange.ngc file.  I think that was causing one of the ATC widgets to disappear and throwing off some calcs.  When I added more pockets than the sim (18 vs 12) the additional parameters which represent the pocket numbers duplicated another one used for something else later on in the file.

Just yesterday I had another 'Ah-Ha' moment and realized two things:

1. That the bulk of the HAL files in the Probe Basic atc_sim config are used to drive a vismach display, not the ATC widget or LCNC motion.  That seems to be where the carousel.comp component is being used and why nothing was connected to it in halshow
2. That the ATC widget is being homed & moved using those cryptic (to me) lines like

And since my carousel isn't being commanded like the sim is, the built-in widget isn't moving like I expected it to.  However, tonight's experiment will be to see if the Probe Basic devs left an easter egg for people like me.  Found this in the atc_motion.hal file:

And some similar stuff which might allow me to manage the on-screen ATC widget without the (DEBUC, EVAL...) stuff.  My initial thought is that I'll basically be commanding two ATC's at once - the real one and the on-screen version.

I'll report back with tears of shame or elation.

Tears of shame.

It looks like that atc_motion.hal file isn't attached to anything, or called up /referenced by anything.  There's no extra .comp file to create the widget pins, and none of the python files in the config or main PB folders appear (to my python-ignorant self) to reference anything like "atc_widget.something"

Frankly, it looks like another of the PB devs' tangents that hasn't been fully flushed out yet.  Or I don't understand it.

Back to the (DEBUG...) stuff.