59 posts / 0 new

## Pages

Author
Message

I was wondering if anyone had any experience with half-stepping a bipolar stepper motor using the l297/l298 drivers. In SGS-Thomson's AN1679, figure 18 gives a proposed hardware solution for boosting the motor current during times when it is in a half-step position. This is accomplished by multiplying your normally set current by the squareroot of 2, and should theoretically boost your torque to near-full-step levels.

So, I ordered a nand gate to try this technique out, as per figure 18. Unfortunately, SGS failed to mention that while the inhibit lines do indeed drop to ground when the motor is in a half-step position, when it is not, the lines are bouncing all over place between 5V and ground. This caused the logic gate to be very unhappy.

I next tried to accomplish this in software using a check for an odd step number during the motor commutation interrupt. This has placed a lot of load on my TWI bus, however, which is used to control a DAC which supplies the reference voltage to the l297. The motor will function, but only up to about 450rpm, at which point I believe the bus communication throws an error.

Does anybody have any clever ideas for handling this torque boost? Basically, I need to be able to detect when a line drops to ground in hardware, or come up with a clever way of handling current boosts every other step in software (which seems unlikely given that the interrupt frequency increases as motor speed increases)

A quick look on the datasheet gives me this idea:
Set CONTROL low (so pwm/chopping happens on INH1/INH2)
Use XOR gates betw. A-B and C-D.
Use an AND gate on the XORs output. F = (A XOR B) AND (C XOR D)
The output of the AND gate should tell you when both coils are active (when you like to adjust by 1/sqrt(2)).

Havent tested it so not shure it will work.
Couldn't find the AN1679 btw.

That seems backwards to me. If you have x torque when coil A or coil B is on by itself, those positions are on step boundaries... half step is when both coils are on and magnet is half way between two poles... two coils on, twice the torque in the half step position.. You could reduce it by .707 to make it the same as the one coil on condition....

Imagecraft compiler user

http://www.st.com/stonline/books/ascii/docs/1679.htm is the application note I speak of.

From this application note: "The torque loss in the half-step position may be compensated for by increasing the winding current by the factor sqrt(2) in the phase winding that remains active."

According to this, at least, half-steps occur when only one coil is charged. A link from wikipedia's stepper motor page seems to verify this, but I could be wrong. In full stepping, both coils are active all the time, so logically, it would make sense that 1 active coil would be a half step.

In any case, bob you are correct, that is another valid way of even-ing out the torque curve, either way the max current for torque purposes will be 1.41 Amps with a single l298 h-bridge. Essentially it's the same solution, just approached from a different angle.

Bill: That sounds like a viable alternative, I may try that out. Its a bit heavy on the logic gates, and our board space is very limited, but it may come down to this. It just seems like I should be able to use those inhibit lines since they are following the behavior of an XOR gate, except they put out a square wave at high rather than a constant 5V.

I'm currently seeing if an active lowpass filter will give me a clean signal that I can try to pass to the logic gate.

Ended up using a passive LPF to clean up the signal some, and then passing it to an op-amp set up as a comparator before going to the nand gate. Quite a bit of external circuitry, but it should do the trick.

Quote:

Quite a bit of external circuitry,

Have you considered other drivers besides a 297/298 combination? We've used Allegro with success in the past. We used A3966 with success, but you'd have to switch-in low-ohm current limit resistors to do your task.

But look over the whole Allegro line. For example the A6219 http://www.allegromicro.com/sf/6... has digital inputs to select 0/33/66/100% current. Wouldn't selecting 66% at the even positions and 100% at the odd positions give you almost exactly what you want? Now you are down to a near single-chip solution (pluse the discretes).

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Yep, that would work VERY nicely. I had read a website that suggested driving the coils at 100% and 40% in the half-step position to maximize torque, so your suggestion falls right in line with that. I will take a look at the allegro chips you've suggested, we're very open to switching the motor drive chips as we've had a lot of problems with the 297/298 combo, especially with the 298. Thanks.

I usally don't use HW drivers at all, let the AVR have full controll of the MOS-brigdes.

