pncconf bug in PID connections

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.

Boy I dislike black magic code like that - ok I will fix that - thanks Peter

Chris M

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

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.

Ok thanks for explaining.

Chris M