[Emc-developers] My understanding of the state of JA3

[Chris R. <ch...@ti...>]

On Fri, Aug 16, 2013 at 01:20:35PM +0100, andy pugh wrote:
> 
> The specific case I am talking about is where a jog is altering the
> approach angle of the tool to the work (A and B axes) while not
> altering the tool-tip position in XYZ space. To do this requires
> movement of the X, Y and Z Joints, but there is no change in the XYZ
> coordinates.
> 
> I have a feeling that I have looked at this before and that it all
> works fine for incremental and jogwheel jogs. I will check that point
> tonight.

I've worked on this recently in JA3, and my answer is in terms of
JA3, which is a lot less scrambled up than the other branches.

Let me define terminology so my answer can be as clear as possible.
As we've seen it's really hard to tell what someone is even talking
about unless they are VERY careful.

	AXIS is one of x,y,z,a,b,c,u,v,w representing
	(usually/roughly) cartesian coordinates and tool orientation

	JOINT is a single thing controlled by a motor, whether it
	slides or rotates

	LIMIT is the maximum or minimum position value specified in
	the ini

	CONSTRAINTS are the maximum velocity and acceleration
	settings, also specified in the ini

	WORLD mode is where you can do coordinated moves and
	manually jog AXES

Ok, now let me try to describe the state of JA3:

In your machine config you must have AXIS LIMITS entirely inside
your JOINT LIMITS.  AXIS LIMITS (which define the allowed WORLD
space) form a rectangular solid that you must choose to fit inside
your JOINT LIMITS (which probably do not define a simple shape).

In your machine config you also must set up JOINT homing (JOINTS,
not AXES, are homed) in such a way that the final homed position
places the controlled point inside the WORLD space.  That way you
can switch to WORLD mode after homing.

In JOINT mode jogs and homing, JOINT LIMITS and JOINT CONSTRAINTS
are honored.

In WORLD mode, when running gcode (and when loading it in the AXIS
gui) each move is validated against the AXIS LIMITS just as in
trivkins, and also against JOINT LIMITS.  So you can get both errors
from a line of gcode if it's too long or you have offsets set wrong
or whatever.  Validating gcode against JOINT LIMITS is probably not
necessary because of the requirement I spelled out above.

In WORLD mode, when running gcode, AXIS CONSTRAINTS are honored.
JOINT CONSTRAINTS are not checked.  This means: just like you have
to set AXIS LIMITS to be inside JOINT LIMITS, you must also set up
your configuration so obeying AXIS CONSTRAINTS keeps you within your
JOINT CONSTRAINTS.  This can be tricky, but you must do it.  I think
your question is about this paragraph.

In WORLD mode, when jogging (teleoperating), AXIS LIMITS set the far
endpoint of a jog, so you'll end up nicely against whatever AXIS
LIMIT you're jogging towards, just like with trivkins.  You can jog
more than one AXIS at once, just like with trivkins.  AXIS
CONSTRAINTS are used for WORLD jogs, just like when running gcode.

Wheel jogging in WORLD mode is not implemented - micges thinks he
implemented this once already but the code is unfortunately lost.  I
think he is looking for it.

Chris