Just made some rough code for mega48 using PWM to controll current in the windings. Getting the same torque when only one or both windings are powered is just adjusting numbers in a table.
(To add microstepping I just need to increase the size of the table :)

If this is a way to go, contact me and I'll see if I can clean up some code (It's based on appnote AVR446: Linear speed control of stepper motor)

Our largest motor is rated for 1.85A, although I think being able to drive 1.5A is acceptable, as it would still be just as good as our current drive method. We're using a 40V power supply. The 3974 looks like it'd meet those requirements, but unfortunately it looks like the 6219 is the only one with those nice variable current selector pins.

Bill: microstepping is overkill for what we need, I think the 297/298 was originally chosen to minimize the amount of work that the uC needed to do in order to spin the motor. Some applications of this device are going to be spinning at 1000rpms and up. Maybe the uC could handle it, but I'm a little skeptical. What kind of speeds have you been able to achieve, and what freq was your uC running at?

Hey Zalfrin... do you have an R in series with the coil from 40V? This is supposed to hit the coil with 40v, but then hold at whatever v remains after the IR drop across the R

Imagecraft compiler user

Hmmm--hats off to you and yours that are "good at" high-speed stepper work at full power. My novice work turned out OK, but my method of tuning was to see what speed things started to break down/shuuder/shake, and then don't go that fast anymore. From what I know one of the tricky parts will be accel/decel ramps.

Lessee--1000 rpm is 8000 half-steps/minute, or 7.5ms/step. Since the actual stepping "engine" through the half-step table is only a few us, that leaves loads of time for accel/decel adjustments and the rest of the app.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

bob: I'm not sure what you mean. We have 8 protection diodes in place on the 4 lines, but no series resistors. The 297/298 does use sense resistors and a chopper mechanism to limit motor current to the level set by your choice of vrefs and sense resistors. Can you explain what you mean?

Does anybody have any other suggestions for good h-bridges? My requirements are listed above, but I'll give them again in case you don't want to read that far.

Half-stepping bipolar stepper motor
largest motor is 1.85 Amps
Would like at least 1.5Amps coming from h-bridge, preferably 2.0 or even 3.0
supply voltage is 40V
minimal external components required

What are your requirements regarding footprint, power dissipation, and cost?

Si9978 with two littlefoot(R) transistors is a full-bridge (need 2). Bottom line is it's a smaller footprint, costs three times as much, and dissipates almost no power. The parts suggested in Vishay app note AN406 handle 4A, and the cost of a bridge is about \$8.50 in singles.

Since the Si9978 only rated at 40V, there's no margin if your supply is actually 40.

Quote:
What kind of speeds have you been able to achieve, and what freq was your uC running at?

The limit has been the stepper motor, its torque drops at around 190rpm so this has been the maximum speed. It is a 400(half)steps/round motor so 76000steps/min works well with a m48 running on 3,68MHz

Doing the current limiting with a PWM, and PWM not being in sync with steps, consider 'setting' a given number of PWM pulses as minimum step period (eg you want min 10 PWM pulses in one step, so current max can be 10% off)
Example:
8 bit PWM, running on 3,68MHz (->PWM freq 14,375kHz)
10 PWM pulses / step -> max 1437 step / sec
A stepper with 400 (half)step/round you get a max rpm of 215

But 8 bit pwm might be overkill (4-5 bits should maybe do)
5 PWM pulses / step might do (max 20% error in current)

well, you do the math for your stepper...

Text book circuits will not (reliably) work at the speed and torque you require. There are quite bit of parameters like coil inductance, motor design, etc., play a role in this. Commercial design are not as simple as two chip solutions. They are circuitry wise very much involved. So analyse your design shortcomings and you might need multiple solutions to overcome the different aspects of it.

As mentioned always, please post your design / implementation, what is expected of it and what is actually available. It will enable the members to give proper solutions.

BTW, out of curiosity, what kind of application is that requires such a speed with half step accuracy?

Last Edited: Fri. Jul 7, 2006 - 01:19 PM

