Switchkins Master possible malfunction/bug.

ORIGINAL DELETED - Obviously too much detail to elicit any response..

Reposted with hopefully improved and more brief statement under:
Switchkins Testers

We are using LinuxCNC Master with its switchkins. We use the G12.1 and G13.1 gcodes to switch between non-polar / polar kinematics. We have remapped the G12.1 and G13.1 gcodes to command the required switch in kinematics.........etc

The plots are curious but i have not been able to
reproduce problems based on my understandings (no
posted details for your kins, ini settings,etc.).  The
tools used to make the plots do not appear to be ones i
am familiar with so i have made a test branch
dgarr/stest which replicates (as far as i understand)
the basic setup and uses halscope for plotting:

test branch: dgarr/stest includes:

1) simplified sim config:
     configs/sim/axis/vismach/stest/stest.ini
based on:
     configs/sim/vismach/millturn/millturn.ini.
(reduced scope, no vismach, pyvcp panel, etc.)
uses remaps g12.1,g13.1 (g121.ngc,g131.ngc)

2) stest.comp -- kinematics module based on the
switchkins millturn.comp (xzya) but performs
*identical* forward/inverse kinematics calculations for
any switchkins type

3) test ngc file: stest.ngc -- attempts to replicate
the problem sequence (with simplifications to remove
tool handling etc.)

Test branch Ref:
github.com/LinuxCNC/linuxcnc/commits/dgarr/stest

Actuating g0 when a g1 was expected would be odd for
sure but the most interesting thing i see in the plots
(halscope2.txt) is that it shows (as i understand it) a
single block (N108 G01 X40 C20 F800) implemented using
overlapping moves -- the plot shows the x movement
starting in the middle (approx) of the c movement (i
didn't think that is possible for the interpreter to
generate overlapped moves -- movement for each
coordinate specified always start and end in concert --
so i'm not sure how the plot was generated or if the
block is what was i think was reported).

#

---

I see no overlap nor unexpected rate on a combined
linear/rotary move following a kinematics switch:

halscope plot: stest.jpg

 


#

---

You can try the sim config :

  configs/sim/axis/vismach/stest/stest.ini

using the test branch (dgarr/stest rebased on recent
master master7c60ea8b8 Sat Oct 16 14:28:50) to see if
you can modify the config or kinematics component
(stest.comp) to reproduce the problem (using xyza).
Perhaps your result is dependent on ini settings for
max velocities or accelerations (that are unknown to
me) or on other things left out in the provided,
simplified sim config.

The sim config includes a halscope app triggered
by motion.switchkins-type and a sim_pin app to
aid in running a loaded file (stest.ngc) and for
altering (between runs) ini settings for the x,a
coordinates' max_velocities.

I can't guess your config details but the problems
described would likely be reproducible by modifying the
stest.ini sim config if it is a systemic problem in
core LinuxCNC code.

#

---

Also note:

Re:

(Note that this Joint type is set to
ANGULAR in the ini file)

Ini settings for [JOINT_n]TYPE and [JOINT_n]UNITS are
*not* used anywhere in the core LinuxCNC code.  The
confusing/unused provisions for these settings are an
unclean legacy inherited by joints-axes updates and
will likely be removed in the future.

See branch dgarr/joints_updates:
Commits (rebased to master branch 16oct21):

github.com/LinuxCNC/linuxcnc/commit/775fc7060
github.com/LinuxCNC/linuxcnc/commit/5bed440fe
github.com/LinuxCNC/linuxcnc/commit/6a36a554e
github.com/LinuxCNC/linuxcnc/commit/a8fd6574b


#

---

Other notes:

Using Inverse Time mode (g93) is often required when
combining linear(xyz) and rotary(abc) coordinate
motion.

Using g94 (units per minute mode) may have some
surprises.  From a few quick experiments:

a) G94 linear(xyz)-only g1 move
The feed rate is interpreted as linearunits/minute
and is constrained by the linear(xyz) ini vel/accel limits

b) G94 rotary(abc)-only g1 move
The feed rate is interpreted as angularunits/minute
and is constrained by the rotary(abc) ini vel/accel limits

c) G94 linear(xyz)/rotary(abc)-combined g1 move

The feed rate is interpreted as linearunits/minute and
is set to the current F word number if and only if the
resultant motion can comply with both the linear and
rotary constraints (vel/accel limits).  If either the
linear or rotary limits are constraining,  the rate is
set to the largest linear rate allowed to complete
the linear and rotary movements at the same time.
 

Thank You for responding - much appreciated.
Please forgive our use of strange tools! We have in past times done a lot of flight control data analysis and so developed tools to be able to investigate large data files and so did it that way. Also, I have not found how to capture screens in the linux machine..other than a photo of the screen which is not so nice...

