JA13 scarakins wrong trajectory

k-1 wrote:

But I set P=20 why these is not a good idea??

You could try not using a PID loop at all. How does that work?

Use of a HAL PID loop is a moderately recent development, though back in the early days of EMC2 it was the only way to do it.

Stepper systems work pretty well without a PID loop in HAL. You connect motor-position-cmd to the stepgen position pin, connect the feedback pins to make sure that the system has managed to make all the steps, and that's it. That might be an experiment well worth doing with your machine, so that you only have one PID loop in the system, the hardware one in the servo drive.

With the switch to PREEMPT-RT kernel support it has been noticed that much larger latency can be tolerated with a Mesa card setup if the stepgen is driven by a PID loop in HAL. This is just a way to automatically compensate for thread jitter. But it isn't a a typical PID loop that needs tuning, all the loop parameters are known and the P, I, D and FF terms can all be derived analytically.

If your servo-thread rate is 1000uS / 1ms / 1kHz then the only correct number for the P term is 1000. If your serv-thread rate is not 1kHz then you might need a 500 or 2000. But unless you have an unfeasibly fast servo-thread rate a P-gain of 20 can not be correct.


So, my suggestion would be first to comment-out the PID parts of the setup, change the stepgens to position mode an run a "classic" stepper system. That will help decide if the figure-8 problem is due to the servo drives or due to corner-rounding in the LinuxCNC trajectory planner. Then you can try exact-path mode in the planner to eliminate that possibility. (to an extent, that might limit speed so much that you can't tell if the problem is still there)