Attached is a schematic of our current motor control system. We use a TWI DAC to generate the voltage reference for the 297/298, which sets the current in the motor windings. The bottom half is new logic which should smooth out the torque curve by pushing equivalent levels of current in both half-step and full-step motor positions.

I'll elaborate a bit on the operating conditions. The boards will be used in several different products, with applications ranging from overhead stirring/mixing of liquids to centrifuge-like spinning of a plate with some loading. The design must be bidirectional, and able to move to a set rotational angle before reversing direction and travelling the same distance in the opposite direction once returned to the original position. This mode of operation will only be used up to around 200rpms, with the higher speed requirements being for the overhead stirrer. An optical sensor is used to simplify ramp-down and allow returning to a home position.

Currently, we can set a ramping current level, equal to the motor's current rating, and a holding current level which is used once the motor is up to speed. Timer interrupts are used to generate the clock signal for the 297. On a smaller 0.85A motor in an older prototype, the circuit works great up to around 800rpm and will even go a bit higher if I ask it to go faster once its running at 800. It doesn't like to ramp past here automatically, however.

Last Edited: Fri. Jul 7, 2006 - 08:43 PM

Is your circuit connections are correct? I feel one end of R23 should goto the output of DAC and the junction of R23 - R24 to the Vref. You should use AND gate to switch, not NAND gate for the current boosting logic to work. Probably the INH1/INH2 lines are jumping because of CONTROL line set low to act on INH1/INH2. Are you using L297 or L297A?

What are the specs of the motor used? Is this some kind of laboratory shaker / stirrer application?

simma: you are correct, I made an error in interpreting the App Note. The lower portion from 1k resistor on should be tagged off the Vref pin on the l297. And yes, the chopper is acting off the inhibit lines, from what I understand this is the prefered mode of operation. The l297 is an L297D. We are using several different motors for testing. The smallest is a 0.95A guy made by Lin Engineering, model # 4118S-22. Its a custom winding, so I can't really say much more about it without calling Lin. The next motor is a 4118M-01 rated for 1.7A, it can be found here: http://www.linengineering.com/site/products/pdf/4118.pdf. We also have a prototype with the 1.3A 4118S-02 on that same sheet. Your guess as to the application is right on.

Quote:

Lessee--1000 rpm is 8000 half-steps/minute, or 7.5ms/step. Since the actual stepping "engine" through the half-step table is only a few us, that leaves loads of time for accel/decel adjustments and the rest of the app.

Given the link to the Lin motor, I was wrong--maybe dead wrong. The link is to a 1.8 degree motor, or 400 half-steps per revolution. I assumed a coarse 45 degree motor.

Let's run the arithmetic again. 1000 rpm is 16.7 rps; 6666 half-steps/second; 150 us/step. Still doable but much much tighter. Note from the linked datasheet that the torque has dropped considerably at those rates.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Here's an updated schematic. Added some weak pull-ups on the comparator output and fixed the problems raised by simma. The circuit seems to be doing its job as I can see the voltage ref changing on a scope. I need to work on our rotation algorithm now, the motor just can't keep up with the microcontroller as its written now. Ramping without direction switching works great.

## Attachment(s):

If I understand this correctly, for a 1.7A rated motor w/ 0.5ohm sense resistors, I should tell my DAC to generate 0.85*1.41 = 1.2V. Does that sound right? If I am thinking properly, that would give 1.68A being delivered to the motor (peak) during a full-step, and 2.4A being delivered during a half-step.

edit: Are motors rated at peak or continuous current levels, generally? It's not really worth it to push too close to the limit, but I'm curious nonetheless.

Zalfrin wrote:
....And yes, the chopper is acting off the inhibit lines, from what I understand this is the prefered mode of operation.

For the method you are using, I feel chopper acting on the ABCD lines will be better. I may be wrong. Please, probe and post the trace pictures.

Zalfrin wrote:
....I need to work on our rotation algorithm now, the motor just can't keep up with the microcontroller as its written now. Ramping without direction switching works great.

Could you please elaborate further and explain your algorithm? Is every rotation reversed?

If I can locate a scope that has some means of capturing an image, I will post some images today. Which lines did you want probed, SENS1/2?

