On Mon, Aug 20, 2007 at 03:03:27PM -0600, Ryan Hulsker wrote:
> Ok, thanks for your help (Chris too), I seem to have it working now.
Yay! I am excited to hear it. If you want to, create a page on our
wiki (wiki.linuxcnc.org, follow instructions on page "BasicSteps" to be
able to add & edit pages) with some information & photos when you have
them. Other people have done this with their new or unusual types of
machines:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Alex_Joni's_Toy
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Koppi's_Toy
> A question about feed rates. From the quick testing I have just done it
> looks like it always tries to apply the feed rate to the XY axes, and
> scales the feed rate for the UV to match so that they all reach their
> end point at the same time. Unless your feed rate at XY causes the UV
> to overrun the max, or any individual axis to overrun its max speed,
> then the XY is scaled down until UV are running at their max. Does this
> sound correct? Seems like the right thing to do to me.
>
> Just wanted to make sure that it is treating the XY and UV as two
> separate pairs from which to calculate 2 separate combined feed rates to
> apply the max.
The rules are a bit complex. Chris described them like this (I think
some variation of this is in the documentation as well):
If any of XYZ are moving, F is units per minute in the XYZ
cartesian system, and all other axes (UVWABC) move so as to start
and stop in a coordinated fashion.
Otherwise:
If any of UVW are moving, F is units per minute in the UVW
cartesian system, and all other axes (ABC) move so as to start and
stop in a coordinated fashion.
Otherwise:
The move is pure rotary motion and the F word is in rotary units
instead of linear, in the ABC (pseudo)cartesian system, as
originally described in NGC 2.1.2.5(B,C) :
http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_32a.html#1010695
if emc violates a machine constraint (e.g., moves V at 2 units/second
instead of the inifile max of 1 unit/second) it's a bug, please report
it. Before emc 2.0.x, we did extensive testing in 4-axis XYZA setups to
eliminate these bugs, but it would not be surprising to learn that there
are some added by the 9 axis code.
As far as writing gcode for XYUV goes, you may wish to consider G93 "inverse
time feed mode", where the F-number is the number of minutes the move
should take to complete, and it is specified on each line with a G0
move. CAM software may have a more complete view of just how the cutter
is moving through the foam, and expressing the desired feed rate in
"minutes per move" may be better than "in XY inches per minute if XY
moves, or UV inches per minute otherwise".
> I am assuming that cutter compensation to handle a variable width kerf
> depending on feed rate, and applying it to 2 different sets of axes is
> not handled by standard g-code? So I am planning on incorporating it
> into my g-code generator.
That's right, cutter compensation remains XY-only. Again, your CAM
hopefully has a more complete idea just what is going on, and can apply
appropriate offsets to X, Y, U and V.
Jeff
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
