Teensy 3.6 - Interface a Microstep driver which uses 5V

Status
Not open for further replies.

C3D

Active member
Hello forum,

Whats the best way to connect THIS Microstep driver to a Teensy 3.6.

The Driver is called "Quimat Nema 17 stepper driver 1,7A 24V 40mm 40Ncm (56.2oz.in) 32 Segments 4A 40V"

It has:

ENA -
ENA +5V
Dir -
Dir +5V
Pul -
Pul +5V

The Rest i understand already (B- B+ A- A+ GND VCC) and i have a 24V Power supply already.

The Microstep Driver does not have any instructions so i found THIS link from an TB6600 and how to connect it to an Arduino.
So i have 2 questions:

1. Is the wiring in the Arduino example correct?
2. How do i get 5V from the PWM pins on the Teensy 3.6 ?

Thank you very much!! :)
 
You‘d need 3 x 74LV1T125 level shifters for these signals. Or you use 3 simple standard NPN transistors with 2 resistors each, but since these would invert the PWM signal, your code needs to invert these again.
 
@Theremingenieur
Thanks for the info.
I think i will go for the chip solution. The transistor solution sounds interesting but is more effort plus i have to invert the code.
Since the chips are only cents its not worth it for my project.

@luni
I checked the specs for both level shifters.
The 74LV1T125 and the 74HCT125.
Maybe iam wrong but the 74LV1T125 delivers 8mA and your recommended 74HCT125 delivers only 6mA and not 20mA.

Is this correct? Maybe you have misread the specs? (Or i did?)

I will go for a Dual in line version.

Thanks to both of you for reply! :)
 
Maybe iam wrong but the 74LV1T125 delivers 8mA and your recommended 74HCT125 delivers only 6mA and not 20mA.
Is this correct? Maybe you have misread the specs? (Or i did?)
You are right, I was looking at the max rating which is 35mA. Max rating for the LV1T is 25mA so both types are quite comparable in fact. I use the HCT series quite often for driving opto coupled stepper drivers and never had an issue with them. So, most probably both types will just work OK.
 
@luni

Hello, thanks for reviewing!
So since you have driven several drivers with this chip i will go for the 74HCT125 N .
I just have to grasp how to connect it to the teensy with the help of the provided datasheet.
Maybe some more questions will arise but i hope not.
Howsoever i will post my results here in my little thread.

Thanks for your time!

Liebe Grüße nach Deutschland!
 
Haha!

Natürlich auch liebe Grüße nach Frankreich!
Wusste nicht daß man dort auch deutsch spricht ;)
 
You‘d need 3 x 74LV1T125 level shifters for these signals. Or you use 3 simple standard NPN transistors with 2 resistors each, but since these would invert the PWM signal, your code needs to invert these again.

I have another question.

Do i really need 3 of these level shifters?
Because i looked at the specs pin description and one chip has 4 data input and 4 data output pins.
 
If I'm not completely blind, there are 6 pins to connect for controlling that beast: 3 of them, PUL+, EN+ and DIR+ need constant 5V from the same power supply as the Teensy (which is powered from 5V, too), thus these might be connected directly to the Vin pin. The PUL-, EN- and DIR- pins would require PWM signals through 3 level shifters.
 
Yes you are right, but i mean the 74HCT125N levelshifter chip.

In the specs here LINK on page 3.

5.2 Pin description:

1A 2A 3A 4A = data input
1Y 2Y 3Y 4Y = data output


Maybe i could use 1A for ENA- and 2A for DIR- and 3A for PUL- ??
 
Errr... It's the Teensy which drives the motor driver and not vice-versa. So, the data inputs (1A, 2A, 3A) of the level shifters get their signals from the Teensy's PWM outputs. And the outputs 1Y, 2Y, and 3Y go to ENA-, DIR-, and PUL- inputs of the motor driver. The corresponding XYZ+ pins must all be connected to permanent +5V supply without any shifting. 4A, und 4Y remain unused, pull 4A to GND. The OE pins 1-3 go also to GND, to enable the corresponding outputs. OE4 goes to +5V to disable the unused output 4Y.

800px-DRI0043_Connection.png
 
Last edited:
Errr... It's the Teensy which drives the motor driver and not vice-versa. So, the data inputs (1A, 2A, 3A) of the level shifters get their signals from the Teensy's PWM outputs. And the outputs 1Y, 2Y, and 3Y go to ENA-, DIR-, and PUL- inputs of the motor driver. The corresponding XYZ+ pins must all be connected to permanent +5V supply without any shifting. 4A, und 4Y remain unused, pull 4A to GND. The OE pins 1-3 go also to GND, to enable the corresponding outputs. OE4 goes to +5V to disable the unused output 4Y.

View attachment 13270

Yes, thats exactly what i meant.

The Teensy signals go to the level shifter and from the level shifter to the stepper driver.
I know its not viceversa.

So in total i need only one level shifter and not 3 then, right?

