Extend M6 remap to allow return to orig. position #2706
Conversation
Made a switch in the Versa_toolsetter section that give the option to direct the return point to either: Option 1 (Default if no option specified): Gmoccapy default already released with QtDragon: Only returns to the Change_Position z height, as programmed at: configs > sim > gmoccapy > macros > change.ngc Option 2: AxisDefault Return to the XYZ tool change position, as programmed at: configs > sim > axis > remap > manual-toolchanges-with-tool-length- switch > nc_subroutines > Manual_change.ngc Option 3: New QtDragon option: Return the tip of the current changed tool to the XYZ position of the tip of the old tool, moving to Tool Change Z first, then Original XY, then down to new offset Z. Also moved some error checking earlier. Changes made to documentation: All changes are limited to the “Auto Tool Measurement” section. (Currently, LinuxCNC#14) except for 1. fixing one typo, 2 adding a [[sub:touch-plate]] tag to the Touch plate section so that the Auto Tool section can redirect readers there. 3. Increase the Table of Contents Levels depth to 4 (default is 2) In the “Auto Tool Measurement” Section 14, I made the following changes: Created a section at the beginning called “Overview” (new 14.1) In this section I explain that this procedure intends to use two probes. be done with one or two sensors. The one sensor only method requires the Tool Switch and is described as One Sensor Workflow. The two sensor method makes use of an additional spindle probe, also called a Renishaw probe. It directs people with repeatable tool holders to the Touch Plate section. It directs those with automatic tool changers to axamine the axis remap code rack-toolchange. It then splits the documentation into “Work Flow Overview” which includes most of the documentation above the QtDragon_HD screen intact. This becomes section 14.2 In this section, I moved pre-requisites earlier (ie, instead of warning near the end to have Use Tool sensor selected, include this along with other pre-requisites under the Important heading near the top. In the “sequence of events” section I added the extra possibilities of this ngc code modification: The INI setting [RETURN_OPTION] can elicit additional behavior after the return to the [TOOL_CHANGE] Z position: • If INI’s [RETURN_OPTION] = 1: (or if it is undefined), no further action. This is the default behavior of the GMOCCAPY M6 remap procedure • If INI’s [RETURN_OPTION] = 2: Continue with a Rapid Move to the X and Y position defined in INI’s [TOOL_CHANGE] X and Y settings. This is the default behavior of the AXIS gui’s M6 remap procedure. • If INI’s [RETURN_OPTION] = 3: Rapid Move to the original X and Y position at the moment the tool-change started, then Rapid Move down to the now offset Z position at the moment the tool-change started. This effectively moves the tool head back to the position just prior to the tool change. This is new behavior exclusive to QtDragon as of 4th quarter 2023. Added another section following that one called “Workflow Example” (new section 14.2) Renamed the next section to be clear it only applies to the QtDragon_hd interface (was 14.1, now 14.4) All the following sections automatically increased in numbering. Added the RETURN_OPTION explanations to what is now section 14.6.3 “The Tool Sensor Section” Corrected “TOOLCHANGE” in section 14.6.3 to be “CHANGE_POSITION”
| ; | ||
| ; G10 L1 is the Set Tool Table Offset: it changes the tool table offset, | ||
| ; it DOES NOT change the offsets in the current coordinate system. (that would be G10 L2) | ||
|
|
There was a problem hiding this comment.
I think there is another pull request adjusting for other user systems.
Maybe you could test/confirm the pull?
#2562
There was a problem hiding this comment.
I'll be happy to test it!
I need to look at it a bit more to figure out what the right test conditions should be.
Sadly, I'm looking for work and so I have to finish some resume work this evening, hopefully I can look at this late in the night.
|
|
||
| G43 | ||
|
|
||
| #<calculated_offset> = [#<touch_result> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>] |
There was a problem hiding this comment.
if you're going to calculate the offset to print it - might as well use that in the G10 command .
There was a problem hiding this comment.
Yes, I agree.
|
Does the sim configuration 'qtdragon_auto_probe' need updating? |
|
Should we change the target to a later branch? If so, which is that, and can that be changed here or does this pull need to be closed and re-pulled? |
|
Master would be the branch, but we can do that later or maybe 2.9 would be ok anyways - it does default to the same behavior. it can be changed: |
|
OK, my apologies for being so long in getting back to this (my job search prep took me a lot longer than I thought it would).
Out of the box, when I try the qtdragon_auto_probe sim, and I try to home the Z axis, I get "Operator Error: Cannot home while shared home switch is closed j=2." I figured that was me not knowing something, but based on your question here and the comments on that other pull request #2562 , then perhaps: yes, there may need to be something done for the sim. But I have an actual machine that I've been testing this remap qt_auto_probe_tool.ngc with, so I'm going to do the test physically. My plan is to: Advise if that's a bad/insufficient course of action. Thank you for your time. |
|
Sorry, I am slowly working through the PR backlog. |
|
Hey, I would love to keep this alive, but I don't know what you need.
I've been swamped with a job search, so I haven't delivered on a testing
video.
If I refresh my repository, can I redo the pull request and have the CI
tests re-run?
Thanks!
Vector Hasting
…On Thu, 14 Dec 2023 at 03:57, andypugh ***@***.***> wrote:
Sorry, I am slowly working through the PR backlog.
Is this still live? I would like to re-run the CI tests, but don't seem to
be able to (perhaps the PR is now too old?)
—
Reply to this email directly, view it on GitHub
<#2706 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMGEZMGAJLZQSM3Y7YH2I43YJLSRBAVCNFSM6AAAAAA6KWYTPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJVG4YTINJSGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I am still not clear on what this PR is for. |
|
Hey Andy,
thanks for this engagement! Wow. I'm honored, and I mean that sincerely.
I'm sorry the following is so long-winded: I'm trying to do justice to my
thinking so far.
*My background*:
I'm coming from 3D printing to CNC. I've built a LinuxCNC system of my own
design for a project that's more artistic than engineering (though I'm
looking forward to also making robot parts). I'm using open-source tools.
The open-source bit includes FreeCad, whose Path processor outputs G-Code
including tool change commands. But FreeCad doesn't provide any
programmatic way to re-position the tool from the safe-z-height above the
tool-setter back to where the work was happening before the tool-change.
When I got qt_auto_prope_tool.ngc working under the QtDragon interface, I
couldn't use my Path output because it would immediately start trying to
cut from the z-safe position over the tool-setter.
Which brought me to:
*My thinking was: (philosophy)*
Since FreeCad (the example CAD that formed my 'standard') assumes that once
the tool change is complete, the tool is back where it was when the
tool-change started, and since I'm otherwise an 'outsider' to CNC, that
seems to me to be what the tool change *should *do anyway: put the tool
back after changing it.
I didn't see a "standard" tool-setter option other than using M6 remapping.
(That might be wrong, see curly brackets below.)
I discovered that the "standard" supplied remap codes for Axis and Gmoccapy
don't return the tool either, but neither are they "standard" since they
both behave differently from each other. Therefore it seemed to me in all
these cases the remap .ngc files were provided as incomplete examples for
people to take and further refine.
I was thinking, based on my reading of the forums, that tool change is
inherently non-standard since there are so many different ways to
accomplish it. It seemed that QtDragon was providing qt_auto_probe_tool.ngc
as a way to make it easier for those in my specific situation (manual tool
change with a tool-setting probe) to get up and running.
{
But maybe that last thought was all wrong: you said "there is built-in
behaviour for where the tool goes for a normal, not-remapped toolchange."
If so, please point me to documentation on how that works? Does it work
with tool-setters? Where is it documented?
FYI: I have looked at:
[a] https://linuxcnc.org/docs/html/man/man1/hal_manualtoolchange.1.html :
To me this seems like a method to basically pause processing and let you
fully-manually-change-a-tool: ie: you jog to where you can get to the tool,
then jog back, and then answer the dialog box to resume processing
[b] http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolChange : My read of this
was that it tells me the pins and orders of operation that happen so that I
could write a routine to automate tool changing, ie with a carousel, or a
chain, or a jukebox or whatever.
}
Moreover, it seems to me that tool changing necessarily involves some kind
of movement of the tool. Therefore the question of what is "before, during
or *after" *(to your point above) seems (IMHO) like it involves a more of a
spectrum and less of an absolute. So I'd argue that I'm not proposing a
change *after *the tool change, but rather a *completion *of the tool
change (at least in the practical sense).
To summarize my thinking: I felt that (a) what I found in this remap code
was essentially an incomplete example (and therefore not actually a
standard part of the interface), where people are supposed to take it and
modify it for their own machine, (b) it would be helpful for people to have
an example that includes the behavior for returning the tool to initial
position, (c) there isn't a "standard" behavior for remaps in LinuxCNC, but
rather two behaviors, neither of which is useful to a large pool of users.
That last point (c) brings us to:
*Why this proposed mod, aka what now?*
I guess I still feel there would be a lot of advantage to having a
canonical automated-tool-measure-and-tool-return program that new users
could pull off the self and get working. It seems to me that providing a
'final-foot' return isn't so much "custom" as it is "right-fit" for a wide
swath of users, specifically those who do not have an automated tool
changer and/or don't have repeatable tool holders (both expensive,
relatively high end items) but who do have a tool-height sensor (a cheap,
entry-level item).
In that world, I'd love to see the functionality I'm proposing somehow
enter the LinuxCNC canon.
As to why it should require adding a parameter to the the .ini file, that's
my ignorance: I didn't consider that a negative. I suppose that as I combed
through the documentation for QtDragon and founds loads of .ini changes for
that remap code (adding it and a bunch of paths to the RS274NGC section in
the first place; then in order for it to function you need a probe, which
means adding the Versa_Toolsetter settings, which I think you helped me get
the documentation cleared up on)... so to me adding another parameter to
.ini just seemed natural.
If that's a bad idea, and even if not, it it brings me to:
I've actually been wondering about the risk to those who have the current
qt_auto_probe_tool.ngc in their .ini file. It's a point you raised in
GitHub. What if a better approach for me to have taken was to suggest a
separate qt_auto_prope_tool.ngc file, with explanation of its optional use
in the QtDragon documentation? Something like
"qt_auto_probe_tool_w_return.ngc," or whatever.
In that case, (a) there would not be any additional "Return_Option"
parameter in .ini file, because you'd make that choice by selecting the
different file in the RS274NGC section, (b) there would be no risk of a
software change for those using the current one, (c) I would address its
possible inclusion in an .ini configuration in the QtDragon documentation,
and (d) I believe the "how to use" procedure I proposed in the QtDragon
documentation would stay almost exactly the same (I'd want to test it
again).
[Alternatively for the (d) point on "how to use" documentation, it could
only appear in the documentation section of the
qt_auto_probe_tool_w_return.ngc... though I would still vote for it being
in the QtDragon web document as well.]
What do you think?
(I know that was long, but I hope it wasn't too long)
All the best, and Happy Holidays.
Vector Hasting
…On Tue, 26 Dec 2023 at 16:00, andypugh ***@***.***> wrote:
I am still not clear on what this PR is for.
There is built-in behaviour for where the tool goes for a normal,
not-remapped toolchange.
But this seems to be meant to address where the tool goes *after* a
remapped tool-change?
It seems to me that the whole point of a remap is to get the behaviour you
want, and that it makes more sense to put the custom behaviour in the
custom remap, rather than add it to the base code.
Can you explain why you think this belongs as an INI setting rather than
as part of the remap?
—
Reply to this email directly, view it on GitHub
<#2706 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMGEZMFEORQEAKHPTO27UV3YLNQKHAVCNFSM6AAAAAA6KWYTPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRZHAZDSNBTGM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I see now there is a conflict with the documentation... Should I update this pull request by refreshing my qtdragon.adoc, the re-applying my changes, then updating my pull request... Or are we going to branch to the "change this pull request to suggest a new 'qt_auto_probe_tool_w_return.ngc' (or whatever) file being added to the repository, instead of modifying the old one? Or is this pull request going nowhere? Thanks! |
|
The "built in" begaviour that I mentioned was basically prior to the tool change. It's a few INI options: Bear in mind that LinuxCNC was designed before the days of high-speed spindles which only accept collets. Back then there was no need to probe tool length as the common tool holder systems all had repeatable length. (CAT, BT, R8 even) I imagine that FreeCAD only moves the tool to a safe change position, and assumes that it is still there when the code resumes after tool change. Which ought to be a safe assumption. I still think it is the job of the toolchanger routine (even if is is a "real" toolchanger with repeatable holders) to put things backj where the G-code left it before continuing the code. In fact, I don't even think that this needs to be configurable, the remap routine should just do it. If there are "stock" library routines that don't do this then I agree that they probably need to be improved. Not that there are any "stock" remaps, in that they are really intended for integrator customisation. Even "standard glue" exists in at least three different versions in various locations in the codebase. |
|
I am soooo sorry for the long delay.
I got Covid while on vacation and didn't see this message until I couldn't
think very well. I'm on the slow mend.
Here's my response and questions:
First: (regarding pull #2562
<#2562>)
Does this discussion affect whether I should be also testing Pull #2562
<#2562> ?
ie, specifically, that change affects this same re-map code
(qt_auto_probe_tool.ngc), which, as you say and I agree, 'are really
intended for integrator customisation.'
I believe the effect of #2562 is to change the error handling and what is
displayed on the debug messages. However, I'm not sure the author had the
program running. Therefore, when the author says his change is "Made sure
both calls to G38.2 are changed to G38.2 (sic?) with a test verifying the
status," I don't think he was able to confirm this had any effect. I'm not
sure it will be the desired effect.
However, if we're putting a really high-bar on changing 'integrator
customisation' code, then should we be altering message handling in
qt_auto_probe_tool.ngc.
Second:
You say above that "the remap should just do it. If there are "stock"
library routines that don't do this, then I agree that they probably need
to be improved."
To me that means we should improve qt_auto_probe_tool.ngc, because I have
tested it extensively, and it does indeed not leave the machine in the
position it was in when the routine was called.
Which is the reason for this pull request.
On the other hand:
Third (and Last):
I think it would be easier and safer if I just reverted all my changes, and
proposed a brand new version of qt_auto_probe_tool.ngc, called, perhaps,
qt_auto_probe_tool_and_return.ngc.
That new "stock" remap would therefore add this version to the community's
capabilities, but would not modify any existing installations. For indeed,
anyone who is using qt_auto_probe_tool.ngc has probably customized it to
fix it. If they are also applying updates through the repository, then this
would change whatever they had customized.
I would then also re-author the documentation changes. I believe they are
now in conflict with the repository, so I would need to do that anyway.
However, instead of the example "qt_auto_probe_tool.ngc" I'd write in "
qt_auto_probe_tool_and_return.ngc."
*In summary:*
1. Should I be testing Pull #2562
<#2562> or is it not going to be
approved because it alters what is customization code?
2. Does this pull request rate being approved because the "stock" remaps
shouldn't leave the machine in a different location?
3. Regardless of #2, would this pull request rate being approved if instead
of altering existing "stock" routines, it proposed a new "customization"
routine?
Thanks again!
Vector Hasting
…On Sun, 7 Jan 2024 at 14:57, andypugh ***@***.***> wrote:
The "built in" begaviour that I mentioned was basically prior to the tool
change. It's a few INI options:
http://linuxcnc.org/docs/stable/html/config/ini-config.html#sub:ini:sec:emcio
TOOL_CHANGE_POSITION , TOOL_CHANGE_QUILL_UP, TOOL_CHANGE_AT_G30
Bear in mind that LinuxCNC was designed before the days of high-speed
spindles which only accept collets. Back then there was no need to probe
tool length as the common tool holder systems all had repeatable length.
(CAT, BT, R8 even)
This is still the case now that we have HSK and Capto (I am really liking
Capto, having bought a holder to experiment with)
I imagine that FreeCAD only moves the tool to a safe change position, and
assumes that it is still there when the code resumes after tool change.
Which ought to be a safe assumption.
I still think it is the job of the toolchanger routine (even if is is a
"real" toolchanger with repeatable holders) to put things backj where the
G-code left it before continuing the code.
In fact, I don't even think that this needs to be configurable, the remap
routine should just do it. If there are "stock" library routines that don't
do this then I agree that they probably need to be improved.
Not that there are any "stock" remaps, in that they are really intended
for integrator customisation. Even "standard glue" exists in at least three
different versions in various locations in the codebase.
—
Reply to this email directly, view it on GitHub
<#2706 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMGEZMDGPK4S3EI6YYVDQO3YNMR5PAVCNFSM6AAAAAA6KWYTPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBQGIYDKOBQGM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Please don't mistake a lack of activity on an issue for active disapproval, it is just that none of us have as much time to check PRs on actual hardware as we would like. I am typing this on a long train journey, for example, so can answer at length, but can't actually try anything out. |
My use case is that I use FreeCAD to generate g-code and that post-processor does not allow inserting custom code into g-code after the M6 tool change. Yet the default return location in the default QtDragon M6 remap does not return to the point my g-code expects, but rather the same point that GMOCCAPY remap does.
I propose that most people would prefer the changed tool tip to return to the same point in space that old tool tip was at.
There does not seem to be a "cannon" since the AXIS gui proposed default M6 remap returns to the tool change position, and many projects abandoned on git or live in the world have customized remaps that return the tool to the original position.
(See this lengthy forum article, for an example of people's interest.)
What I did:
Added an INI setting in the Versa_toolsetter section that give the option to direct the return point to either:
Option 1 (Also the default if no option specified): Gmoccapy default already released with QtDragon: Only returns to the Change_Position z height, as programmed at: configs > sim > gmoccapy > macros > change.ngc
Option 2: AxisDefault: return to the XYZ tool change position, as programmed at: configs > sim > axis > remap > manual-toolchanges-with-tool-length- switch > nc_subroutines > Manual_change.ngc
Option 3: New QtDragon option: Return the tip of the current changed tool to the XYZ position of the tip of the old tool, moving to Tool Change Z first, then Original XY, then down to new offset Z.
I also moved some error checking earlier.
Changes made to documentation:
All changes are limited to the “Auto Tool Measurement” section. (Currently, #14) except for:
In the “Auto Tool Measurement” Section 14, I made the following changes:
Created a section at the beginning called “Overview” (new 14.1) In this section I explain that this procedure intends to use two probes, the Tool Setter and the spindle probe, also called a Renishaw probe.
It directs people with repeatable tool holders to the Touch Plate section. It directs those with automatic tool changers to axamine the axis remap code rack-toolchange.
It then splits the documentation into “Work Flow Overview” which includes most of the previous documentation from section 14 that was above the QtDragon_hd screen. This becomes section 14.2
In this section, I also moved pre-requisites earlier (ie, instead of warning near the end to have Use Tool sensor selected, include this along with other pre-requisites under the Important heading near the top.
In the “sequence of events” section I added the extra possibilities of this ngc code modification:
The INI setting [RETURN_OPTION] can elicit additional behavior after the return to the [TOOL_CHANGE] Z position:
• If INI’s [RETURN_OPTION] = 1: (or if it is undefined), no further action. This is the default behavior of the GMOCCAPY M6 remap procedure
• If INI’s [RETURN_OPTION] = 2: Continue with a Rapid Move to the X and Y position defined in INI’s [TOOL_CHANGE] X and Y settings. This is the default behavior of the AXIS gui’s M6 remap procedure.
• If INI’s [RETURN_OPTION] = 3: Rapid Move to the original X and Y position at the moment the tool-change started, then Rapid Move down to the now offset Z position at the moment the tool-change started. This effectively moves the tool head back to the position just prior to the tool change. This is new behavior exclusive to QtDragon as of 4th quarter 2023.
I added another section following that one called “Detailed Workflow Example” (new section 14.3)
Renamed the next section to be clear it only applies to the QtDragon_hd interface (was 14.1, now 14.4)
All the following sections automatically increased in numbering.
Added the RETURN_OPTION explanations to what is now section 14.6.3 “The Tool Sensor Section” Corrected “TOOLCHANGE” in section 14.6.3 to be “CHANGE_POSITION”
Thank you for your consideration.