Re: Hi, and 2 questions (kinematics and look-ahead)

[Ray Henry <rehenry-at-up.net>]

Hello Robin

Good to hear from you and that you are moving toward Linux as a central 
part of your machine shop.

I really want to take you up on your offer to write something about 
kinematics for the handbook and I'll get back to you on that before long 
but I'm not certain that kinematics is what you need.

Kinematics are the computation of motor motion based on the relationship 
between the motion that a motor controls and the coordinate system in 
which the g-code was written.  For a router with three axes 90 degrees 
from each other we use trivkins which is a perfect correspondence between 
a motor and one of the axes in cartesian space.  Most of our kinematic 
applications are to hexapods where cartesian motion is generated by a 
matrix of strut lengths and angles between struts.  You can see one 
example of this at 

http://www.isw.uni-stuttgart.de/personen/t_franit/primodell/index.html

If you cast about there a bit with model 1 and model 2 you will see 
something that looks a bit like a hexapod.

The other machine where kinematics are essential is a robot where one 
joint or wrist or knee or whatever you would like to think of these robot 
motion points to be is built onto another.  In many robot arms, the joint 
motions are stacked several joints in a row.  Think of your arm and the 
various motions that are possible and then think of motors attached to 
each possible direction of motion and you will see a bit of the problem.

I am certain that there would be a kinematic solution to your axis droop 
problem but I haven't a clue where to start.  We do have several on the 
list who are using routers for one thing or another and I think that they 
may help us with this problem.

I hope this convoluted part of the post hasn't made it worse for you.  
Keep asking until you get what you need.

Look ahead works two ways, at the highest level, it will read several 
thousand lines ahead on my mill here.  At this level it is only reading 
the code and looking for gross errors.  At the motion control level it 
works about 200+ ahead of the current motion command.  For countouring 
that should be more than enough.  I know of one router that is running 
about 600 ipm and doing some pretty detailed work.  So the first part of 
an answer is that yes it can do contouring without even breaking a sweat 
on a reasonable computer.

The second question about will it overshoot or round a corner after a 
bunch of small arcs or lines approaching that corner.  The answer is that 
it depends on how you write the code to do that corner.  If you are in 
constant contour mode it probably will but if you use an exact stop at 
the hard corner then it will go to the point and then take off again in 
the new direction.  You can turn on or off these modes (g61, g61.1, g64) 
in any block of code.  See the rs274 pages at linuxcnc.org/handbook for 
greater detail on how these work.

The cubic spline computation routines really try to get successive sets 
of motions to come together at the transition point fairly well.  How 
well will depend upon your routers ability to accelerate and decelerate 
and the consistency of the tuning that you do the maximize it's ability 
to follow your part file.

Ray
  


On Monday 09 September 2002 04:40 pm, Robin wrote:
> Hi,
>
> I'm  in the process of upgrading from something nasty in DOS to EMC
> under linux for my 3 axis router and plasma cutter
> (http://www.rszemeti.demon.co.uk/cnc2.htm if you want some tacky
> photos) thus allowing me to rid myself of the last bit of Microsoft
> software in the shop.
>
> So ... firstly Kinematics ...
> I've been reading through the various [blah]kins.c packages and trying
> to make head or tail of the nomenclature ... much is spoken of
> 'inverseKinematics' and joints .. and no doubt the documentation would
> mean something to me if I understood the terms ... I naiivley imagined
> hte kinematics to be in the order of
>
> <pseudocode>
>
> convert(xin,yin,zin){
>   xout = fx(xin,yin,zin);
>   yout = fy(xin,yin,zin);
>   zout = fz(xin,yin,zin);
>
>   return (xout,you,zout);
> }
>
> </pseudocode>
>
> or something similar, using refernces etc as appropriate ...
> translating the desired x position into a 'real' x position
>
> Take my router for example .. it 'sags' in Z along the X axis by 20
> thou' due to flex in the beams, I'd really like to take that out of the
> Z axis as the X axis moves along ... trivial really .. but sadly after
> reading through the [blah]kins.c files I'm no wiser ... I'm familiar
> with C C++ and Perl (and a bit of lisp on occasion too) so its not the
> language its just the core concepts of whats going on thats confusing
> me here.
>
> A simple pointer would be much appreciated. I'll even write up a
> 'kinematics' section for the FAQ if I can understand enough of it to
> make it of use to others!
>
> Secondly, lookahead ... reading through the NGC intepreter stuff I was
> not entirely clear how many steps were passed ahead to the emcmot stuff
> .. as you probably know the majority of 3D work consists of linear
> moves along say the Y axis with Z going up and down to follow a 3D
> surface, at the end of the pass the X axis moves along say 1/4" and
> then the pass comes back along the Y axis ...  the GCODE for this is
> thousands of tiny line segments with a sudden X axis right angled
> corner at the end ... unless there is considerable lookahead for
> several hundred steps the machine is going to come to an out of limits
> condition as it hits the right angle at the end ...
>
> The reason I ask this is because the plasma cutter will often have
> multiple small line segments leading up to a right angled corner and
> then a 90 degree turn ... it would be disastorous if it over shot the
> corner (or worse rounded it off) so just how many lines of lookahead is
> there ...??