On the software side, we are using Timer0 to generate an interrupt at a frequency of 244Hz. This interrupt checks the current motor speed in relation to the set motor speed, and adjusts the compare value of Timer1 accordingly. Timer1 generates an interrupt on compare match with the value being supplied by the Timer0 interrupt. Inside this ISR, the clock signal to the l297 gets generated; if back-and-forth rotation is desired, this routine handles updating ramp rates and checking if the direction needs to be switched. This is an inherited project, and frankly I'm surprised it works as well as it does. When the motor is first started, the number of pulses necessary to move the motor shaft to the desired angle is calculated. At half that many pulses, the motor begins to ramp down to the original starting speed. Once all the pulses have occured, the motor switches direction.

What sort of ramping profile would be likely to work with this direction switching? Ramp up to speed, hold for a moment, ramp down to (low) starting speed, hold, switch directions, etc?

Its hard to be very clear with this, here's an example. If I choose 180 degree rotation at 100 rpm with a starting speed of 10 rpms, the motor will start off at 10 rpms and then ramp to 100rpms, achieving it at around 90 degrees. It then ramps back down to 10 rpms, reaching that speed at the 180 degree mark. It then switches direction, and rotates 180 degrees in the opposite direction with the same ramping profile.

Yes, probe SENS1/2. Use chopper/pwm on ABCD.

Why do you speed ramp? is it for torque or to avoid spillage or anything else?

As you have inherited the design and if works desirably, why don't you trace up the profile?

Anyway, what is your desired goal, rotational angle or speed or others? if you say speed, how do you quantify? For example, saying 100 rpm will not reflect the true speed, because of the ramping.

What kind of mechanical linkage is implemented between the platform and the motor? What kind of materials are used - liquids, solids, etc.,?

I'll bring in my digital camera tomorrow and take some pictures, apparently there are no scopes in the building with a floppy or serial interface. The speed ramp is in place for both of those reasons, primarily because we don't know what kind of load will be on the motor. As I said, the board will have a few possible operating expectations. On one extreme, the motor shaft will have a plate attached to it with compartments for samples to be spun back and forth. On the other, the motor shaft will be attached to a propellor of sorts which will be used to mix liquids of varying viscosity. So primarily, the ramping is an attempt to minimize the possibility of a motor stall, but will also be useful for, say, keeping a sample from flying out of its container.

The user will supply a desired speed and rotational angle. The motor will ramp to that speed and reverse direction upon reaching the proper angle. The actual details for switching directions are open for interpretation, the only requirement is that the motion be consistent. The actual ramping up and down in a single direction works as I would expect and has a desirable smoothness of operation. The problem occurs when the direction switch occurs, at which point the motor starts missing steps. What other precautions can I make beyond ensuring that the direction switch occurs at a low shaft speed?

I'm not sure about the mechanical details, there are threaded holes drilled in the motor shaft which have allen-type bolts being used to connect to the plate for the one prototype; the overhead stirrer uses similar bolts to mount a drill head which can clamp on to a propellor-type shaft. Overhead stirrer will have to deal with liquid viscosity, other will have loaded plate of unknown contents, likely a liquid with container. Motor is mounted to the casing with screws and a metal plate bracing the bottom of the motor to distribute the load.

I'm not sure what you mean by trace up the profile. When all that is desired is to ramp up to a high speed, the design performs very well, my problem lies in the direction switching. I can use the same function for direction switch ramp rate generation as for non-direction switch ramp rate generation.

I was always confused over two meanings of the word 'ramp' One meaning is just a trapezoidal graph of speed and time.... it speeds up, runs, slows down. The max speed can be up to xx steps/sec before the motor starts to resonate and get lost. The other use of the word 'ramp' means "I can take steps every 4000usec no prob, so I am going to take a step, take next step 3500us later, next step 2000us later, next step 1500us later, next step 1000us later, now I am running along 4x faster than I was before by ramping up over a period of 4 steps" Is the 1st or 2nd way what you mean by 'ramping'?

Imagecraft compiler user

Since you have inherited the design and have a working prototype, let us stick with it, atleast for time being.

