Wrong position when using moveTo on esp32?

[OT12345]

Hi, im having issues with the stepper moving to wrong position when i run the example code, seems like it only moves wrong when going in reverse, to little. This is a awesome library if the position is correct :)

im not using the enable pin, its is connected to ground (on).
the stepper im using is a nema23 closed loop with the driver directly on top of it.

#include "FastAccelStepper.h"

// As in StepperDemo for Motor 1 on AVR
//#define dirPinStepper    5
//#define enablePinStepper 6
//#define stepPinStepper   9  // OC1A in case of AVR

// As in StepperDemo for Motor 1 on ESP32
#define dirPinStepper 17
#define enablePinStepper -1
#define stepPinStepper 16

FastAccelStepperEngine engine = FastAccelStepperEngine();
FastAccelStepper *stepper = NULL;

void setup() {
  engine.init();
  stepper = engine.stepperConnectToPin(stepPinStepper);
  if (stepper) {
    stepper->setDirectionPin(dirPinStepper);
    stepper->setEnablePin(enablePinStepper);
    stepper->setAutoEnable(true);

    // If auto enable/disable need delays, just add (one or both):
    // stepper->setDelayToEnable(50);
    // stepper->setDelayToDisable(1000);

    stepper->setSpeedInUs(200);  // the parameter is us/step !!!
    stepper->setAcceleration(5000);
    
  }
}

void loop() {
  
  stepper->moveTo(10000);
  delay(2000);
  stepper->moveTo(5000);
  delay(2000);
  }

[gin66]

Looks all ok. Could you please elaborate on how wrong the position is ?

What I could recommend: Please try with the StepperDemo example using key commands via serial monitor. This should help to isolate the problem.

[OT12345]

Hi and thanks for your answer :) i ran the demo code and it passed on everything exept test 7 and 8? Test9 seems to go on forever? What is wrong?

21:02:21.304 -> Select test_seq: 07
21:02:22.341 -> Run tests
21:02:22.341 -> M1: @-622 [-880] nonstop QueueEnd=-622/268435455us/4294967295ticks ACC
21:02:22.434 -> M1: @-8 [-266] nonstop QueueEnd=95/152us/2432ticks ACC
21:02:22.526 -> M1: @1816 [1558] nonstop QueueEnd=2032/79us/1268ticks ACC
21:02:22.668 -> M1: @4846 [4588] nonstop QueueEnd=5165/53us/858ticks ACC
21:02:22.764 -> M1: @9078 [8820] nonstop QueueEnd=9481/40us/650ticks ACC
21:02:22.764 -> 405
21:02:22.764 -> finished
21:02:22.764 -> >> M1: @9333 [9075] [9076] nonstop QueueEnd=9875/40us/640ticks COAST
21:02:22.764 -> M2: @0 Acceleration [Steps/s^2]=0 Speed [us/step]=0
21:02:22.764 -> M3: @0 Acceleration [Steps/s^2]=0 Speed [us/step]=0
21:02:22.764 -> M4: @0 Acceleration [Steps/s^2]=0 Speed [us/step]=0
21:02:22.764 -> M6: @0 Acceleration [Steps/s^2]=0 Speed [us/step]=0
21:02:22.764 -> Failed status from test

21:02:54.513 -> Select test_seq: 08
21:02:56.545 -> Run tests
21:02:56.545 -> speed=1607 accel=187505 move=-622
21:02:56.636 -> M1: @-121 [-182] => -622 QueueEnd=-134/1607us/25712ticks COAST
21:02:56.731 -> M1: @-245 [-368] => -622 QueueEnd=-258/1607us/25712ticks COAST
21:02:56.825 -> M1: @-370 [-555] => -622 QueueEnd=-383/1607us/25712ticks COAST
21:02:56.921 -> M1: @-494 [-741] => -622 QueueEnd=-507/1607us/25712ticks COAST
21:02:57.065 -> M1: @-619 [-929] => -622 QueueEnd=-622/0us/0ticks MANU
21:02:57.065 -> stepper pos=-622 real pos=-933
21:02:57.065 -> finished
21:02:57.065 -> >> M1: @-622 [-933] Acceleration [Steps/s^2]=187505 Speed [us/step]=1607
21:02:57.065 -> M2: @0 Acceleration [Steps/s^2]=0 Speed [us/step]=0
21:02:57.065 -> M3: @0 Acceleration [Steps/s^2]=0 Speed [us/step]=0
21:02:57.065 -> M4: @0 Acceleration [Steps/s^2]=0 Speed [us/step]=0
21:02:57.065 -> M6: @0 Acceleration [Steps/s^2]=0 Speed [us/step]=0
21:02:57.065 -> Failed status from test

