Motor driver issue

Could you please shed any light on the following issue:

I am trying to run the attached code with Thommy and a pico:
The results I am getting depend on the Makerverse connections as follows:
(B= blue wire, O= orange wire, Y=yellow wire, G-green wire)

Test 1
Makerverse connections: A+=B, A-=O, B-=Y, B+=G
result: stepper motor only moves 50 steps clockwise and repeat of green run button produces no result.

Test 2
Makerverse connections: A+=B, A-=O, B-=G, B+=Y
result: stepper motor only moves 50 steps anticlockwise and repeat of green run button produces no result.

Test 3
Makerverse connections: A+=O, A-=B, B-=Y, B+=G
result: stepper motor only moves 50 steps anticlockwise and repeat of green run button produces no result.

Test 4
Makerverse connections: A+=O, A-=B, B-=G, B+=Y
result: stepper motor only moves 50 steps clockwise and repeat of green run button produces no result.

Sorry to trouble you but do you have any suggestions?

1 Like

Hi Toni,

Welcome back!

In your code if you change the ‘-s’ and ‘+s’ to -50 and 50 does that work in both directions? Python might be doing some behind the scenes typecasting making it behave unexpectedly.


No, that has the same result as well.

Could it be connected with the fact that the green button appears to do nothing when pressed again after the first attempt?


High Liam,

I have also just tested commenting out all of the print and time statements but still the same result.


Have you confirmed the stepper wire colour codes are correctly matched ??
You have Blue Orange as a pair and Yellow Green as a pair.
Some web sites show Blue Yellow as a pair and Orange/Red Green as a pair.

Using a multimeter you should be able to find the correct ones.
The stepper I tested measured 35 ohms for each coil.

It shouldn’t work if the pairs are incorrectly matched.
For the Stepper I think you are using; the datasheet does not say what colours are the pairs.

Anyway might not be the problem, but something I would want to know and check before using.


Thanks Jim that was the first thing I checked using the mutimeter

The observed clockwise and anticlockwise single movements suggest that the wiring is OK but ……


1 Like

I’m still having problems making the Motor driver work using the Application Guide instructions.

Checked Pico Blink program works - OK.

Triple checked connections between Pico and MV driver.
Checked earth only connected between Pico and MV driver.
Triple checked connections between MV driver and motor.
Checked external +/- 12V power supply connected to MV driver.

Copy and pasted into Pico
Copy and pasted demonstration code into Pico and saved as

Rechecked Pico is correctly connected to RPi as /dev/ttyACM2

But, on system start up and running the code the motor rotates the 50 steps but neither the -180 angle rotation nor the Home rotation occur.

Running the code again doesn’t produce any results at all until the whole system is shut down and restarted which results in the 50 step rotation and nothing else as previously.

The programme is not stalling as I temporarily put in some print() statements which show it is running through the complete code.

Can anyone shed some light on what I am doing wrong or how to debug it.

Many thanks


1 Like

Hi Toni,

Would it be possible to post a link to your motor?

When you mention that a retry of the green button produces no result? Do the print statements re-appear?

Would it be possible to get a screenshot/video of the console and your setup while running this code?
(A couple of times would be handy)

from Makerverse_Motor_2ch import bipolarStepper
from machine import Pin
from utime import sleep

onboard_LED = Pin(25)

stepper = bipolarStepper(pwmPinA = 0, dirPinA = 1, pwmPinB = 2, dirPinB = 3, RPM = 10, stepsPerRotation = 200)

1 Like

Hi Liam,

Yes the green button retries produce the same ‘print’ results.
Static screen shot of this programme included below.

Also static screen shot of the result of running your suggested code which failed. I tried to attach a MOV file but it was rejected with ‘utime’ isn’t defined message


1 Like

Hi Toni
I don’t know anything much about Python or coding Python to drive steppers. I have been browsing rhis thread and one thing stands out.

The stepper rotates 50 steps then stops with no further action.
Immediately after the stepper.rotate(50) you have utime.sleep(1)
Then in your text you say

As I said I know nothing about Python but as this is the point where the motor stops is there not a clue here somewhere like the program doesn’t want to know about “utime”.
Although it seems strange that the program itself does not appear to stall as indicated by the print statements.

Could there be something wrong with the line “stepper.rotate(angle=-180)”. Should the “=” be there. To me that is telling the system the current position is equal to -180º not telling it to rotate -180º. Might be worth removing the “=” and try again.
Cheers Bob

Another easy experiment.
Change “stepper.rotate(angle=-180)” to “stepper.rotate(-50)” and if the stepper goes back to the starting position there will be definitely something wrong with that line of code causing it to be ignored.

