External drivers

I plan to use some 570 oz stepper motors on a vertical mill CNC conversion. I am trying to decide what stepper motor drivers to use. It seems that the DQ860MA Stepper Motor Driver is the only one that has been reported as working with the smoothieboard.

I am interested in trying the digital steppers from Automation Technology, specifically the KL-5056D driver, which people have been happy with for this purpose. Do these drivers have any advantages or disadvantages relative to the DQ860MA? Will they even work with the smoothieboard? I don’t really understand how these newer digital drivers work, for all I know it may be the same basic technology as the DQ860MA.

I am happy to pay a little more for the Automation Technology products in the anticipation of better customer support.

The current technology that people use for mill CNC conversions seems a bit nutty to me. They use the ethernet smooth stepper board to convert an ethernet signal to a parallel port in order to transmit the g-code from Mach 3/4 to the drivers. This seems circuitous compared to using a smoothieboard just to translate a g-code file, and much more expensive, but maybe I am missing some advantage that this other system offers.

Imported from wikidot

Hi,

I’ve tried the DQ860MA external steppers with the smoothieboard and they work without any problems so far.

vimeo.com / 115509540

In my opinion the KL-5056D should work as well.
In the kelinginc.net / KL-5056D.pdf , page 4 figure 3 you can see how you have to wire the drivers to the ST,DIR,EN and GND pins of the smothieboard. The internal resistors are 270Ohm and calculated for 5VDC signals, as far as i know the smoothieboard outputs only 3.3V, but for my DQ860MA that was not a problem, the optocouplers get only 8mA in this case but it seems to be enough to switch them.

Bouni

I plan to use some 570 oz stepper motors on a vertical mill CNC conversion. I am trying to decide what stepper motor drivers to use. It seems that the DQ860MA Stepper Motor Driver is the only one that has been reported as working with the smoothieboard.

Pretty much any external driver with a step/direction interface will work with Smoothieboard.

In some cases the driver will want 5V input, and Smoothieboard outputs 3.3V, but generally the drivers are fine with 3.3V even if rated at 5V. If 3.3V is not sufficent it’s trivial to use a level shifter to bump the 3.3V up to 5V.

So generally, the vast majority of external drivers work out of the box with Smoothieboard.

I personally use the CW5045 and am pretty happy with it.

I am interested in trying the digital steppers from Automation Technology, specifically the KL-5056D driver, which people have been happy with for this purpose. Do these drivers have any advantages or disadvantages relative to the DQ860MA? Will they even work with the smoothieboard?

Yes.
All of those drivers are very similar, and work with Smoothie.

Pretty much, if you read DIR+ DIR- EN+ EN- PUL+ PUL- on it, you know it’ll work with Smoothieboard.

The current technology that people use for mill CNC conversions seems a bit nutty to me. They use the ethernet smooth stepper board to convert an ethernet signal to a parallel port in order to transmit the g-code from Mach 3/4 to the drivers.

Yeah that’s just a relic of the 80s :slight_smile:

Smoothie is the modern way to do it :slight_smile:

I am using an ST5045/2M542 from Sain-Smart to drive a NEMA-23 stepper using the SmoothieBoard step/direction/enable signals. It works fine. I have also used a DM542 from China and it, too, worked fine. They seemed OK with smoothieboard’s default 1 us pulse duration, but the driver manuals specify 10 us minimum (in conflict with the max step rate spec as 300 ksps), so I set the smoothieware pulse duration to 3us to have just a little margin over the default 1 us.

The Sain-Smart ST5045 and DM542 appear to be the same thing, only slightly different- it’s one of those devices made by 20 different companies in China that are all more or less the same with tiny differences and all selling for about the same price. $35-40 in this case. Sain-smart calls it a 2M542, but their photos, their manual, and the part that arrives are labeled ST-M5045. You can find the same module selling all over ebay under 3 or 4 different part numbers, most containing a “542” somewhere.

I connected the ground of the driver module to the smoothie board ground (and the motor power supply ground), the - (negative/minus) inputs for step and direction on the driver module to ground, and then the + inputs for step/direction/and enable all went straight to the smoothieboard, no resistors required. I am running the motors from 32V supplies.

I would never compare Mach3/4 or LinuxCNC to Smoothie or any of the other grbl-based motion controllers.

Sure, it can execute a very small subset of g-code, but if you are spending more than a few thousand dollars on a machine the lack of features will really start to hurt.

If we just look at the basics, the existing grbl-based motion planner is lacking in many ways. You don’t have control over corner rounding/exact stop, and acceleration calculations are limited to what an 8-bit arduino can manage. If we go a step above that, there is no support for backlash compensation which is extremely useful for hobby conversions.

At the g-code level, huge chunks of functionality are missing. The biggest ommisions are canned cycles and radius compensation. You can work around this in CAM, but it can be annoying.

