ATC Project - Debug phase
30 Jun 2022 11:43 #246265
by spumco
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.
Replied by spumco on topic ATC Project - (WOO!!!)
Out of curiosity: This works with 2.8.2 as well or only within 2.9? (I don't immediately see a reason as to why that would be the case).
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.
Please Log in or Create an account to join the conversation.
30 Jun 2022 12:27 #246266
by andypugh
Replied by andypugh on topic ATC Project - (WOO!!!)
How are you driving jog-fwd and jog-rev ? Jogging waits for the jog key to be released _then_ does the final alignment.
The easiest way (if you don't have physical job buttons) is to use sim-pin:
The easiest way (if you don't have physical job buttons) is to use sim-pin:
(halcmd) loadusr sim_pin carousel.0.jog-fwd/mode=hold carousel.0.jog-rev/mode=hold
Please Log in or Create an account to join the conversation.
30 Jun 2022 14:42 #246280
by spumco
Replied by spumco on topic ATC Project - (WOO!!!)
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.
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.
Jogging waits for the jog key to be released _then_ does the final alignment.
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.
Please Log in or Create an account to join the conversation.
30 Jun 2022 19:09 #246294
by andypugh
Replied by andypugh on topic ATC Project - (WOO!!!)
It should work with any LinuxCNC version.Out of curiosity: This works with 2.8.2 as well or only within 2.9? (I don't immediately see a reason as to why that would be the case).
Please Log in or Create an account to join the conversation.
30 Jun 2022 19:15 #246296
by andypugh
Replied by andypugh on topic ATC Project - (WOO!!!)
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?
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?
Please Log in or Create an account to join the conversation.
30 Jun 2022 20:03 #246300
by spumco
Replied by spumco on topic ATC Project - (WOO!!!)
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.
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.
Please Log in or Create an account to join the conversation.
30 Jun 2022 21:18 #246314
by spumco
Replied by spumco on topic ATC Project - (WOO!!!)
Test results:
Was that helpful?
- 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?
Please Log in or Create an account to join the conversation.
01 Jul 2022 04:27 - 01 Jul 2022 04:31 #246340
by spumco
Replied by spumco on topic ATC Project - (Remap Phase)
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:
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.
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
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:
#<tool_in_spindle>
#<selected_tool>
#<selected_pocket>
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.
Last edit: 01 Jul 2022 04:31 by spumco. Reason: Formatting
Please Log in or Create an account to join the conversation.
01 Jul 2022 13:41 #246365
by spumco
Replied by spumco on topic ATC Project - (Remap Phase)
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'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?
Please Log in or Create an account to join the conversation.
01 Jul 2022 13:49 - 01 Jul 2022 21:10 #246366
by spumco
Replied by spumco on topic ATC Project - (Remap Phase)
Last edit: 01 Jul 2022 21:10 by spumco.
Please Log in or Create an account to join the conversation.
Time to create page: 0.126 seconds