Skip to content

Stepper motor control research

Jump to bottom Edit New page
chamnit edited this page Nov 29, 2012 · 4 revisions

Intro

With the planned reworking of the stepper control this page exists as a collection of research and thoughts regarding potential alternatives.

See https://github.com/grbl/grbl/issues/145 for more info

Requirements

  • Depending on the highest supported step rate, currently at 30kHz, the step generation interrupt must complete, in the worst case scenario, to within about 50%-70% of the step period. So for 30kHz, a step is generated every 33 microseconds, hence the interrupt must complete within 15-25 microseconds. Build v0.8c testing showed the step generation during cruising was an acceptable 20-25 microseconds per step pulse, but a lengthy calculation during every velocity change was found to add another 45 microseconds. This causes occasional steps to be delayed (not lost) and is particularly noticeable with acceleration transitions at high step rates greater than 15 kHz as audible "thumps".

  • The algorithm must be simple and flexible, meaning that it's not strictly tuned for one particular microcontroller and can be easily modified later.

  • The step generation must play nice with the execution of feed holds and feed rate overrides. The current implementation of feed holds may be modified but functionality cannot. Feed rate overrides have yet to be installed and this should be a major consideration when surveying new step generation algorithms.

  • A user configurable direction pin delay must be installed. Some users have experienced issues with the current implementation of the direction pin setting, as their systems require delays reportly ranging from 10usec to 30usec.

  • Real-time position tracking. Although costly in the stepper interrupt, this provides the most accurate and direct measurement of Grbl's position.

  • A higher resolution Brensenham line algorithm to minimize algorithm artifacts during multi-axis moves. This usually occurs when the non-primary axes move at a rate is very close, but not at, to a factor of the primary axis rate.

Techniques

  • Offload as much as possible to the main program. All the step generation interrupt should to is step, update position, and update the timer. Anything else is too costly.

  • To solve the Bresenham line algorithm issue, an adaptive method to adjust the algorithm resolution is proposed. To increase algorithm resolution, the primary step generation axes would simply fire every two or more interrupts (rather than every one), while the non-primary axes could fire at any time within the increased number of interrupts. This allows the non-primary axes to move more independently to the primary axis and greatly reduces the algorithm artifacts. If we know the maximum step frequency, we then can set for certain step frequency ranges a resolution. For example, with a 30kHz maximum step frequency, all step rates below 6kHz could have a 3x resolution; 6-12kHz have a 2x resolution; and 12kHz or greater could run at the normal full resolution.

  • Feed holds are tricky. The current thought is to create line segment manager that serves as a intermediary between the stepper driver and the planner. The line segment manager sole purpose is to feed small step (accel,decel,cruise) motions of a known time execution directly to the stepper driver and keep track of how many steps are remaining the planner block being executed. If a feed rate override occurs, the line segment manager would place a lock on the block to a future point in time, where the planner is guaranteed to start and finish re-calculating a new plan with the overridden feed rate beyond that future point. During which, the line segment manager will continue executing the locked portion of the block and when reaching the lock point, the line segment manager will begin executing the newly planned portion of the buffer. This can get very complicated, very quickly. So I'm open to alternative ideas on how to implement feed overrides in real-time.

  • The current thought on setting the direction pins before beginning the step generation part of a block is to do it upon the loading of the block. We just need to make sure that the direction pin can be set almost immediately after the first edge of the last step in the previous block. This is because the stepper driver pre-loads motions.

Sources

Add a custom footer
Add a custom sidebar
Clone this wiki locally