[DONE]Testers needed for integration of switchable kinematics

An updated branch for switchable kinematics has been made available here:

github.com/LinuxCNC/linuxcnc/commit/d0ae...78619c1aa6019c33214d

The branch can be installed using a 'scratch' deb from the buildbot. See the instructions at
buildbot.linuxcnc.org/
The 'scratch'-debs can be found in the last section of the page sorted by distributions. They are built automatically by the buildbot and are available for a limited amount of time.

Or to build the branch as a run-in-place (rip) install (Note that for this you will need to have all the required dependenies installed to compile LinuxCNC):

$ git clone git://github.com/linuxcnc/linuxcnc.git linuxcnc-s_kinsv2-dev
$ cd ~/linuxcnc-s_kinsv2-dev/src
$ git checkout dgarr/s_kinsv2
$ ./autogen.sh
$ ./configure --with-realtime=uspace
$ make && sudo make setuid
$ source ../scripts/rip-environment

This branch adds the capability to switch between two (or more) different switchable kinematic modules inside a GCODE program using M codes. This functionality can be used for machines where post-homing joint control is needed during setup or to avoid movement near singularities from gcode. Such machines use specific kinematics calculations for most operations but can be switched to identity kinematics for control of individual joints after homing. This is very useful when using non-trivial kinematics such as 5axis milling and is essential for industrial robots.

The following switchable kinematics modules have been included in the branch:


The following sim configs can be found in the directory 'configs/sim/axis/vismach':


Please note that any user-created/user-modified kinematic modules will need to include these required elements in order to function (Kinematic modules that come with the distribution already comply) :



The easiest way to create a custom kins module is to adapt the hal component userkins (added oct 2020). This template component can be modified locally by a user and can be built using halcompile (instead of c) so should be much simpler for many users (plus no Makefile mods required). The component should be able to do almost anything a c-file-based kinematics module can do.

Any test of non-trivkins kins and any test that exercises a gui is helpful especially since different users may use guis in different ways and find errors or unexpected behavior. Of particular interest are servo systems to test for thudding or following errors when switching kinematics.

It would be nice if users with experience in 5axis machining could review the 5axis sim configs mentioned above and in particular the setting of the rotation points.

Reviewing the switchkins documentation for accuracy/completeness would be useful:
github.com/LinuxCNC/linuxcnc/blob/dgarr/...otion/switchkins.txt

and also the README and .txt files in the switchkins sim config directories would be helpful too.


Personally, I believe this is a very useful feature and I'd like to get this included as a permanent feature in LinuxCNC.

Please report any findings and successfull tests in this thread.

Thanks

One thing I notice is that if I try to load a config that uses classicladder it fails.
Opening classic ladder in gmoccapy gives an error:

"Classicladder real-time component not detected"

[edit]
I just built the current master and classic ladder doesn't work. So something has gone wrong there.

[edit2]
Issued a bug report about broken classicladder on github

I managed to get my drives working without needing Dmitry to put his patch on the source code. Turns out I can get his driver installed using halcompile and I got homing working using a workaround with the inbuilt functionality for absolute-encoders.

So this makes it a lot easier for me to test any updates on the branch. Also I can now start with tests on my servo system since my other mill (with stepper motors) needs classicladder support.

In the switchkins documentation :
buildbot.linuxcnc.org/doc/scratch/v2.9.0...tion/switchkins.html

4.2. Gcode/Mcode commands

in the gcode sequence

I think this:should maybe be:

6. User kinematics provisions

Maybe there could be a note that userkins.comp will not (as I understand it) produce a switchable kinematic?



7. Warnings

Two Typos, should be:

2. Reading the _digital_ input
3. Aborting (M2) the gcode _program_ ...

switchable kinematics was inspired by this thread on 5axis simultaneous machining:
forum.linuxcnc.org/10-advanced-configura...kinematics?start=220

Also here is my application for a serial manipulator where switchable kinematics is not only useful but essential to overcome the limitations of the kinematic involved:
forum.linuxcnc.org/38-general-linuxcnc-q...lity?start=10#192821

Note that there aren't many users of non-trivial kinematics and even fewer are regular contributors on the forum. I have however helped a few to install the switchkins-branch for use on 5-axis mills.
The ability to switch between trivial and non-trivial kinematics is a major contribution to anybody working with advanced kinematics.

Would switching between C axis milling and regular spindle control on a lathe be an application (or make it simpler)?

Would switching between C axis milling and regular spindle control on a lathe be an application (or make it simpler)?

Interesting question. I guess we would have to ponder how a change in the kinematic model might be helpful (ie. lathe to milling)

I've though about converting the A-rotary on my knee mill to an A-rotary/lathe-spindle. A milling operation would still be a regular XYZA setup. If I then changed the mill bit to a lathe tool the Z (milling) would become the X (lathe) and the X (milling) would become the Z (lathe).
I could see this to be an application of switching between two trivial kinematics.

So, within a program I can switch between joint, world and tcp?
something like this rough example?

So, within a program I can switch between joint, world and tcp?

Correct.

Note that it doesn't have to be joint, world, tcp. It could also be a switch between mill and lathe kinematics that basically just swaps X and Z axis. This way you can use standard GCODE for milling and lathe work on the same machine in the same program. Im working on a sim config for just such a mill-turn setup.