TCP 5-axis kinematics

Same here, I had previously 5I20 and 2 analog servocards and 1 io card.
This setups did not had this lost pulses problem.

I still need to investigate more accurately what is going on.

Any news here?

Sven

Hello

Well yes.
It's now working perfectly.

Error was lost encoder pulses.
I'm using 6I25-7I77 compo and it turned out that it's max count rate is ~550 KHz when filtering is on.

I was loosing encoder pulses on rapid moves.
I dropped my encoder count on all axis, this resolved my problem.
I still need to run impeller to test how this affected my surface quality.

Nice....

How did you home the rotating Axes? Home on index with a separate Ini?

You are German, right?

Sven

Hello

All file are included in this topic, latest are in page 7.
There's only one ini file to define all axis and joints.

All joints use index in homing including 2 rotary axis.

Not German, I'm from Finland

That is some nice work!
Where is the chuck pointing when it is tilted at 0 (B=0?) - the default position, is that up and the correct one is Z offset?
The second offset would be used instead of the first one if it was pointing 90deg down, is that possible?
I think You could trick the machine to switch modes at any position by allowing huge f-error for the moment of transition - perhaps using MUX component in hal.

I also wonder about tool changes. Does your machine need a defined XY position for change or it uses only Z for that? Does BC position matter for that so you need to move to B0 C0 for correct outcome?
I'm beginning to worry about that because I want to use a tilting device and I have tool height sensor on the corner of the table. That is more like a toy when compared to what You use, but anyway I will probably replicate Your switching idea.
I believe i could make the tool miss the sensor with G53 [probe position], does anyone have a view on that or some standard solution?
Thanks

Hello

"Where is the chuck pointing when it is tilted at 0 (B=0?) - the default position, is that up and the correct one is Z offset?"

When B-axis is 0.00 it will point against spindle.
Z- and Y- offset's are not in use, math is not correct to use those.
they should be left 0 at this point. When I have pit more time I will finis kinematic calculations.

"The second offset would be used instead of the first one if it was pointing 90deg down, is that possible?"

Like mentioned above offset's are not used, don't use them.
If your B-axis is rotated 90 degrees in initial state.
Meaning that when B-axis is at zero, C-axis is parallel to X-axis.
This basically means that it has different kinematics and you should form different forward and
inverse kinematic functions to suit your machine.

Way you could use BC-kinematics with BA-setup is that you would give additional 90 offset for
B axis value inside forward and inverse kinematics.
But still you would need to compile this kinematic module and I suspect that you will have problem with
transferring between two kinematics.

"I think You could trick the machine to switch modes at any position by allowing huge f-error for the moment of transition - perhaps using MUX component in hal."

It is really not so simple...
f-error comes from a reason.
When you pre-rotate BC axis and then activate TCP,
linuxcnc will command joint to same coordinates in rotated coordinate system that it was in non-rotated.
This will cause instant jump of maybe several hundreds of millimeters.
Not possible or even if it would be, not vice to allow enormous error for PID-loop.
This jump could also cause collision trough part or rotary table.

There is one way to change between kinematics after BC-axis are rotated:
1. BC rotation
2. change to joint mode
3. activate TCP
4. change to world mode.

This procedure will update current position in rotated coordinate system upward to trajectory planner and all other functions.

Current problem is that,
one can not enter in "joint mode" while running NC-code.
If you can make custom command that will preform states: 1.- 4. during NC-code run.
I will brew you your own personal beer.

"I also wonder about tool changes. Does your machine need a defined XY position for change or it uses only Z for that? "

My machine does only move Z up for tool change.
But again if automatic tool changer is used you need to know exact position of tool change.
For this you need to but your machine to TCP off state (change to machine coordinate system) and move tool change position.
There is no reason why one should try to drive machine to tool change position while TCP on,
cause tool change position changes along BC axis values and it is not practical to calculate this position.

Transfer between kinematics is only possible at rotary's zero position. (at the moment)
Also there is one other thing that forces machine to TCP off mode.
One can not activate or deactive tool offset while in TCP on, this will cause joint to jump and will give f-error.

Tool length parameter is used inside kinematics to calculate correct Z joint position.
Changing this parameter while TCP on will cause length difference jump in Z-axis.

So you need to:
- run rotary axis zero position
- deactivate TCP
- do toolchange
- activate tool length compensation
- run your tool measuring subprogram (that will index rotary adn measure tool and return Z-axis up position at least)
- pre-position closer (these comes from post)
- activate TCP
- start toolpath with safe rotary indexing.(need some post configuration)

Hopefully this will answer some of you questions.

Ok,
This is now much more clear. It looks like You would want the machine not to move at all when changing modes, but instead display different position? I wonder where in emc is the right place to do it.
Commanded position could be intercepted in hal, and the kinematics module could supply the offset, and some ugly things could be done on the way but that does not seem right.
I am not sure if I understand this fully: can You make the safe transition at B0 C0 without leaving the world mode, or it is impossible because of tool offset related Z - jump? Or for other reason?
I remember it was stated somewhere that normal tool offset is used during "next" move, not after loading. I am not sure about that, and that is certainly not the case if the module uses it for calculation. For handling jumps with increased F-error on only one axis (and when it is safe with no obstacles), it should be possible to temporarily limit the joint speed (also with mux). I will try that soon. I know already that by changing Z offset more than f-error I get f-error when in world mode but that is not a big secret...