I would like to clarify the following

1. What is lacking in the inherited design, that causes you to design or modify it?
2. What do you mean by "missing steps"? what is its impact on your appication?
3. How much of modifications / changes you can accept? Is it OK to redesign if it is neccessary?

I have my reservations on your design and specs, considering the intended final usage. But I may be out of sync in understanding your customer requirements. Please do understand that I am not taking about the quality of the design. I have my respects for you. In my experience (over 20 years) I realised we engineers in our quest for producing good design, tend to overdo and end up negatively. Please remember perfection is a illusion.

bob: I'm using strictly in a speed vs. time sense, not specific to the step timing.

In modifying the hardware of the design, my aim was simply to make sure we were maximizing the torque available to us while half-stepping. It was primarily an attempt to overcome the misstepping during back-and-forth rotation. With the small 0.95A motor with no load on the motor shaft, direction switching goes off without a hitch. On our larger 1.7A model with a metal plate attached to the motor shaft, direction switching fails. Up to about 50rpms max speed the rotation occurs as expected, albeit a little jerkily. Beyond that speed, it begins to overshoot the direction switching position. Sometimes it will miss the first direction switch and go well beyond the point it should have reversed direction at, sometimes it will miss the 2nd direction switch as it overshoots the original home position. Is it simply a matter of giving the motor more time to slow down before doing a direction switch?

I'm willing to look at any options, if theres a different IC that will make my life easier, I'm perfectly willing to give it a try. Also, I've got those pictures of the sense lines, I'll post them when I get home tonight. I appreciate all your help.

edit: To clarify further, with back-and-forth rotation, our ultimate goal is to have consistent motion with the motor switching directions at the same two points each time. We need to ensure that the motor isn't spinning past this angle due to momentum.

So the stepper motor has to speed up the plate from zero deg/sec, then slow it down and settle at the new step position ON EVERY STEP. So hi speed stop motion movies would show the position changing in little stairsteps. So you should be able to step along at 4ms per step and just change direction, because every step is a new move from zero. If it cogs a couple of steps, you dont have enough oomph for that load. Need more juice! That other explanation of ramping works, but you need to know the load so you can calc the f=ma and get the timing exectly right!

Imagecraft compiler user

Quote:

So the stepper motor has to speed up the plate from zero deg/sec, then slow it down and settle at the new step position ON EVERY STEP. So hi speed stop motion movies would show the position changing in little stairsteps.

Well, not ideally Bob. I'm just a crude stepper person, seat-of-the-pants as I mentioned earlier--if going too fast causes chatter then lower the max rate if the app can handle it.

Anyway, at speed the ON EVERY STEP is the >>last<< thing you want--at speed you want to have the stop action film be as near to continuous motion as practical. Using the steppers has the desireable characteristic that no additional position feedback is needed, counting steps is sufficient--IF--you never lose one.

--You can't accellerate right to speed especially under load. (On, say, a DC fan motor you just hit it with the desired V for the speed desired and let it accellerate on its own. On the stepper you can't hit it with pulses at the full rate right away--it won't come near finishing the current pulse and may even try to go backwards at the next.)
--You can't stop from speed to 0 "right now" especially under load. You'd end up coasting a few clicks and lose position and the next step probably won't be what you intend.

Thus you ramp up & ramp down. You can seat-of-the-pants do it like I do; use a stepper driver subsystem that has the smarts; or use your own smarts with current levels and profiles and algorithms and such as OP is trying to do.

Usually some kind of positive stop or other reference device is needed to establish and re-establish the current position. For example, power drops and is then restored--you have no idea of the app position.

For a stirring/agitator app as OP described, one method might be to have two "stops" on the stirrer shaft; Hall sensors or equivalent. These could both be used to reference the device, and also if back-and-forth agitation is a normal operation then one could not worry about the steps and stopping--drive to the stop in one direction, ramp down, reverse, ramp up, and drive to the stop in the other direction. then re-reference when the cycle ends. The same could be done with uni-directional stirring--when the stirring ends re-reference at a slow speed to the stop. Kind of a combination "normal" motor and a stepper.

Steppers are fun, tho, when you get your ramps tuned and can make it sing at a nice clip with smooth starting and stopping, right on the dime.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

As written the torque of the stepper vs the momentum of the load decides how fast you can accelrate/decelrate.
You need to keep your acceleration/deceleration constant. Who can be a bit tricky.

Maths for this are a bit complicated, but by doing some simplifications (Taylor series approx) you end up with somthing your uC is able to handle.
'AVR446: Linear speed control of stepper motor' is one example of how to do this. Shouldnt be much work to change the code to work with your HW stepper driver.

Thats why I asked what the definition of the word 'ramp' was to him. You seem to be describing the technique of accelerating thru the resonance region to run like a synchronous ac motor at several times the single step rate. Are we on the same wavelength? If you stay below resonance, a step is a step. You can take em from dc to max, and everything stops and settles after every step. Load speeds up and stops every step.

Imagecraft compiler user

Quote:

Load speeds up and stops every step.

Not really, at least not on my apps. The AVR "knows" that it is going from step 2 to step 3 to step 4 (say) and at speed the load merrily keeps marching in that direction getting a nudge every step. Yes, the cogging is noticeable at very low step rates but at the "sweet spot" speed I cannot hear it or see it with my eye. Get much above that sweet spot and everything goes to heck.

Here is the analogy: Herding a tired child through the airport. Without constant nudging each step, the speed becomes noticeably slower between nudges. ;)

I thought of some old farm boy analogies as well, but maybe a wheelchair would be the best--discrete nudges (imagine that only 4 or 8 handholds are available) and the trick is to get a "rythm" where the wheelchair is propelled smoothly.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Unfortunately, load conditions aren't really known. The fact that the same board is being used in several different end products complicates things, so we're trying to leave enough options in the user interface to allow the user to adjust parameters based on the anticipated load. Currently, these parameters amount to a starting/stopping motor speed, ramp rate (in rpm/sec), ramping current level, a lower holding current level (never used in direction-switching mode), and 15 degree increments for choosing how far the motor turns before reversing direction. Currently we have some math adjusting our speed increments so that going from 10 to 20 rpms takes longer than going from 20 to 30 rpms. At 10rpms and 90 degrees rotation (100 steps), the next interrupt will increment the speed by 3/100 of an rpm. At 50rpms and 90 degrees rotation, the next interrupt increments motor speed by 7/10 of an rpm. At 100rpms, 90 degrees rotation the next increment is by 2.7 rpms. These numbers only apply in the direction-switching mode, and only at 90 degrees rotation. For 180 degree rotation, the increments will be one half of the numbers above.

What you are saying makes sense, however the motor is able to handle the load since it will happily run at 1000rpms as long as you don't want direction switching. The problem arises when you command the motor to move forward 90 degrees then back 90 degrees repeatedly. Perhaps just adding a little delay after reaching the half-way mark (full speed) and a little after reaching the original location (almost 0 speed) will allow the motor to stop oscillating before I send the next step command. When the direction switch occurs, the motor is moving at 10rpm = .17 rps = 68 steps/ sec which means a step is occuring every 15ms.

Good info. I bet if you put an accelerometer on the thing, you would see it accelerating for 5ms, decelerating for 5ms and bouncing back and forth on the magnetic field settling for 5ms. If you give it more torque, you should be able to go faster.

Imagecraft compiler user

I can push the current levels a little more I think, but not much. As it stands, with two coils energised, my motor is pulling 1.2A peak. With one coil, it pulls 1.7A. I THINK I can bump that up so two coils pull the max rated amperage of 1.7A, but I'm worried that the l298 won't be able to handle supplying 2.4A during the single-coil active steps.

edit: Bob, you might be right. I dropped the one coil active current back to 1A and ran at 50rpms. The problem resurfaced, whereas with the higher current level, 50rpms had no problem.

You should win a Nobel Prize. If you could patent that deal where you turn on two of something and use less current, I have a couple of airconditioners I'd like for you to hook up for me.....

Imagecraft compiler user