Thanks for the wiring picture!! :)
 
You need just one 74HCT125 since it has 4 lines, yes. But you would need three 74LV1T125 (these were the parts I talked about in post #2 above) instead, since these are single channel.
 
Please be aware that you need to generate inverted control signals if you connect the "+" inputs to 5V and the control signals (stp,dir,en) to the "-"inputs of the driver. For DIR and EN this doesn't matter much but you need a stepper library which can generate active LOW step pulses. Alternatively you can connect all the '-' inputs to GND and use the '+' inputs for the control signals.
 
I had this exact question, and the even more basic version as it pertains to connecting a Teensy 3.2 or 3.5 that are still 5V.

Thank you luni for adding the comment about inverting the control signals. That's the first I have ever seen anyone mention that tid-bit of info.

That said, I have seen numerous documents and videos that show Arduino-type microcontrollers connected to these types of stepper drives, using both wiring schemes mentioned here:

1) Tie all common "-" sides to GND and then "+" control signals to pins under software control

--or--

2) Tie all common "+" sides to Vcc and then "-" control signals to pins under software control


Can someone who understands the electronics on both the microcontroller (output?) side and the optocoupler (input?) side comment on which scheme is preferred and / or why?

Secondly, are there any timing or speed limitations with these level shifters (buffers?) that would limit high speed microstepping signals? If so what part of the specs / datasheet come into play for part selection?

Thanks!

--Jon
 
That said, I have seen numerous documents and videos that show Arduino-type microcontrollers connected to these types of stepper drives, using both wiring schemes mentioned here:

1) Tie all common "-" sides to GND and then "+" control signals to pins under software control

--or--

2) Tie all common "+" sides to Vcc and then "-" control signals to pins under software control

Can someone who understands the electronics on both the microcontroller (output?) side and the optocoupler (input?) side comment on which scheme is preferred and / or why?

Some (old?) buffer ICs and microcontrollers can sink significantly more current in LOW state than they can source in HIGH state. For those buffers / controllers it is better to use scheme 2.

And I guess I will have the same problem with the 3.2 and 3.5, which for some reason I was mistakenly thinking supported 5V output, but now I realize they are just 5V tolerant on inputs. Oops.
Just use a 74HCT125 or a similar buffer (74HCT245...) and you are fine. (That might sound over-cautious but I use buffers even for 5V outputs to protect the controller in case of some malfunction of the connected electronics)

Secondly, are there any timing or speed limitations with these level shifters (buffers?) that would limit high speed microstepping signals? If so what part of the specs / datasheet come into play for part selection?
Those buffers are pretty fast. The 'HCT125 has a propagation delay of about 10ns. A typical step pulse has a duration of about 5µs. You will definitely not run into timing problems with such a buffer.

BTW: If you are looking for a fast stepper driver library you can have a look here: https://github.com/luni64/TeensyStep
 
Last edited:
Thank you for the added explanations luni.

I am not an electronics wizard, so I just manage to keep my head above water while trying to make steppers do fun things. Even after playing with them for a few years there are still many mysteries and surprises.

