> >> >One question: why not make the pipe chuck be a U axis, the torch >> >carriage is X, and let the g-code programmer have complete control >>of >> >what happens? Move pipe only, torch only, or both, under g-code >> >control. >> >> >> Not sure I understand how to use the U axis. I will be using the >> sheetcam rotary plugin to do the gcode. I will have to look at the >>usage >> of a U axis before I can decide on that. > >If you are using CAM it probably makes sense to skip the U axis. >If you were writing your own G-code the U axis would give you more >flexibility, but the CAM won't understand it anyway. > >Just divide the steps per mm for X in half, and send the X steps to >both >gantry and pipe chuck motors using HAL. Also send X direction to both >motors, and invert one so they travel in opposite directions. Use HAL >logic (in the base thread) to turn off steps to each motor when that >motor >hits its home switch (only while homing), and to send a composite home >switch signal to LinuxCNC when both motors have hit their home >switches. > >If you are generating step pulses in hardware (Mesa, Pico, or other) >then >things get a little more interesting. More like a servo system, still >doable >but the approach is a little different. > The step generation is with software so this approach seems to be the thing to do. Thanks a lot John you have been a great help. I will report back when the machine is running.
> >-- > John Kasunich > jmkasun...@fastmail.fm > >------------------------------------------------------------------------------ >_______________________________________________ >Emc-users mailing list >Emc-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