[gin66]

Thanks for spending the time.

I should add docu, what those tests do:

• 01 - Run the stepper like a clock for one minute
• 02 - Run the stepper towards positive position and back to zero repeatedly
• 03/04 - same like 02, both different speed/acceleration
• 05 - Perform 800 times a single step and then 800 steps back in one command
• 06 - Run 32000 steps with speed changes every 100ms in order to reproduce issue #24

All those test have no internal test passed/failed criteria. I use them for automated tests with tests/simavr_based and even with tests/esp32_hw_based. One commonality: They should run smoothly without hiccups and return to start position.

• 07 - measures timing of several moveByAcceleration(). Should stop at position zero. (should be started from position 0)
• 08 - is an endless running test to check for esp32, if the generated pulses are successfully counted back. The moves should be all executed in one second with alternating direction and varying speed/acceleration
• 09 - is an endless running test with starting a ramp with random speed/acceleration/direction, which after 1s is stopped with forceStopAndNewPosition(). It contains no internal test criteria, but looking at the log, the match of generated and sent pulses can be checked. And the needed steps for a forceStopAndNewPosition() can be derived out of this
• 10 - runs the stepper forward and every 200 ms changes speed with increasing positive speed deltas and then decreasing negative speed deltas.

[gin66]

In your case test sequence 08 is very interesting, because it shows, that running in negative direction the attached pulse counter does not match with the number of generated pulses. For two generated pulses, the pulse counter measures three.

Test sequence 07 does not display any similar anomaly, but the timing is not ok. Perhaps can check again, if the esp32 comes out of reset.

Here couple of questions:

• do you use Linux ?
• which esp32 derivate do you have ?
• can you provide the spec of your motor ?
• Do tests 01-06 stop all at the start position ?
• do you have an oscilloscope and can measure the step line ?
• does test seq 08 run continuously without abort, if no stepper is attached ?

[OT12345]

Hi and thank you for your reply :).

Edit: Changed from common gnd on the stepper to common 5.0v and used a logic converter for the lines from the esp32 to the stepper.

Seems like this did the trick!
Thank you so much for the help! I think this is the absolutely best stepper library out there :)

//Old Reply
I didnt answer completely on your first reply, it seems like it overturn/underturn about 1/4 in one direction, i have to do more test to be sure thou.

1.Operating system : Im not using windows.

2.Microprocessor :Im using Wemos Mini D1 Esp32 :
https://www.ebay.com/itm/TTGO-Wemos-MINI-D1-ESP32-WiFi-Bluetooth-Wemos-D1-Mini-ESP8266-ESP-32-Module/183413480551?hash=item2ab44b9c67:g:wf4AAOSw3RZevJZ4

3.Motor Specs : Im using a closed loop nema 23 with stock config :
Ebay:https://www.ebay.com/itm/NEMA23-1Nm-36V-DC-IHSS57-36-10-Closed-Loop-Schrittmotor-Treiber-Kit-CNC/163544454860?hash=item26140256cc:g:LT0AAOSwx~lcZjtt
Datasheet:http://donar.messe.de/exhibitor/hannovermesse/2017/G151302/nema-23-2n-m-integrated-stepper-motor-eng-451437.pdf

4.Stopping at starting position:
Test01 : ok, stops at start position.
Test02 : no, does not stop at start position.
Test03 : no, does not stop at start position.
Test04 : no, does not stop at start position.
Test05 : no, does not stop at start position.
Test06 : no, it stopped 3 out of the 4 times i tested in the correct position.
Test 01-06 says test passed.

5.Oscilloscope : Yes, i tried to take a look at the signal to the stepper but it is to many pulses to keep track of, but the pulse lines looks clean :)

6.It runs fine when i disconnect the stepper, when i connect it, it stops immediately.

x-I also increased the voltage to 32V as high as my 10amp powersupply can go with no luck.
x-Rewired everything with no luck.
x-Changed from common gnd on the stepper to common 3.3v. Helped maybe a little.

//

[gin66]

Happy to see, that you have identified and fixed the root cause. Why it works with common VCC, but not with common GND is interesting. From the data sheet, the outputs have to drive the LEDs of an opto coupler. Just this does not explain the direction pin dependent stray pulses with the funny ratio of approx. one stray per two regular pulses for negative direction, only. Anyway, if it works for you now, then this is OK. I personally would go back to the former failing version and try to understand, what the real issue is. But that's just me.

