TCP 5-axis kinematics

@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.

In my setup, with step/dir interface via 7i76 to the servo drives, LinuxCNC does not see any encoder feedback for motion control. I do happen to have access (CanOpen over Ethercat) to the rotary position and a few other pieces of information as well as torque control as well - but for all practical purposes its as if LinuxCNC sees no encoder information.

Or am I missing your point Andypugh?

@dgarrett will check in the next day or so - ok?

If you test dgarr/homing_h successfully and report so
it can be merged, i will work on adding support for
something like HOME_INDEX_NO_ENCODER_RESET as you
suggest

Deal

andypugh wrote:

plopes9000 wrote:

In my setup, with step/dir interface via 7i76 to the servo drives, LinuxCNC does not see any encoder feedback for motion control. I do happen to have access (CanOpen over Ethercat) to the rotary position and a few other pieces of information as well as torque control as well - but for all practical purposes its as if LinuxCNC see's no encoder information.

LinuxCNC always see some feedback, and it uses this for the homing process.
I imagine that currently it is the internally-generated stepgen feedback. If you were to use the absolute position from the drive in place of the stepgen feedback then you might be able to use that for homing.

If it is true-absolute then this ought to work as-is. If it is single-turn absolute then you would need to hack things using a position.txt file (saves shut-down position) and HAL logic to infer the current position from the encoder feedback and a calculated number of complete revs from position.txt. (this does work, and is actually built-in to the 7i49 resolver driver)

You are right that that the mesa driver stepgen is providing the feedback - I recall checking if there was a pin on the mesa driver to reset the counters - unfortunately there wasn't any.

The CanOpen rotary position is single-turn absolute ... however since its CanOpen over Ethernet, I do not think I would get fast enough updates for high speed motion - its fine for homing at slow speeds though.

dgarrett wrote:

If you test dgarr/homing_h successfully and report so
it can be merged, i will work on adding support for
something like HOME_INDEX_NO_ENCODER_RESET as you
suggest

I took your branch dgarr/homing_h made one single change (see below) and homing with HOME_USE_INDEX = YES
worked just fine for all axis, I ran it twice - so for this configuration I can confirm it works.


Was there anything else you meant for me to test?

Do you think this is generalisable?

Depending what you mean with this.
It is already generic for normal xyzac or xyzbc table-table machine.

But if you mean that it could handle basically any kinematic machine type, like:
table-table, head-table, head-head + non orthogonal varieties of these machines.

Meaning we could write generic kinematic module that you simply select axis type, axis names, axes vectors and offsets.
From kinematic definition file it would automatically form needed translation and rotation mattresses and calculate these together to form inverse and forward transformations.


It is not practical to write different kinematics for every type of machine.

This would simplify multiaxis kinematic definition by factor of 10.

I know it not a simple task, but doable.