pncconf bug in PID connections

16 Nov 2018 11:47 - 16 Nov 2018 11:54 #120829 by PCW
Both servo and stepper pncconf configurations connect a signal N-vel-cmd to pid.N.command-deriv
but the signal is undriven, This makes the FF1 term a no-op, causing new configurations to fail.

This bug was not detected earlier because of a bug in the PID component with the command-deriv pin
that was fixed recently. (the logic to detect if the pin was detected was broken)

The best general fix is to just not create the net N-vel-cmd => pid.M.command-deriv statements at all.
Last edit: 16 Nov 2018 11:54 by PCW.
17 Nov 2018 05:09 #120888 by cmorley
Boy I dislike black magic code like that - ok I will fix that - thanks Peter

Chris M
17 Nov 2018 05:13 #120889 by cmorley
It looks like it was connected if using a stepper system.
It was connected to : joint.N.vel-cmd

Is that not right?

Chris M
17 Nov 2018 10:50 - 17 Nov 2018 10:51 #120891 by PCW
Replied by PCW on topic pncconf bug in PID connections
In my experience it works better when not connected (and the PID comp calculates the derivative)

The bad thing is that I suggested the PID fix (so the PID component matched its manual page description) :-(

The PID bug was that its local value of command derivative (calculated via d/dt from command) was supposed to be overridden if the PIDs command derivative pin was connected, this did not work (it ignored the command-deriv pin) and was fixed, exposing the unconnected signal bug.

Why exactly the internal command derivative works better than using the external commanded velocity is something I do not understand, but is likely a sample period delay issue somewhere. So currently best to leave the pin unconnected for both servo and stepper systems.
Last edit: 17 Nov 2018 10:51 by PCW.
The following user(s) said Thank You: tommylight
17 Nov 2018 19:20 #120917 by cmorley
Ok thanks for explaining.

Chris M
Moderators: cmorley
Time to create page: 0.072 seconds
Powered by Kunena Forum