Exactly control stepper motor with high Pulses per seconds

[Christian Bodenstein]

Hi,

Im looking for a solution to control a stepper motor as exactly as possible. I already have a circuit  which allows me to send one pulse to rotate the motor by one step.

Now want to reach a pulse rate of 3000 pulses per sec (3KHz). PWM seems to be a nice feature but i can not exactly count how many pulses was send after time.

E.g. if I want to send 3000 pps over 1 sec I can not exactly know was there 2990 or 3010 pulses.

Thread.sleep() will not work in microseconds so i also cant use a normal digital output..

Have anyone a good solution for this Problem?

[kolbe]

Ytai may correct me on this but I don't think at the moment there is a way to do exactly what you ask, x pulses at exactly 3000Hz. The best you can do is use a timer to more or less give you x pulses at whatever PWM frequency you choose. Just set the duty cycle to zero when you don't want any pulses. Conversely you can do x pluses at more or less 3000Hz. He has talked about implementing at some point, some kind of scripting to allow the IOIO to do work independently and I imagine would let you do what you ask. I'm hoping too this will come soon. You can always customize the firmware, if you are up to the task.

[Ranganathan Sridharan]

If all you want to do is monitor how many you sent and send correction less frequently based on what you measured I would say use the PWM and connect that pin to another input capture pin to count pulses.

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/4qJY1XrrMlUJ.
To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.

[Ytai Ben-Tsvi]

Hi all,

I have an application using stepper motors with IOIO, and for that purpose I added a little enhancement to the PWMOutput API that allows controlling the frequency. It works great, but it is missing the feature you're requesting which is counting the pulses. So it basically lets you precisely control the speed, but not the position.

I'm planning on adding position control too at some point, an API that will let you say "go X steps at Y steps per second", possibly syncing more than one stepper. You'd be able to enqueue several such commands, and then query the current steps traveled and which command is currently being executed.

For the time being, there's no easy way around this.

InputCapture will not currently let you count pulses, but only measure their width and frequency. This is again something I'm planning of addressing,  in the form or an encoder API, which would also support quadrature encoders.

Stay tuned...

[kolbe]

Thanks Ytai, can't wait.

On Saturday, May 12, 2012 2:35:10 AM UTC+2, Ytai wrote:

Hi all,

I have an application using stepper motors with IOIO, and for that purpose I added a little enhancement to the PWMOutput API that allows controlling the frequency. It works great, but it is missing the feature you're requesting which is counting the pulses. So it basically lets you precisely control the speed, but not the position.

I'm planning on adding position control too at some point, an API that will let you say "go X steps at Y steps per second", possibly syncing more than one stepper. You'd be able to enqueue several such commands, and then query the current steps traveled and which command is currently being executed.

For the time being, there's no easy way around this.

InputCapture will not currently let you count pulses, but only measure their width and frequency. This is again something I'm planning of addressing,  in the form or an encoder API, which would also support quadrature encoders.

Stay tuned...

On Fri, May 11, 2012 at 12:47 PM, Ranganathan Sridharan  wrote:

If all you want to do is monitor how many you sent and send correction less frequently based on what you measured I would say use the PWM and connect that pin to another input capture pin to count pulses.

[olli pyynönen]

The adding position control would be very useful feature for stepping motor controlling! 

Pls. Let me know if/when added. More than one stepper sync would be fantastic!

Olli

2012/5/12 Ytai Ben-Tsvi <yta...@gmail.com>

--
Olli Pyynönen
olli.p...@gmail.com

[Chris Stratton]

On May 11, 6:03 am, Christian Bodenstein

<crossfire124...@googlemail.com> wrote:
> Im looking for a solution to control a stepper motor as exactly as
> possible. I already have a circuit  which allows me to send one pulse to
> rotate the motor by one step.
> Now want to reach a pulse rate of 3000 pulses per sec (3KHz).

When you do high pulse rates, you can't just start hitting the motor
with full rate pulses, but must instead ramp it up at a rate which
doesn't exceed the available torque (which falls with step rate
anyway), and then ramp it down again as you near your desired end
position.

You'd likely be better off with a system where you had the high level
device (ie, Android side) setting a signed "desired count position"
register (quite possibly 64 bit). Then you have something running on
the ioio embedded side which looks at a "current count position
register" and a "current count rate" register and adjusts the rate by
gradual amounts to close the error between the two position
registers. The rate register then governs the pulse generation, which
of course increments/decrements the current count position as each
pulse is generated. (You can also make a true closed loop system if
you count an encoder input rather than the generated pulses)

[Ytai Ben-Tsvi]

Agree with Chris.

Such control loops are probably better closed on the IOIO side. With steppers, however, you can often safely run in open-loop, so the control problem becomes a lot simpler.

Take a look at my post to this thread dated May 11 for a description of how I envision the API. I believe it will address your needs and more. The implementation then can easily incorporate, say, a PWM-controlled motor with encoder under the exact same API ("go this much, this fast").

Makes sense?

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.

[antiplex]

ytai,

these thoughts sound great to me, in the response of yours you are referring to you state
'I'm planning on adding position control too at some point, an API that will let you say "go X steps at Y steps per second", possibly syncing more than one stepper. You'd be able to enqueue several such commands, and then query the current steps traveled and which command is currently being executed.'

such would be a very comfortable interface to suit many needs regarding stepper control (and the ability of ramping up/down the frequency sounds even better).
i looked around and came across this tutorial about easydriver for stepper motors with arduino http://bildr.org/2011/06/easydriver/
the code presented there does not use pwm pulses but switches digital signals over the step control line which is what i suppose christian means by 'I already have a circuit  which allows me to send one pulse to rotate the motor by one step'.
i now wonder which pulse-rate would be doable this way in combination with ioio and if the time resolution and latency would be exact enough to provide a relatively steady movement.
of course a proper and supposedly way more powerful solution would be through precisely controllable pwm-signals but until such is available i wonder if it would be feasable to start of into this direction?

