Switchkins Master possible malfunction/bug.

i think you you can download the deb from the linked dir and install:

$ wget buildbot.linuxcnc.org/dists/buster/scrat...~7e7a1c756_armhf.deb
$ sudo dpkg -i linuxcnc-uspace_2.9.0~pre0~dgarr.stest~7e7a1c756_armhf.deb

I plan to update the stest branch so that the sim config is more like OP's
config in ini settings and force push that branch this weekend.

The deb name includes the top commit: 7e7a1c756
(Scratch debs are available for a limited time.)

Thanks for the guidance - I lack experienced with this so battle a bit.
I think the Pi4 is a bit of a waste of time - After doing as you proposed I end up with broken packages in Synaptic - linuxcnc-uspace-dbgsym and linuxcnc-uspace-dev
and with linuxcnc-uspace (1.2.9.0~pre0~dgarr.stest~7e7a1c756) starred for 'upgrade'

Linuxcnc then obviously has no Stest in the config picker..
When I ran sudo dpkg there was a warning - downgrading linuxcnc-uspace from ....pre.4830.gfaab5f10e to ....dgarr.stest.7e7a1c756, but the dpkg ran and completed ok.

I don't want to waste your time with this and the Pi - resolving the odd axis behaviour is the aim!
We have some ideas wrt modifying the mill-turn sim itself to simulate the same problem - probably the quickest route now.
In parallel I am procuring an amd64 pc - the only other pc's around are old 32bit machines - one has Lcnc/wheezy/stretch on it, but I think we will mess around with the same issues on that - I am reluctant to use the pc on the lathe for this since I fear breaking that one as well!

Any comments of the capture using Task_Issue ( with the missing feedrate in the linear move)?

Attesting to my linux inexperience..I redid the master install on the Pi4, and achieved a successful install of the stest branch - all running on the Pi.
I will let you know how it goes.

We have tried to reproduce the problem in the stest simulation - without success. On the Simulation, the first C axis move after the switch is generated correctly, whereas with the same ini file settings on the actual lathe, it is always incorrect. 
The problem seems to be related to what occurs as a result of the M66 command after the M68 command. What we have noticed is that there is
a repeatable difference in the motion.program_line log.
The ngc file is as follows
G7
G18
G01 X40 F800
G0 C0
G12.1
G01 X40 C20 F800
G01 X-40 C20 F800
G01 X-40 C-20 F800
G01 X40 C-20 F800
G01 X40 C0 F800
G13.1
M30
%


In the simulation, the log is line 3 --> 0 --> line6 (See plot of motion.program-line below)
  


Whereas in the real machine, the log is line 3 --> line 4 --> 0 --> line6 (See plot below of motion.program-line below)
 

We are not sufficiently clued as to what the significance of this is - but maybe it may aid those endeavouring to assist us with this issue to home in on the problem


 

Updated branch dgarr/stest 23oct21:
0) rebased to master (@be96bf6d6)
and force push dgarr/stest = commit 8c6a400f4
1) adds some debugging prints to supplement debug
TaskIssue messages
2) stest.comp provision for stest.fakeoffset pin
sim_pin stest.fakeoffset to activate in sim
3) uses [DISPlAY]OPEN_FILE=stest_square.ngc
with provisions to to add dwell command and
detect/exit for unexpected c,j2 values

If using deb: fetch and reinstall updated scratch deb
reqd, then use linuxcnc config picker to make an
updated stest sim config

Adding timing dwell(s) and test provisions akin to those in
stest_square.ngc might provide some clues on hardware
testing too.

github.com/LinuxCNC/linuxcnc/blob/dgarr/...est/stest_square.ngc

> Any comments of the capture using Task_Issue ( with
> the missing feedrate in the linear move)?

The debug print:
> Issuing EMC_TRAJ_LINEAR_MOVE -- ( +220,+208, +0,-52.250000,0.0,0.0,0.0,0.0,20.0,0.0,0.0,0.0, +2,0.0,0.0,0.0, +0, -1,)
i have not reproduced and have not yet found a scenario that can
reset ini_maxvel to 0.

The added debug prints in dgarr/stest may provide clues --
requires running the scratch branch (8c6a400f4) on the
hardware under test

Please post output from the command 'linuxcnc_info' for the
hardware under test.

You could experiment with the sequencing of the 'addf
caxis.0 servo-thread' to see how placing it last or first
changes the observed behavior.

We have performed the tests as requested. Results as follows:
(1) Playing with sequence of addf caxis.0 servo-thread makes no difference
(2) The outputs from the debug prints are as follows:
        Dwell_______ 0.000
        aBEFORE SWITCH OK j2=0.0
        bBEFORE SWITCH OK j2=0.0
        AFTER SWITCH OK j2=0.0
(3) linuxcnc_info for hardware is attached

Regardless of whatever changes we make to settings related to accelerations and velocities in the ini file, the problem remains unchanged with the problem line : (ie vel and ini_maxvel set tro zero)

