External driver: constant step lost

Printer: custom built
Board: 5XC
External Drivers: Leadshine M542
Firmware: 30 Nov 2018 (downloaded today)

Symptom : the printed object appears skewed (leaning toward -Y) and won’t touch endstops after a G0 X0 Y0 after a print.
Resisting with hand had no effect (not power/mechanical issues), no weird noise.

The M542 manual states that the DIR sig must change ahead of STEP pulse by at least 5us (0.4us for A5984), I don’t know what how Smoothie does this but I’m guessing this is the cause. Can anyone help me fix?

….What method you use to attach photo?

edit: probably related to this …/forum/t-8682295/new-smoothieboard-5xc-fault (can’t post a link yet)

Imported from wikidot

Replaced Y-axis driver with a Leadshine DM556 and it’s now just slightly leaning toward +X and Y-motors are completely silent
Confirmed to be driver related

Now which driver should I buy?
FYI: I’m using dual NEMA17 on X-Y at 1.2Amp * 2

I had the same problem, and I tried to get help, but I was not able to solve the problem

First I had this problem with the RE-ARM for RAMPS board, then I changed to Smoothieboard 5X, and I still had the same problem. Now finally I switched to Duet WiFi, and I STILL had the same problem with external drivers, finally I got the Duet expansion board, so now I have 10 internal motor drivers, and FINALLY I got my printer to work properly.

I have spent way too much money than I should have to, Smoothieboard (Re-ARM and Duet) should fix this issue!!
So Duet has the same problem with external drivers, but it worked with the Duex expansion board since it’s basically the same as having internal drivers. Also note that the Duet drivers are 2.4 amps, and you don’t need to connect motors in series, just connect each motor to it’s own driver, and you can map the motors drivers for each axis in the config with G code. I have 4 motors for Z axis, 2 for Y axis, 1 for X axis, and 3 for extruders, so I am using all the drivers on the Duet + Duex

The external motor drivers that I tried to use are for CNC similar to TB6600, and they worked fine when I used them on with Arduino + RAMPS. I just connected the wires (direction, step, enable) to the pins on the RAMPS board, and I didn’t have shifting problem, it ran fine for 6 months. But I wanted to upgrade to a 32 bit board.

I will use my Smoothieboard on a small 3D printer that does not require external drivers / beefy motors

TLDR - The ND556 drivers are rubbish - I changed to DRV8825’s which can handle 2A @ 40V which is what I wanted all along, although they run noisier than the ND556s

I’ve just discovered that I have the same problem. (after a year of ‘fixing’ everything else on this printer - motors replaced three times, power supply twice, leadscrew nuts, bearing blocks; and changing voltage/current/microstepping/acceleration/junction deviation/speed etc etc etc)

I’m using the Leadshine ND556 drivers to drive my leadscrew driven delta printer and have been having this missed step/drift problem for ages. The severity has changed from day to day and is very dependant on the g-code. Some programs, even large ones (like vases) print OK, but others would be unprintable, with individual layers being shifted up to 1mm from the layer below, with somewhat random shifting, but always with a general drift in one direction.

I have (I think) narrowed it down to 3 possibilities:

(1) Driver itself misses steps (My old, cheap external drivers, HY-DIV268N-5A, are known to be crappy and miss steps, according to google). The ND556 drivers are not cheap though, so I doubt this is the problem.

(2) Timing between DIR change and next STEP from smoothieware. In the edge source code, in StepTicker.cpp, in bool StepTicker::start_next_block(), there is a comment:

        // set direction bit here
        // NOTE this would be at least **10us** before first step pulse.
        // TODO does this need to be done sooner, if so how without delaying next tick

This suggests that this timing should be fine. The driver documentation specifies a 5us gap required between DIR change and next STEP. The question is, is that what smoothie actually does? Has anyone ever put a scope on it? Unfortunately I don’t have a dual channel DSO.

or:

(3) CMOS to TTL(actually optoisolator) level problem. The smoothieboard STP and DIR signals are 3V, measured at the driver. I guess there is a 0.3V drop somewhere, because the LPC1769 runs at 3.3V (This may because we are sourcing more than the 4ma spec on the io pin). The ND556 documentation specifies a 4 to 5V input requirement, and a 7ma minimum current for signal input. It could be that because the driver is receiving a lower voltage (and possibly lower current) input than specified, it is taking time for capacitance/opto isolation at the driver input to be overcome and this is creating timing anomalies every now and then between DIR and STP. The LPC1769 can source only 4ma (while staying within 0.4V of VDD) Further research shows that the ND556 uses a 6n137 opto isolator, with a 270 ohm series resistor between the screw connector and the 6n137 pin. The 6n137 input capacitance is 55pf. With a 3V input, plus 270 ohm resistor, this seems like (without actually doing the math) it would be the lower limits of what the optoisolator is happy with (switching time of max 0.1us is specified at 5V/7ma so who knows what at 3V/4ma, maybe leading to this problem where things work mostly OK but not 100%)
Of course this would also be fairly easy to test by using a level converter, which I would do right away if I hadn’t already removed the drivers and tried to go back to DRV8825 drivers (which are really noisy and not quite up to the voltage/current levels I need)

