OLD Lathe conversion to a CNC

Today I ran some more tests. I can now reproduce the issue described in the other thread with 100% consistency. I noticed that when the Z-axis is moving, G96  doesn't seem to be working. I recorded a video showing that the spindle speed doesn't change at all during the movement.



PS. I think there might be something wrong with the HAL configuration. I just noticed that when starting LinuxCNC, I need to go into the calibration settings and re-save the PID values for the spindle (I enter test). If I don’t do that, the PID control is soft– under higher spindle load, it triggers a hold  .Also, if I leave LinuxCNC running idle (without running a program) for about an hour, and then start program execution again, the axis movement speed during a G1 command is once again higher than what was set.

Today I started the program with the axis graphical interface. No change, the problem remains. Could someone check the HAW connections?

this problem also exists : " ... I just noticed that when starting LinuxCNC, I need to go into the calibration settings and re-save the PID values for the spindle (I enter test). If I don’t do that, the PID control is soft– under higher spindle load, it triggers a hold .Also, if I leave LinuxCNC running idle (without running a program) for about an hour, and then start program execution again, the axis movement speed during a G1 command is once again higher than what was set."

You don't have auto-tuning PID permanently in tuning mode by any chance?

The HAW show shows that automatic tuning is not enabled.
What can I test? The problem I have is serious.

There is mention in the HAL of closed-loop steppers. Does this mean that you are closing the position loop in LinuxCNC HAL with encoders and PID (you clearly _are_ doing this) but do you also have closed-loop stepper drivers that also read the encoders?

It is possible that your problem is due to cascaded controllers.

I would be tempted to try a making an alternate config without the DPLL and with the stepgens in position mode, directly driven by motor-pos-cmd. Having a PID in HAL ought to give better results, but if the problem goes away with a more "classic" config then that at least suggests somewhere to look.

X and Z operate in open loop .The encoder (X and Z ) is not connected to the PID controller.
I also have protection in the motor driver if it misses a step.
I also checked the spindle pid controller constants in the haw show .All constants entered.

Can you post your hal/ini files?

Might help with more eyes looking at them
 

PCW wrote:

Can you post your hal/ini files?

Might help with more eyes looking at them

 

I found some configs posted earlier in the thread:  forum.linuxcnc.org/26-turning/52640-old-...-cnc?start=60#326830

Ahh, I missed that

As far as the spindle speed changing goes, it would probably be helpful to
disable the PID/feedback, in case there's something odd going on there.

Disable the feedback by setting all PID terms to 0 except FF0 so the
PID component is just a pass through.


Another thing for debugging would be to dump all the hal pins when
things are working correctly and when misbehaving:

halcmd show all > ok.txt

halcmd show all > bad.txt

and post the results here.
 

I found the issue with G1 — it's an easy fix. When I stop the program while it's running with G96, there is a G95 command loaded just before it. But when I start the program from the beginning, there's no G94 command in the G-code.

The PID problem is caused by the pid.s.maxerror constant — I had accidentally used the same name twice. I'm also adding the issue with Gmoccapy as described in the relevant topic. forum.linuxcnc.org/20-g-code/44739-g96-issue