EMC_TRAJ_LINEAR_MOVE -- ( +220,+208, +0,-52.250000,0.0,0.0,0.0,0.0,20.0,0.0,0.0,0.0, +2,0.0,0.0,0.0, +0, -1,)

We have hence searched the source code to trace the path of code executed as a result of the M66 command. 
This command will result in function 'flush_segments' being executed.With reference to the lines

    if (canon.cartesian_move && !canon.angular_move) {
        if (vel > canon.linearFeedRate) {
            vel = canon.linearFeedRate;
        }
    } else if (!canon.cartesian_move && canon.angular_move) {
        if (vel > canon.angularFeedRate) {
            vel = canon.angularFeedRate;
        }
    } else if (canon.cartesian_move && canon.angular_move) {
        if (vel > canon.linearFeedRate) {
            vel = canon.linearFeedRate;
        }
    }

the second case is applicable for our problem move (ie an angular move only). If for some reason, the value of canon.angularFeedRate is zero, this would explain why the values of vel and ini_maxvel are zero. Could this be the source of the problem?

Is there a pin by which we can gain further insight into these values?

 

> (2) The outputs from the debug prints are as follows:
> Dwell_______ 0.000 ...

testing for nonzero values (3sec) of Dwell would be
welcome too.

>> The added debug prints in dgarr/stest may provide
>> clues -- requires running the scratch branch
>> (8c6a400f4) on the realmachine under test.

To clarify, the debug prints referred to for
dgarr/stest include added prints to stderr (e.g., you
must: 1) run linuxcnc from the command line, 2) enable
debug for TaskIsuue, and 3) view/capture terminal
output).

> This command will result in function 'flush_segments'
> being executed.With reference to the lines ...

The branch dgarr/stest (8c6a400f4) committed 23oct
includes added prints in emccanon.c in flush_segments()
(and other places):
github.com/LinuxCNC/linuxcnc/blob/dgarr/...ask/emccanon.cc#L935

> the second case is applicable for our problem move (ie
> an angular move only). If for some reason, the value of
> canon.angularFeedRate is zero, this would explain why
> the values of vel and ini_maxvel are zero. Could this
> be the source of the problem?

Possibly -- I have not found a way to do that
in a sim config. If you find a way, let us know.

> Is there a pin by which we can gain further insight
> into these values?

You should load the test branch deb on the hardware
buster/amd64 machine to see, record, and post output
from the added prints (to stderr) in the test branch

e.g.; (for buster/amd64) replace the reported package
(master deb of 12oct21):

> ii linuxcnc-uspace 1:2.9.0~pre0.4760.gc4345283f

with the scratch deb (buster/amd64):

buildbot.linuxcnc.org/dists/buster/scrat...~8c6a400f4_amd64.deb

Using the scratch deb on the real machine: 1) start
linuxcnc from a terminal, 2) run the square.ngc and 3)
post a file of the terminal output and a snapshot of
the unexpected x,c motions, motion.switchkins-type,
motion.program-line.

We have upgraded to your latest version and run the tests as requested. Attached are screen shots and terminal outputs for cases with Dwell = 0 and Dwell = 3. Hoping the debug prints shed some light...

I examined the terminal output / prints done by your updated code.

Based on the values of axis velocity and accel I could link the prints in function flush_segments to the EMC_TRAJ_LINEAR_MOVE information.
This clearly shows that the last 4 moves are generated correctly.
However, the print in flush segments for the first move after the G12.1 (BOLD) shows a problem in that the values of linearMoveMsg.vel,  linearMoveMsg.ini_maxvel and linearMoveMsg.acc are all zero!
In addition, one would have expected the print related to the angular move only to have occurred (as we are moving from X40, C0 to X40, C20), but this print is not there.
So something is amiss after the call to handle_kinematicsSwitch()?

=== SET_FEED_RATE feed_mode=0 linFRate=  13.333 angFRate=  13.333 emc/task/emccanon.cc 566
=== getStraightVelocity feed_mode=0 linFRate=  13.333 angFRate=  13.333 emc/task/emccanon.cc 876

=== flush_segments type=2 vel=   0.000 ini_maxvel=   0.000 acc=   0.000 emc/task/emccanon.cc 980     this is X40 C20  First move after G12.1

