Trouble debugging Config.

I created a configuration for one of our twin spindle routers (Z and W axis). In order to take advantage of the new trajectory planner, I could not use W movements in the carving G-code (only XYZ work). As a workaround I made a config that can use a couple of M1xx codes to slave and unslave the movement of the W axis to the Z. It seemed work quite well in a sim stepper config, but I am having some trouble with it on the real machine with servos.

To slave the W to the Z I will command both axis to the same height (relative to the material) usually with a g0z1w1, followed by the slaving M-code m122. This uses a couple of Mux2 components to connect the z-position command + an offset to the w-PID and the w-PID error + w-position command are connected to the w-feedback. So (when it's working) while the W is moving with the Z, the DRO shows W=1(+/- servo error).

The problems I am having are:
After first starting Linuxcnc, the first time I call the axis slaving command (M122) I almost always get a joint 8 following error, the Linuxcnc goes into shutdown (F2), and even while in shutdown or e-stop the DRO for the W will continue to runaway, but the axis will show no movement. If I Press F2 and issue an MDI G0W1, it will usually return the W back to what it should be, and I can unslave the axis and return to normal behavior.

After this initial screw-up it will often behave fine for the rest of the day, slaving and unslaving at the start and end of each run.

But once in a while for some reason it randomly does the DRO w runaway (w-axis hasn't actual ever moved noticeably). Issuing an MDI w command usually rights it.

This afternoon it took off once when no one was watching and when I got to it F1 and F2 (e-stop and machine power) were completely unresponsive, while W DRO showed over 43K inches and climbing. Since I could not re-power the control, I could not issue the MDI w command. I had to close Axis and restart.

Any suggestions

Consider the case where mux2.1.sel == 1
If the average w-error is non-zero then the sum2 will increase without limit. (especially if the PID is disabled)

So, is the sum2 not the right hal component to use for this?

It does seem to work most of the time. Such as when the axis are not slaved, the inputs mux2.1.in0 and mux2.1.in1 are mostly equal. (maybe +/- 0.00001 while moving), but that is hard to see when just watching the mux2 inputs with hal meter or hal scope.

What would you recommend instead?

I think I've also noticed when the DRO runs away that axis.8.motor-pos-cmd is moving the same as the DRO position??? Could this possibly be related to a similar bug in the tool planner that I thought was fixed a couple of weeks ago?

Todd Zuercher wrote: So, is the sum2 not the right hal component to use for this?

I would expect to be using a sample-hold to feed an offset into an "offset" component in this application.

You can't use the actual sample-hold component ( linuxcnc.org/docs/html/man/man9/sample_hold.9.html ) as that is S32 data-type, but you can use a mux2 that feeds back into it's own input.

Maybe you are misunderstanding just what I am trying to do with the sum2.

How I understand motion works, is that it generates the axis.N.motor-pos-cmd then compares that to axis.N.motor-pos-fb to determine if a following error alarm should be set. When I have the axis slaved to a different command source obviously the motor feed back positoin will not be what it should be. I wanted to fool the system by adding the servo error from the w=pid to the axis.8.motor-pos-cmd. That way if there is a problem with the servo a flowing error alarm will still be generated.

On the position command side, when the M122 is called i think (and hope) it sets sets the value of the offset (which is the difference between the motor command values of z and w) at that instant. That offset plus the z motor-pos-cmd becomes the new pos-cmd to the w-PID.

I suppose I could short circuit axis.8motor-pos-fb entirely and use a near Near component to check for excessive servo error. but then I'd loose motions ability to use a corcer feedback limit for high speed movement and finer for low.

Todd Zuercher wrote: Maybe you are misunderstanding just what I am trying to do with the sum2.

Almost certainly.

How I understand motion works, is that it generates the axis.N.motor-pos-cmd then compares that to axis.N.motor-pos-fb to determine if a following error alarm should be set.

The "offset" component is specifically designed to lie about feedback for this sort of application.