TCP 5-axis kinematics

I am also interested in the current status.
Especially around the shifting of kinematics at arbitrary position.
Is that real now?

I too have joined the club of getting TCP to work and be practical in LinuxCNC.

I have read this thread and looked at the code/configs of jsskangas and automata/r.lol.
In my view the switchkins approach is sound and its working.
jsskangas approach to include the rotary axis machine coordinates in the kinematics calculations is key to make it practical to use.

Since I wanted to get the latest dev branch, I actually retrofitted the switchkins branch changes into the 2.9pre dev branch.
Key topics:


1) change the switchKins kinematics to take into account the machine coordinates of the rotary axis - see switchKins.c attached.


2) Improve my machine homing precision
This was not straight forward since my servo drive's connector and function to output the zero pulse are busy with the linuxcnc step/dir pulses and I certainly did not want to install additional encoders. I could use a different servo drive connector with 24V step/dir inputs but the frequency limit would go from 1MHz to 250KHz and I would need to fab a 5V differential (mesa 7i76) to 24V single ended circuit. Since I already use CanOpen over Ethercat for the servo drives and that gives me access to the motor rotary position - which is derived from the servo drive known absolute rotary position - I decided to write a small component to calculate the zero pulse.

However the LinuxCNC index homing procedure assumes that the sync is done with an encoder that resets its position and counters upon seeing the zero pulse. For that reason I had to change emc/motion/homing.c to keep using the offsets.

Finally, see attached test gcode file and video.

Do you think this is generalisable? ie are there machine-specific constants compiled in to the kinematics? If it could be considered a generalisable kinematics then there might be an argument for building it in to LinuxCNC.

plopes9000 wrote: Since I already use CanOpen over Ethercat for the servo drives and that gives me access to the motor rotary position - which is derived from the servo drive known absolute rotary position - I decided to write a small component to calculate the zero pulse

Are you aware that LinuxCNC now supports absolute encoders for homing?
linuxcnc.org/docs/2.8/html/config/ini-co...t__lt_num_gt_section
(HOME_ABSOLUTE_ENCODER)

@plopes9000
Interesting work and excellent video!

Since you modified homing.c, I wonder if you could
help test an experimental branch: dgarr/homing_h

The purpose of this branch is to define a homing api
(applications interface) to make it easier for users to
create a custom homing.c for special applications (like
yours).

This branch is a candidate for a merge to the master
branch. I have tested numerous configs but have not
merged as i do not have the hardware needed to test
index homing.

The branch is rebased to the current master branch
(2.9~pre0) at commit baaf887f1 Jul 17.

To test with your application:
1) checkout the experimental branch
2) adapt the branch version of homing.c
'case HOME_SET_INDEX_POSITION'
statement as you did for the current master branch.

#

---

Commit message excerpt:
0) clarify interface with new homing.h
1) provide for initialization (homing_init())
2) localize per-joint homing-specific hal pins:
use: export_joint_home_pins() (one-time)
read_homing_in_pins() (servo-rate)
write_homing_out_pins() (servo-rate)
3) localize internal homing state machine (home_state_t)
'hiding' state variables from other motion components
4) use simple set_/get_ functions for overall and per-joint
queries and settings (instead of macros)
5) maintains use of existing logic and core routines:
do_homing_sequence()
do_homing()
6) use rtapi_bool.h
7) uses sequence states (home_sequence_state_t) per existing
design

No interface or functional changes are intended.

Ref: github.com/LinuxCNC/linuxcnc/commits/dgarr/homing_h

With regards to the changes to the switchkins kinematic module, which essentially combines the trivial and xyzac standard kins, there are no machine specific constants, its absolutely generic. and if the parameters for xyz rotation coordinates are provided with zero values, it behaves just like the standard trivial/xyzac kins.

With regards to the homing index changes, I think they should also should go in LinuxCNC, but it should be configurable ... something like a new setting HOME_INDEX_NO_ENCODER_RESET or similar. This would make the index homing sequence more generic.

Happy to work with one of you guys to get these changes in - would hate to have to re-patch every time I want to upgrade LinuxCNC.