muvideo post=260991 userid=29999
[...]
If I understand correctly TOLP implementation, the position pid part in his software is already embedded in the driver so his implementation hides most of this and your life is simplified.
I prefer to not rewrite a PID logic inside my driver, since we already have a very good PID in ours hal components.
IT is correct that I like to make things as easy as possible. However, your understanding of
pos2vel is not completely correct.
The
pos2vel component is not a PID implementation. The reason is like you stated, the feedback is predictable. The only part which is not predictable is the amount of counts between two succesive cycles. This is due to the FPGA not running exactly at 40 MHz and also due to the jitter of the thread. These things we can measure and correct for, whilst keeping in mind acceleration limits. The component makes sure that if the acceleration ends (and thus a constant speed is attained), this speed can be reached within one cycle. It is pure physics in the component, very similar to the driving part of LinuxCNC component
stepgen, but with added complexity to allow for the stepgen actually taking place on a FPGA.
Also,
pos2vel is not baked into the driver. This is because the driver should not contain magic (I agree with you on this one). It is very much possible to use a PID approach to LitexCNC if a user wants this. This also opens the road for full close-loop systems.
