On 09/11/2013 20:22, Bertho Stultiens wrote:
> 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.
>
Thanks Bertho,
I did originally write both parts as per your changes. But kept getting
a compilation error. I cannot remember what the message was and it was
probably because of something else. So made those changes and it all
seemed to work . I probably inadvertantly fixed the real problem but not
having written C in such a long time I am not sure what was wrong.
> 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.
Didnt know about that thanks for the information
Finally a comment about angles. I found when generating gcode in my own
windows based program that I had to be careful with angles greater than
360. (This was before wrapped axes havent tried wrapped axes so dont
know what will happen) . If I generated a path with multiple turns
around the origin (easy to do with the wheels patterns), so that for
example the polar coordinates (radius, angle,depth) of successive points
was say (10,360,-1) then (12,10,-1) then (15,40,-1) in the same
direction which for my setup is anticlockwise. Linuxcnc would get to 360
then do a clockwise move back to 10 ploughing a nice big path through
the work and spoiling the pattern. So I have to generate positions
(10,360,-1) (12,370,-1),(15,400,-1) to keep rotating in the same
direction. So I keep a note of how many times the cutter crosses the x
axis in an anticlockwise direction (the winding number) and use this to
calculate the angle. If the cutter has a retrograde move and crosses the
x in a clockwise direction I reduce this winding number.
I mention this because generating polar coordinates is not quite so
straightforward as cartesians. So even using your example below
vec = [x, -, z, -, -, c];
There has to be some pre-processing. Can this be accomodated by your meta
compiler? Just thinking about your explicit angle conversions mentioned above.
Anyway keep up the good work, How far do you intend to take this structs?
classes?
Alan
------------------------------------------------------------------------------
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
