general questions about 6dof system

Aciera wrote:

1. Limitation: We need to be able to switch kinematics from inside gcode and we cannot do that in regular LinuxCNC-master. We need to build Dewey Garrett's 'switch-kins-branch' since his work was not allowed to be merged with master.

I can't imagine that anyone prevented it being merged with Master. I don't think that anyone could. Dewey has push-rights. I don't recall any discussion on the matter in which any opinion was given either way.

If I recall correctly, Deweys wording was that his code changes for switch-kins "were not accepted to be merged with master". As to why or by whom I have no idea but apparently the place to lobby for such things would be the developers mailing list. At the time I was a very new user of LinuxCNC so I certainly didn't feel like I had any business speaking up at the developers table. I do recall some concerns that the switching of kinematics would cause servo systems to throw a following error. Come to think of it I'm actually not sure if I found that to be a problem with my robot configuration.
He also noted that the number of users using non-trivial kinematics is rather small so I guess there are not many to actually do any lobbying for such things.
In any case when I contacted him last winter about merging the switchkins-branch with the current master he seemed to have moved on with other projects but kindly agreed to rebase the branch on the current master so Dmitry could merge his nxy-branch with the switchkins-branch.

I for one feel that the ability to switch kinematics in GCODE is not only a USEFUL addition to LinuxCNC but is actually a NECESSITY for anybody using non-trivial kinematics. Whether it's 5 axis milling or serial manipulators switchkins makes a LOT of things possible.
We even use it on a mill with a manual swivel head to mill slanted holes in handrails.

I'm sorry sibelius for getting your thread off topic but I miss quoted Dewey in my last post and I would like to set things right.

In my last post I wrote this:

If I recall correctly, Deweys wording was that his code
changes for switch-kins "were not accepted to be merged
with master".

This is Deweys response:

I don't think i said the above at all -- there is no
procedure to 'accept' a major change. But, there may
be well-reasoned *objections* either before or after
a change and the changer is obliged to respond i suppose.

Not that this is a big deal but I felt that in times of fake news and alternative facts I had to flag my own disinformation and set the record straight.

My apologies again.

Robot toolpaths will look exactly the same as any other TCP toolpath.

I think that (with the right options paid for) Fusion 360 can do it. (It needs a few switches to be changed in the generic LinuxCNC post-processor to enable TCP mode)

The PocketNC can run in TCP mode, I think, and they seem to bundle Fusion360. (PocketNC uses LinuxCNC/Machinekit as the controller)

Roiki wrote:

Pocketnc doesn't have inverse kinematics so no tcp support.

But you said that about LinuxCNC too.

For professional use:
www.robotmaster.com/en

I believe RoboDK has an import function for GCODE toolpaths and it can then create the corresponding code for the particular Robot/Controller.

All solutions will of course require the exact mathematical model of the robot in use.


Here is a very readable introduction to the problems of singularities:
www.mecademic.com/en/what-are-singularit...a-six-axis-robot-arm