On 11/09/2013 07:40 PM, alan wrote:
> I also think this is a good idea.
> To test it I have quickly rewritten my g-code wheels program see
> attached file.
> It currently works only for paths cut in XY plane using XY movements. I
> cannot check this but the axis path plot look ok.
Nice pattern. I'll include it, but may alter the formulation of the code
a bit (see below).
I am really excited that the grammar performs this well :-)
> My setup is a rotary system so I need to convert all cartesian XYZ
> movements into polar R theta depth movements where rotation is around
> the Z axis. Instead of move emitting g1 X?? Y?? Z?? I need to emit g1
> x?? C?? Z?? . I am not sure how to do this. I havent looked yet in
> detail at the source code . I would appreciate any help / suggestions
> you have for creating a polar version of the goto and move functions.
The current gcmc version uses a 6-axis system XYZABC in the vectors to
move/goto calls. Arcs only use XYZ.
However, there is a bug that fails the output at the moment because the
ABC axes are converted to mm and not to degrees. A fix is in git (and
pushed to gitorious).
To move in a XZC axis system, you have vectors that look like:
vec = [x, -, z, -, -, c];
An additional fix is in the pipeline which includes a 9-axis system
XYZABCUVW, where XYZ and UVW are distance based and ABC angular based
(also pushed to gitorious).
A few comments on the code.
You write:
function CreateWheel(r,s,p) {
local w;
w = [r,s,p];
return w;
}
It could be simply written as (faster at runtime):
function CreateWheel(r,s,p)
{
return [r,s,p];
}
FWIW, you do not need the function as such... You call it with explicit
addressing as:
wheels = {};
wheels[0] = CreateWheel(10,1,0);
wheels[1] = CreateWheel(5,7,0);
wheels[2] = CreateWheel(3.333,-17,90);
I would have written:
wheels = {};
wheels += { CreateWheel(10,1,0) };
wheels += { CreateWheel(5,7,0) };
wheels += { CreateWheel(3.333,-17,90) };
or
wheels = { [10, 1, 0], [5, 7, 0], [3.333, -17, 90] };
Both alternatives have the advantage that you do not need to keep track
of the indices yourself. However, the latter may be more difficult to
understand. There are more ways to come to the same result.
Something not documented correctly (or not extensively enough) is the
conversions of sin() arguments and to_XXX() functions. You do explicit
radians conversion in CalcPoint() using to_rad().
If you have defined the angles from the start, then the conversions will
be implicit in the grammar:
wheels = { [10, 1, 0deg], [5, 7, 0deg], [3.333, -17, 90deg] };
...and...
CutPath(wheels, 0deg, 0.01deg, 360deg, cuttingdepth, svec);
The sin(), cos() and tan() functions will internally convert from
degrees to radians before calling the underlying system sin/cos/tan
function.
Your example has made it clear that I need to implement a vector
slice/combine operator to isolate and combine XYZ, ABC and UVW parts of
any vector. Also shift/rotate must be implemented for vectors (I already
did that for vectorlists). Such operations would help vector
calculations in some instances. Alternative is that a final calculation
must do coordinate-system conversion, but that may be quite hard as it
depends on the physical setup of the target.
Some input on axis conversion and geometry conversion calculations and
options is appreciated to find a generalized and easily comprehensible
solution.
--
Greetings Bertho
(disclaimers are disclaimed)
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
