TCP 5-axis kinematics

M66 a sync command? does some needed trick internally?

Yes - a workaround to allow changes to motion module to
be passed back to task. The synchronization is a
normal activity for commands that need to synchronize
task and interp. Such 'Queue-busting' commands
include probing, toolchange, and the reading of hal
inputs -- like M66.

Can we combine this all under one G or M code
that is modal, like M128 what is user defined M command?
And M129 to deactivate it.

1. A user is free to create user M codes to invoke the
setting of the motion.switchkins-type pin with code
like:
But, they are USER codes -- so you as a user
are free to add them but the base LinuxCNC code cannot
reserve the M number without potentially affecting
existing, unrelated configurations in the field.
(And, you would still need a command to sync.)

2. Perhaps a better alternative: as a user, you can
probably remap a command to subsume the
o<switchkins>call[mode] functionality for both setting
the hal pin and causing a sync. The remap docs
indicate that you can remap commands to a modal group.
See 'Section 2.4 Execution Sequencing' in:

Ref: linuxcnc.org/docs/master/html/remap/remap.html
I haven't tried it as i am not a user of remap.

M128 is modal, so TCP active state is readable
from active modal codes in UI.

My understanding is that with the current and
longstanding LinuxCNC code, the display of active codes
by a UI is *not* generally indicative of the
contemporaneous state of the motion module. Currently,
the state reported is based on the interpreter which
rapidly queues commands up until a queue buster. This
queueing is commonly completed well before motion acts
on commands so is not very useful while running. The
(stalled) state-tags branches intend to address that
issue in the future (see references at end of message).

*****************************************************

The branch dgarr/s_kins intentionally avoids
modifications to the interpreter, task, and nml which
are needed for adding new gcodes. I avoided because:

1) Could not find a common/accepted/standard set of
gcode naming rules so the choice would just start a
debate and further delay implementation.

2) There are not many active developers that have
worked on the interpreter or task code in the last
several years to advise, help, or review code.

3) I do not have the experience or interest in the
wilderness of the interpreter and task modules to
want to undertake responsibilty for such code.

I think the dgarr/s_kins branch is workable and you may
be able to use remap to address your issues. If you
view your items as requirements it may be a long wait
for implementation.

*****************************************************
links for statetags branches:

Ref: github.com/LinuxCNC/linuxcnc/commits/feature/state-tags-master
last touched August 2015
Ref: github.com/LinuxCNC/linuxcnc/commits/statetags
last touched Oct 2016

statetags issues:
Ref: github.com/LinuxCNC/linuxcnc/pull/283
Ref: github.com/LinuxCNC/linuxcnc/issues/134

Hello

."A user is free to create user M codes to invoke the
setting of the motion.switchkins-type pin with code
like:
$ cat M128
#!/bin/bash
halcmd setp motion.switchkins-type 0 # trivins
exit 0

$ cat M129
#!/bin/bash
halcmd setp motion.switchkins-type 1 # xyzac,xyzbc
exit 0
"

Yes I'm already using this method, but can I include these Sync commands to it?

Or is it better to M128 to call subprogram that makes kin switch?


"1) Could not find a common/accepted/standard set of
gcode naming rules so the choice would just start a
debate and further delay implementation."

If I recall correct, TCP functionality is not included in ISO RS-274.

That is why TCP command varies between controllers.
Fanuc based controllers like: fanuc, mitsubishi, mazak, okuma, command is G43.4.

Siemens use TRAORI command to activate TCP.
Heidenhain native uses M128 to activate TCP.

I would not recommend to Fanuc way to use G43.4 for activating TCP.
Deactivating TCP in fanuc is done by G49 at the same time it will deactivate tool length compensation. I think you can go around this by commanding G43 again, this cancels TCP, but retains Toll length compensation on.


Currently we are doing it same way than Siemens or Heidenhain.
We have dedicated commands or in this case sub programs to turn on/off TCP(kinematics).
I think this is most best way.

Yes I'm already using this method, but can I
include these Sync commands to it? Or is it better to
M128 to call subprogram that makes kin switch?

A user mcode cannot call a gcode subroutine (the
interpreter is not reentrant) and currently there is no
way to request a synch except from gcode. However, I
could modify user m code handling so that a special
exit error code requests a synch. It is a signicant
change but could have some general utility so i will
investigate more.

A question regarding Heidenhain M128/129: What is the
default (startup) condition (M129==TCP_off or
M128==TCP_on)?

Eventually, i would *not* want to support redundant
code for kinematics (e.g., both
xyzac-trt-kins,xyzac-trt-switchkins) so we would have
only a single updated xyzac-trt-kins with switchable
enhancements (similarly for xyzbc).

Since there are existing users for xyzac-trt-kins,
for backwards compatibiliity, the startup (default)
kins type would need to be xyzac (e.g., TCP)

(If the TCP startup mode is mode is not wanted,
it could be addressed with a single halfile command
so i don't think it would be a show-stopper)

A question regarding Heidenhain M128/129: What is the
default (startup) condition (M129==TCP_off or
M128==TCP_on)?

I havent restarted a machine with TCP enabled yet but i believe that TCP off is the default.

Hello

I have newer countered a NC machine where TCP is on after reset or startup.
But if it is possible, there should be clear indicator that TCP is on.
Because rotary axis movement will cause a fast response of other axis.
This can cause those "brown pants" moments...

Sync included to user defined M command would be nice addition.

I'm thinking turnmill or millturn solution where C axis can be switched to positioning, spindle mode or TCP mode.

I am daydreaming of direct drive 4th axis {A axis}) that could be used as turning spindle.

I am daydreaming of direct drive 4th axis {A axis}) that could be used as turning spindle.

something like this?

Yep. That but bigger diameter motor, so called direct drive.

Today's update to branch dgarr/s_kins:

0) force-push commit (c6e267a0a):
Ref: github.com/LinuxCNC/linuxcnc/commits/dgarr/s_kins
1) startup in trivkins mode
2) sim configs now demonstrate remapped mcodes for
switching (similar to Heidenhain):3) revise sim configs, mark obsolete items for deletion
4) rebased to master

****************************************************
Notes:
1) The LinuxCNC remapping functions allow a subroutine
to be mapped to a g or m code but for remapped m codes,
numbers in the range 100-199 are not allowed since
they are reserved for *user* m codes.

Ref: 14.3 linuxcnc.org/docs/master/html/remap/rema...:unallocated-m-codes

2) Syncing from a user m code command is not feasible.

I work hard on a 5 axis machine for testing all these stuff.
Is there a step by step tutorial to include all your work in LCNC?

Best regards
Sven

Is there a step by step tutorial to include
all your work in LCNC?

Not sure i understand the question but the buildbot
is not working these days so one must build LinuxCNC
from source and use run-in-place (RIP) builds. You
must learn the process to build and run a RIP build
as documented here:

linuxcnc.org/docs/master/html/code/building-linuxcnc.html

With respect to dgarr/s_kins, i've put some addtional
info here:

www.panix.com/~dgarrett/stuff/s_kins_guide.txt