Trying to sort out the story around controlling stepper motors for a 3D printer.

3D Printing
, , , ,
1

Trying to sort out the story around controlling stepper motors for a 3D printer. I have not as yet run across any sort of a summary. So I will summarize what might be the story.

Continuing from:
https://plus.google.com/+PrestonBannister/posts/PAJw3wsYwaN

First, found one site that made the distinction between a stepper driver and a stepper controller.

A stepper driver is taking low-level signals (from the CPU usually in the case of a 3D printer) and bumping them up to the larger voltages and currents needed to directly drive a stepper motor. There is a one-to-one relationship between incoming signals and outgoing signals.

A stepper controller takes higher-level commands and sends a series of signals to the stepper motor, as is needed to complete the commanded action. There are quite a range in the features offered, and not clear commonality or consistency.

Unfortunately, in common usage the labels “controller” and “driver” seem to be almost interchangeable.

Second, in the first generation of small 3D printers (RepRap and the like), the printer’s CPU was serving as a stepper-controller, and directly driving the stepper-drivers. For the first generation(s) of printers, this worked well. More recently, as the printer’s CPU (usually 8-bit Arduino-based) is asked to do more things, there are complaints of insufficient CPU. There seems to be some(?) consensus that that Arduino platform is running out of headroom.

Third, we have an interesting variation in the BeagleBone series of boards. The ARM CPU is running Linux, and offloads the real-time signal input(?) and output to a co-processor optimized for the task. This should work very well at handling the real-time requirements of the stepper-drivers used in past for printers of the RepRap generation.

Fourth, there is a wildcard. Some of the newer very-inexpensive stepper-drivers are using I2C and accepting movement commands - in effect becoming basic stepper-controllers.

At this point things become a bit unclear as the documentation I have found is less than minimal.

If this is what it appears, then the implications are huge. Precise generation of step-movement signals is really the only aspect of 3D printers that require “hard” real-time software, and that requires a lot of processing in present printers. Remove this load and Arduino-based systems gain a bunch of headroom. Remove this load and the clever part of the BeagleBone boards goes mostly(?) unused.

At least the above is what I have found, so far. Insert the usual caveats.

2

@Alex_Skoruppa Iterating on the print-bed supports - and (of course) trying dubious things.

Used the last of the spool of blue Hatchbox PLA (unsatisfactory) and started using a spool of green PETG from Inland. Not getting especially good results with the PETG, but it might be a limitation of my printer. (Slow prints at the highest extruder temperature - in excess of what Inland recommends - are just barely passable.)

Iterations are counter-clockwise from the blue PLA (an incomplete print and upside-down). The longer runner seems to “grab” less, though friction is higher. PLA seems(?) to have less friction than PETG. Once assembled, will the plate joining the supports be rigid enough to keep the runners from rocking and grabbing? May want better materials (Delrin, Nylon, Igus) for the bearing surfaces in the final iteration, but trying simpler fabrication.

Also need to determine if I need one worm screw or two to drive the Z. Simpler would be preferable, if it works.

Iterating…

4d1489871befe117df6b711d2b5029ce.jpeg
4d1489871befe117df6b711d2b5029ce.jpeg3036×4048 2.76 MB

3

If each stepper had a controller, would it allow much easier implementation of sensor feedback real time print settings adjustment by a CPU working less and sending higher level signals to each controller? that would seem to be a good thing… ?

4

Both are stepper drivers. You are focusing too much on terminology and should instead be looking at requirements. A driver is something that takes a control signal and creates an output that is translated. It can be a single mosfet, or a complicated scheme that has feedback loops. Some drivers use a built in controller that handles different protocols or can take commands (there are a few that can handle acceleration and step generation).
In any case, an integrated stepper driver should at least include the generation logic and feedback loops. Some utilize external mosfets, but we don’t need that much power.

As for controlling the signals going to the stepper drivers, that’s whatever you like. You could use a 555 timer if you’re feeling frisky. In your case it looks like you want to use the raspberry pi. But whatever it is, it needs to be able to syncronize all of the steppers, and deterministically control the stepper and timing.

5

@Preston_Bannister nooooo.

Typical 3d printer steppers (bipolar hybrid steppers) have two coils that, when microstepped, are fed coarse sine wave current profiles 90 degrees out of phase from each other. The relative magnitudes of the coil currents is what determines the rotor angle within the four step sequence. That four step sequence repeats 50 times per rev for a total of 200 steps per rev.

The purpose of the stepper driver is to take a simple step/direction pulse input and do the necessary position indexing and coil current control functions to output appropriate motor coil currents.

There’s no meaningful difference between the term stepper controller and stepper driver.

Go read the datasheets for the A4988 and DRV8825 drivers and it will explain in great detail how those interfaces work.

6

@Ryan_Carlyle Yeh. I recall this sort of conversation the hardware folk before. :slight_smile: Different points of view on the same problem. Can take a while to converge.

Yes, I understand how stepper motors work, and how they are driven. The physics is simple. Never been confused on that.

There is at least one guy out there who wants to distinguish between stepper drivers and controllers. Go fight it out with them(?), I just want to make clear a point. I will use whatever term you want, as long as we keep clear a distinction.

The stepper-drivers like the ones you referenced are a royal pain in the ass from a software point of view. The one-to-one correspondence between input and output pushes the problem into the real-time domain. The one-to-one mapping is a killer.

