Switching between different kinematics on-the-fly

Here is how to switch between kinematics

+ You need to combine the kinematics you will use into one (new) c-file. Basically a copy and paste exercise.
+ The code for the two kinematics are separated by a switch + The variable TCPmode (arbitrary name) has to be added to variables in the new kinematics file. It is then accessed by It also need to be prepared in rtapi_app_main, there should already be some offset parameters. Just copy how it is done for them.
+ To set the value of TCPmode, make two macros say M100 and M101 with the lines if the new kinematics is called "newkinematics".
+ Put "newkinematics in the KINEMATICS line in the ini file.

To switch between kinematics you need to go to a position where the coordinates are the same for both kinematics, typically (0,0,0,0). Then run the M100/M101 macro and you are now using the other kinematics. If not at (0,0,0,0) there will immeditaly be a following error, and that is what they where dealing with in the last few pages of the link above.

I'll attach such a kinematics file. It is called trivkins, because there are some functions that require the name "trivkins" such as mpg jogging. It was some months ago I used this. It worked, but I wasn't happy with jogging and positioning movements and eventually went back to trivkins. Use at own risk; I will not come and repair your machine if using this.

My simple 4 axis kinematics (it is really 5 axis with C at 0) can be switched on the fly in any position. It is for tilting platform. I believe it could be used to prioritize movements (by altering the velocity) to avoid the collision, by grouping the movements, that would be required in more complex scenarios. It basically switches the max velocity and allowed max f-error so it does not throw an error during the transition, nor does it "jump" at any crazy speed. When the transition is over (this is decided on actual f-error by the state-machine), the machine goes back to normal operation. This is done with hal components. If anyone is interested I can possibly explain this more with an example from my machine.
You can use it with the M100/M101 macro or by connecting it to any free digital input and output with M64/M65 thing, and the thing to wait for transition-done input

for knives cuts i use the HEEKSCAD CNC CAM
this gives me a real good in and out as it can overrun and move in out at any point

jmr, at least I am interested. Sounds like an elegant solution.

JakaP wrote: Andy, can you elaborate on input filters for G-code preprocessing a bit more? What are they, where can I find and set them?

linuxcnc.org/docs/2.7/html/config/ini-co...html#_filter_section
You will probably find that your existing config is already set up to pass .jpg files through image-to-G-code, for example.

Here is an example that munges G-code:
forum.linuxcnc.org/38-general-linuxcnc-q...r-me?start=10#120524

Hi, sorry for the delay. I found a fuzzy drawing of the hal implementation in a stack of papers. I will try to see if it relates to my config and I really need to it in another hal file. Right now it does not make much sense for me.
My kinematic module does not do TCP rotation so it is enough that I change the offset (that should be Z offset when A=0). It is not possible to change it at once more than max allowed f-error, and until the transition is done the axis.*.f-error-max (?) is muxed to higher value which has to be as high as the max offset.
I remember there was a suprise, and there was some similar parameter related to each joint, or that was just max-vel which had to be altered for the joint in order for it not to jump too violently. I can say more when I cut the important things from the real config.
When the offset is zero it should be possible to switch the kinematics safely. With the drag knife engraving problem, zero offset would possibly mean the exact inside of the ring, other variants could be less-safe, however I believe similar hal solutions can be used for other scenarios.
If I do the switch off at Y=0 Z=0 (or generally lower than offset), the tool can (and it would, but it did not so far) hit the platform, so that needs some care.