We have done some more work based on your observations and efforts:

 We compared your remaps for G12.1 and G13.1 to ours and they are the same. Also, the component stest.comp is essentially the same as our component (gn_userkins.comp - attached) except that we use axes x (Joint0), z (Joint1), c (Joint2) and b (Joint3 For the ATC).

To avoid confusion, we have done a plot with halscope which clearly shows the problem in the plot of axis.c.pos-cmd - the first axis.c.pos-cmd after the trigger on kinstype.is-1 is not  per the defined feedrate.

For our C axis, we are using a component which was developed by Andy - caxis.comp. We have investigated this deeply and cannot see that this could cause the problem - Caxis.comp functions as expected in all other cartesian/rotary/Trivkins modes, before any Switchkins switching.. we have attached it just in case you believe there could be an issue here?

Attached are also our ini and hal files.

Regarding adding simulations - We have not recompiled Master software ourselves-  it is a download via Buildbot and as such, I am unsure how to add a simulation as you suggested. Please advise if it is possible to do this in this case.

 

Further investigation to try home in -

First, to be sure that the CAxis component is not a possible source of the problem-
The component was modified so that after the G12.1 remap (ie switchkins type change - ref kinstype.is-1in plot), the component was inactive. It would no longer update any variables used by linux cnc.

In the first plot below, the CAxis is enabled - trace of c-pos-fb (a value output by the component) follows
axis.c.pos-cmd.
 

In the second plot, the CAxis is disabled after the kinematics switch - trace of c-pos-fb remains constant.
In both cases, the trace of axis.c.pos-cmd is the same - ie the first move on C after the kinematics switch
remains incorrect.
 

In the second test, we removed the M66 command in the remapped G12.1 file, hence not performing a synch after having 
requested a change in kinematics. The result is shown in the third plot. There is a step change in the axis.c.pos-cmd
 - as one would expect for a G00 move in C, instead of the requested G01 move.
 


Still points to Switchkins..

 

> Also, I have not found how to capture screens in the linux
> machine..other than a photo of the screen which is not so
> nice...

A photo is ok if it shows details like the per div time scale
etc and is not too blurry. (but there are many answers to a
search engine request for "how to screenshot in linux")

It would help to accompany halscope screen shots with the
exact gcode file used.  I am still puzzled by plots showing
overlapped x,c motion e.g., with non-simultaneous starting
and stopping of x and c.  Including motion.program-line in
the plots might clarify what is happening.

#____________________________________________________

> Regarding adding simulations - We have not recompiled
> Master software ourselves-  it is a download via Buildbot
> and as such, I am unsure how to add a simulation as you
> suggested.

Instructions for getting a buildbot test ('scratch') branch
are provided at:

buildbot.linuxcnc.org/

19oct21: Updated the branch dgarr/stest (force push) to
rebase to the current master branch and configure as xyzc
(formerly was xyza).  i have not reproduced
the problem as yet.

When using the buildbot scratch deb, you can start linuxcnc
normally and save the stest sim config fron the
configuration picker as usual.

The stest.ini sim config is a implementation that provides
all the hal components and connections needed to test the
interactions of the the LinuxCNC modules -- interpreter,
task, io, motion (with switchkins) -- in order to examine
gcode behavior as well as the affects of inifile settings.

After testing the unmodified stest.ini sim config with the
supplied parameters, you can modify the sim config inifile
settings, gcode file, etc. to try to reproduce the problem
you are seeing.

If you are unable to run the stest config, i can
prepare a tarfile for it

#____________________________________________________

You may find it useful to view "Task_Issue" debug messages
when testing gcode (or mdi) to check if unexpected motion
requests are issued from the interpreter to task.  These
messages can be enabled from the axis gui menu:
  Machine/Set_Debug_Level/Task_Issue

Alternatively, use ini setting [DISPLAY]DEBUG=0x10

Debug flags are defined in:
github.com/LinuxCNC/linuxcnc/blob/master...ml_intf/debugflags.h

#____________________________________________________

I need to study more but briefly, debugging Task_Issue
will show (to stdout) EMC_TRAJ_LINEAR_MOVE
commands issued for both g0,g1 moves.   The command
specifies (to the trajectory planner in motion) a
Cartesian endpoint (xyzabcuvw), and settings required
to plan the move.

Example:

Issuing EMC_TRAJ_LINEAR_MOVE --     (  +220,+208,    +0,-10.000000,0.000000,0.000000,0.000000,0.000000,20.000000,0.000000,0.000000,0.000000,    +2,13.333333,60.000000,400.000000,    +0,    -1,)

args:
 4th arg is x coord endpoint
 5th arg is y coord endpoint
...
12th arg is w coord endpoint
13th arg is type          1 == g0, 2 == g1
14th arg is vel           in units/sec     (13.33u/s == 800 u/m)
15th arg is ini_maxvel    in units/sec     (60u/s    == 3600 u/m)
16th arg is accel         in units/sec/sec
17th arg is feed_mode     units_per_minute=0,inverse_time=1,units_per_rev=2
18th arg is indexer_jnum  -1 if not used

i have not seen unexpected values using stest.ini

Unexpected overlap:

 

Thanks for the response. We will execute with debug enabled tomorrow. Just a comment - you refer to being confused as 'c motion starts before x motion'. We would expect this as the gcode file here is:
G01 X40 C0 F800
G12.1
G01 X40 C20 F800 --> here only axis.c.pos-cmd should change
G01 X-40 C20 F00 --> here only axis.x.pos-cmd should change
So one would expect the x motion to start only when the c motion is complete. However, we have it starting BEFORE the c motion is complete - unless we take out the sync - in which case the axis.c.pos-cmd is a step change, and axis.x.pos-cmd starts immediately after axis.c.pos-cmd.
What is intriguing is the shape of the axis.c.pos-cmd - it really looks like feedback from a typical axis move - accelerate, run at a velocity, decelerate. We are clueless where this shape of cmd can come from

I have attached the zip file of my config as requested

 

As suggested, I have done captures using Task_Issue and this shows the problem being in the first EMC_TRAJ_LINEAR_MOVE command after the kinematics switch.

Case 1 (First move after G12.1 is move on CAxis only) (The problem case)
Relevant lines in the gcode file (square.ngc) are as follows :
G01 X40 F800
G0 C0
G12.1
G01 X40 C20 F800
G01 X-40 C20 F800
The relevant debug prints (ref  square.txt) give:
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-52.250000,0.000000,0.000000,0.000000,0.000000,-0.000000,0.000000,0.000000,0.000000,    +2,13.333333,60.000000,350.000000,    +0,    -1,)
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-52.250000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,    +1,60.000000,60.000000,400.000000,    +0,    -1,)
Issuing EMC_MOTION_SET_AOUT --      (  +304,+48,    +0,\003,1.000000,1.000000,\001,)
Issuing EMC_AUX_INPUT_WAIT --      ( +1209,+40,    +0,    +0,    +0,    +0,0.000000,)
Issuing EMC_TASK_PLAN_SYNCH --      (  +516,+24,    +0,)
kinematicsSwitch(): type=1
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-52.250000,0.000000,0.000000,0.000000,0.000000,20.000000,0.000000,0.000000,0.000000,    +2,0.000000,0.000000,0.000000,    +0,    -1,)
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-92.250000,0.000000,0.000000,0.000000,0.000000,20.000000,0.000000,0.000000,0.000000,    +2,13.333333,60.000000,350.000000,    +0,    -1,)

Note the first EMC_TRAJ_LINEAR_MOVE after kinematicsSwitch() has vel, ini_maxvel and accel all set to 0!!!

Case 2 (First move after G12.1 is move on XAxis only) 
Relevant lines in the gcode file (squarewithlinera.ngc) are as follows :
G01 X20 F800
G0 C0
G12.1
G01 X40 C0 F800
G01 X40 C20 F800
G01 X-40 C20 F800
The relevant debug prints (ref squarewithlinear.txt) give
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-62.250000,0.000000,0.000000,0.000000,0.000000,-0.000000,0.000000,0.000000,0.000000,    +2,13.333333,60.000000,350.000000,    +0,    -1,)
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-62.250000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,    +1,60.000000,60.000000,400.000000,  
Issuing EMC_AUX_INPUT_WAIT --      ( +1209,+40,    +0,    +0,    +0,    +0,0.000000,)
Issuing EMC_TASK_PLAN_SYNCH --      (  +516,+24,    +0,)
kinematicsSwitch(): type=1
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-52.250000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,    +2,13.333333,60.000000,350.000000,    +0,    -1,)
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-52.250000,0.000000,0.000000,0.000000,0.000000,20.000000,0.000000,0.000000,0.000000,    +2,13.333333,60.000000,400.000000, 

In this case the first EMC_TRAJ_LINEAR_MOVE after kinematicsSwitch() has vel, ini_maxvel and accel set as expected
 

To aid debugging I am trying to get the sim running on a Rpi-4 on the bench in the study - the lathe and Linux computer are down in the workshop - cold and no internet. I have managed to get linuxcnc master running on the Pi, but see no scratch branch for ARM ( Pi processor architecture), only amd64, etc.
Am I correct in assuming I cannot get your Stest onto the Pi then?...I tried various combinations of stanza in Synaptic>settings>Repositories, to no avail, referring to the files in > buildbot.linuxcnc.org/dists/buster/scrat...reempt/binary-armhf/.
If not possible, not a big deal, I will find another amd64 pc to play on.