Kinematics for XYZAB mill

No problem at all, nothing wrong with sharing ideas.
My tilted work plane remap works just as you described. With G68.2 and it's different modes the user defines a tool z-axis and x-axis. The custom tool kinematic is then used to calculate the joint positions and the tool is then oriented using a g53.x command. Still needs some work to get the details working though. As soon as it's halfway presentable I'll share it in the other thread.

hi Aciera,
This is in continuation of my idea for separating the machine kinematics from the CAM system and have the CAM system specify the CLData with the tool orientation vector independent of the machine kinematics.
From the Fanuc 5 axis document I shared on the tilted working plane thread ( forum.linuxcnc.org/20-g-code/47984-tilted-working-plane#263524 , pdfcoffee.com/qdownload/fanuc-5-axis-pdf-free.html ) , G43.4 and G43.5 commands are used for different methods of specifying the tool orientation when using 5 axis commands.
When using G43.4, the ABC words in the further G0G1G2G3 lines mean the position of the rotary axes. The tdr and trt kinematics from linuxcnc will work fine when using this type of output from the CAM system.
When using G43.5, the IJK words in the further G0G1G2G3 lines mean the tool orientation vector specification as explained by Rudy in  linuxcnc.org/docs/html/motion/5-axis-kinematics.html . From the definition, it looks to me that the tool orientation vector needs to be normalized. A better explaination for G43.5 is available at  www.linkedin.com/pulse/fanuc-g435-rtcp-t...-5-axis-tim-markoski by Tim Markoski.

Using G43.4, we will still need support from the CAM system for the kinematics where the CAM will resolve the Angles ABC from the tool orientation data.

For  becoming truly independent of the CAM system for kinematics support, we will need to implement G43.5 where the tool orientation vector will be programmed into the Gcode motion line. For that we will have to allow IJK values in G0G1 moves (maybe somehow repourpose the IJK words in G2 G2 moves too OR allow G2G3 with R format arcs only when in G43.5 mode) and compute the ABC from the tool orientation vector in IJK. Then interpolate the ABC with the regular XYZ words.
Note that we can do the IJK to ABC conversion in a "pre-processor" using a filter program which has access to the machine kinematics that are available on the HAL fabric.

The main physics challenge I see is that there is no easy way to specify linear interpolation for rotation angles using Euler angles (except using Quaternions). So we will always have to slice the gcode lines to smaller and smaller resolutions to meet the linearity criteria for angles just like we can approximate any smooth curve with a polyline (series of small G1 moves). But this is a problem literally everyone has to contend with.

I would appreciate any comments on my line of thinking.

Regards,
-automata              

Vector programming gives you independence from the postprocessor but you still need a CAM that calculates the tool path and orientation. Hence why I'm more interested in 3+2 and tilted work planes that can be used for many or even most parts machined on a 5axis machine. The only real benefit of vector programming is that the controller does it's own postprocessing and the same program can be used on different controllers. (I used to think that the controller does this in real time while it runs the program but maybe it actually does it when the program is loaded?)
For interpolation one would want to do the calculations with quaternions, also less hassle with gimbal-lock. Building a custom interpreter for linuxcnc doesn't seem to be a terribly difficult thing to do.
The main challenge in my eyes would be to come up with an algorithm that guarantees smooth interpolation of tool vector changes. In my sim with the A/B rotation/nutation spindle head there can be different solutions for a given tool-vector. If the tool is to be oriented along the machine y (ie along the rotary B axis) then there are an infinite number of solutions since the B axis can be in any position.
My guess is that there are numerical algorithms that can be checked for convergence but I really have no idea and as I noted before I have not found a good paper about the mathematical methods used for postprocessing.

Hi,
I wanted to run my understanding of the Kinematics module with the community and maybe get some more insight into the organization of the kinematics modules.
The question I have I how does Linuxcnc accommodate G5x, G43 and G92 offsets in the final position values given to the kinematics module?
1. G5x, G92 and G43 offsets are applied and stored in the Gcode interpreter. The task and planner modules have no knowledge of the offset values.
2. The Task (milltask) module will take axis values from the Gcode module in what it thinks is Machine Coordinate System (MCS). Let us call this coordinate system as the "Assumed" MCS (AMCS)
3. Trajectory planning is done by the realtime motion component and it is done in the AMCS space.
3. The kinematics module using switchkins assumes the G5x coordinate frame has its origin at the rot_point offset which is given in the original machine MCS coordinate frame. This is done by setting the G54 offset to the rotation center point at the start of the Gcode in the example NGC file made by Aciera in the XYZAB sim config.
4. The Tool length offset is applied along the Z axis of the workpiece by the Gcode interpreter. 
5. The Inverse Kinematics function calculates the joint positions from the assumed AMCS positions handed to it via the motion/trajectory planner module.

The formula used by the XYZBC inverse kins is:  My inferences are as follows:
1. First we corrected the assumption that the Gcode module made about the G5x and G43 and AB axes center offsets and substracted them from the AMCS. This aligned the center of the workpiece coordinate system to the rotation center.
2. Then we orient the the workpiece coordinate frame to align the axes with the original MCS.
3. Then reapply the G5x offset along the MCS axes and the tool Z offset along the J2 axis.

My Questions:
1. We compensated for G5x and G43 offsets in the inverse kinematics. What about G92 offset? OR does that not need to be compensated in this way? I am comming up with some mechanism to check the G92 offset in the sim config.
2. The G43 offset is compensated only along the Z axis. What if the G43 offset is applied along other axes too? For this also I am going to do some trials on the sim config
3. If we have to remove rotate and re-apply the G5x and tool offsets in the inverse kinematics, can we say that there is an inherent flaw in the method of inverse kinematics and the location of application (gcode interpreter) of offsets in Linuxcnc? Should the offsets be handled in the kinematics module? 
4. The position velocity and acceleration limits being applied to the axes by the motion planner will be very poor approximations of the correct values (which aer measured along the joints). Although joints-axes separation from V2.8 onwards does address this issue to a certain extent, the velocity and acceleration limits should be handled in a more refined way?

I would appreciate any comments and will surely help in furthering my understanding of the kinematics moduleand overall structure of LinuxCNC.
-automata

3. The kinematics module using switchkins assumes the G5x coordinate frame has its origin at the rot_point offset which is given in the original machine MCS coordinate frame. This is done by setting the G54 offset to the rotation center point at the start of the Gcode in the example NGC file made by Aciera in the XYZAB sim config.

The work offset (eg G54) does not influence the rotation center. You can set your work offset anywhere you like. The rotation center is defined by setting the 'rot-point' values that define the offset of the rotation point from machine zero. Without the 'rot-point' offset the center of rotation is the machine reference point. 
I'm not very familiar with the internals of the trajectory planner but I believe, as you say, that it does indeed calculate everything in machine coordinates, so it strips the offsets from the input and adds them back to the result.
 

I suggest that for a clearer picture of how offsets are applied in respect to the kinematics component you add an 'rtapi_print' statement to the kinematic component so you can monitor the values of 'pos->tran.(x,y,z)' which is the coordinate position used in custom kinematics.