<p>By avoiding pin 3 entirely, the Z-axis steppers have started to move correctly. My bed heater went out a while ago, so I redefined the connections in Marlin to use that pin (pin 12) as the Z-step pin, connecting it to the A4988 accordingly. This has caused no issues other than small noise problems so far. Unfortunately, I can't speak to any potential issues pin 3 may have had to cause this behavior, all I have is this one potential solution.</p>

CC BY-SA 4.0
2021-02-14T02:47:42.570Z
2021-02-14T02:47:42.570Z
malachik
<p>I was replacing a stepper driver on my Melzi 2.0 board with a A4988 Pololu module and for some reason, it won't cooperate with Marlin.</p>
<p>For reference, I'm using a Melzi 2.0 TRONXY with a ZONESTAR-style 5-button LCD. This LCD may be related to my problem. I'm using a custom configuration of Marlin 2.0.x since I replaced the main board and it's been giving me a lot of problems.</p>
<p>When testing the printer with an Arduino sketch, the Z-axis moves flawlessly. However, when I uploaded my Marlin configuration, the printer once again refused to move. Upon probing the Step and Direction pins with my oscilloscope, I found what I think is the problem. I was giving step commands from the LCD and from Pronterface when I saw this on the Z-Step pin:</p>
<p><a href="https://i.sstatic.net/88fD2.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/88fD2.jpg" alt="A shot of my oscilloscope showing step pulses ~5 us long" /></a></p>
<p>Apologies for the blurry picture. The timescale is 20 μs/square and the voltage is 1V/square. What I'm supposed to see is a series of discrete 5 V pulses that tell the stepper to move, but what I got was a handful of tiny ~5 μs blips instead.</p>
<p>What I've taken this to mean is that the pin (digital 3, for those curious) is being set to pulse by the step request, but is being reset by something else. Everything points to the firmware as far as I can tell. Again, I've confirmed that the 1284p, the A4988, and the motor itself all work when programmed correctly with an Arduino sketch. I've also tried swapping the pin definitions for Step and Direction (switched <code>2</code> and <code>3</code>), but I had the same problem.</p>
<p>A possible cause for this I think could be my LCD: It requires the user to define an analog pin for reading the buttons (a quirk of the LCD design). In my pins_MELZI_TRONXY.h and pins_SANGUINOLOLU_11.h files, Marlin defaults to using <code>#define ADC_KEYPAD_PIN  1</code> (analog pin 1) with the <code>ZONESTAR_LCD</code> selected. On the 1284p, pin 3 (the Z-Step pin) is also listed as <code>AIN1</code>. On the <a href="https://reprap.org/mediawiki/images/6/6f/Melzi-pcb.png" rel="nofollow noreferrer">PCB layout</a> for the Melzi 2.0, this pin isn't connected to the 10-pin LCD header. The pin the LCD is actually using is the <code>A1</code> header pin, which goes to <code>PA1</code>/<code>ADC1</code> on the 1284p.  But perhaps this definition has caused some confusion in the firmware?</p>
<p>To be clear, the relevant parts of my firmware look like this:</p>
<pre><code>#define ADC_KEYPAD_PIN                     1
        //from pins_SANGUINOLOLU_11.h, which is - as far as I know - the only place this is defined.

#define LCD_PINS_RS                           28 //RS           28
#define LCD_PINS_ENABLE                       29 //EN           29
#define LCD_PINS_D4                           10 //D4 -&gt; RX1 -&gt; 10      
#define LCD_PINS_D5                           11 //D5 -&gt; TX1 -&gt; 11     
#define LCD_PINS_D6                           16 //D6 -&gt; SCL -&gt; 16
#define LCD_PINS_D7                           17 //D7 -&gt; SDA -&gt; 17
        //the rest of the LCD pin definitions from pins_MELZI_TRONXY.h

#define Z_STEP_PIN                             3 
#define Z_DIR_PIN                              2
        //my Z-stepper settings from pins_SANGUINOLOLU_11.h, which I'm pretty sure is normal for all Melzi boards
</code></pre>
<p>If anyone can provide any insight into this, it would be hugely appreciated! I'm very new to 3D printer configuration and repair, so I'll gladly take any help you can provide!</p>

