Patrick Ferrick wrote: >>One thing to note - you probably wouldn't want to control the turret >>with G-code, even if you could. Changing tools and moving them around >>are separate actions, so there's no need for coordinated motion between >>the two activities. It just opens up possibilities for errors down the >>road. >> >>- Steve >> >> >> >Steve, Chris et al, > >Thanks for the hints. The reason that I first thought of using gcode >to control the toolchanger was that it will eventually consist of a >turret and a two degree-of-freedom arm, all controlled by three steppers >that I _would_ want to move in coordinated motion, just like they were >the U,V and W axes. (But not coordinated with, say, X,Y and Z since as >you point out tool motion and tool changing are separate.) > > Hmmm.
Although you do want the motors to move at the same time, you may not need fully coordinated motion. If you can generate a series of waypoints for the various motions (move to a "ready position", move to the selected tool position, grab tool, move back to ready, move through several waypoints on the way to the spindle ...), then a fairly simple HAL module can control when those waypoints get "issued" to the step generators. I'd probably loop through the points, outputting the next position when all motors are "close enough" to the current position. This would give you poor-man's blending. >Please correct me if I'm wrong, but is the point of using >HAL+ClassicLadder to make the toolchange operation itself transparent to >the gcode? Then it seems as though what I'm aiming for is being able to >use HAL+CL to re-create the functionality of three regular axes. > > How regular are they? :) You likely need different kinematics for these motors, since they wouldn't be a cartesian set like XYZ (the G-code definition of UVW). You would have to write a custom trivkins-like module, that treats the first 6 axes normally, but treats the last 3 like a scara robot (more or less). I'm sure it would be easier to write a waypoint sequencer as a separate component. >That's the part where things start to get really fuzzy! Given enough >i/o pins, it would then seem that the only limit to the number of motors >EMC could control would be the ability of stepgen to make pulses fast >enough for acceptable speed. > > Yes, EMC+HAL can control as many motors as you have I/O pins to output and CPU time to calculate steps (assuming you're using step+dir on all your motors :) ) The part that is the EMC motion controller can only control 9 joints at a time, though you could change that if you want to delve into the motion code (you don't :) ). - Steve ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
