@Andy, "In the newer versions of LinuxCNC you can re-define the behaviour of M6"
So that's what all the talk about re-mapping is in the gmoccapy forum... Geesh more complications :) As for the frantic spinning of A, XYZA will all be "live" all of the time, I would think in one machine configuration. At least that's what I've paid for, I'm not into swapping wires to share a driver. My concern is that to do rotary work I'll have to use a different processor, wrapping X about the A axis. That's when I'm wondering if all the X moves required for tool changes will be performed as expected, and then go back to "A0" and start running the wrapped gcode. The tool changes are manual by the way, only the tool lengths will be automated. Now I"m reading there are issues with feed based on the diameter of the stock, that folks have trouble with the linear feeds not being properly transferred to degrees per whatever. My rabbit hole is getting deeper, Alice. :) Again, thanks Gene, and Andy for the support! On Sun, Mar 29, 2015 at 5:00 AM, andy pugh <[email protected]> wrote: > On 29 March 2015 at 04:53, Scott Salrin <[email protected]> wrote: > > Here is a link to the code Probotix uses: > > http://www.probotix.com/wiki/index.php/Automatic_Tool_Length_Sensor > > Their approach to tool-length sensing is to replace the M6 tool change > command with a call to a subroutine which probes the tool length and > then issues the tool-change command. Basically it adds moves and a > probe before and after the M6 command. > > In the newer versions of LinuxCNC you can re-define the behaviour of > M6, so you can in fact leave your G-code using M6 for tool-change and > the effect will actually be to call the 100.ngc subroutine. > (The "M6" in the re-mapped subroutine is interpreted as a normal M6, > the subroutine doesn't keep recursively calling itself) > This would be the minimal remap described in section 5.6 here: > > http://www.linuxcnc.org/docs/html/remap/structure.html#_making_minimal_changes_to_the_built_in_codes_including_tt_m6_tt > > However, the Probotix post-processor for Vectric is set up to use the > O100 CALL rather than M6, so if you are using that postprocessor > things should work without the remap process. > > As for whether the tool-change macro will lead to frantic spinning of > the A axis rather than X movement, that rather depends on how the > 4th-axis work is configured. If it is an alternative machine config > which has the A-axis stepper driven by the G-code X-word then I rather > suspect that it would. But there are other ways that it might be done. > > -- > atp > If you can't fix it, you don't own it. > http://www.ifixit.com/Manifesto > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
