Mitsubishi RV-6SDL Robot arm Servo/Encoder usability

I believe the only way to do 3d arcs in gcode (outside of the 3 main planes) is to either do it in CAM and create short straight segments (which may be problematic given that the trajectory planner falls back to 1 line look ahead for any move involving more than XYZ axes) or do the plane orientation in our custom kinematic.
I have done some work in implementing a tilted work plane (TWP) feature for tool-rotation kinematics (which works quite well) and have been working on doing the same for my melfa 6axis robot. I had to abandon 'genserkins' out of lack of understanding and create my own kinematic with twp parameters built in. I have not ironed out all the bugs but the TWP feature looks promising. The path below is the result of just four lines of gcode:
 

 

The next hurdle for welding would be to modify the kinematics so the C axis (ie wrist rotation) is done in joint mode (to be able to keep the torch pointing to the center of the arc) instead of doing it in world mode like the position.

So basically you would define the tilted work plane by teaching in the 3 points as in the video (which I have already implemented in my 5axis TWP work) and calculate the center of the arc from the same 3 points.
Mind you all of this would only give you circular (and helical)  arc moves which would not let you weld, for example, a pipe joining another pipe.

Here is the current state of the kinematic model, which also contains the math to calculate the orientation of the end effector:

 

Nonsense deleted

Aciera wrote:

I have done some work in implementing a tilted work plane (TWP) feature for tool-rotation kinematics 

There was some work done a long time ago on "arbitrary arcs" but it was apparently abandoned. 

github.com/LinuxCNC/linuxcnc/tree/arbitrary-arc (looks like it was 12 years ago) 

It does feel like it should be possible to give XYZ and points and IJK centre points to define an arc. It probably needs to be a short arc (less than 180 degrees) as the whole concept of clockwise and anticlockwise loses meaning if the plane is not defined, and if it is exactly 180 degrees there are infinite solutions. 

It probably needs to be a short arc (less than 180 degrees) as the whole concept of clockwise and anticlockwise loses meaning if the plane is not defined, and if it is exactly 180 degrees there are infinite solutions.  

Yes, in the end we still need the plane and normal to define the arc.

[edit] actually looking at the code in the commit the idea was to give the end coordinates the center and the normal so everything is defined.

Aciera wrote:

Nonsense deleted

How are we to know it was nonsense?

You'll just have to take my word for it, I guess.

Aciera wrote:

[edit] actually looking at the code in the commit the idea was to give the end coordinates the center and the normal so everything is defined.

You only need the normal if you want to retain the concept of CW and CCW. If you say that all arcs need to be less than 180 degrees then the start, end and centre define the plane unambiguously, and the defintion that it always chooses the shortest arc defines the direction. 

That does mean that full turn and multi-turn arcs are not supported. 

Do you know if any other control has a paradigm for this? Other than defining ad-hoc planes for each arc, which seems clumsy.