Is it viable to link stepper motor direction pins?

Question

I am building a 3D printer. I was wondering if, instead of running individual step and direction lines to each stepper motor driver, it was viable to link all the direction pins together and simply set the global direction immediately as I pulse each step line.

This will free some precious pins on the microcontroller for other uses.

However, maybe this won't work. Maybe drivers get confused if the direction changes mid-step. Maybe the software changes won't be easy. Maybe the motors need to move precisely in unison. I have no idea.

Can anyone more experienced with this lend me their wisdom?

Answer 1

In principle I think this may work, but I'm not sure if any of the existing firmware is prepared to use a shared direction pin. If not, you may need to make minor changes that amount to virtualizing the direction pin and copying the current motor's virtual direction pin value to the actual direction pin each time a step is issued.

One caveat that may be a show-stopper is if the direction pin needs to remain constant for the entire step pulse direction, which would not work if you need to make a step on a second motor before the pulse is finshed in the first. But I would not expect this to be the case. My expectation would be that the direction pin value is sampled on the edge of the step pulse and ignored after that. Checking whether that's the case would require either experimentation or digging up data sheets.

Answer 2

I haven't really built the printer yet or got all the hardware, but I rigged up a minimal test with 2 drivers and 2 motors.

It seems to work absolutely fine. I set the single shared direction pin before pulsing each step pin and can spin the motors simultaneously in the same or opposite directions.

Checking datasheets for a few stepper drivers, apparently the direction pin is sampled once at the beginning of each step:

The specified minimum signal times differ:

Driver	Step high	Step low	Dir setup	Dir hold
A4988	1000 ns	1000 ns	200 ns	200 ns
DRV8825	1900 ns	1900 ns	650 ns	650 ns
TMC2208/9	100 ns	100 ns	20 ns	20 ns

I do not know if "bus capacitance" could be an issue at this sort of frequency, but that would make the minimum times longer. Each direct write to the port registers of the 16 MHz Arduino Nano I'm using takes a minimum of 2 cycles = 125 ns. With some hardware setups, there will definitely need to be an inserted delay between setting the direction and pulsing step, although my TMC drivers seem quite happy with no added delay, so the motors still step (effectively) in unison.

I looked at the source code for Teacup and it appears the macros to write out the direction and step of each motor are isolated in one place (pinio.h), so the changes to insert the hack will hopefully be minimal.

This is great because it gives me 3 bonus MCU pins.

Answer 3

No, you loose access to normal slicers

A 3D Printer creates 3D objects by layering 2D paths over one another. Let's say we want to print a triangle with the corner points (0,0), (1,1), (2,0)

For that, we can use the following code block:

G90 // absolute Mode
G0 X0 Y0 F1000 // goto origin
G91 // relative Mode
G1 X1 Y1 // go to (1,1)
G1 X1 Y-1 // go to (2,0)

There's a reason I used relative mode: THAT is how the commands to the motors are actually given. You send either a signal on the direction line, or not, and you do that because of the sign of the movement order. As the simple example above shows, those two absolutely need to be independent to allow any movement in which one of the X-Y coordinates reduces while the other increases.

Only if you also write the slicer to forbid any movement command with not-same sign you might manage to tie those. Custom writing the slicer behavior is not worth the freed-up pins. You also buy that little convenience at the price of speed: stair stepping also is notoriously slow, as you have many more lines executed one after another - instead of a simple 2 lines of code for the top of the triangle.