=== SET_FEED_RATE feed_mode=0 linFRate=  13.333 angFRate=  13.333 emc/task/emccanon.cc 566
=== SET_FEED_RATE feed_mode=0 linFRate=  13.333 angFRate=  13.333 emc/task/emccanon.cc 566
=== getStraightVelocity feed_mode=0 linFRate=  13.333 angFRate=  13.333 emc/task/emccanon.cc 876
=== flush_segments type=2 vel=  13.333 ini_maxvel=  60.000 acc= 350.000 emc/task/emccanon.cc 980    this is X-40 C20 (based on 60,350)
=== getStraightVelocity feed_mode=0 linFRate=  13.333 angFRate=  13.333 emc/task/emccanon.cc 876
=== flush_segments vel=  13.333 (using canon.angularFeedRate)emc/task/emccanon.cc 939
=== flush_segments type=2 vel=  13.333 ini_maxvel= 500.000 acc= 750.000 emc/task/emccanon.cc 980    this is X-40 C-20 (based on 500,750), and is angular only
=== SET_FEED_RATE feed_mode=0 linFRate=  13.333 angFRate=  13.333 emc/task/emccanon.cc 566
=== SET_FEED_RATE feed_mode=0 linFRate=  13.333 angFRate=  13.333 emc/task/emccanon.cc 566
=== getStraightVelocity feed_mode=0 linFRate=  13.333 angFRate=  13.333 emc/task/emccanon.cc 876
=== flush_segments type=2 vel=  13.333 ini_maxvel=  60.000 acc= 350.000 emc/task/emccanon.cc 980    this is X40 C-20 (based on 60,350)
=== getStraightVelocity feed_mode=0 linFRate=  13.333 angFRate=  13.333 emc/task/emccanon.cc 876
=== flush_segments vel=  13.333 (using canon.angularFeedRate)emc/task/emccanon.cc 939
=== flush_segments type=2 vel=  13.333 ini_maxvel= 500.000 acc= 750.000 emc/task/emccanon.cc 980   this is X40 C0 (based on 500,750), and is angular only
Issuing EMC_OPERATOR_DISPLAY --      (   +13,+280,    +0,    +0,AFTER\032SWITCH\032OK\032j2=0.000000,)

Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-32.250000,0.000000,-5.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,-112.250000,0.000000,-5.000000,0.000000,0.000000,20.000000,0.000000,0.000000,0.000000,    +2,13.333333,60.000000,350.000000,    +0,    -1,)
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-112.250000,0.000000,-5.000000,0.000000,0.000000,-20.000000,0.000000,0.000000,0.000000,    +2,13.333333,500.000000,750.000000,    +0,    -1,)
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-32.250000,0.000000,-5.000000,0.000000,0.000000,-20.000000,0.000000,0.000000,0.000000,    +2,13.333333,60.000000,350.000000,    +0,    -1,)
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,-32.250000,0.000000,-5.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,    +2,13.333333,500.000000,750.000000,    +0,    -1,)

This is a follow up on our previous post. Please could you respond as to comments on what the debug prints show, and what further tests we can assist with.
Just a reminder that the problem does not occur if the first move after the switch is a cartesian move only, or a combined angular/cartesian move. The problem is there only if it is an angular move only

  Attached is a new sim config (stest2) that adopts
caxis.comp (renamed as stest2_caxis.comp) and implements
joint2 (c coordinate) using the in-tree sim_spindle
component configured with a velocity-based pid.

Instead of making a test branch, all files are included
in the attached tar file so it can be tested with the
master branch (or any branch based on recent master).
(The stest2*.comp hal components must be
halcompiled/installed).

Example:
$ wget stest2.tar ;# use link for attached file
$ tar xf stest2.tar ;# extract contents
$ cd stest2
$ # Note: sudo reqd for deb installs (not needed if RIP)
$ sudo halcompile --install stest2.comp
$ sudo halcompile --install stest2_caxis.comp
$ linuxcnc stest2.ini ;# run the stest2 sim config

In axis gui:
F1 # Estop off
F2 # Machine-on
Ctrl-Home # HomeAll
R # Run OPEN_FILE=stest2_square.ngc

==========================================================

A definitive test for checking the compatibility of a
machine's hal components/connections that manage
joint.N.motor-pos-fb values is to 'short circuit' the
joint's motor-pos-cmd to its motor-pos-fb. Such a test
will disable actual joint motion but ensure LinuxCNC's
expectations that joint.N.motor-pos-cmd and
joint.N.motor-pos-fb are *always* the same (to within
the limits enforced by inifile settings for
[JOINT_N]MIN_FERROR and [JOINT_N]FERROR).

The tar file includes an additional inifile
(stest2_shortcircuit.ini) that demonstrates this test
by adding a [HAL]HALFILE=shortcircuit.hal that removes
(unlinkp) prior joint.2.motor-pos-cmd, motor-pos-fb
connections and then makes the short circuit
connections.

When a configuration works as expected with
shortcircuit connections but fails with halfile
specified connections, something unexpected is
happening.

A similar test on real hardware would be useful.

One method is to copy the realmachine inifile to a
new 'test.ini' file and add an appropriate
[HAL]HALFILE=shortcircuit.hal.

==========================================================

The setting in CNC_Lathe.ini (zip file from post
223654) for [JOINT_2]MIN_FERROR=1000,FERROR=1000 are so
big they will likely mask unexpected following errors.
Large ferror settings may be useful while tuning but
should be set to realistic values for operation. Using
appropriate inifile ferror limits and plotting the
joint.2.f-error could be instructive.

==========================================================

Refs:

linuxcnc.org/docs/devel/html/man/man9/sim_spindle.9.html

linuxcnc.org/docs/devel/html/config/ini-...t__lt_num_gt_section

forum.linuxcnc.org/10-advanced-configura...n-bug?start=0#223654