Switchkins Master possible malfunction/bug.

We have got the new sim working and have run the tests on the target hardware with the short circuit as requested. The short circuit makes no difference to the problem - ref the plots attached. The second plot is just zoomed in - please ignore the plot on joint.2.motion-pos-fb and axis.c.pos-cmd prior to the switch. I suspect these are happening as the homing does not complete due to the short circuit. However, the shape of the command after the swithkins switch clearly shows that the problem is still there irrespective of the short circuit.

With reference to the code - could I please request an update to the stest branch (as I am not able to rebuild the code myself at this stage). From my analysis of the debug prints, it seems the problem is originating in the call to getStraightVelocity from flush_segments. It would be useful to have the values printed in function getStraightVelocity if the value of debug_velacc is non-zero. So a build where

static int debug_velacc = 1;

would be appreciated.

It is a relief that you can reproduce the problem. Thanks for the effort!
We have done the test as requested (ie first move after G12.1 does not specify an X axis value) - and can confirm that in this case, the problem is
not there.

(Only now saw your next post - will test and revert shortly)

I ran the test
G0 X40 Z10 A0
kinematic switch here
G01 Z10 A20 F100 <- this move is executed with feedrate as specified
And confirm the move is correct in this case

I have managed to rebuild the linuxCNC software myself and as such can report on some progress on this issue.

In all tests below, I am using the ngc as follows 
G8 ;radius
G18
G01 X20       F800
G0 C0
G12.1
G01 X20  C20  F800 
G01 X-20 C20  F800
G01 X-20 C-20 F800
G01 X20  C-20 F800
G01 X20  C0   F800
G13.1

I believe the problem is arising due to the following lines in function handle_kinematicsSwitch:

      kinematicsForward(joint_posKinsSwitch,  &emcmotStatus->carte_pos_cmd,  &tmpFFlags, &tmpIFlags);                                           
      tpSetPos(&emcmotDebug->coord_tp, &emcmotStatus->carte_pos_cmd);

I printed the value of emcmotStatus->carte_pos_cmd.tran.x before and after the call to kinematicsForward. (kinematicsForward will be 
setting carte_pos_cmd.tran.x to the X axis Joint position). 

   Before : emcmotStatus->carte_pos_cmd X=-52.25000000
   After : emcmotStatus->carte_pos_cmd X=-52.2500000120

As the two values are not the same, the move is seen to be a Cartesian Move (very small...) as well as an Angular Move

(In previous posts I reported that in the case of the incorrect move, the values of vel, ini_maxvel and acc as output from functions getStraightVelocity/getStraightAcceleration in emccanon.cc were always set to zero. The values are in fact not zero, but very small. These very small values are generated as canon.cartesian_move && canon.angular_move are both non-zero (as dx is not zero). The value of out.tmax will 
be derived from the C axis move time (as this is the longest time), but the computation of out.dtot will use the dx value, which is very small - hence resulting in a very small out.vel value. The same applies in function getStraightAcceleration. I was able to get the correct vel and acc values by using a comparison to an EPSILON_ZERO value (rather than zero) in lines
        if (dx <= 0.0 && dy <= 0.0 && dz <= 0.0 &&
        du <= 0.0 && dv <= 0.0 && dw <= 0.0) {
and 
        if (da <= 0.0 && db <= 0.0 && dc <= 0.0) {
However - this did not solve the problem of the incorrect move....)

What I have established conclusively is that the incorrect move is as a result of the line 

    tpSetPos(&emcmotDebug->coord_tp, &emcmotStatus->carte_pos_cmd);

The small deltaX is somehow resulting in the trajectory planner generating the incorrect move we are seeing. I proved this by using the following code, which ensures that the value of emcmotStatus->carte_pos_cmd.tran.x passed to function tpSetPos does not result in tpSetPos seeing a small delta X:

      savedPosX =  emcmotStatus->carte_pos_cmd.tran.x;      
      kinematicsForward(joint_posKinsSwitch,  &emcmotStatus->carte_pos_cmd,   &tmpFFlags, &tmpIFlags);
      emcmotStatus->carte_pos_cmd.tran.x = savePosX ;                                             
      tpSetPos(&emcmotDebug->coord_tp, &emcmotStatus->carte_pos_cmd);

In this case, the move is generated correctly.

It has been reported previously that if in the first move after G12.1, X is not defined 
G12.1
G01 C20  F800 
the move is correctly generated. 

I can only assume that in this case, although the same small deltaX value exists, it is not used by the trajectory planner as X was not specified - but I have still to confirm this in the code.

I am hoping that this information will help those more closely acquainted with the source code to be able to hone in on the
problem and how best to address it. Perhaps one needs to relook at the calls in handle_kinematicsSwitch as these seem to be the root
cause of the problem.

I also think that one may be able to get the problem happening in the simulation by forcing the value returned by kinematicsForward to be a small delta from the joint position (as in the real world....). This is assuming that in the simulation, the joint actual positions are probably just set to the joint commanded positions, which would explain why until now the problem has not been reproduced in the simulation

You are correct, i've been working on the problem after
finally reproducing with real hardware this weekend
(my sim configs were too ideal) and posted a branch
with two commits:

branch: dgarr/stest3

If you and Aciera can test and veriy using a buildbot
deb, will merge to the master branch.  (the buildbot
is currently backlogged for a few hours)

749edfb04  is a fix (i think, not sure if there are
           unintended consequences)
80eb27741  is some additional cleanups

github.com/LinuxCNC/linuxcnc/commit/749edfb04
github.com/LinuxCNC/linuxcnc/commit/80eb27741

Good news - I can confirm that with the updated file control.c the problem is resolved! Many thanks for your efforts.

If I may... as you will be updating the build I would suggest that the functions getStraightAcceleration and getStraightVelocity in emccanon.cc also be changed such that the comparisons use as EPSILOB_ZERO value (similar to TP_POS_EPSILON in tp.c) rather than expect a delta value of zero in the lines such as 
        if (dx <= 0.0 && dy <= 0.0 && dz <= 0.0 &&
        du <= 0.0 && dv <= 0.0 && dw <= 0.0) {
and 
        if (da <= 0.0 && db <= 0.0 && dc <= 0.0) {

I have two further questions I hope are a lot less complex than the previous one:
(1) I am needing to access the value G54_X (as stored in variable 5221) from my component. Can you advise / suggest how I can access it?
(2) I am needing to command the C Axis to do the homing function from my component. How can I generate that request? 

> ... I would suggest that the functions
> getStraightAcceleration and getStraightVelocity in
> emccanon.cc also be changed ...

Ref:
github.com/LinuxCNC/linuxcnc/blame/maste...ask/emccanon.cc#L643
github.com/LinuxCNC/linuxcnc/blame/maste...ask/emccanon.cc#L772

code not touched in at least 14+ years

Note that if an epsilon test had been incorporated in the
emccanon functions, the principal or "root cause" mistake in
handle_kinematicsSwitch() would be masked and lurk until exposed
in some future use case.


You could certainly make a pull request (especially if you
can provide evidence of a problem) and some developer with
in-depth knowledge of emccanon.cc may incorporate it.

Ref:
linuxcnc.org/docs/master/html/code/contr...ing-to-linuxcnc.html

> I have two further questions I hope are a lot less complex
> than the previous one:

Probably better to start new forum topics for questions not
closely related to existing topic.