ATC Project - Debug phase

I am trying to understand the jog-fwd behaviour, and the lack of homing on the first jog.

Have you noticed that you can setp "carousel.0.homed" to zero and then it will re-home?
Could you possibly make sure that the carousel is well away from the home pin, then unhome it, and try a forward jog, then repeat for reverse?

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?