CC BY-SA 4.0
2021-02-12T07:13:41.250Z
Not that I could help here, but does it work with LCD disabled? (You can send G-code commands via serial terminal, can't you?) Why did you have to redefine anything in "pins.h", when "pins_SANGUINOLOLU_11.h" already contain section dedicated to MELZI boards: `// LCD / Controller` `#if HAS_WIRED_LCD` `#define SD_DETECT_PIN -1` `#if HAS_MARLINUI_U8GLIB` `#if ENABLED(LCD_FOR_MELZI)` (and so on) ?
octopus8
CC BY-SA 4.0
2021-02-13T03:38:02.460Z
@octopus8 What I meant by "my pins.h files" was the "pins_MELZI.../pins_SANGUINOLOLU...h" files, sorry for the confusion. I edited the post for clarity. On the other note, I have tried operating it with `ADC_KEYPAD_PIN` disabled and it didn't appear to behave any differently, but I'll try disabling the LCD if nothing else works.
malachik
CC BY-SA 4.0
2021-02-13T10:06:35.083Z
You might actually be seeing intended behavior. A 5uS blip is not technically out-of-spec. The A4988 datasheet lists a minimum pulse duration of 1uS. The `MINIMUM_STEPPER_PULSE` is configured in Conditionals_adv.h and equal 1uS for the A4988. You could try increasing this value.
Tom van der Zanden
<marlin><z-axis><stepper-driver><lcd-screen>
Z-step pulses too short (Marlin 2.0.x)
malachik
# Z-step pulses too short (Marlin 2.0.x)

(Asked by: username_0 on 2021-02-12)

I was replacing a stepper driver on my Melzi 2.0 board with a A4988 Pololu module and for some reason, it won't cooperate with Marlin.
For reference, I'm using a Melzi 2.0 TRONXY with a ZONESTAR-style 5-button LCD. This LCD may be related to my problem. I'm using a custom configuration of Marlin 2.0.x since I replaced the main board and it's been giving me a lot of problems.
When testing the printer with an Arduino sketch, the Z-axis moves flawlessly. However, when I uploaded my Marlin configuration, the printer once again refused to move. Upon probing the Step and Direction pins with my oscilloscope, I found what I think is the problem. I was giving step commands from the LCD and from Pronterface when I saw this on the Z-Step pin:

Apologies for the blurry picture. The timescale is 20 μs/square and the voltage is 1V/square. What I'm supposed to see is a series of discrete 5 V pulses that tell the stepper to move, but what I got was a handful of tiny ~5 μs blips instead.
What I've taken this to mean is that the pin (digital 3, for those curious) is being set to pulse by the step request, but is being reset by something else. Everything points to the firmware as far as I can tell. Again, I've confirmed that the 1284p, the A4988, and the motor itself all work when programmed correctly with an Arduino sketch. I've also tried swapping the pin definitions for Step and Direction (switched 2 and 3), but I had the same problem.
A possible cause for this I think could be my LCD: It requires the user to define an analog pin for reading the buttons (a quirk of the LCD design). In my pins_MELZI_TRONXY.h and pins_SANGUINOLOLU_11.h files, Marlin defaults to using #define ADC_KEYPAD_PIN  1 (analog pin 1) with the ZONESTAR_LCD selected. On the 1284p, pin 3 (the Z-Step pin) is also listed as AIN1. On the PCB layout for the Melzi 2.0, this pin isn't connected to the 10-pin LCD header. The pin the LCD is actually using is the A1 header pin, which goes to PA1/ADC1 on the 1284p.  But perhaps this definition has caused some confusion in the firmware?
To be clear, the relevant parts of my firmware look like this:
#define ADC_KEYPAD_PIN                     1
        //from pins_SANGUINOLOLU_11.h, which is - as far as I know - the only place this is defined.

#define LCD_PINS_RS                           28 //RS           28
#define LCD_PINS_ENABLE                       29 //EN           29
#define LCD_PINS_D4                           10 //D4 -> RX1 -> 10      
#define LCD_PINS_D5                           11 //D5 -> TX1 -> 11     
#define LCD_PINS_D6                           16 //D6 -> SCL -> 16
#define LCD_PINS_D7                           17 //D7 -> SDA -> 17
        //the rest of the LCD pin definitions from pins_MELZI_TRONXY.h

#define Z_STEP_PIN                             3 
#define Z_DIR_PIN                              2
        //my Z-stepper settings from pins_SANGUINOLOLU_11.h, which I'm pretty sure is normal for all Melzi boards

If anyone can provide any insight into this, it would be hugely appreciated! I'm very new to 3D printer configuration and repair, so I'll gladly take any help you can provide!

**Tags:** marlin, z-axis, stepper-driver, lcd-screen
> **Comments:**
> **username_1**: Not that I could help here, but does it work with LCD disabled? (You can send G-code commands via serial terminal, can't you?) Why did you have to redefine anything in "pins.h", when "pins_SANGUINOLOLU_11.h" already contain section dedicated to MELZI boards: `// LCD / Controller` `#if HAS_WIRED_LCD` `#define SD_DETECT_PIN -1` `#if HAS_MARLINUI_U8GLIB` `#if ENABLED(LCD_FOR_MELZI)` (and so on) ?  
> **username_0**: @octopus8 What I meant by "my pins.h files" was the "pins_MELZI.../pins_SANGUINOLOLU...h" files, sorry for the confusion. I edited the post for clarity. On the other note, I have tried operating it with `ADC_KEYPAD_PIN` disabled and it didn't appear to behave any differently, but I'll try disabling the LCD if nothing else works.  
> **username_2**: You might actually be seeing intended behavior. A 5uS blip is not technically out-of-spec. The A4988 datasheet lists a minimum pulse duration of 1uS. The `MINIMUM_STEPPER_PULSE` is configured in Conditionals_adv.h and equal 1uS for the A4988. You could try increasing this value.  

---

## 1 answers

### Answer by username_0 on 2021-02-14. Score: 1

By avoiding pin 3 entirely, the Z-axis steppers have started to move correctly. My bed heater went out a while ago, so I redefined the connections in Marlin to use that pin (pin 12) as the Z-step pin, connecting it to the A4988 accordingly. This has caused no issues other than small noise problems so far. Unfortunately, I can't speak to any potential issues pin 3 may have had to cause this behavior, all I have is this one potential solution.


---

