PID problem with 'D' in ver 2.5 & 2.5.1
Hello,
I am new to forum so I hope I am putting this post in the proper place.
I recently converted two large servo driven milling machines from my old DOS based system to Linuxcnc 2.5 and 2.5.1
I have a desktop mill for testing, It is running Linuxcnc 2.4.
in Linuxcnc ver 2.5 & 2.5.1 the D in pid is not working.
It was ok in 2.4 but in 2.5 it is very flakey.
I found the problem in the source code.
component pid.c Line 353 needs to be like line 309 in ver 2.4
ver 2.4
line 309
/* calculate derivative term */
*(pid->error_d) = (tmp1 - pid->prev_error) * periodrecip;
pid->prev_error = tmp1;
/* apply derivative limits */
ver 2.5
line 353
/* and calculate derivative term as difference of derivatives */
*(pid->error_d) = *(pid->commandv) - *(pid->feedbackv);
pid->prev_error = tmp1;
/* apply derivative limits */
Please inform me as to the correct way to rectify this problem.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Wed, 27 Oct 2010 09:37:24 -0500 (09:37 -0500)
One problem frequently identified with pid is that the D term is
excessively noisy due to quantization (particularly of feedback position).
Introduce command-deriv and feedback-deriv pins. These can be connected
to some (hopefully superior) source of the derivative. For example, a
system with an analog tach signal in hal could use that value for
feedback-deriv. It also becomes easier to test different derivative
computation functions, such as explicit smoothing of the D term or
the five-point method mentioned on wikipedia
en.wikipedia.org/wiki/Numerical_differen...Higher_order_methods
Zero, one, or both of the -deriv pins may be connected. When a -deriv
pin is not connected, the related value input is computed by the
traditional two-point difference method. This means that when neither
pin is connected the behavior is the same as before (except for rounding
differences).
John
Please Log in or Create an account to join the conversation.
I seem to recall that Jepler did something a but cunning to work out if the pin was connected or not.When a -deriv pin is not connected, the related value input is computed by the traditional two-point difference method.
Perhaps that cleverness has been broken, or was never as clever as it looked?
Please Log in or Create an account to join the conversation.
- /* calculate derivative term */
- *(pid->error_d) = (tmp1 - pid->prev_error) * periodrecip;
+ /* compute command and feedback derivatives to dummysigs */
+ *(pid->commandvds) = (command - pid->prev_cmd) * periodrecip;
+ *(pid->feedbackvds) = (feedback - pid->prev_fb) * periodrecip;
+ /* and calculate derivative term as difference of derivatives */
+ *(pid->error_d) = *(pid->commandv) - *(pid->feedbackv);John
Please Log in or Create an account to join the conversation.
thread.gmane.org/gmane.linux.distributio...evel/3615/focus=3632
The derivative value calculated the old-fashioned way is written to a shared-memory address that he unconnected feedback-deriv pin was allocated when first created.
If that pin is netted to a signal in HAL then it will move to a different point in shared-memory. So the value will still be written to there, but not used.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
- Todd Zuercher
-
- Away
- Platinum Member
-
- Posts: 4965
- Thank you received: 1370
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.