as asked earlier, has this pwm api-extension already appeared on the ioio wishlist or should it be added for a better overview?

ytai, could you elaborate on what you mean with open-loop and why it makes the problem simpler?

regards,
anti

[Ytai Ben-Tsvi]

On Thu, Jun 14, 2012 at 2:47 PM, antiplex <anti...@coma.cc> wrote:

ytai,

these thoughts sound great to me, in the response of yours you are referring to you state
'I'm planning on adding position control too at some point, an API that will let you say "go X steps at Y steps per second", possibly syncing more than one stepper. You'd be able to enqueue several such commands, and then query the current steps traveled and which command is currently being executed.'

such would be a very comfortable interface to suit many needs regarding stepper control (and the ability of ramping up/down the frequency sounds even better).

Ramping would be achieved by queuing a sequence of motions with increasing / decreasing frequency.

 

i looked around and came across this tutorial about easydriver for stepper motors with arduino http://bildr.org/2011/06/easydriver/
the code presented there does not use pwm pulses but switches digital signals over the step control line which is what i suppose christian means by 'I already have a circuit  which allows me to send one pulse to rotate the motor by one step'.

To be precise: PWM is not what's being used here. The pulse width makes no difference to the stepper driver, but rather the frequency. The module in the PIC that used in both cases is called "output compare", and it allows controlling both frequency and pulse width. For that reason, it was easy to piggy-back a setFrequency() on the Pwm interface, although it is not really PWM per se. The code (just setFrequency, not the fancy API discussed above) is currently available on the pwm-improvements branch, and will be included in the next release.

 

i now wonder which pulse-rate would be doable this way in combination with ioio and if the time resolution and latency would be exact enough to provide a relatively steady movement.

If you mean using a DigitalOutput to control a stepper, the answer is probably no, unless you're interested in relatively low speeds. However, ultimately the intention is to provide this functionality without burdening the Android CPU or the IOIO CPU or the connection or the developer :) and also not to be at all sensitive to throughput, latency and jitter of the connection.

 

of course a proper and supposedly way more powerful solution would be through precisely controllable pwm-signals but until such is available i wonder if it would be feasable to start of into this direction?

Give it a try and see if you're satisfied with the results. It all depends a lot on what you're trying to do. I wouldn't use it to control a CNC mill probably :D

 

as asked earlier, has this pwm api-extension already appeared on the ioio wishlist or should it be added for a better overview?

I think there's a bug on that but even if not, it is on my personal wish-list, so will probably be done relatively soon after the IOIO V2 dust settles.

 

ytai, could you elaborate on what you mean with open-loop and why it makes the problem simpler?

When wanting to control a motor to a specific position, one might use a DC motor and an encoder, and make corrections to the motor speed until the desired position is reached. This is called a closed-loop system, since we're sending a motor command, then using position feedback from the encoder, measuring the error, sending another command to fix, etc. Our command affects the position and the position affects our command, hence the "loop"  (BTW, this specific type of closed-loop system is called a servo).

When using a stepper, under normal circumstances you can know it's exact position (relative to some starting point) without measuring it, since it is exactly the number of steps you commanded it to go. So normally to set it to a certain position you'll just need to send the right number of steps, and then you can safely assume that it's there without the feedback. Hence the "open-loop" terminology, and you can probably now see why it is simpler to implement.

regards,
anti

On Thursday, June 14, 2012 6:41:16 AM UTC+2, Ytai wrote:

Agree with Chris.

Such control loops are probably better closed on the IOIO side. With steppers, however, you can often safely run in open-loop, so the control problem becomes a lot simpler.

Take a look at my post to this thread dated May 11 for a description of how I envision the API. I believe it will address your needs and more. The implementation then can easily incorporate, say, a PWM-controlled motor with encoder under the exact same API ("go this much, this fast").

Makes sense?

--

You received this message because you are subscribed to the Google Groups "ioio-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/I_LulxlUhUIJ.

[Gilad Meller]

Following the issue of this thread - can someone publish example controlling a stepper with IOIO ?
I have a Pololu stepper driver and all i need to output is direction and pulse.

[Ytai Ben-Tsvi]

If you need speed control only, see here:

https://github.com/ytai/ioio/blob/pwm-improvements/software/applications/ShoeBot/src/ioio/applications/shoebot/ShoebotActivity.java

Note that this is on a non-standard branch, which has a slightly modified firmware, that's unfortunately hasn't yet been ported to support IOIO-OTG.

If you need position control, you'll have to wait until I release the motor control library (the one I've used for the plotter). Unfortunately, for the past couple of months I was too busy with my primary life, so couldn't give the IOIO too much attention.

--

You received this message because you are subscribed to the Google Groups "ioio-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ioio-users+...@googlegroups.com.

To post to this group, send email to ioio-...@googlegroups.com.

Visit this group at http://groups.google.com/group/ioio-users.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Gilad Meller]

What is the big gap in the motor control ? is it simultaneous control of two motors ?
I am quite sure that the IOIO can output digital pulses "ones" to the driver (direction and step), so what do I miss ? encoder integration ??

[Ytai Ben-Tsvi]

If you try bit-banging the stepper drivers, you'll get very inconsistent timing and a very slow rate compared to what you can get with the motor control library. You'll also be placing a lot of burden on the Android CPU, the USB connection and the IOIO MCU.