Stepper motors not responding

[flkmrz]

I'm using an H4 with TB6600 stepper drivers like these: https://www.amazon.com/gp/product/B09XTJC3WF/ and can't get the steppers to respond at all.

Since the output of the H4 is single ended, I wired all of the minus side inputs to ground, and connected the positive side inputs to the H4.

I'm powering the stepper drivers with a lab power supply. I tried a second power supply just in case the first one was bad, but no help there.

I tried with the shipped software and got no response from the steppers at all, so I went through the software and set the relevant constants to the appropriate values, recompiled, and then uploaded to the H4 with no issues. Still no response from the steppers.

The encoder is responding normally and seems to be indicating accurately, but no matter what I try I can't seem to get the steppers to respond at all.

I'm not sure if I need to make changes to the wiring, reconfigure the software, or do something else.

Any help would be greatly appreciated.

Thanks for reading!

DL

[kachurovskiy]

Hi @flkmrz, sorry that you're facing problems with steppers.

One potential problem could be the inverted enable signal - try disconnecting the ENA contact on the stepper and see if it helps.

If it doesn't, I suggest uploading the original h4.ino and trying the wiring as per https://github.com/kachurovskiy/nanoels/tree/main/h4#wiring - if this doesn't help, there might not be enough current on the 5V terminal for the stepper driver to receive the signal. In this case I suggest providing 5V from the power supply to PUL+, DIR+ and ENA+ on the stepper.

[flkmrz]

Hi Maxim,

Thanks for the reply.

It turned out to be the enable line on the stepper controller. I disconnected it and let it float open and it works fine now.

I did have to turn on microstepping. It was unhappy with anything less than 800 steps/rev. Either the controller or motor wouldn't keep up. It was nice and smooth at 1600, 3200, and 6400 steps, although it got rather slow. It appears that either 800 or 1600 is optimal with that controller and those motors. I have the leadscrew geared down at 2:1, and the cross slide at 4:1. I may end up having to change the leadscrew to 4:1 as well. I'm using NEMA 23 motors, so I'll have to experiment a little and see where on the speed/power curve is optimal. I also need to experiment with voltage and current settings to see what will work best.

Thanks again for the help!

DL

[pf-and-more]

Hi @flkmrz, sorry that you're facing problems with steppers.

One potential problem could be the inverted enable signal - try disconnecting the ENA contact on the stepper and see if it helps.

If it doesn't, I suggest uploading the original h4.ino and trying the wiring as per https://github.com/kachurovskiy/nanoels/tree/main/h4#wiring - if this doesn't help, there might not be enough current on the 5V terminal for the stepper driver to receive the signal. In this case I suggest providing 5V from the power supply to PUL+, DIR+ and ENA+ on the stepper.

Sorry for reviving an old thread.

@kachurovskiy my closed loop motor is the same and it only works when the ENA pin is not connected. I am waiting to receive a simple oscilloscope that I ordered to make sure the signal from the micro is indeed working as expected.

While I wait, is there any simple way to invert the logic of the Enable pin on I/O 16 in the code? I tried to look in there and I think its behavior should be entirely dictated by the 'stepperEnable' function, but since I don't yet have the scope I thought to ask first :)

pf

[kachurovskiy]

@pf-and-more you'd have to swap DHIGH for DLOW and DLOW for DHIGH in a couple places to invert the ENA logic:

• https://github.com/kachurovskiy/nanoels/blob/main/h4/h4.ino#L1705-L1713
• https://github.com/kachurovskiy/nanoels/blob/main/h4/h4.ino#L2665-L2669

[pf-and-more]

@kachurovskiy I think I found a bug in the code, or something is wrong in my implementation. Either way, I put some debug messages within the functions stepperEnable and updateEnable and I found out that axis Z is always reported as disabled. To make the logic of the Enable pin functional I had to remove the check on the "disabled" parameter in the first IF instance of updateEnable():

  //if (!a->disabled && (!a->needsRest || a->stepperEnableCounter > 0)) {
  if (!a->needsRest || a->stepperEnableCounter > 0) {

This is a log of my debug messages in which I enabled and then disabled Gearbox mode. Note how the ENA signal is never set HIGH:

  17:43:36.520 -> Axis = Z; needsRest = 1; active = 1; disabled = 1; value = 1; stepperEnableCounter = 1; Axis Z Exit Code = ENA LOW.
  17:43:36.520 -> Called on Line 2158
  17:43:36.520 -> Axis = X; needsRest = 0; active = 1; disabled = 1; value = 1; Exit Code = needsRest/active.
  17:43:36.520 -> Called on Line 2160
  17:43:36.520 -> Axis = C; needsRest = 0; active = 0; disabled = 0; value = 1; Exit Code = needsRest/active.
  17:43:36.520 -> Called on Line 2162
  17:43:41.742 -> Axis = Z; needsRest = 1; active = 1; disabled = 1; value = 0; stepperEnableCounter = 0; Axis Z Exit Code = ENA LOW.
  17:43:41.742 -> Called on Line 2158
  17:43:41.742 -> Axis = X; needsRest = 0; active = 1; disabled = 1; value = 0; Exit Code = needsRest/active.
  17:43:41.742 -> Called on Line 2160
  17:43:41.742 -> Axis = C; needsRest = 0; active = 0; disabled = 0; value = 0; Exit Code = needsRest/active.
  17:43:41.742 -> Called on Line 2162

This is what happens disabling that check. This time the ENA signal gets correctly set as HIGH when the mode is engaged and then set back to LOW as the mode is disengaged:

  17:10:31.009 -> Axis = Z; needsRest = 1; active = 1; disabled = 1; value = 1; stepperEnableCounter = 1; Exit Code = Axis Z ENA HIGH.
  17:10:31.146 -> Called on Line 2158
  17:10:31.146 -> Axis = X; needsRest = 0; active = 1; disabled = 1; value = 1; Exit Code = needsRest/active.
  17:10:31.146 -> Called on Line 2160
  17:10:31.146 -> Axis = C; needsRest = 0; active = 0; disabled = 0; value = 1; Exit Code = needsRest/active.
  17:10:31.146 -> Called on Line 2162
  17:10:35.229 -> Axis = Z; needsRest = 1; active = 1; disabled = 1; value = 0; stepperEnableCounter = 0; Exit Code = Axis Z ENA LOW.
  17:10:35.229 -> Called on Line 2158
  17:10:35.229 -> Axis = X; needsRest = 0; active = 1; disabled = 1; value = 0; Exit Code = needsRest/active.
  17:10:35.229 -> Called on Line 2160
  17:10:35.229 -> Axis = C; needsRest = 0; active = 0; disabled = 0; value = 0; Exit Code = needsRest/active.
  17:10:35.229 -> Called on Line 2162 

I still haven't figured out where the axis is set as disabled in the code. Another weird thing is that Axis "a1" is reported as Axis "C", but I didn't investigate into this.

Best,
pf

[pf-and-more]

So, quick update: I figured out that the reset() function could re-enable all the axis at once and that I could call it by long-pressing the STOP button. As it turns out, it was something wrong with my implementation :)

I still don't understand what was the event that raised the "disable" flag for my device and put that value in memory in the first place though!

I'll leave my post there, maybe someone will find it useful in the future :)