RoninATX
commented
1 year ago Update (and Closing this issue)
After wrestling with this for a couple more hours, we decided to start swapping out components and discovered that some motors were able to behave correctly in both the live code and the test harness code. We discovered that out of 12 or so motors that we bought, only 5 were able to drive in the correct directions, while the remaining (and our original specimen) have the erratic back-and-forth steps along the OPEN / CLOSE commands.
The fact that the "failed" motors still seemingly turn correctly when pausing between individual position steps (test harness) is still baffling, it's almost like a continuous stream of FORWARD / BACKWARD overloads something in the motor's chip or something.
Anyhow, TL;DR - if this is happening to you, try swapping out motors.
Got the parts, got everything connected, and even got the motors to behave correctly in a very simple test harness loop that is capable of moving the motor FORWARD and BACKWARDS reliably using either Stepper.move() or Stepper.revolve()
However when we run the provided code, the MQTT side appears to be functioning properly (e.g. OPEN and CLOSE messages in /blindsCommand publishing the appropriate 0 and 12 integer messages to /positionCommand), and in the diagnostic ouput we can even watch the interim positions step up 0-1-2-3-4-etc and down 12-11-10-9-etc, but the corresponding motor movements are erratic. On the same command, it might do two or three steps in the correct direction, then stutter back in the opposite direction for a step, then even resume in the correct direction.
As a test, we tried modifying the original movement blocks (i.e.)
to something like this:
And then a similar approach for the BACKWARD movement code block.
Basically, rather than going through a repeating 12 step loop between newPosition and currentPosition to drive OPEN and CLOSE commands, we instead want to test fire a 5 pulse FORWARD movement with 1 second between pulses, and then "drop out" of the loop by equaling out newPosition and currentPosition, so the code only executes once per OPEN or CLOSE command.
The expected result works fine. When I hit OPEN, I count 5 distinct movement bursts in the correct direction on the motor. When I hit CLOSE, I count 5 distinct movement bursts in the opposite direction on the motor. This behavior ends up working correctly with over 5 min of OPEN and CLOSE alternating commands.
Take the same code, and instead let it go back to doing the whole currentPosition++/currentPosition--, single Stepper.move() call, and it goes back to unpredictably changing directions.
Near as I can tell, there seems to be something wonky going on in how the stacked Stepper.move() commands buffer out to the driver, where perhaps there's some kind of... latency? or +/- loss in the direction that ends up getting passed? I don't know. Not sure what else to do or check.