another thought. Does the word “utime” precede “sleep”? I would think “utime” is where you are importing “sleep” from so you would just use "sleep(1).


Correct. Depending on how you import into python is how the commands work. @Liam120347 code is incorrect in this aspect.

import utime 
from utime import sleep

This example is shown in the guide. Using angle=-180 and is what the stepper.rotate function is expecting. The angle variable is set to None if not passed to the function.

def rotate(self, steps = 0, angle = None):
        if angle is not None:
            steps = round(angle/360.0*self.stepsPerRotation)
        if steps < 0:
            while steps < 0:
                steps += 1
            while steps > 0:
                steps -= 1

As the code @Toni135859 is using is from the guide it should work (assuming the guide has been checked), so there may be something else. I don’t have one of these Makerverse boards so I cannot check.


1 Like

Hi Jim,

Thanks for pointing that out, I’ve edited the code above.

I’ll shoot through a message to the Core guys to get a setup tested.

Would it be possible to send through a photo of your full setup and a link to the motor Toni?

Sorry I thought I’d sent it already!

Did some extensive theoretical testing of the library. (don’t have a motor board to do real world tests)
Initially I thought the library was incorrect. I changed the pin assignments to variables to allow them to be printed at each step. The resulting table matches up with the motor driver chip datasheet and a NEMA-17 stepper motor datasheet.
I think the library is correct after this test.
(almost makes me want to buy a motor board to do real world tests, LOL)

Note: dirA dirB do not relate to motor A & B. The code changes A first then B.
The motor expects B first then A. Maybe this could be the problem, unsure.
Simply swapping the A & B sides on the motor driver board should fix it.


Code results, 5 steps only.

steps dirA pwmA dirB pwmB
5 1 1 1 1
4 0 1 1 1
3 0 1 0 1
2 1 1 0 1
1 1 1 1 1

Motor driver chip datasheet.

NEMA-17 datasheet.

Hi James, Liam

I just tried reversing the A/B connections as you suggested and, unfortunately it made no difference!

The code (from the Application Guide) I am testing it with is :

from Makerverse_Motor_2ch import bipolarStepper

stepper = bipolarStepper(pwmPinA=0, dirPinA=1, pwmPinB=2, dirPinB=3, RPM=10,stepsPerRotation=200)


This code presents no error message when run.

I’m not sure if it’s relevant but the motor does move 50 steps on power up.

It will be interesting to get the results of the Core guys tests.

Many thanks to both of you for your persistence with this problem.


You should be able to get some useful clues by trying other commands.

If you change that value to -50 does it rotate 50 in the other direction?
If you change that to another value does the rotation angle change?
If you repeat that line after the delay, does it step another 50?

1 Like

@Toni135859 The library code looks ok after testing it theoretically today.
(it actually moves the motor from your testing)

That leaves the Stepper Motor.
If you can get access to another 2 phase bipolar stepper motor, see if it does the same thing.

Found a link to 17HS3417 Datasheet

Wiring Diagram:

Your pic shows Green to B+, Yellow to B-, Blue to A+, Orange (Red) to A- on the Motor Driver.
It should be Yellow to A+, Blue to A-, Orange to B+, Green to B-, according to the datasheet.

The stepper is moving using both H-Bridges in the driver chip on both coils crossed.
I think the driver chip maybe going into shutdown or something.
The number of steps it is producing would be less than 50 because one coil will have the same voltage on both sides and the other not, for every alternate step.

I might be completely wrong here. Just going by what I found related to the stepper part number.


Thanks for the suggested changes which I have fully implemented - to no avail.

One extra thing I have noted is that when the motor does rotate (only on the first green Thonny button push, (post system shutdown/startup) it only moves 1/8 of a full rotation, ie 45deg or 25 steps. This does not relate to any of the steps (+/-50) nominated in the code.

I’ve even tried reloading the code.

Sorry to be taking up your time but any suggestions or results from the Core guys would be greatly appreciated.



You can check that the driver is operating using the multimeter. You should be able to see the voltage on any of the pins flicker as the pulses are sent to the motor.

Does the software provide a speed setting? The motor will miss steps if the speed is set faster than it can handle.

I have used a hand held display to look at the motor pins waveforms when the green button is activated.

When initial system power is applied and the test code run, it doesn’t matter which channel is monitored, the signal appears and the motor rotates (by only 25 steps, not the 50 expected).

Subsequent runs of the code produce no rotation or waveform on either channel.

I have also double checked that the bridge on the rear of the PCB is open.