Controlling Stepper Motors Using Power IO Wildcard MOSFET Driver

For optimal efficiency, set MAX_STEPPERS to the number of stepper motors being controlled, with a maximum limit of four. Motors are identified by indices 0, 1, 2, and 3. On the QCard, there is a trade-off between the number of motors controlled and the maximum stepping speed, which is constrained by the processing power of the 68HC11. Each interrupt-driven step requires 120 µsec per motor, and when all four motors operate at maximum speeds of 1000 steps or half-steps per second, the 68HC11 processor is engaged approximately 50% of the time to manage motion through low-level interrupt-driven utilities. Consequently, most applications either utilize fewer motors or increase the MSEC_PER_TICK constant to reduce the maximum speed of each motor. The PDQ Board features a more powerful processor, allowing the use of four motors at 1000 full- or half-steps per second with only 8% of its processing capability utilized. A significant parameter in the stepper status structure is the signed 32-bit step counter, which tracks the step count within a range of ±2,147,483,647 counts. Positive values indicate clockwise rotation, while negative values indicate counter-clockwise rotation. The Step_Count function provides a 32-bit pointer to this variable in common RAM, accepting the motor index as an input parameter. The Revolutions function in the demo program demonstrates how to read and write this value. If the motor is halted, the step count remains unchanged during that time. The step counter can be set to any desired value as long as the motor is stationary. For instance, during a HOME operation where a microswitch detects the home position of stepper motor 0, the motor's step count can be reset to zero. If the motor is configured for full stepping, the counter reflects the number of full steps taken since initialization or the last reset. In the case of half stepping, it indicates the number of half-steps taken. In both scenarios, the counter is a signed 32-bit value. To determine the total revolutions, divide the step counter by the number of steps (or half-steps) per revolution for the specific motor. The default stepper motor from Mosaic has 200 full steps or 400 half-steps per full 360° revolution. The defined direction constants are CW (clockwise) =1 and CCW (counter-clockwise) = -1. It is important to note that stepper motors from different vendors may have different internal wiring, potentially causing them to rotate in the opposite direction compared to the default motor from Mosaic. In such cases, the simplest solution is to define new direction constants with opposite values. Additionally, the byte that tracks the motor state is another valuable parameter in the stepper status structure. This variable is managed by the interrupt-driven control functions, rendering it "read-only" to the application program. The pre-coded Motor_State function returns the value that encodes the motor's state. Pre-defined constants such as MOTOR_STOPPED (value 5) and MOTOR_AT_FINAL_SPEED (value 1) are useful for identifying when the motor is halted or has reached the specified terminal speed. The Revolutions function in the demo program illustrates the application of this function. After executing a command like Steps_At_Speed, the background interrupt-driven code prepares the ramp data structures to control the motor for the specified action. However, it is essential to note that the command (e.g., Steps_At_Speed) completes well before the stepper motor.

The described system effectively manages multiple stepper motors, allowing for precise control over their operation. The architecture involves a central processing unit (CPU) that handles the timing and execution of motor steps through interrupts. Each motor's stepping behavior is governed by the defined parameters, including the maximum number of motors and the stepping speed, which can be adjusted based on the application requirements.

The signed 32-bit step counter serves as a critical component for tracking motor position and direction. This feature is particularly useful in applications requiring accurate positioning and movement. The ability to reset the step counter during specific operations, such as homing, enhances the flexibility of the system, allowing for recalibration as needed.

The direction constants and motor state tracking ensure that the system can accommodate various motor configurations and vendor differences. This adaptability is vital for integrating different stepper motors into the same control system, promoting versatility in design.

The interrupt-driven architecture provides efficient processing, allowing the CPU to manage multiple motors simultaneously while minimizing processing overhead. This design choice is essential for applications where real-time performance is critical, as it enables the system to respond promptly to changes in motor state or command inputs.

Overall, the described stepper motor control system is a robust solution for applications requiring precise motor control, with features that allow for customization and adaptability to various motor types and operational requirements.For maximum efficiency, set MAX_STEPPERS equal to the number of stepper motors that you are controlling (but never more than 4). Motors are referred to by their indices 0, 1, 2 and 3. On the QCard there is a trade-off between the number of motors being controlled and the maximum stepping speed, limited by the available processing power of the 68HC11.

Given that each interrupt-driven step requires 120 µsec per motor, while all 4 motors are stepping at their maximum speeds (1000 steps or half-steps per second in this application), the 68HC11 processor is busy about 50% of the time managing the motion via the low-level interrupt-driven utilities. Thus most applications would either use fewer motors or would raise the value of the MSEC_PER_TICK constant to decrease the maximum attainable speed of each motor.

The PDQ Board has a more powerful processor, so using four motors at 1000 full- or half-steps per second consumes only 8% of the PDQ Board`s processing capability. A useful parameter in the stepper status structure is the signed 32-bit step counter that keeps track of the step count over a range of ±2, 147, 483, 647 counts.

Positive values represent clockwise rotation, and negative values represent counter-clockwise rotation. The Step_Count function returns a 32-bit pointer to this 32-bit variable in common RAM; it accepts the motor index as the input parameter.

The Revolutions function in the demo program shows how to read and write this value. If the motor is stopped, the step count will not change during the interval. You can set the step counter to any value you want as long as the specified motor is not moving. For example, if you perform a HOME operation in which a microswitch is used to detect the home position of stepper motor 0, you could then set the motor`s step count to zero. If the motor is configured for full stepping, the count indicates the number of full steps that have been taken since the status array was initialized or since the step counter was last zeroed.

If the motor is configured for half stepping, the count indicates the number of half-steps that have been taken. In each case the counter is a signed 32-bit value. To calculate the total number of revolutions, simply divide the step counter by the number of steps (or half-steps) per revolution for your motor.

The default stepper motor provided by Mosaic has 200 full steps or 400 half-steps per full 360 ° revolution. The specified direction constants are CW (clockwise) =1, and CCW (counter-clockwise) = 1. Note that stepper motors purchased from different vendors may be wired differently internally, and the most common difference is that they spin in the opposite direction than the default motor supplied by Mosaic.

If this happens with a custom-specified motor, the simplest fix is to define new direction constants that have the opposite values compared to the default (that is, swap the 1 and 1 values). Another useful parameter in the stepper status structure is the byte that keeps track of the motor state.

This variable is controlled by the interrupt-driven control functions, so to the application program it is a "read-only" parameter. The pre-coded Motor_State function returns the value that encodes the state. Pre-defined constants MOTOR_STOPPED (value 5), and MOTOR_AT_FINAL_SPEED (value 1) are useful for detecting when the motor is stopped or has reached the specified terminal speed, respectively.

The Revolutions function in the demo program illustrates how this function is used. After a command such as Steps_At_Speed is executed, the background (that is, interrupt-driven) code sets up the ramp data structures which will control the motor to carry out the specified action. But note that the command (Steps_At_Speed in this example) finishes well before the stepper motor 🔗 External reference