NEW: Abs Angle Sensor Object & Stepper Linear Speed Control Object
Greg P
Posts: 58
Hey Folks !
This recently completed project demonstrates the versatility & power of the Propeller micro-controller.
It includes several new objects which developers may find of interest: in particular, the
absolute angle encoder object & the stepper motor linear speed control object. This job took
just a few weeks effort .... the Propeller is simply amazing !
I will eventually post these two objects to the exchange. Feedback welcome. If anyone
would like to upgrade the linear speed control object be substituting assembly for spin
code in the launched cog I would greatly appreciate their efforts. The machine has
been shipped, so I'm unable to continue development.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Project Overview:
The goal was to control the movement of a large 29" wheel upon which were mounted 12
smaller 4" diameter 'sample' wheels at 30 degree spacing. These sample wheels were suspended
using 3 small rollers 120 degrees apart such that the center of each sample wheel was
open and within which could be mounted unique target materials. A TV and keyboard were used
to program the machine to rotate a particular 'sample' wheel into alignment with an external
proton beam source, then engage a small spring-loaded 'spin' drive stepper to slowly spin the
target material within the 'sample' wheel for a programmed dwell time. The large wheel required
rather precise positioning so that its 'sample' wheel would always properly align with the
spring-loaded 'spin' drive wheel. An angle encoder was used to read back the large wheel's
angular position prior to each wheel movement. This machine permits unassisted overnight
operation at a particle accelerator facility in which 'beam time' is a limited resource.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
1) MA3P12_Encoder_V3 Object - Absolute Angle Encoder
US Digital offers a small absolute angle magnetic shaft encoder with < 0.5 deg accuracy for ~$36.
The device has mounted to its shaft a small internal magnet suspended a fraction of a millimeter above
a magnet-field orientation-sensing IC. The long-life ball-bearing version can withstand 15,000 rpm,
250,000 rad/s2 acceleration, and 1 lb of shaft loading. It's available in a 3-wire 12-bit resolution
PWM output version with a pulse period of ~4 milliseconds (250 Hz update rate). Unfortunately,
temperature changes effect pulse period up to +/-10%, so a simultaneous measurement of both pulse
width and pulse period is required for the highest accuracy. The 5v output of the PWM signal required
placement of a 2K ohm series resistor between the sensor's PWM output and the Propeller input pin.
An assembly-code implementation was required since the pulse width at very small angles may be
only a few microseconds. The algorithm employed to convert pulse width and pulse period (in system
clock cycles) to an angle reading in units of millidegrees is both simple and elegant as no explicit
multiplication or division operations in assembly code are required. Initially, if the pulse width
( in cycles) is greater than 1/2 the pulse period (in cycles), a value of 1/2 of full scale output
( 180000 millidegrees) is added to an output accumulator. The pulse width cycle count (if greater)
is then reduced by 1/2 the pulse period cycle count. In successive code loops, the pulse width cycle
count remainder from the previous cycle is compared with pulse period cycle counts repeated reduced
by a factor of 2 (bit shift right). If the pulse width cycle count remainder is again found to be
greater, the output accumulator is incremented by the appropriate scaled-by-2 version of the full
scale output value (360000).
A unique feature of this object is that it only consumes a cog resource at the time of the angle
measurement, lasting less than 10 milliseconds. The Propeller launches the assembly-language cog
in just 0.1 milliseconds. The period spacing of 4 mS necessitates a worst case 8 mS for pulse width
& period measurements to be acquired. The actual clock cycle to millidegree conversion requires
less than 0.5 mS. The calling spin object preloads the 'angle' variable with an illegal response
of '-1', launches the assembly angle code, waits 10 mS, then tests for a legal reply (0 through
360000). Since waitpeq statements are employed, it's possible that a non-responding sensor or
poor connection could 'hang' code execution. In this case, the angle value remains '-1' upon
testing after a 10mS wait, prompting the cog to be terminated from spin code. The trick to force a
cog to self-terminate in assembly are the consecutive instructions: cogid thiscog, cogstop thiscog.
Multiple instances of the object may be started, each with its own PWM input pin assigned. A cog
resource is only consumed during the GetAngle method call and for less than 10mS. This allows near
simultaneous measurement of multiple sensor angles. For relative time comparison, a 200 step/rev
stepper motor at 1 rps (60 rpm) requires 5 mS between consecutive pulses.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
2) StepMotor_RampControl1 Object - Acceleration/Deceleration Stepper Motor Control
Our particular application involved rotation of a heavy 29" diameter wheel using a 570 oz-in stepper
(5v @ 2.5 amps) with an 8:1 gear ratio chain-sprocket drive train. Given the wheel's high rotational
inertia it was desired to both accelerate and decelerate from top speed. David Austin wrote an article
for Embedded Systems Design back in 2004 which offered an elegant approach for smoothly altering the
stepper pulse rate while performing a stepper motor rotation through a specified number of steps.
In 2006, Atmel application note AVR446 employed his algorithm with their 8-bit AVR microcontroller
product line. After simulating the algorithm using Visual Basic, I ported it over as Spin code for
use in our project.
The Move() method launches a cog running Spin code, DriveMotorCog(). After completion of a motor
movement, DriveMotorCog terminates and the cog is released. Our particular motor controller uses
a buffer IC with a high input impedance for all the direction/step input lines. This created a
subtle problem. Erratic stepper motor activity was observed even while no stepper pulse commands
were being issued. It turned out that after motor movement completion and cog termination the step
& direction output lines were being floated as unused inputs. The cabling from Propeller to motor
controller then became a nice antenna coupling all those high frequency PWM stepper motor wiring
voltages to the high input impedance step input of the motor controller leading to erratic motor
behavior. A partial solution was found by keeping the step & direction lines as outputs following
a call to the Init() method. Just prior to launching DriveMotorCog the calling cog (running Spin)
converts these lines to inputs. DriveMotorCog at startup sets these same lines back to outputs.
Upon cog termination, these lines are again reset to outputs. The best final solution was placement
of 1K ohm resistors to ground at all step & direction lines near the motor controller input.
As only two lines (step & direction) are required per motor, and one line (PWM input) is needed
per angle sensor, up to 10 separate motor / angle sensor pairs could be controlled by one Propeller
chip. Depending on the availability of cog resources, multiple motors could be engaged simultaneously.
Linear Motor Control References:
================================
D. Austin, Generate stepper-motor speed profiles in real time,
article in Embedded Systems Programming January 2005.
WEB: http://www.embedded.com//showArticle.jhtml?articleID=56800129
ftp://ftp.embedded.com/pub/2005/01austin/Motor.c
AVR446: Linear speed control of stepper motor Atmel application note.
WEB: http://www.atmel.com/dyn/resources/prod_documents/doc8017.pdf
D.W. Jones, Basic Stepping Motor Control Circuits (Part of Stepping Motors)
The University of Iowa Department of Computer Science
WEB: http://www.cs.uiowa.edu/~jones/step/circuits.html
http://www.cs.uiowa.edu/~jones/step/physics.html
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
3) PulseGenerator2 Object
This code was copied from an early project where it was desired to freely configure
multiple 'pulse generator' objects programmatically. An object wrapper, StepperMotorControl3,
for the PulseGenerator object was quickly written to create a simple stepper motor driver.
Upon reflection, it represents quite a bit of "overkill". I much simpler approach would have
been to launch spin code running from a separate cog.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
4) i2c_interface_v3 Object
This is a generic i2c interface object. Code from the object exchange was highly modified
to accommodate some i2c devices which required both their data and clock lines to float
high using pullup resistors. It was discovered rather late in this project that the clock line for
the Propeller Demo Board's EEPROM is a dedicated Propeller output, so the i2c object's code
was modified accordingly.
The 24LC256_Microchip_EEPROM2 object is a wrapper for the i2c object. It permits read/writes
to an external EEPROM across page boundaries.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
5) SerialMirror2 Object
Minor modification to original SerialMirror object: added a 'debug' parameter to the startx() method.
When set TRUE, the serial cog is launched. When set FALSE all serial method calls are disabled and
the cog is not launched. At project completion the debug flag is set FALSE, freeing an extra cog.
The globally-disabled serial object method calls permit me to leave all the serial method calls used
for debugging untouched. Previously I would have had to remove each and every serial method call
throughout all objects referencing the SerialMirror object.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
This recently completed project demonstrates the versatility & power of the Propeller micro-controller.
It includes several new objects which developers may find of interest: in particular, the
absolute angle encoder object & the stepper motor linear speed control object. This job took
just a few weeks effort .... the Propeller is simply amazing !
I will eventually post these two objects to the exchange. Feedback welcome. If anyone
would like to upgrade the linear speed control object be substituting assembly for spin
code in the launched cog I would greatly appreciate their efforts. The machine has
been shipped, so I'm unable to continue development.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Project Overview:
The goal was to control the movement of a large 29" wheel upon which were mounted 12
smaller 4" diameter 'sample' wheels at 30 degree spacing. These sample wheels were suspended
using 3 small rollers 120 degrees apart such that the center of each sample wheel was
open and within which could be mounted unique target materials. A TV and keyboard were used
to program the machine to rotate a particular 'sample' wheel into alignment with an external
proton beam source, then engage a small spring-loaded 'spin' drive stepper to slowly spin the
target material within the 'sample' wheel for a programmed dwell time. The large wheel required
rather precise positioning so that its 'sample' wheel would always properly align with the
spring-loaded 'spin' drive wheel. An angle encoder was used to read back the large wheel's
angular position prior to each wheel movement. This machine permits unassisted overnight
operation at a particle accelerator facility in which 'beam time' is a limited resource.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
1) MA3P12_Encoder_V3 Object - Absolute Angle Encoder
US Digital offers a small absolute angle magnetic shaft encoder with < 0.5 deg accuracy for ~$36.
The device has mounted to its shaft a small internal magnet suspended a fraction of a millimeter above
a magnet-field orientation-sensing IC. The long-life ball-bearing version can withstand 15,000 rpm,
250,000 rad/s2 acceleration, and 1 lb of shaft loading. It's available in a 3-wire 12-bit resolution
PWM output version with a pulse period of ~4 milliseconds (250 Hz update rate). Unfortunately,
temperature changes effect pulse period up to +/-10%, so a simultaneous measurement of both pulse
width and pulse period is required for the highest accuracy. The 5v output of the PWM signal required
placement of a 2K ohm series resistor between the sensor's PWM output and the Propeller input pin.
An assembly-code implementation was required since the pulse width at very small angles may be
only a few microseconds. The algorithm employed to convert pulse width and pulse period (in system
clock cycles) to an angle reading in units of millidegrees is both simple and elegant as no explicit
multiplication or division operations in assembly code are required. Initially, if the pulse width
( in cycles) is greater than 1/2 the pulse period (in cycles), a value of 1/2 of full scale output
( 180000 millidegrees) is added to an output accumulator. The pulse width cycle count (if greater)
is then reduced by 1/2 the pulse period cycle count. In successive code loops, the pulse width cycle
count remainder from the previous cycle is compared with pulse period cycle counts repeated reduced
by a factor of 2 (bit shift right). If the pulse width cycle count remainder is again found to be
greater, the output accumulator is incremented by the appropriate scaled-by-2 version of the full
scale output value (360000).
A unique feature of this object is that it only consumes a cog resource at the time of the angle
measurement, lasting less than 10 milliseconds. The Propeller launches the assembly-language cog
in just 0.1 milliseconds. The period spacing of 4 mS necessitates a worst case 8 mS for pulse width
& period measurements to be acquired. The actual clock cycle to millidegree conversion requires
less than 0.5 mS. The calling spin object preloads the 'angle' variable with an illegal response
of '-1', launches the assembly angle code, waits 10 mS, then tests for a legal reply (0 through
360000). Since waitpeq statements are employed, it's possible that a non-responding sensor or
poor connection could 'hang' code execution. In this case, the angle value remains '-1' upon
testing after a 10mS wait, prompting the cog to be terminated from spin code. The trick to force a
cog to self-terminate in assembly are the consecutive instructions: cogid thiscog, cogstop thiscog.
Multiple instances of the object may be started, each with its own PWM input pin assigned. A cog
resource is only consumed during the GetAngle method call and for less than 10mS. This allows near
simultaneous measurement of multiple sensor angles. For relative time comparison, a 200 step/rev
stepper motor at 1 rps (60 rpm) requires 5 mS between consecutive pulses.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
2) StepMotor_RampControl1 Object - Acceleration/Deceleration Stepper Motor Control
Our particular application involved rotation of a heavy 29" diameter wheel using a 570 oz-in stepper
(5v @ 2.5 amps) with an 8:1 gear ratio chain-sprocket drive train. Given the wheel's high rotational
inertia it was desired to both accelerate and decelerate from top speed. David Austin wrote an article
for Embedded Systems Design back in 2004 which offered an elegant approach for smoothly altering the
stepper pulse rate while performing a stepper motor rotation through a specified number of steps.
In 2006, Atmel application note AVR446 employed his algorithm with their 8-bit AVR microcontroller
product line. After simulating the algorithm using Visual Basic, I ported it over as Spin code for
use in our project.
The Move() method launches a cog running Spin code, DriveMotorCog(). After completion of a motor
movement, DriveMotorCog terminates and the cog is released. Our particular motor controller uses
a buffer IC with a high input impedance for all the direction/step input lines. This created a
subtle problem. Erratic stepper motor activity was observed even while no stepper pulse commands
were being issued. It turned out that after motor movement completion and cog termination the step
& direction output lines were being floated as unused inputs. The cabling from Propeller to motor
controller then became a nice antenna coupling all those high frequency PWM stepper motor wiring
voltages to the high input impedance step input of the motor controller leading to erratic motor
behavior. A partial solution was found by keeping the step & direction lines as outputs following
a call to the Init() method. Just prior to launching DriveMotorCog the calling cog (running Spin)
converts these lines to inputs. DriveMotorCog at startup sets these same lines back to outputs.
Upon cog termination, these lines are again reset to outputs. The best final solution was placement
of 1K ohm resistors to ground at all step & direction lines near the motor controller input.
As only two lines (step & direction) are required per motor, and one line (PWM input) is needed
per angle sensor, up to 10 separate motor / angle sensor pairs could be controlled by one Propeller
chip. Depending on the availability of cog resources, multiple motors could be engaged simultaneously.
Linear Motor Control References:
================================
D. Austin, Generate stepper-motor speed profiles in real time,
article in Embedded Systems Programming January 2005.
WEB: http://www.embedded.com//showArticle.jhtml?articleID=56800129
ftp://ftp.embedded.com/pub/2005/01austin/Motor.c
AVR446: Linear speed control of stepper motor Atmel application note.
WEB: http://www.atmel.com/dyn/resources/prod_documents/doc8017.pdf
D.W. Jones, Basic Stepping Motor Control Circuits (Part of Stepping Motors)
The University of Iowa Department of Computer Science
WEB: http://www.cs.uiowa.edu/~jones/step/circuits.html
http://www.cs.uiowa.edu/~jones/step/physics.html
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
3) PulseGenerator2 Object
This code was copied from an early project where it was desired to freely configure
multiple 'pulse generator' objects programmatically. An object wrapper, StepperMotorControl3,
for the PulseGenerator object was quickly written to create a simple stepper motor driver.
Upon reflection, it represents quite a bit of "overkill". I much simpler approach would have
been to launch spin code running from a separate cog.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
4) i2c_interface_v3 Object
This is a generic i2c interface object. Code from the object exchange was highly modified
to accommodate some i2c devices which required both their data and clock lines to float
high using pullup resistors. It was discovered rather late in this project that the clock line for
the Propeller Demo Board's EEPROM is a dedicated Propeller output, so the i2c object's code
was modified accordingly.
The 24LC256_Microchip_EEPROM2 object is a wrapper for the i2c object. It permits read/writes
to an external EEPROM across page boundaries.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
5) SerialMirror2 Object
Minor modification to original SerialMirror object: added a 'debug' parameter to the startx() method.
When set TRUE, the serial cog is launched. When set FALSE all serial method calls are disabled and
the cog is not launched. At project completion the debug flag is set FALSE, freeing an extra cog.
The globally-disabled serial object method calls permit me to leave all the serial method calls used
for debugging untouched. Previously I would have had to remove each and every serial method call
throughout all objects referencing the SerialMirror object.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Comments
This is all way over my head but it sure sounds great!
I'm additionally impressed by all the documentation you are providing with it.
thanks!
·· I have only started to look over your project. Very nice work. I coded the same Austin algorithm a few months ago. My approach was a little different. Instead of specifying angles in .01 radian units, I converted everything to motor steps. And I·wrote the algorithm in assembly language to get higher speeds. I would be glad to share any of this with you if interested, but be advised that my code is sparsely commented compared to yours. The coding has taken a back seat to hardware design and build for now, but when finished I am hoping to drive 4 stepper motors and handle all overhead from a single Propeller.
Great work
Al