On 02/26/2019 10:52 AM, andy pugh wrote:
On Tue, 26 Feb 2019 at 14:24, <[email protected]> wrote:
the driver works (with both devices). but is not ready and
not optimized.
at the moment, the raspberry can drive 5-6kHz with an unpatched
and 10-12kHz with a patched stepgen. (and I think, much more
is possible)
If the driver still uses stepgen then I think you are doing it wrong...
Look at how the Pico and Mesa drivers do stepgen and PWM, they read a
steps-so-far number from the FPGA card, do some calculations, and tell
the remote device how many steps to output in the next servo period.
stepgen.c isn't involved at all.
Yes, this is full-hardware step generation. You won't see
much in the driver, however.
All the magic is in the FPGA board. The driver is
src/hal/drivers/hal_ppmc.c and it supports two different
servo systems as well as the stepper board. The step output
function just computes a divisor and sends that to the
board, it counts out so many clock pulses and then issues a
step of the required pulse width. Because the clock on the
board is not linked to the clock of the CPU, it has to count
position so they can stay in sync. The trajectory planner
feeds position to the PID component, which feeds best-guess
velocity to the step generator. This is not actually #
steps for next servo period, it is just plain velocity, in
steps/second (or more accurately, number clock
pulses/step). Every servo period, the position count is
read, and a new velocity computed to keep position error to
a minimum. This also allows you to run steppers with
encoders. Instead of counting the steps issued, you count
encoder position. This is not a real servo, as with a
stepper drive you can't order the drive to "try harder".
But, it will constantly correct for individual lost steps.
It won't do anything for a real motor stall except detect it
and halt the machine.
Jon
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