Mach3 will also provide full real-time backplots, accurate program run times, and a proper GUI interface for managing work/tool offsets. I don’t even know if smoothie has work/tool offesets which are absolutely critical for efficient production.

You can start or resume a program at any line and perform intelligent prepositioning to avoid crashes. You also get immediate feedrate and spindle speed override which is nice when you are learning the capabilities of a machine.

Mach3 provides many wizards, and even the free ones make a reasonably useful conversational system when combined with MDI. If you do any kind of prototyping or small one-off experimentation it is extremely clumsy to go into CAM for every part.

I’m sure you could use smoothie for a mill and be completely happy, but only because you don’t know what you are missing. I’ve used bare-bones motion controllers on a mill before, and it’s painful if you are not doing 100% of the work in CAM and getting everything right on the first run.

IMO Smoothie is the absolute best option for its intended application, but being productive on a mill needs a lot more. If the machine is just a sherline or small router table then a smoothie is fine.

Well I’ve never tried it but apparently you can use Mach3 to control a Smoothieboard :slight_smile:

Most of the G-codes you mention are related to writing G-code by hand.

That’s not something our users do, so there is no big pressure to implement those ( though some of them are being implemented, we have canning cycles somewhere in a separate branch for example I think ).

Smoothie expects the user to do everything in CAM, which is fine for probably all hobby users, and for some professional users at least.

You bring up some good points. My concern about the Mach3/4 -> ethernet smoothstepper -> stepper controller is that it is clearly something of a kludge and there should be a more rational and cheaper setup at this point. On the other hand, as you point out, the lack of backlash compensation and tool offsets is a problem and the conversational features make it easier to do hand/custom work.

The smoothstepper looks more complicated than it is. In reality it has just as many parts as a smoothieboard, and actually functions in a very similar way, especially if you are running a GUI Host. If you are streaming gcode to a smoothieboard it is actually near-identical. In both cases you have computer->board->machine.

The new smoothstepper uses ethernet instead of USB because you have a guarantee over message timing. USB starvation can occur with high performance motion controllers such as the KFlop.

There is actually no parallel port involved in a smoothstepper system, they simply break the pins out to a db25 connector instead of terminal blocks or header pins. The reason for this is mostly legacy, but its convenient when interfacing with many older servo drives and some commonly used components such as the g540.

OK. I had misunderstood the role of the smoothstepper. It is more sophisticated than I had understood.

So Arthur mentioned that generally any driver with, "DIR+ DIR- EN+ EN- PUL+ PUL- " will work with smoothieboard. I recently obtained smoothieboard V1.1 and this has been nothing but a headache.

I have 4 drivers — 2 Drivers are DM542 (some random seller on Ebay) and the other 2 are DM542T (from steppers online). DM542 cheap drivers work with the smoothieboard, but the DM542T does not. Why would this be the case? They’re identical drivers. The reason I bought DM542T’s was because when I bought the cheap ones, I purchased 4 of them and 2 of them were defective.

So now I am attempting to run this on DM542’s and DM542T’s,

Is there anything I can do to verify as to why they wouldn’t work? They both have identical connections on the drivers.

Both drivers are wired exactly the same - literally went over the connections 100 times, and everything looks right.

I also tested another motor and all motors work with DM542s but not DM542T’s

Hopefully all of this makes sense and would appreciate any help I can get.

A lot of chinese manufacturers sell drivers with those part numbers, so I don’t know what the T means, but they could be fairly different if they have come from different manufacturers.

It seems your DM542Ts may be duds. Do you have any way to verify they work at all? Have you tried manually stepping them (like connecting a button to the STP input?)

Is it possible the old drivers damaged the smoothieboard in some way? Have you tried swapping the working DM542s with the DM542Ts, just to eliminate that possibility?

If you’ve eliminated those possibilites (dud drivers, damaged smoothie), then it could be a logic level problem. The smoothieboard outputs 3.3V, and most external drivers expect 5V (though most apparently work fine with the 3.3V, but maybe yours dont)

I’ve been having trouble with external drivers too, still not 100% sure what, but my next test is to put a logic level shifter inbetween the board and the driver, because mine work, but miss steps every now and then.

Hey, thanks a bunch for the response.

I didn’t realize someone responded!

I figured out what the issue was. Apparently the drivers with the T couldn’t run on 3.3v while the other ones could. That’s my assumption anyway.

When I wired all of the power to the 5 volt it all works, however I might post a question about s difference in documentation later as I noticed something odd and not sure if its s mistake.

On a different note my motors don’t actually need the drivers since they’re old shopbot motors that run on 1 amp (amazing motors btw) but for whatever reason I can’t get the on board drivers to run the motors. What happens is they badly run (slow and choppy) and then they stop responding after 1 to 2 minutes. It’s like they lock up and then stop completely.

I don’t know if my power supply is the problem but it’s a 24v 15amp psu.