I’ve got a setup with the Spark Core, that runs 3 different motors (2 DC motors using the Pololu DRV8801 driver and 1 stepper motor using the Pololu DRV8825 driver). I’m using the AccelStepper library to handle the stepper motor. In a previous thread (Spark Core + AccelStepper Library problems) I was told that the permanent to the Cloud drains a huge amount of the performance. So I used SYSTEM_MODE(MANUAL); and that solved most of the problems.
Now I have a PWM based speed control of all of my motors. When I’m using the AUTOMATIC system mode, the DC motors can be controlled perfectly fine and the stepper motor is running slow as hell. When I put in the MANUAL mode, the stepper motor is just fine, and can be controlled with my potentiometers perfectly … BUT there is a problem with the DC motors. When I turn the potentiometer for the DC motors, It only takes a few degrees of turning the potentiometer to enable the full speed on the DC motor. So it does NOT use the full range of motion of the potentiometer. So maybe after 10% of turning the potentiometer the DC motor has its full speed, and the rest of the turning of the potentiometer the speed stays the same.
And this is somehow related to the MANUAL system mode.
When I press my button (connected to D0) that fires the connect() function and fires up Spark.connect(); the speed control with my potentiometer for my DC motor is behaving normally again.
I also note that all my motors are running counterclockwise, even though they are wired correctly and have the correct polarity.
I’ve read around and learned that if the loop’s are calculated too fast the accuracy of the potentiometers will suffer. Therefore I’ve inserted a delay(100) at the end of the getPot() function and the controls of the DC motors with SYSTEM_MODE(MANUAL) will work just fine.
BUT, as a result, the stepper motor will step extremely slow. Only When I remove the delay, the stepper motor will turn just fine, even though the control with the potentiometer is just fine … but just not with the DC motor … how can this be?
A delay(100) does block and hence will slow down the iteration speed of your loop() while what I’ve done with my code is called a non-blocking or “soft” delay whicht will not impact the frequency with which loop() will be serviced, allowing for the time critical tasks - as your other motors - to be run more frequently than the non-critical or even speed-limited tasks.
So if you haven’t tested it, do.
And if you have tested it, can you show your updated code, to see if you’ve used my excerpt at the “proper” position.
Did I understand correctly: With the delay (blocking or soft) in place your motor 3 behaves correctly but the two others don’t and without delay M1 & M2 do behave correctly but M3 not?
If this sounds right, then I’d suggest to try this instead
And you could even do something similar with your run().
On the Photon there was a PWM glitch at some point, where each time you set the PWM value anew, the current PWM cycle was stopped, not fullfilling the puls-gap-ratio and restarting immediately a new cycle, causing a way too high puls-gap-ratio, since the gap keept getting cut short.
This would also explain your M3 problem.
To verify this theory, could you please try out all three combinations:
I tried every suggestion but none of them worked…
Further I’ve experienced a few thermal shutdowns of my Stepper motor driver… it gets insanely hot and the soft blocking of the motor3.setSpeed won’t reduce the the heat.
I’m so fucking annoyed by this project, so I will just get rid of the damn stepper motor and get another simple DC motor…
But thanks for your advices and help. I really appreciate it.
Yes, I’m using 0.4.5 firmware. The soft blocking that you’ve mentioned in any of the described places, for the stepper motor and I’ve tried it even for the DC motors reading and running speeds, but I didn’t worked.
OK, now after watching your video my understanding of the problem just got flipped round.
Obviously I've not read/understood your written description right
And this was obviously wrong
Since I got it wrong then, try everything I said for M3 with M1 & M2 instead
If I'm not wrong again then I guess M3 needs to be serviced as often as possible while M1 & M2 want some breathing time in between.
Most likely I'd think soft-delaying the analogWrite() part should do the trick and applying a moving average to the pot readings might help too.