After running across the Adafruit boards that used I2C, took a step back and searched more generally online for I2C stepper drivers. Found a bunch (especially on AliExpress) that … at least some of which seem to accept movement commands.

Maybe these are relatively new. Maybe the meager descriptions are misleading. (The AdaFruit boards seem to be using an I2C device meant for LEDs??)

The short version is I care about what the CPU sees.

If the CPU sees a device that accepts a single command for movement by a variable number of steps, that is a very different sort of device.

@Stephanie_A From my perspective as a software guy, it is completely absurd to feed one step at a time to a device. (Reminds me of programming the very early UARTs and hard disk controllers. That was the early 1980s.) Doing simple/fast/fixed repetitive stuff is more suited for hardware.

If these I2C stepper drivers are indeed accepting variable-movement commands (which is not clear), then that changes the problem quite a lot.

7

That’s why we’re saying it’s better to use a microcontroller. You gain a lot more control. You can program acceleration curves and handle complex timing issues like pressure compensation. The problem with current controllers is they need to calculate acceleration, bed levelling, and pressure compensation in real-time. These could be calculated off the controller. However it gets more complicated if you addin feedback loops like filament diameter sensors or location sensors.
Think of an inkjet printer where the driver handles translation of the print job into commands for the printer.
I2c can work but you need to be able to syncronize all of the drivers and handle priority interrupts like endstops and probes.

8

The part you are perhaps missing here is that the smarter stepper controllers that you are talking about are going to mean there is a microcontroller incorporated into it that deals with only one motor, compared with the current arduino situation where there is one big microcontroller communicating with a pile of slightly dumber stepper drivers. it all boils down to the same thing, there is a microcontroller doing the hard work, the only difference is cost. The cost differential between one big microcontroller, or a central cpu and a bunch of smaller microcontrollers.

9

An excerpt of interest:

" Contrast to the Grove - I2C motor driver V1.2, the V1.3 enables users to control the stepper motor more easily. You do not need to control the steppers all the time anymore, simply send a command to I2C motor driver V1.3 to drive a stepper motor, and it will act as your command, which would save your Arduino resource and simplify your code. "
http://wiki.seeed.cc/Grove-I2C_Motor_Driver_V1.3/

10

Also apparently of interest, from documentation for:

PCA9629A
Fm+ I2C-bus advanced stepper motor controller

" Output wave train is programmable using control registers. The control registers are programmed via the I2C-bus. Features built into the PCA9629A provide highly flexible control of stepper motor, off-load bus master/micro and significantly reduce I2C-bus traffic.

These include control of step size, number of steps per single command, number of actions from 1 to 255 or continuous rotations and direction of rotation. Re-start motor for new speed and operation without waiting for motor stop. A ramp-up on start and/or ramp-down on stop is also provided with re-enable ramp-up or ramp-down to change the ramp rate curve on the fly. "

11

@Preston_Bannister make sure its ramp function includes a pull-in mode with speed discontinuities. 3d printers need those to traverse corners without stopping.

12

@Justin_Mitchell As a point of comparison, hard disk controllers evolved through a series of steps:

  1. Single-sector read/write operations.
  2. Multiple-sector read/write operations.
  3. Command-queuing.
  4. Controller moved to the drive (IDE).

Familiar with (1) as I wrote the driver and diagnostics at Western Digital for the WD1002(?) board that went into the Pascal Microengine. First job out of college. When I got the driver working, my manager was very happy, and paraded me through a series of offices. I was confused and a bit embarrassed. Later learned I was the first guy to write a working driver for the WD chipset, aside from the original hardware designer - and I got about 3X better performance on nearly identical hardware. (Hardware folk are usually very bad at writing software, in my experience.)

The WD1003 was the original hard disk controller that went into the IBM PC/XT, is the first instance of (2), and the ancient ancestor all the mass-market hard disk controllers used in PCs. The WD1003 was a prototype in the downstairs lab when I was writing the above driver.

So I am acquainted with the tradeoffs. :slight_smile:

Of course, at present the 3D printer market is relatively tiny - more like the pre-PC era in the small computer market. The current landscape of technology choices is different.

And not.

Reading the Linux kernel code for I2C, there seems(?) to be some provision for command queuing. (Unclear, as yet, whether this works on a Raspberry Pi 3.)

Taken together, and once implemented, we might be up to the equivalent of the late-1990s, if in a different domain. :slight_smile:

13

@Ryan_Carlyle If in software I know how the physical device behaves, I can plan accordingly.

Not sure what you have in mind, but fairly sure I can live with simple linear deltas in the hardware.

My pain point is hardware that has to be spoon-feed one pulse at a time. That is not a good thing. A very simple controller in the peripheral adapter (for a stepper motor), can and should do the simple/fast/repetitive things.

We are right on the threshold of using more complex algorithms to drive 3D printing. Better to not have a CPU distracted by tick-tick operations needed to support over-simple hardware.

14

@Stephanie_A Just to be frisky, I had a digital speedometer on my bike in the late 1970s, hand built by a very able hardware guy around a 555 chip. (Helps when your father works at a giant R&D laboratory.)

A couple years later, in a lab course as a Physics student, it became obvious how that worked, with a magnet and a reed switch.

While tempted to design hardware to solve the problem at hand, my aim is to avoid that temptation. :slight_smile: