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

[Jon Elson <elson-at-pico-systems.com>]

robin szemeti wrote:

> 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

<snip>
Most people with cartesian machines ignore this, and use 'trivkins' which is
just cartesian in and back out.

> 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.

Now, this is an interesting idea, and I suppose it could be done.  I'm not sure
the
usual 4x4 matrix has a high enough order to perform the kind of correction
you are considering.  Normally, these kinematics routines are used to translate
the joint position of a robot to/from cartesian coordinates.

> 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 ...

Well, as I understand it, without a detailed reding of the code, ALL of the
G-code,
if possible will be converted into trajectory information and buffered for the
real-time
section to peruse as it comes to it.  The trajectory code reads ahead as far as
the buffer
size in memory will permit, which is the entire program in most cases.

> 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 ...??

It depends on the number of axes in simultaneous motion, I think.  But, it is
thousands of blocks of G-code, in all cases, I think.  I have never seen any
hard-coded number in the code, anywhere, that would limit the lookahead.

As for corner rounding, the default behavior is to begin interpolating in the
next
move as soon as the current move reaches the deceleration point.  If you don't
like this behavior, you can activate the exact stop mode (G61).  This pretty
much
defeats the lookahead, though, as it has to stop at all moves that are not exact

continuations of the previous direction.

I have never seen the lookahead foul up and slam into an unexpected 'wall'.

Jon