In the past years, the development of filament-based 3D printers (short FDM) was driven by technical enthusiasts to an impressive technology. Despite dealing with the limitations of 8-bit AVR controllers, the community was able to develop a CNC like path-controlled motor control using stepper motors in nearly all of the designs.
To bridge the chasm between technical enthusiasts and mainstream users, the technology now has to overcome several restrictions of existing designs and become accessible to the consumer market.
As the majority of the printers is desktop-sized and will be located close to or on top of the operator’s desk, which in the future will no longer be in a lab, garage, or the maker’s cellar, one of the main objectives is to reduce noise. The primary source of noise in the printer is the motors positioning the print bed, the print head, and the extruder itself. Therefore, the best way to reduce acoustic emissions is to reduce resonances and mechanical vibrations by increasing the microstep resolution. As a positive side effect, less mechanical vibrations will also optimize the quality of the print.
The second main objective of current designs is to increase the speed of printing, requiring higher step frequencies. As these step frequencies are still generated by the microcontroller, the maximum step rate nowadays is limited by the highest timer interrupt rate achievable.
This paper provides an overview of different concepts of step pulse generation and a way to achieve both objectives without increasing MCU size and cost, by making use of dedicated motion control peripherals integrated in today’s stepper motor controllers.
Background
Typical FDM-type 3D printer firmware on the market for open source solutions uses a principle of operation that’s very similar to the principle used by closed source commercial solutions – a central MCU handles communication on a USB or UART port, reads data from a memory card, in some cases controls a display for status information and controls 4 or more stepper motor driver ICs. The typical interface to these drivers is step and direction. The motor driver IC calculates microstep currents and controls and drives the motor current directly.
In a 3D printing application, at least the 3 axes must be path-controlled: X, Y, and extruder. This means the motors must be synchronized. Not only for the target positions but for every coordinate in a motion segment. All coordinated axes must be calculated and controlled closely at the same time and step pulses for all of those have to be generated synchronously – so the maximum interrupt frequency limits the highest achievable pulse rate and indirectly the highest achievable printer speed.
Challenges with software-based step pulse generation
Generating step pulses using a fixed interrupt frequency falls apart in two cases:
- fstep < finterrupt but close to finterrupt
- fstep > finterrupt
Case 1: fstep < finterrupt
Generating a step pulse frequency from a fixed frequency timer that does not divide the desired frequency without remainder causes a beat as shown in Fig. 3. Thus, the actual step frequency generated by this solution changes all the time. As the step frequency translates into the commanded motor velocity, this results in continuous accelerations and decelerations, requiring additional torque.
Velocity error
Depending on the ratio of fstep to finterrupt, the absolute timing error (Terror) is between a minimum of 0 – in case the interrupt period (Tinterrupt) divides the commanded step period (Tinterrupt) without remainder – and a maximum of just below Tinterrupt.
With a step width of the resulting velocity is:
And the commanded velocity:
The relative velocity error results in:
With a maximum error of:
The absolute velocity error will tend to:
Assuming an achievable interrupt frequency of e.g. , the maximum timing error will be in the range of 1ms.
Case 2: fstep > finterrupt
As with an interrupt frequency of 1 ... 3kHz, the maximum step pulse rate is quite limited and does not allow for high speed and medium to high microstep resolutions. To overcome this limitation the software solutions use a concept that is called “double step”. If the intended step frequency is higher than the interrupt frequency, multiple step pulses are generated in one interrupt service routine, resulting in a short sequence of steps with a fixed frequency at the beginning of this routine with a following break until the next interrupt service routine starts.
Separating calculation and execution
As an alternative to software-based solutions, pulse and ramp generation can also be generated by dedicated peripherals such as external ramp generators.
Firmware design considerations and implementation using the TMC5130 cDriver
To offload the pulse generation to a component with a dedicated ramp controller, the microcontroller has to precalculate the parameters of the ramps of all coordinated axes before the segment can be executed. All whilst the peripheral component takes care of the real-time task of executing the actual ramps and generating the high-frequency step pulses.
In this case, the microcontroller has to take care of the following precalculations:
Acceleration phase:
Plateau:
Deceleration phase:
The only time critical operation left in the microcontroller is to start the new segment just before the last segment finishes.
At t1, the processor has to write the acceleration in Amax and Dmax registers, the initial, maximum and final speeds in Vstart, Vmax and Vstop, and finally the final position into Xtarget. The timer must be set here to the sum of the three movement phases.
Timing considerations
Timing for the next ramp segment can be generated in two different ways.
Starting the ramp segment with a timer interrupt
As the expected ramp times have been calculated in preparation to the movement, (t1 + t2 + t3 + t4), this information can easily be used to preload a timer interrupt to trigger the transmission of the next segment. Since this interrupt only occurs once per segment, the overall timer interrupt load is reduced by the segment length.
Making use of the position interrupt output of the TMC5130 ramp controller
By loading the X_COMPARE register of one of the ramp controllers with a value of a few microsteps lower than the target position of the segment, the controller will issue a position-reached interrupt at SWP_DIAG1. This will leave enough time to safely update all motion controllers with the next segment so the next motion segment will start during the deceleration ramps.
When the motion controller receives the new target position in time before the last segment is finished, it will automatically take care of the transition from one segment to the following. This allows for a timing-uncertainty of a few microsteps without influencing print quality.
Concern: time lags caused by serial commanding several axes via SPI
A potential time lag between the updated data of the different motion controllers will be in the microseconds range. Even for high step-frequencies like 256 microsteps per full step, this results in less than one microstep latency. It could also be pre-compensated for, as the time sequence of the SPI transfers is well-known.
Programming a register within the TMC5xxx family driver requires 40 SPI bits to be sent. Assuming a 4mHz SPI rate, which is well below the limit of the IC, this will require about , which is well below the median error achieved by step direction calculations and does not accumulate.
This way, several ICs and parameters can quickly be set and the delay between the axes to the different controllers is negligible. It even can be compensated for by software. As an option, to achieve a real zero delay, all drivers can be put into a single SPI chain. However, this will require an n-times 40-bit SPI datagram to be sent for each access, even when accessing only one single driver.
Implementation using TMC5130 cDriver
See Application Note 046 - Adapting step/dir CNC firmware for ramp generators.
Conclusion
Making use of dedicated ramp controllers can reduce the MCU load, improve print quality and make your printer faster and more silent with no additional components required and at no additional or even lower cost than systems with comparable performance.
Using dedicated ramp controllers solves technical restrictions such as vibrations and speed limitations, and reduces software design risks and development time. Technical products usually enjoy several firmware updates and development steps during their lifecycle, so the same reduction in design and test efforts applies to all future releases as well, reducing the total cost of ownership significantly.