On Tue, Aug 03, 2010 at 10:44:44AM +0100, Andy Pugh wrote: > On 3 August 2010 09:41, Erik Christiansen <dva...@internode.on.net> wrote: > > On Mon, Aug 02, 2010 at 07:44:06PM +0100, Andy Pugh wrote: > >> I can't help thinking that using a G-code routine (and, in fact, > >> having the ATC defined as an axis) is sub-optimal. > > > > What's the basis for that Andy? The method seems to have worked well for > > Schooner, and it sounds very appealing. > > It seems rather like defining the spindle as a rotary axis. It would > work, but would need non-standard G-code.
Oh ... yes, I forgot about aligning the INT30 dogs when inserting the toolholder. Still, that could at worst be done by running the spindle at inching speed over a springloaded toolholder until it engages the socket, as detected by a microswitch? (OK, that necessitates a very good VFD.) Do we need non-standard G-code in order to have the spindle serve alternatively as a rotary axis? If M3/M4 were to also block spindle encoder pulses from the rotary axis input, then there wouldn't be a following error when it's just a spindle. M5 could again admit rotary axis input, allowing gcode to drive the spindle as an axis. EMC2 wouldn't know that they are physically one. After all, if the spindle can't at least rotate to a home, to align with the toolholder, then the tool magazine becomes horribly complex, doesn't it? > In general M6 T4 should be all it takes to load T4. In Schooner's > setup he needs to replace all the M6 TN lines with a <m6> oldtool > newtool (If I have read it correctly) > Tool changes will happen very slowly if the max-velocity slider is set > low. That also seems a bit wrong. If I have physically set a manual velocity override, there seems little basis for protesting that it works. Alternatively, if it's only intended to operate when cutting, then, again, that could be masked by M5, in hardware if necessary. > > Even with gcode processing being single threaded, it'd work well > > enough for me, I think, since there's not a lot of point moving XYZ > > about until the new tool has been inserted. Unless, of course, the > > tools merely sit in holders off the edge of the table, and > > toolchange is handled by the existing axes. > In the case of a rack-type toolchanger G-code looks like a more > logical way to do it, but there is also some support for such > toolchanges: > http://wiki.linuxcnc.org/emcinfo.pl?RackToolChanger Hmmm, I didn't find even a vestigial hint of what is intended there, but looking at the patch, and finding generate_toolchange_move() in STOP_SPINDLE_TURNING(), there seems to be scope for sufficient reverse engineering to get some idea of what it is supposed to do. How much state do we really need if a tool carousel is driven as a rotary axis, with as few as one encoder pulses per tool position? If it can home, and rotate in both directions, then we can keep track of the current tool position in a gcode variable, and choose CW or ACW. > > But fun though that would be, it seems hard to beat chucking out the M6 > > command and just hoofing about in a subroutine to change tool. It does > > make gcode to <m6> communication a bit of a doddle. ;-) > > I am not entirely clear that that is how it works for Schooner. I have > a feeling that he needs to call an <m6> subroutine instead of using > the M6 G-code. I might be wrong, perhaps M-words can be overloaded? No, I also understand that the <m6> subroutine replaces the M6 G-code command in his case. In there he can move XYZ and or extra axes to change tool, and return. A spare M[100-199]-code pair may perhaps be used to operate e.g. your pneumatic tool grabber. > > And anything which obviates the need to use that ladder thing is worth > > whatever it costs, and more, in my case. > > I have managed to avoid it so far, though I am sure it is great when > you are used to it. > My approach would have been the HAL module written in comp that I > half-wrote earlier in the thread, used in place of the > hal_manualtoolchanger Ah, yes, a bit of 'C' with clearly visible states would suit me right down to the ground. Much easier for me to deal with than trying to ladderise a state machine. It's 30 years since I touched relay logic, and I didn't warm to it then. (Designing telecommunications systems with hundreds of instances of large and small state machines quickly moves things beyond relay logic.) Erik -- Truth decays into beauty, while beauty soon becomes merely charm. Charm ends up as strangeness, and even that doesn't last, but up and down are forever. - The Laws of Physics ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