In terms of information available, the problem seems likely to be #3, because directly connecting STP and DIR from the smoothie to the Leadshine driver is not satisfying the driver specs, whereas according to the comments in the smoothie source code, the timing between DIR and STP is within the driver’s spec.

Mike, can you comment on this? Did you use a logic level shifter at all? I thought maybe the reason your external drivers worked with the Arduino RAMPS setup was because that is 5V?

EDIT 11 March 2019
I can confirm that by switching back to DRV8825 drivers, the problem is resolved. They make the motors incredibly noisy (whereas the ND556 were nearly silent) and need a noisy fan to cool the drivers, so my very quiet printer has become unbearably noisy! My logic level shifters have arrived, so next project is to try them with the ND556s and see if that works.

EDIT 13 March 2019
So after looking closer at how the Sparkfun level shifters work, I decided they probably won’t help with an opto isolators inputs, which need current to light the LED (the level shifters connect the 5V supply through a 10k resistor, leaving a max 0.5ma). I’ve instead ordered SN54HCT245 buffers which can source sufficient current at 5V to switch on the LEDs nice and quick, plus have around 15ns switching time)

The other thing I just noticed in the Smoothie documentation is the suggestion to use common anode connection and set the output pins to open drain, and hooking up the inputs on the driver to a 5V pin on the main board. So I will try that first.

14 March
Tried common anode setup, didn’t help. Was getting around 4.5v to the ND556, so that should theoretically have solved any LC problems I was imagining it could be.

Now I’m fairly sure this has to be a DIR/STEP timing problem in Smoothie firmware - I don’t think the source code comment about 10us is correct. If only I had a 2 channel DSO …

Either that or there is something wrong with my ND556s.

15 March
I discovered that Duet3d dot com sell a special breakout board with 75ALS192 ic’s specially for driving external drivers and they mention Leadshine ND556 by name, so I will try that next … that should reliably eliminate the possibility of level problems between the LPC1769 and the optoisolators on the ND556. If that board doesn’t work, I can move on from this idea and onto …

Trying different firmware on this board, and finally,

Different external drivers.

A whole new motherboard etc…. (if I get this far, I’m just going to go the expensive route and get a Duet)

27 March 2019
I tried the SN74HCT245N to bump up the voltage to the external drivers, and they do their job, but the problem remains.
I also tried lengthening the step pulse in the config to 5us, and it didn’t help.
I’m now 99% sure Smoothie is outputting Step too soon after Dir change, but I’m patiently waiting for the logic analyzer I ordered to arrive before I can 100% confirm. (I’m 1% sure my Leadshine drivers are duds)

I’ve been trying Klipper in the meantime, and the same problem occurs, although the general drift of errors seems to be in a different direction.

31 March 2019 - Conclusion
So I’ve concluded there is something wrong with the ND556 drivers. I tried Klipper firmware and Kevin confirmed that the delay between DIR and next STEP wouldn’t be less than the STEP pulse, which I set at 15us. I took some short captures with my el cheapo logic analyzer which confirmed that because of acceleration, the time between a DIR change and next step is huge, never anywhere near the 5us minimum for the driver.

Incidentally, I also tried (at various times over the last 12 months or so of troubleshooting this problem) inverting the STEP pin in config, just in case, because e.g. when I tried common anode connection, of course the pins needed inverting. I can confirm if the STEP pin is improperly inverted, you get very badly shifted layers, but that is not the problem I’ve been having!

I left everything the same and just swapped the drivers for DRV8825s and it works fine. I added large heatsinks top and bottom of the stepstick boards and cool them with a large fan, and so far they seem to be up to the task, so I’m giving up on the external drivers.

One thing I did notice with the Klipper firmware was as I increased the length of the step pulse (initially 2us, then 5, 8 and finally 15) the print improved, so I don’t quite know what to make of that. Maybe the longer the pulse is kept high, any induced noise isn’t going to create a rising edge because its already high? Anyway, time to move on ….