<p>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.</p>
<p>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.</p>
<p>Checking datasheets for a few stepper drivers, apparently <strong>the direction pin is sampled once at the beginning of each step</strong>:</p>
<p><img src="https://i.sstatic.net/IYTxC5vW.png" alt="" /></p>
<p>The specified minimum signal times differ:</p>
<div class="s-table-container"><table class="s-table">
<thead>
<tr>
<th>Driver</th>
<th>Step high</th>
<th>Step low</th>
<th>Dir setup</th>
<th>Dir hold</th>
</tr>
</thead>
<tbody>
<tr>
<td>A4988</td>
<td>1000 ns</td>
<td>1000 ns</td>
<td>200 ns</td>
<td>200 ns</td>
</tr>
<tr>
<td>DRV8825</td>
<td>1900 ns</td>
<td>1900 ns</td>
<td>650 ns</td>
<td>650 ns</td>
</tr>
<tr>
<td>TMC2208/9</td>
<td>100 ns</td>
<td>100 ns</td>
<td>20 ns</td>
<td>20 ns</td>
</tr>
</tbody>
</table></div>
<p>I do not know if &quot;bus capacitance&quot; 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.</p>
<p>I looked at the source code for <em>Teacup</em> and it appears the macros to write out the direction and step of each motor are isolated in one place (<code>pinio.h</code>), so the changes to insert the hack will hopefully be minimal.</p>
<p>This is great because it gives me 3 bonus MCU pins.</p>

CC BY-SA 4.0
2024-09-03T03:16:35.763Z
2024-09-03T14:04:59.833Z
2024-09-03T14:04:59.833Z
Boann
<h2>No, you loose access to normal slicers</h2>
<p>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 <code>(0,0)</code>, <code>(1,1)</code>, <code>(2,0)</code></p>
<p>For that, we can use the following code block:</p>
<pre><code>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)
</code></pre>
<p>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 <em>sign</em> of the movement order. As the simple example above shows, those two <strong>absolutely need</strong> to be independent to allow any movement in which one of the X-Y coordinates reduces while the other increases.</p>
<p>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 <em>also</em> 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.</p>

CC BY-SA 4.0
2024-09-01T19:45:41.930Z
But why would that stop me stair-stepping?
Boann
CC BY-SA 4.0
2024-09-01T19:49:44.410Z
@Boann Lines are operated *one after another*, and slicers don't stair-step, but try to accomplish a code *as short as possible*. They see a wall over `1,1` to `2,0` and order a movement of `(+1,-1)`, not 1000 lines of stairstepping. You'd require a custom slicer to achieve that.
Trish
CC BY-SA 4.0
2024-09-01T19:57:31.190Z
I don't see why a slicer stops me stair-stepping, so long as the driver chips don't get in a tangle.
Boann
CC BY-SA 4.0
2024-09-01T20:01:28.533Z
the slicer is what creates the G-code. The chip then executes the code **as written**. But simply tying the direction of the pins together will result in a a movement to either `(0,0)` or to `(2,2)`, depending if the sign of the 1st or 2nd coordinate is followed. The chip on the board just turns the command into what accounts to "X: turn 42 clockwise, Y: turn 42 anti-clockwise".
Trish
CC BY-SA 4.0
2024-09-02T17:58:48.820Z
If you have 2 Z stepper motors doing exactly the same this should be possible. The slicer doesn't know there are 2 Z steppers commanded to move. I image that this is a theoretical question, it lacks a good example.
0scar
CC BY-SA 4.0
2024-09-02T22:21:24.227Z
OP's problem has nothing to do with the slicer. There's no reason the direction pin for a given motor should be constant throughout an entire gcode move. In fact, on a delta machine, it generally won't be - any move crossing a midline will have at least one of the axes reverse direction during the move. The problem is entirely at the firmware/motion-planning layer, and if the firmware can handle switching direction pin between steps for different motors, it should work.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2024-09-01T19:33:20.457Z
2024-09-02T18:13:26.030Z
2024-09-02T18:13:26.030Z
Trish
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2024-09-02T22:19:07.243Z
2024-09-02T22:19:07.243Z
R.. GitHub STOP HELPING ICE
<p>I am building a 3D printer. I was wondering if, instead of running individual <strong>step</strong> and <strong>direction</strong> 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.</p>
<p>This will free some precious pins on the microcontroller for other uses.</p>
<p>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.</p>
<p>Can anyone more experienced with this lend me their wisdom?</p>

<electronics><stepper-driver>
Is it viable to link stepper motor direction pins?
Boann
# Is it viable to link stepper motor direction pins?

(Asked by: username_0 on 2024-09-01)

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?

**Tags:** electronics, stepper-driver


---

## 3 answers

### Answer by username_3 on 2024-09-02. Score: 3 | Accepted answer

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 by username_0 on 2024-09-03. Score: 3

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**:

![](https://i.sstatic.net/IYTxC5vW.png)

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 by username_1 on 2024-09-01. Score: 0

## 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.

> **Comments:**
> **username_0**: But why would that stop me stair-stepping?  
> **username_1**: @username_0 Lines are operated *one after another*, and slicers don't stair-step, but try to accomplish a code *as short as possible*. They see a wall over `1,1` to `2,0` and order a movement of `(+1,-1)`, not 1000 lines of stairstepping. You'd require a custom slicer to achieve that.  
> **username_0**: I don't see why a slicer stops me stair-stepping, so long as the driver chips don't get in a tangle.  
> **username_1**: the slicer is what creates the G-code. The chip then executes the code **as written**. But simply tying the direction of the pins together will result in a a movement to either `(0,0)` or to `(2,2)`, depending if the sign of the 1st or 2nd coordinate is followed. The chip on the board just turns the command into what accounts to "X: turn 42 clockwise, Y: turn 42 anti-clockwise".  
> **username_2**: If you have 2 Z stepper motors doing exactly the same this should be possible. The slicer doesn't know there are 2 Z steppers commanded to move. I image that this is a theoretical question, it lacks a good example.  
> **username_3**: OP's problem has nothing to do with the slicer. There's no reason the direction pin for a given motor should be constant throughout an entire gcode move. In fact, on a delta machine, it generally won't be - any move crossing a midline will have at least one of the axes reverse direction during the move. The problem is entirely at the firmware/motion-planning layer, and if the firmware can handle switching direction pin between steps for different motors, it should work.  

---