That is what is happening, bob.... The motor is rated for both coils being active, when only a single coil is active you can supply 1.41 times more current. There is no magic energy appearing from the ether, check the schematic at the top of this page.

Just tried upping the current to max out the motor. The L298 handles it just fine. Direction-switching at 100rpms now occurs correctly 9 times out of 10, but it still loses its position occasionally.

Attached are pictures of the sense lines for both chopper acting off inhibit and acting off coils.

## Attachment(s):

Some basics first (correct me if I am wrong). Let us assume a 1.8 degree/step motor. The AB and CD are in fact series of coils placed alternatively inside the motor. In full step mode, only one set of coil is energised. The magnetic rotor alligns with the pole created by the energised coil. When the next set of coil is energised, the rotor alligns to the new pole created. This allignment phenomena causes the rotor to move, ie., from old to new. That is the reason the stepper motors are run using a pattern of energising the coils.

Now, in half step mode, two sets of coils are energised. Therefore, the magnetic force acting on the rotor is vector sum of magnetic force created by the two coils. Hence the rotor alligns in between these poles. This results in half the distance to move compared to full step. This is reason for the reduction in the torque in half step mode. In order for the half step to work perfectly, the magnetic force produced by the two coils should be identical. Otherwise it will result in positional inaccuracy, unstable and poor torque, missing steps, etc. This was the reason I said earlier that the design is much more involved. I will post some pictures of a stripped stepper motor later.

1. Is the rotational angle (my understanding is the amount of angle to move in one direction. Correct me if I wrong) fixed (like 90, 180, 270) or set by the user. What is the setting & detection mechanism used?
2. How do you determine the change direction position?
3. Do you really feel half step method is neccesary considering your final application ie., shaker? Technically, you can acheive the accuracy. But the material inside the container that is shaked is not going to stop exactly at the position where the motor has stopped. Since I don't know your requirement exactly, I am assuming.

Rotational angle is selected by the user in increments of 15 degrees. I can't recall the upper limit, I believe it is 1080degrees (3 full revolutions). And yes, if you select 90 degree rotation, the motor should move 90degrees forward, then 90 degrees back and so on. There is a menu system which can be entered when the motor is not running which allows adjusting this value. Detection amounts to calculating the number of steps it SHOULD take to move the requested amount. We have an optical sensor that is looking at the motor shaft which has a black strip attached, so we could use this to make sure we're returning to the proper position at the end of each cycle. This doesn't help for detecting when the motor has actually reached the proper angle, however. If we constrained our options to 90 degree increments, maybe we could use 4 strips on the motor shaft and use the optical sensor that way.

Current algorithm gradually increases speed until the controller has been sent half the number of pulses necessary to move the motor the requested amount. It then gradually decreases speed for the remaining steps, and switches directions after the step count matches the calculated number of pulses. Now that I'm thinking about it, it may be that the same function used for ramping up is used for ramping down. Would it be better to decrease the speed slowly at first and then more rapidly? It may be doing the opposite at the moment, I will check it out tomorrow.

I'm not entirely sure why half-stepping was chosen over full-stepping, I will check with my boss. I tend to guess that it was done to alleviate some motor resonance, and to allow smoother motor operation.

So from your detection method I guess half stepping is choosen not for positional accuracy.

Yes there is chance for resonance. However, PWM / chopper method will elevate it to some extend. You should look at the datasheet of the motor for resonance point on PPS vs torque graph. Moreover, most of the time simple mechanical damping will eleminate the resonance. Since you have load, I don't think resonance will be a issue. I suggest as test to run the motor in full step mode at various speeds to assess the torque, resonance and smoothness. Of course disable the wave shapping used for half stepping.

Quote:
The problem arises when you command the motor to move forward 90 degrees then back 90 degrees repeatedly. Perhaps just adding a little delay after reaching the half-way mark (full speed) and a little after reaching the original location (almost 0 speed) will allow the motor to stop oscillating before I send the next step command. When the direction switch occurs, the motor is moving at 10rpm = .17 rps = 68 steps/ sec which means a step is occuring every 15ms.