I have some HCT125's and I'm waiting for the DM542T's to arrive. I'll be working with those together on the bench in the next couple days. I guess I also need to drag out my ancient oscilloscope and try to learn how to use it to see the stepper waveforms (I've resisted that so far in my experimentations :confused: ).

BTW: If you are looking for a fast stepper driver library you can have a look here: https://github.com/luni64/TeensyStep

I am well aware of, and very impressed with your TeensyStep library. Once I have this bench arrangement up and running, my next goal is to start doing some test ports of my existing code, currently running with AccelStepper, over to TeensyStep.

I am really looking forward to testing your scheme for simultaneous arrivals of multiple motors, as that is where I have spent a lot of my time tweaking AccelStepper to do exactly what I need it to.

Is there any place you have more examples posted for TeensyStep? One thing I do a lot is use Paul's encoder library and a knob encoder as a variable speed controller (along with run / stop and direction buttons). I have that all working well in AccelStepper, but haven't started looking at how to do the same in TeensyStep yet. Hints or examples for those types of uses would be very nice as starting points.

--Jon
 
I use lunis library and like it really and also use the HCT125 for buffering. Here is a diagram (done with lunis advice):SN74HCT125 connections.jpg
 
Thank you jpk, that is very helpful. You just saved me a couple hours at the bench I'm sure.

Do you also use the inverted wiring, common "+" scheme above?

And if so do you set your pins for the driver like this:

Code:
motor_3
    .setPullInSpeed(300)      // steps/s   
    .setMaxSpeed(10000)       // steps/s
    .setAcceleration(50000)   // steps/s^2     
    .setStepPinPolarity(LOW); // driver expects active low pulses

I can't seem to find any examples of setting the enable pin. Is that just clearStepPin()?

Maybe there is a TeensyStep thread with all those types of questions. I need to find that to make progress moving from AccelStepper I guess.

--Jon
 
Do you also use the inverted wiring, common "+" scheme above?

I wired like shown in my diagram: "load" is the input of the drive with + and - .

As for the enable pin: you can just issue digitalWrite commands and connect the pin also to a channel of the HTC125. As far as I know there is no handling of enable in TeensyStep.

Hope that helps!
 
I run the exact setup originally posted. Teensy 3.6 driving two 5 volt microstepper drivers with no level shifting. Direct connection without any issues whatsoever. Works great!

Thanks,

Ed
 
I run the exact setup originally posted. Teensy 3.6 driving two 5 volt microstepper drivers with no level shifting.
That may or may not work. I found that it largely depends on the drivers you use. Here a case where it didn't work: https://forum.pjrc.com/threads/48524-Stepper-Driver-Voltage?highlight=stepper+driver. I'd not use those optocoupled drivers out of spec for anything but a quick breadboard test. The small stepper drivers like the DRV8825 have digital inputs and work perfectly directly connected to a 3.3V output.

I can't seem to find any examples of setting the enable pin.
As jpk mentioned there is no special command for setting an enable pin since you can just do a digitalWriteFast(XX) to set that pin. Anyway, I can add a corresponding command to the lib if that makes usage easier.

Maybe there is a TeensyStep thread with all those types of questions. I need to find that to make progress moving from AccelStepper I guess.
I'm not aware of any thread in this forum discussing the usage in more depth. If you describe what information / examples would be useful for you (and probably others) I can add a few chapters to the readme.
 
The small stepper drivers like the DRV8825 have digital inputs and work perfectly directly connected to a 3.3V output.

I have been using the DRV8825's and just bought some DM542T's, so these two threads and their solutions are exactly what I needed to understand the problem. The DRV8825's accept anything over 2.5V as logic high, so as you say they work perfectly with Teensy's. The DM542T specs aren't as clear, but look like they need 4-5V minimum.

DRV8825 specs --and-- DM542T specs

Anyway, I can add a corresponding command to the lib if that makes usage easier.

I don't think a command is necessary, but incorporated in an example, just to show how to de-enegize coils when not in use, might be a good snippet in the Readme.

If you describe what information / examples would be useful for you (and probably others) I can add a few chapters to the readme.

First of all, let me say that your library is very well thought out and designed. Although I haven't switched over to it yet, I have read through the documentation numerous times to familiarize myself with it before transitioning, and I think your documentation covers the expected cases very well. You have solved very important problems (simultaneous arrivals), and identified the critical use cases. You have included code snippets for most of the library functions / commands. I'll be transitioning soon, so I know I will personally have more questions.

That said, because I have used Accelstepper for many years, having read and contributed to the support forum as well, here are the areas that I think need explicit examples to make getting up and using TeensyStep easier:

Simple, complete, compilable examples showing how best to work simultaneously with other "competing" system resources, e.g.:

1) Getting input from pins - most critically reading buttons, encoders and analog devices like a pot e.g. three specific examples:
- A run / stop (overloaded state) button (and possibly dir button - would show complexity of using two state buttons simultaneously)
- Variable speed set using Paul's encoder library (this was a challenge for me personally, so I know how hard it can be, e.g. increase / decrease speed based on knob rotation, extra credit for bumping up the speed increment if knob is rotated faster ;-)
- Variable speed reading a pot on an analog pin (lots of beginners have issues with reading a pin occasionally, rather than every pass through loop(), simple interrupt based example would be fine too, but must be complete and commented)

2) Output to pins - something simple like lighting an LED, in conjunction with motor movement, that users can expand to other output, say at the end of a motor cycle (e.g. motor has finished moving, now trigger a camera shutter).

3) Serial communication - this is the main area that causes huge problems in Accelstepper performance due to architectural delays. Serial output for anything from debug (println), to getting keyboard input. I don't know what user expectations are for serial usage while moving motors, but there are lots of questions that arise (and performance limitations especially using an Uno and motors, which TeensyStep circumvents for the most part).

4) Display output - Another area where simultaneous use of devices with motors causes issues and lots of questions. I don't have a good baseline to suggest here, but it is clearly desirable. My own use has almost always involved a display and / or touchscreen for UI, so I have always faced challenges here. I'm not sure an example is easy to create, but advice for how best to work with SPI, I2C and serial devices for output would be very useful (I'm currently using serial touchscreens from Nextion - enhanced version with flash for pre-installed screens, but have also used Paul's ILI9341 Color Touchscreen, as well as simple 20x4 LCD's). Because there is no standard here, this could be a quagmire, but perhaps you can come up with a suggested framework (pseudocode?) for how to cooperatively communicate to output devices in general? If there was a "standard" a great example would be current position output to a screen, similar to a DRO.

I hope that helps, and thank you again for the outstanding work, and for sharing TeensyStep with the rest of us.

--Jon
 
Status
Not open for further replies.
Back
Top