At least I have added the test sequence description to the README, as I've written it down here. Perhaps someone else needs similar info, what those test sequences do, so it is now available.

As the problem is resolved, the issue can be closed.

[OT12345]

Hi, im so sorry to open this again but after more testing it seems like the problem still persists so i pulled out my logic analyzer.
Here is a screenshot of my measurments, 10000 steps is the correct step amount. I ran the motor back and forward until it failed :)

[OT12345]

Hi, here i used the UsageExample with some small modifications.

Channel 0 : Step After Logic Converter.
Channel 1 : Dir After Logic Converter.
Channel 2 : Step Before Logic Converter.
Channel 3 : Dir Before Logic Converter.

#include "FastAccelStepper.h"

#define dirPinStepper 17
#define stepPinStepper 16

FastAccelStepperEngine engine = FastAccelStepperEngine();
FastAccelStepper *stepper = NULL;

void setup() {

  pinMode(13,OUTPUT); //Power Control
  digitalWrite(13,HIGH); //Power Control
  
  engine.init();
  stepper = engine.stepperConnectToPin(stepPinStepper);
  if (stepper) {
    stepper->setDirectionPin(dirPinStepper);
    stepper->setSpeedInUs(200);  // the parameter is us/step !!!
    stepper->setAcceleration(7000);
    
  }
}

void loop() {
  stepper->moveTo(10000);
  delay(5000);
  stepper->moveTo(0);
  delay(5000);
  
  }

Here is the measurments, im using Saleae Logic 1.2.18 To do the measurments, i also uploaded a csv of the measurments if it is of any use :)

Software: https://www.saleae.com/downloads/

Measurements 24 MHz, 720 M Samples [7].zip

[gin66]

Thanks for the investigation and the data file. Actually I prefer the csv-file, so I can analyze with some gawk script. And besides, that the ramp is done faster, there is no anomaly.

Just checked on my hw and I cannot reproduce the problem using same step pin as yours. My device is an ESP-WROOM-32

Now some more questions:

• You say I ran the motor back and forward until it failed :). How long does it take till it fails ?
• If you invert the dir-pin with setDirectionPin(dirPinStepper, false). Is then still the negative move too short ?
• Can you invert the dir-pin via HW ? If yes, which move is too short ?
• Any chance to use a different step pin ? any change ?
• Any chance to use a different direction pin ? any change ?

still from the test seq 08 above, the pulse generation and pulse count by second counter do not match. This still indicates glitches, while on salea there are none to see. As the esp32 is a complex board, there may still be glitches inside the housing not visible to salea.

[OT12345]

Hi, csv file notet :). i woke up this morning, powered on my setup without touching anything and it ran normally, wierd, maybe it has something to do with my code or setup even thou the day before i uploaded the UsageExample and it still happened? i dont know?

I haven't tried all of your last suggestion yet but il do as soon as i can reproduce the anomaly :)

1.I ran the motor 2-3 times before it happened and it always happened on the high side of dir,
2.If i use "stepper->setDirectionPin(pinMotorDir,false);" it still only happened on the high output of dir.
3.Havnt tried it yet, going to try it and experiment som more.
4/5.Il try to change the pins and/or use another wemos esp32 and see if it happens.

i also tried to power cycle the esp32 and stepper yesterday without luck.

Is it possible that in some way my previous uploaded code was interfering with the timer the library uses? like pairing of the Bluetooth or the clock speed of Wire (Wire.setClock(1000000)? Which timer does the library use?
Im running BluetoothSerial.h , Wire.h and fastled.h in my code, im sorry that i cant post the code im using but it ran fine today.

Im going to test some more and se if i can reproduce it and get back to you, its most likely something with the esp32 im using maybe. Thanks so much for the fast response and help so far :)

[gin66]

As stated in the readme for timer usage: This stepper driver uses mcpwm modules of the esp32: for the first three stepper motors mcpwm0, and mcpwm1 for the steppers four to six. In addition, the pulse counter module is used starting from unit_0 to unit_5. This driver uses the pcnt_isr_service, so unallocated modules can still be used by the application.

Any update ?

[gin66]

stalled, so close

[ILikeRubberDuckies]

Had the same issue with a closed loop. Then I set driver_type for the stepperConnectToPin-method to DRIVER_RMT(1). Works like a charm now.