TCP 5-axis kinematics

More
19 Jul 2019 15:29 #139888 by dgarrett
Replied by dgarrett on topic 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

Please Log in or Create an account to join the conversation.

More
19 Jul 2019 15:32 #139889 by plopes9000
Replied by plopes9000 on topic TCP 5-axis kinematics
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.

Please Log in or Create an account to join the conversation.

More
19 Jul 2019 15:42 - 19 Jul 2019 15:51 #139891 by plopes9000
Replied by plopes9000 on topic TCP 5-axis kinematics
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?
Last edit: 19 Jul 2019 15:51 by plopes9000. Reason: typo

Please Log in or Create an account to join the conversation.

More
19 Jul 2019 15:43 #139892 by plopes9000
Replied by plopes9000 on topic TCP 5-axis kinematics
@dgarrett will check in the next day or so - ok?

Please Log in or Create an account to join the conversation.

More
19 Jul 2019 15:43 #139893 by dgarrett
Replied by dgarrett on topic TCP 5-axis kinematics
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

Please Log in or Create an account to join the conversation.

More
19 Jul 2019 15:49 #139894 by plopes9000
Replied by plopes9000 on topic TCP 5-axis kinematics
Deal :-)

Please Log in or Create an account to join the conversation.

More
19 Jul 2019 15:53 #139895 by andypugh
Replied by andypugh on topic TCP 5-axis kinematics

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)

Please Log in or Create an account to join the conversation.

More
19 Jul 2019 16:05 #139896 by plopes9000
Replied by plopes9000 on topic TCP 5-axis kinematics

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.

Please Log in or Create an account to join the conversation.

More
19 Jul 2019 20:25 #139922 by plopes9000
Replied by plopes9000 on topic TCP 5-axis kinematics

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.

case HOME_SET_INDEX_POSITION:
		/* This state is called when the encoder has been reset at
		   the index pulse position.  It sets the current joint 
		   position to 'home_offset', which is the location of the
		   index pulse in joint coordinates. */
		/* set the current position to 'home_offset' */
		joint->motor_offset = - H[joint_num].home_offset;
		joint->pos_fb = joint->motor_pos_fb -
		    (joint->backlash_filt + joint->motor_offset);
		joint->pos_cmd = joint->pos_fb;
		joint->free_tp.curr_pos = joint->pos_fb;

		// PL ++
		/* this moves the internal position but does not affect the
		   motor position */
		offset = H[joint_num].home_offset - joint->pos_fb;
		/* this moves the internal position but does not affect the
		   motor position */
		joint->pos_cmd += offset;
		joint->pos_fb += offset;
		joint->free_tp.curr_pos += offset;
		joint->motor_offset -= offset;
		// -- PL


		/* next state */
		H[joint_num].home_state = HOME_FINAL_MOVE_START;
		immediate_state = 1;
		break;

Was there anything else you meant for me to test?

Please Log in or Create an account to join the conversation.

More
19 Jul 2019 21:04 #139925 by jsskangas
Replied by jsskangas on topic TCP 5-axis kinematics
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.

Please Log in or Create an account to join the conversation.

Time to create page: 0.105 seconds
Powered by Kunena Forum