I am not going to use TCP for now, but a very simple kinematics without rotating the coordinates which turned out to be is just;
Joint Y = posY + sinA *Dz; Joint Z = posZ + cosA*Dz. I'm not very sure about the Y sign there yet.
It is based on xyzac-trt code. I should get away with using generic way of handling tool length.
I believe this way I can easily generate gcode from FreeCAD for simple indexed milling and drilling operations. I need to change tools, and probably the easiest way will be to use post to add A=0 move after safe Z to before every tool change, and maybe the Z offset can be accounted for elsewhere.

Edit: Another way would be to use 'extra' M code to trigger world mode/joint mode switch. This should be possible with no source hacking, and maybe a simple hal component, here I found a bit of info:
forum.linuxcnc.org/10-advanced-configura...tom-kinematics#20850
I assume all reliable solutions resulting in autonomous machine work are good...

i am also in need of 5 axis TCP function, but with these drawbacks i will only use trivial kinematics and the swiveling program. If i need simultaneous 5 axis work i have to set the zero point like in the CAM program and put the part exactly where i put it in CAM. Does anybody know if it is even possible with Linuxcnc at all to be able to switch kinematics when not at ABC zero? also i have heard that in nontrivial kinematics the look ahead is only one line and that the linear velocity and acceleration can be higher than in the INI specified if in TCP mode rotating the axis? (i think the acceleration and velocity in nontrivial kinematics should be based of linear axes, not rotational, which it looked like) If those "problems" can be solved i will use TCP again.

There is no drawback at the moment.
Switching between TCP on/off is done at rotary 0 position will not cause joint jumps.
When you make good post for your self, which can handle safe movements in
both rotated/non-rotated coordinate systems, this setup works really nice.

It is true that certain rotary motions would force really fast motions for joints,
but I would say that this is user error.
CAM programmer should take care of what kind of movements toolpath is doing
and where machine is capable.
This is true even with commercial machines.


Trajectory planner will drop to one line at the time...
I think this is true, if you use linuxcnc versions where where axis and joints are not separated.

Im using "2.8 pre" where joint and axis are separated.
And I think this is what makes a difference.

Axis joint separation allows trajectory planner to have decent look ahead.
For what i have understood, is that trajectory planner will work with axis only.
Axis is a "virtual axis" not necessary connected directly to joint and has its own acceleration, max speed, position,
ect... that trajectory planner uses for calculation and feedback.
Joint is mechanical axis of cnc machine.
In 3 axis machine you can connect axis to joints directly,
but in 5-axis machine with rotating coordinate system fixed to rotary table axis can not be directly connected to joints.

What makes this connection between joints and axis in linuxcnc is called kinematic module.

In kinematic module axis position is fed to joint, that has its own acc,vel,position, ect... parameters.
When you activate TCP it will only change position information between joints and axis towards joints.
Axis and trajectory planner will not see any change, X direction is still X direction and all its parameter are correct.
This is due forward kinematics, that will calculate non-rotated XYZ positions from actual joint values and then feed them to axis pos values.

So this means that axis and trajectory planner will not see difference between trivial and non-trivial kinematics anymore.

ok, lets think this example trough:
Kinematic module , actually inverse kinematics(TCP:ON), will rotate coordinate system along with BC angles.
So this means that when C axis is rotated 45 degrees, X-axis position is equally divided between X- and Y-joints.

When trajectory planner updates new position to X-axis, inverse kinematics will divide this position (at this case)
between X and Y joint to corresponding equal movement in rotated coordinate system.
Forward kinematic module will calculate non-rotated XYZ values from joint positions and BC angles, then feed them back to axis positions.

This way X-movement from trajectory planner will be transformed to XYZ movement of joint in rotated coordinate system,
feedback from joints is backwards calculated to corresponding movement in non-rotated coordinate system for trajectory planner.


There are some things that needs to be kept in mind when typing in acc. and vel. parameters for joints and axis.
lets continue example above:

Our current position is x0. y0. and c45.
Next position will be x50. y50. with G0.
So we can run both X and Y axis at full acceleration/deceleration and full velocity to reach this point at same time.
Lets assume that axis and joints has equal acceleration and max velocity parameters.
This would be ok if we where at B0 and C0 position, but we are at C45.
So this movement will be happening only using X joint at positive direction.

This is cause, original movement is at 45 degrees between X and Y axis,
but addition to that we have rotated C axis for 45 degrees with TCP:ON,
this will result of X-movement only.

Resulting acceleration / deceleration is more than one joint alone can handle,
also combined velocity will be higher than one joint alone is capable of.(assuming joint and axis has equal acc. vel. parameters)

Resulting max velocity would be SQRT(Xvel^2 + Yvel^2).
From this we can safely assume that joint acceleration and max velocity need to be
at least 1.45 times of what axis acceleration and max velocity is. (again in this case)

In worst case individual joint's acceleration / velocity should be at least as much as
result of combined vel. / acc. values of XYZ axis.
Even this is not enough,
addition to above BC axis max acceleration and angular velocity compared to
max tooltip distance from rotary center should be considered.

In my case I did not calculate this, it was a lot quicker to just test different 5-axis paths to get good enough values.
I ended up 1.5 times axis values to joints and modest acceleration and max velocities for rotary axis's.
This also helped a lot for jerk that was present with fast rotary's.


There is no way to run 5-axis without TCP.
This is hard truth that some users can not swallow.
Problems will occur with path following and feeds.
CAM program will generate toolpath using rotating or non-rotating TCP, so if machine does not use TCP resulting toolpath will differ from CAM generated.

You can move all axis at same time without TCP, but trust me it is not a same thing than TCP.
If you get good enough results with it, then its ok and use it.