ATC Project - Debug phase

I can't see why it wouldn't work.  Keep in mind that 'counts' mode version(s) have not been pushed to 2.8 on github.  I believe Andy pushed counts to 2.9/master a little while ago, but not sure which of the 4 or 5 versions he's posted on the thread are in master.

And yes, I'm trying to integrate carousel.comp in 'counts' mode with Probe Basic.  Given my inexperience with this side of things, it's been a challenge.

Assuming you want to use the existing PB screen buttons to manage the ATC, you have to (sort-of) follow the ATC control scheme created by the PB devs.  They don't just have a single "M6" remap file that handles everything.  They've broken up the control sequence in to multiple files, and near as I can tell there are a number of .ngc files in the subroutines folder which aren't used anywhere (legacy or abandoned).

The main issue with integrating carousel with PB is that the PB remap files contain the bidirectional pocket calculations and motor controls... which is unneeded if using carousel.  Carousel handles everything for you - you tell it a pocket and it does all the heavy lifting.

Those remap files also contain - I think - commands that control/manage the on-screen ATC widget so it follows or displays the correct pocket & platter alignment.  There's no documentation on the qtpyvcp page for passing gcode stuff back to cutom widgets.

I haven't gotten to the point where I can test out my remap modifications... maybe tonight is the night.  Either way my intention is to have a go and then report back how I got from OEM Probe Basic to Carousel Probe Basic.

I'm driving the pins through halshow.  I have halshow open during testing so I can adjust values and watch the state changes.

The newer halshow version has a number of features that make using it easier - such as screen buttons to set pin states.

To trigger jog-fwd & jog-rev, I click on the 'set' and 'clear' (or whatever they are named) buttons from the halshow screen.

I could be wrong, but I don't think using this method of driving the pins is the underlying cause of the jog issues.  If it were, then I don't think jog-rev would work perfectly while jog-fwd is acting up.

I plan on doing my first ATC commissioning tonight, and I have both jog pins connected to digital-out-nn pins in hal for that test.  Probe Basic has on-screen ATC jog buttons that I've mapped to an  Mxx.ngc file which contains M64 Pn / M65 Pn lines.

I can do the above tonight, or some other jog pin trigger if you think it would help eliminate user error.

Yes, it's acting like that in both directions, whether I set & clear the pin quickly or wait for the initial move to end.

And it works for jog-rev.  But jog-fwd does the final alignment back to the original pin.

I did not notice I could unhome carousel...  I guess because I had the homed pin connected to a digital-in pin the halshow 'clear' button was greyed out.  That should make testing easier as I won't have to restart LCNC every time I want to home the thing.

I'll be in a position to test it in about an hour.  Let me know if there's anything else you want tested in the mean time.

Test results:

• Test 1
  • Starting state: machine out of estop & on, carousel unhomed
  • Enable carousel < carousel homes to index pin & performes slow search.
  • set pocket-number to 3
  • enable carousel < carousel moves to pocket #3.
  • unhome carousel via halshow button
  • set jog-fwd HIGH then immediately LOW from halshow (i.e. like a momentary button)
    • carousel rotates to pocket 1, does slow search to 1
    • current position = 1, pocket-number = 3
    • state = 0
    • no further movement
• Test 2
  • Start at pocket 3
  • unhome carousel
  • set jog-rev HIGH then immediately LOW from halshow
    • carousel rotates to pocket 1, does slow search to 1
    • current position = 1, pocket-number = 3
    • state = 0
    • no further movement
• Test 3
  • Restarted LCNC, start with machine out of estop & on
  • no first enable of carousel, carousel at pocket 3
  • set jog-fwd HIGH then immediately LOW from halshow
  • same results as tests 1 & 2 - homes, search to 1, then stops with state = 0
• Test 4
  • Start at pocket 3, set to unhome
  • set jog-fwd HIGH, did not clear to LOW
  • carousel homed to index, slow search to index, then moved to pocket 2 and stopped
  • set jog-fwd LOW < carousel backed up to pocket 1 at slow search
• Test 5
  • Start at pocket 3, set to unhome
  • set jog-rev HIGH, did not clear to LOW
  • carousel homed to index, slow search to index, then moved to pocket 18 and stopped
  • set jog-rev LOW < carousel did slow search to pocket 18 and stopped.

Was that helpful?

We're still working out carousel.comp, but I figured I'd have a go at the toolchange choreography tonight.

I'm using the Probe Basic remap scheme/files, suitably edited for carousel instead of the PB ngc bidirectional pocket calculator.

Probe Basic splits up the toolchange sequence in to components.  I tried to follow those so my own scheme didn't vary too far from the original plan.  Here's the list of ngc files with basic functions:

• toolchange => Main toolchange macro
• M10 => Rotate to correct pocket, home if not homed
• M11 => Jog one pocket FWD
• M12 => Jog one pocket REV
• M13 => Home carousel
• M21 => Move tool from ATC to spindle (Orient, Lower head, extend ATC, activate PDB, raise head)
• M22 => Move tool from spindle to ATC (Orient, activate PDB, Lower head, deactivate PDB, retract ATC)
• M24 => Activate PDB
• M25 => Extend ATC
• M119 => Orient sequence (my addition, not in PB)
• load_spindle_safety => Set tool in spindle

store_tool_in_carousel => Remove tool from spindle, store in ATC

So right now M13.ngc and load_spindle_safety.ngc work.

All the other subroutines error out as they all refer back to parameters defined in toolchange.ngc (M6).  And toolchange.ngc errors out with something like parameter #<selected_pocket> is undefined.

That parameter is the first one defined in toolchange.ngc, and I also found a reference to it in stdglue.py.  Not really sure where the parameter gets defined...

According to the remap manual I see that #<selected_pocket> should be exported to the NGC code:

Then, the following parameters are exported to the NGC procedure:
: the tool number of the currently loaded tool
: the tool number selected
: the selected tool’s tooldata index

Sadly, I really, really don't know anything about python and can't tell if the file has something commented out, or if it's in the wrong flavor python (I'm on LCNC 2.9, qtpyvcp master, and PB python3), or something else...

I don't think it's a file path error since M13 works, but I just don't know.

Refining my question a bit...

I've collected  a dozen M6 remap examples from the forum, and all of the stdglue.py files refer to local parameters:
#<tool_in_spindle>
#<selected_tool>
#<current_pocket>
#<selected_pocket>

This is confirmed in the LCNC manual (remap section):self.params["tool_in_spindle"] = self.current_tool
self.params["selected_tool"] = self.selected_tool
self.params["current_pocket"] = self.current_pocket
self.params["selected_pocket"] = self.selected_pocket
Further in the manual:
An exposed parameter is a named local variable visible in a remap procedure which corresponds to interpreter-internal variable which is relevant for the current remap

But the LCNC manual (Gcode section) refers to global named parameters:
#<_tool_in_spindle>
#<_selected_tool>
#<_current_pocket>
#<_selected_pocket>

Why does stdglue use what appears to be local parameters, and how/where do those local parameters connect to the global parameters?

I wonder if having my [PYTHON] section in INI pointing to the wrong folder has anything to do with this...

EDIT - That wasn't it... I'd already changed the file paths.

Iguess my question still stands - why does there appear to be local parameters in stdglue instead of global parameters?