Zalfrin, do I get it right? :
You stand still at start position, you accelrate up to speed, (keep it a while), turn direction, (keep it a while) and decelerate down to standing still?

Will not the momentum of the motor and the load when turning direction be the problem? Turning direction at 10rpm is the same as instant acceleration to 20rpm.

Bob:
I never been using speeds above the resonate region of the stepper motor. I was of the belief that you had to change driver scheme on the fly to be able to pass it (But this I really know nothing about).

Bill: not quite right. Motor starts at rest. User specifies how far the motor must travel in 15 degree increments. Lets say we're doing 180 degree rotation at 50 rpms. In this case, as currently implemented, the motor will accelerate from a starting speed of 10 rpms to a speed of 50 rpms, achieving 50 rpms when the motor shaft has traveled 90 degrees. It will then decelerate for the remaining 90 degrees, returning to the start speed of 10 rpms before issuing a direction switch. The lowest speed we can go is 3 rpm, anything below this overflows the OCR1A timer. There is also no delay implemented currently, the motion should be as continuous as possible, I don't want to have to wait for 2 or 3 seconds for the mechanical vibrations to die down before I can move the motor safely again.

Simma: I played with full stepping a little this morning. Our unloaded, smaller prototype which had been able to achieve 900-1000 rpms refused to go past 400-ish. I moved to the larger 1.7A motor and tried various speeds without direction switching, as well as with direction switching. Without, resonance was audibly present at 3 places between 3 and 100 rpms for full-stepping. Half-stepping reduced this to 1 trouble spot. Choppiness at low speeds seemed no different between full and half stepping. With direction switching, I couldn't really tell if the oscillations upon actually switching directions were any better or worse. However, with half-stepping the prototype functioned properly at 50 rpms with rotation, whereas with full stepping, performance was abysmal with 1/3 of direction switches failing. The motor would either continue to make slipping noises if pulses were coming too fast, or seem to accelerate more and miss the direction switch entirely. I don't have any means of measuring torque directly, but I was unable to tell a difference when obstructing the plate with my hand.

Which mode have you tried - two phase on or wave drive?

Did you remove or isolate the INH lines acting on the reference voltage?

How about the drive current? did you vary and check?

I believe it was set for two phase on, since the motor is initialized to the home position and I never set the bit the half/full line is connected to. I will probe the inhibit lines to verify this. I used a completely different prototype board which didn't have all the modifications made for ref voltage boosting during half-stepping. I didn't vary drive current at all. What kind of things am I looking for?

Inhibit lines are constant, although only sitting at 4.4V. So the controller is in two-phase mode, and is acting off the phase lines rather than the inhibit lines. Can you offer an explanation for why at times the motor shaft will rapidly accelerate instead of switching directions? It seems like even if motor resonance caused the direction switch to fail, the speed of the plate would still relate to the speed we are clocking the l297, but that does not seem to be the case. I'm considering reworking the motor ramping algorithm so the acceleration profile is a sawtooth, which would give a smoothed out velocity profile. Currently we are using a 2nd-order equation to generate the next speed increment with current speed being the squared term. There is no way to control ramp rate, except by twiddling the constant in the equation. I'd like to do something similar to the AVR linear stepper motor control app note, in that we would break the movement into discrete parts, each with its own speed increment equation. First section would be ramping to max acceleration, then ramping down to 0 acceleration, continuing ramping to max deceleration, then ramping back up to 0 acceleration. Timing is going to be problematic.

Also considering adding an optical encoder to allow us to actually measure how far the shaft has moved. Apparently our current optical sensor has extremely poor resolution and rise time and such, but was a cheap way of returning to a set home position.

It occured to me that my speed increment is just a synonym for acceleration. So directly controlling that will not be as difficult as I first thought. I should be able to replace the 2nd order equation with 2 linear equations and an offset. Then I could easily adjust my ramp rate by playing with the coefficient.

It also occurs to me that my full-stepping tests didn't account for half as many steps in a revolution. I'll re-examine that tomorrow. What kind of advantage do you think chopping off the phase lines provides in this application? From a zoomed out perspective, the inhibit line chopping seems much more like what I would expect.