Rigid tapping and PID control

Thank you andypugh for your reply.

The version of LinuxCNC is 2.8.2.
I have checked many control pins, including MUX2, but I haven't found any inconsistencies.

I suspected the possibility of noise in the electrical wiring, but I have not found any problems related to the number of revolutions of the spindle in various operations. I have a problem with G33,1.

Regarding the description of HAL, I suspect that there is something that seems to be a problem in the description such as loadrt and addf and the position of the line of net.

What were the PID inputs and outputs doing? Did the command change unexpectedly, or did the output change unexpectedly?

Suppose you ran G33.1 with the NC program mentioned in the first post.

pid_sp.command still receives 3.333.
The value of pid_sp.feedback will increase immediately. If no other spindle command is issued in advance, it will show a value of about 10. When Z reaches the specified depth and reverses, it shows the same value as the command value. If you have turned the spindle even once, it will run out of control up to the maximum speed of 50. At this time, even if Z reaches the specified depth, it cannot be reversed and returns to the position where it has gone too far.
pid_sp.output remains showing the maximum value of 10 in the event of a runaway.

Since it is a problem of PID processing, it is not possible to determine which is feedback or output.

Also, hole drilling cycles other than G33.1 work normally.

Of course, if you do not use PID for the spindle and use the speed control function of the servo amplifier, it will work without problems. The reason for using PID is to use the torque control of the servo amplifier and to use the orientation effectively.
 

You can use velocity control for spindle orient. In fact I would expect velocity control to work better for orient.

If you are working in torque mode then the PID output is a torque command, so can't be directly related to a speed command, so what you see is probably correct.

The pid_sp feedback is based on the encoder position feedback after being passed through a ddt. I think what is happening is that when the index resets during the G33.1 the encoder position changes by a _huge_ amount, and so the instantaneous velocity from the ddt is massively negative. (tens of thousands of revolutions / 1mS = negative _millions_ or rpm.
This leads to pre-loading the I-term with an enormous torque request, which takes a long time to unwind.

If the pid_sp.index-enable was connected, this should not happen (that is what that input is for).

So, first un-comment the pid_sp,index-enable line.

If that doesn't work, then set the pid_sp I-gain to zero, purely as a test of my theory.

Does the lcec driver output an encoder velocity directly? Most other LinuxCNC drivers do, and that should be configured to not glitch on index reset.
However, looking here: github.com/sittner/linuxcnc-ethercat/blo...c/lcec_el7342.c#L181
I don't see any sign of such a thing.

Thank you for the information, andypugh.

The index-enable matter is currently enabled.
It's a suggestion about PID gain, but when I gain was set to 0, it didn't run out of control.
However, it is rotating with a decrease of about 20% of the command rotation speed.
It is unthinkable in normal use. Normally
Pgain = 0.4
Igain = 0.5
Dgain = 0

Even if I gain is set to 0 and P gain is increased, overshoot may occur during rotation and the desired adjustment cannot be made.

If the servo amplifier is used for speed control, the orientation operation will be unstable, and it will take a long time to settle and time out. Therefore, the servo amplifier is used for torque control.

The encoder output from lcec will be count and Position when using the Beckhoff EM7004. The speed must be calculated using ddt. I don't know if I used another encoder module.

thank you for everything. I would like to try various things that can be considered.

Setting I gain to zero was intended as a test only. The fact that it worked seems to suggest that my theory about what is happening is correct.

If index-enable is configured in the pid_sp then I think that the problem now is that the ddt, pid and encoder read are running in the wrong order.

Currently you have (keeping only the relevant items)

Which, actually, looks correct.

It might be possible to mask (but not fix) the issue by using:

pid.N.maxerrorI float in

Limit on error integrator. The error integrator used by the Igain term will be limited to this value, unless it is zero. Can be used to prevent integrator windup and the resulting overshoot during/after sustained errors. Not normally needed.

add
To the HAL file and see if that helps.

500 is a guess. It might need to be higher to get spindle speed control, or lower to have the required result.