Do you have plans to offer a carrier board for the A5984? Only one source I see on the web so far…
Thanks for the product suggestion! We do not currently have any plans for the A5984 stepper motor driver. It seems like the most exciting feature of the A5984 is the Adaptive Percent Fast Decay (APFD) current control. The Toshiba TB67Sx stepper motor drivers that we already have carriers for have a similar Advanced Dynamic Mixed Decay (ADMD) current control algorithm that dynamically switches between slow and fast decay modes by monitoring the state of current decay. Are there other specific features of the A5984 you are excited about?
I just saw the claims for much smoother and quieter operation… Glad to learn the Toshiba chips are similar!
I did an audio noise test of three drivers. Conclusion is not much difference between them. Write-up included:Noise measurements for Stepper drivers.pdf (824.0 KB)
In your test description you wrote that you were pulsing the step line at 1981 Hz in half-step mode. Why did you choose that frequency to test? In my (very) limited experience, this is much faster than anything I’ve built could support, almost 5 rotations per second (disregarding the gearbox and assuming 200 steps/rotation at the motor). Do you think it’s fast, and if so, how do you explain the performance you’re getting?
5 rotations per second (300 rpm) is well within the normal range of the motor I’m using. As you can see from their torque curve, the motor can operate from 100 rpm up to 800 rpm. The step frequency for this rpm range goes from 500 to 5000 Hz.(half stepping) In my application, a speed I need to run at is just under 3 rpm (at the gear reducer output) hence the odd 1981 Hz. Hope this answers your questions!
17HS19-1684S-PG100_Torque_Curve.pdf (179.2 KB)
It does, thank you. My motor’s vendor did not provide a torque curve, so I didn’t know to look for it. So is the max RPM mostly a function of the motor, and not the driver? I built my own stepper driver using an Arduino and dual H-bridge motor driver, completely ignoring the decay mode stuff, and I was wondering whether I was suffering for that lack of sophistication in some way I was not aware of.
Using an Arduino and a H bridge are good for dc motor speed control using PWM but a real compromise when trying to drive a stepper motor. You can do it but the computations required are quite a challenge for the arduino severely limiting the max rpm you can obtain. Using one of the stepper drivers from pololu takes a lot of the computation load off the arduino. I like the DRV8825 for example. Operating a stepper motor properly is not a trivial exercise but why reinvent the wheel? These drivers implement complex algorithms to develop the right signals to your stepper motor based on a simple step and direction signals from your arduino. The TIC products look quite nice too. You can get a feeling for the max rpm ranges for stepper motors by looking at the data sheets for the basic sizes on stepperonline. The max step frequency is going to be limited by the arduino. The topic of motion control is very interesting, here’s one of many articles on the topic: How to generate the motion profile for a linear system
So motor size is the main factor in determining max RPM (up to some variation between models)?
RE reinventing the wheel, this is all just for fun, so it’s worth it to me if I learn something. I started out with Allegro’s A3967, but it was annoying to have to translate RPM curves into delays between steps, e.g. try doing a cosine-shaped RPM curve. So for fun I tried using quadrature audio sines (essentially analog current drive)–at slow speeds it was dead quiet, and at high speeds the motor hummed at the frequency of the sine, i.e. the stepping frequency and its harmonics were gone. So you can see why your paper caught my eye. My current version approximates the analog version using a MKR1000, a 1.6kHz sample rate, a 256 point sine lookup table, and 32kHz PWM using the SAMD21 hardware. There seems to be enough CPU cycles left to manage WiFi comm, 4 motor controllers, 2 servos, an IMU, and an RFM69 packet radio transceiver. But yes, it’s expensive computationally.