Linear Actuator Notes
Important from the AVR freaks
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1030267
Following are some extracts from the comment section of the AVR freaks : For a simple servo control we have to:
Read the actual position
Compare with demanded position
Compute the error
Add some deadband
Tell motor to go fwd,rev or stop
The longest part would be reading the adc, i would guess a total of 200us for each servo
For the linear actuators,
Get current position
Compare with wanted position
Tell motor to go fwd,rev or stop
Encoder fires an external interrupt.
Isr updates the current position and stops the motor when it hits the wanted position.
Flat stick the isr will suck 3% of cpu.
Mainline code will take a couple of microseconds to figure out what to do.
So based on those numbers, 60hz is easily achieved.
You should have plenty of time to do serial comms via a circular buffer.
From the site:
http://www.robot-r-us.com/vmchk/motor-linear-stroke/linear-actuator-with-feedback-and-6-stroke-lact6p.html
SKF at least next time,Please do it write and do understand it is not alone the mechanical engineer who
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1030267
If I have to remove these contents against copyright please do leave a comment,I will remove it.
All I wanted with this post was to accumulate all these to this page as I will not loose time pondering the internet for these data.
All I wanted with this post was to accumulate all these to this page as I will not loose time pondering the internet for these data.
Following are some extracts from the comment section of the AVR freaks : For a simple servo control we have to:
Read the actual position
Compare with demanded position
Compute the error
Add some deadband
Tell motor to go fwd,rev or stop
The longest part would be reading the adc, i would guess a total of 200us for each servo
For the linear actuators,
Get current position
Compare with wanted position
Tell motor to go fwd,rev or stop
Encoder fires an external interrupt.
Isr updates the current position and stops the motor when it hits the wanted position.
Flat stick the isr will suck 3% of cpu.
Mainline code will take a couple of microseconds to figure out what to do.
So based on those numbers, 60hz is easily achieved.
You should have plenty of time to do serial comms via a circular buffer.
From the site:
http://www.robot-r-us.com/vmchk/motor-linear-stroke/linear-actuator-with-feedback-and-6-stroke-lact6p.html
IT's no doubt that the SKF makes very good linear actuator but I cannot complaint enough
how easily they have neglected all the details in there data sheet which would help
a control system designer who not only have to deal with linear actuators among a large
amount of work around it.Following is specification I found informative to a certain extend and should be
something the linear actuator should be aiming at,Here it goes
General specifications
| Gear ratio: | 20:1 |
|---|---|
| Free-run current @ 12V: | 500 mA |
| Stall current @ 12V: | 10 A |
| Linear speed @ 12V: | 0.5 in/s |
| Linear force @ 12V: | 110 lb |
| Feedback potentiometer included?: | Y |
SKF at least next time,Please do it write and do understand it is not alone the mechanical engineer who
has to work with these actuators.
Two rotations for 1mm. 35mm => 70 rotations, 560 pulses. 55mm => 110 rotations; 880 pulses.
4800rpm => 80rps. That doesn't quite work out--the full travel on the 55mm then should be over a second. But not too far off, within a factor of two.
For the sake of discussion, let's split the difference and say that the 55mm travel takes 880ms for the 880 pulses. That would be 1ms per pulse. In AVR terms, that is a fairly looong time. A couple of channels of that should not be a problem, even at a relatively modest AVR clock rate.
The next important question: Are the encoder edges "clean" when observed on a 'scope? If there is ringing then it gets trickier. One would need fast polling/debounce intervals on the order of 100us or less with skinny ISRs. Not a deal breaker but a bit tricky. Let's say the edges are clean.
All of my "solutions" would involve interrupts.
If it were one channel, indeed running the signal into T1 pin to externally clock the timer would be cool. A single-channel (not quadrature) encoder won't give direction information anyway, so no real need for up/down counting of the timer. You are driving the motor in one direction or the other so when you are stopped and want to move n counts in one direction, you clear TCNT and set a compare match at the desired number of pulses. Enable the compare match interrupt and when it trips, do your thing (probably "stop").
The same can be done with the 8-bit timer. However, the full-travel counts don't fit into TCNT0 (560, 880). There are a couple of approaches to address this.
First, if you can overshoot up to 1mm or so then (depending on the AVR model--do we know which one?) you could set a prescaler on the timer0 of say /4 and then proceed as above.
Or, you can count overflows on timer0 and only enable the compare match after all the "wholes" (256 counts) are done and only the "partial" remains.
(Or, if your travels are never more that 256 counts/32mm then that isn't a worry.)
==================
Next approach: the pulses are far enough between that an external interrupt or pin-change interrupt can be configured for each signal. Simply count the hits and "trip" when the setpoint is reached.
==================
Another approach might be to ignore the encoder and do everything by time. That would be sloppier probably if there are accel and decel considerations."
These are some sites with suggestion to control the actuators
The following point seems interesting and worth to remember as what he mentioned seems to be the problem
of the overshooting and settling time of the operation of controlling a linear actuator DC motor
"Thanks for the input. It was helpful. I have tested the circuit and the software, and it seems to work OK. The only caution that I would add for anyone else who might be slamming linear actuators from limit to limit is to allow some time for the motor to start and the current to get established before checking the motor current. Physical systems take time to get going and even an 8 bit micro can get way ahead long before the motor gets spooled up and starts drawing current. I allowed 100mS and that, while a long time, works for my application."
"Now we have some numbers to do some noodling.
Two rotations for 1mm. 35mm => 70 rotations, 560 pulses. 55mm => 110 rotations; 880 pulses.
4800rpm => 80rps. That doesn't quite work out--the full travel on the 55mm then should be over a second. But not too far off, within a factor of two.
For the sake of discussion, let's split the difference and say that the 55mm travel takes 880ms for the 880 pulses. That would be 1ms per pulse. In AVR terms, that is a fairly looong time. A couple of channels of that should not be a problem, even at a relatively modest AVR clock rate.
The next important question: Are the encoder edges "clean" when observed on a 'scope? If there is ringing then it gets trickier. One would need fast polling/debounce intervals on the order of 100us or less with skinny ISRs. Not a deal breaker but a bit tricky. Let's say the edges are clean.
All of my "solutions" would involve interrupts.
If it were one channel, indeed running the signal into T1 pin to externally clock the timer would be cool. A single-channel (not quadrature) encoder won't give direction information anyway, so no real need for up/down counting of the timer. You are driving the motor in one direction or the other so when you are stopped and want to move n counts in one direction, you clear TCNT and set a compare match at the desired number of pulses. Enable the compare match interrupt and when it trips, do your thing (probably "stop").
The same can be done with the 8-bit timer. However, the full-travel counts don't fit into TCNT0 (560, 880). There are a couple of approaches to address this.
First, if you can overshoot up to 1mm or so then (depending on the AVR model--do we know which one?) you could set a prescaler on the timer0 of say /4 and then proceed as above.
Or, you can count overflows on timer0 and only enable the compare match after all the "wholes" (256 counts) are done and only the "partial" remains.
(Or, if your travels are never more that 256 counts/32mm then that isn't a worry.)
==================
Next approach: the pulses are far enough between that an external interrupt or pin-change interrupt can be configured for each signal. Simply count the hits and "trip" when the setpoint is reached.
==================
Another approach might be to ignore the encoder and do everything by time. That would be sloppier probably if there are accel and decel considerations."
Comments
Post a Comment