Maslow Home Maslow Community Garden Newsletter

Motor won't stop turning

Hello,

Last weekend we’ve installed our Maslow. We’ve
uploaded the latest firmware to the Arduino and hoked up the motors. When we plug in the USB cable to my computer the left motor starts turning and won’t stop. Trying to stop the motor with ground control or start a other motor doesn’t work.

We’ve reinstalled the firmware (several times) but this does not fix the problem.

Any ideas what could be the problem?

Thanks in advance,

Fren en Onno

In addition:

  • List item We have installed the latest firmware version (1.26), the latest version of the Arduino IDE (1.8.15) and the latest version of Ground Control (1.26).

  • Uploading the firmware is finished sucessfully

  • Switching the left and right motor results in the right motor to start turning.

  • When we test the motors all tests fail (left, right and z)

  • When the USB cable is disconnected, the motor stops turning.

  • We wiped EEPROM

  • We reset settings to default.

  • We have removed the ini file. (forgot the exact name)

  • We have switched cables, but with the same result of the left motor to start running.

  • We have not used the Maslow for anything yet

common issues:

  1. cables are not plugged in all the way
  2. What board / motor shield version do you have? If it is 1.5b from eastbay, you need to get the latest firmware from them.

not so common:

  • motor shield is not completely plugged into the control board
  • motor encoder is damaged
  • cable / plug is damaged

since your motor changes when you change cables, check the individual wires and either fix the broken wire or get another cable.

1 Like

Thanks for your reply.

  1. We will recheck the cables.
  2. We have the eastbay board. Will get the firmware from them.
1 Like

My hunch is that this is what will solve your issue.

Thanks for the quick response, will work on it coming weekend and will get back to you on the outcome!

1 Like

@EastBaySource

Do you guys have any interest in merging your firmware into the master branch so that folks who download it from there won’t have this issue? We see this somewhat often and you would be more than welcome to merge your changes in.

Absolutely, merging it to the master would be fantastic. Will work on it, and do the pull request this weekend.

I’ve been also trying to help Orob adding the TB6643 into the Orob/WC firmware branch and although i know the issue, unfortunately haven’t had any time to properly test it yet :frowning: sorry.
It’s the same firmware glitch that affects the TLE boards during motor test and is due to an added eeprom write to System.cpp in the master branch.

line 578

sys.writeStepsToEEPROM

This “writeStepsToEEPROM” messes (somehow speeds up) the execution of while() in Axis.cpp but not the delay(), the abrupt change of direction during the “test motors/encoders” triggers the IC error flag due to a current spike.

//move the motor
while (i < 1000){
motorGearboxEncoder.motor.directWrite(255);
i++;
maslowDelay(1);
if (sys.stop){return;}
}

Adding PWM constrain fixes the glitch in an odd way. As we can see below, as soon as the motor changes direction, it triggers a current surge of more than 8A, setting an “overload error” and turning the motor outputs OFF which immediately get reset back ON by the PWM low part of the duty cycle (IN1=low and IN2=low resets error flag). This cycle repeats till current is low enough to not trigger the flag, the whole event only last 0.058s and is almost imperceptible.

NOTE. It only occurs during motor/encoders test. Also this glitch is only present in the master branch, not in the latest 1.26 firmware release nor in our firmware (1.26b) which is based on it.

IMG_7778

IMG_7779

I believe there is also a small bug in the master Motor.cpp
line 119

bool forward = (speed > 0);

should be

bool forward = (speed >=0); // this way forward will be TRUE if speed = 0 and reach the brake part in line 174

Gab

2 Likes

Nice deduction!

While it would be ideal to be able to handle a current spike like that gracefully, I’m open to lowering the PWM during that test or smoothing the transition. The real value of that test it to let people know that they have their motors plugged in correctly and that the encoder feedback is working. We could do that at a lower speed.

That is very interesting, I remember the changes after 1.26 being quite minor, and the test motors / encoders code hasn’t been touched in a long long time as far as I remember. Let me know if I can help.

I agree. It does seem like that braking mode will never be reached. The comment in 143 implies that the author knew that would be the zero speed case, but I think that maybe a mistake. Since our motors are geared so heavily and not back drive-able I’m guessing the real world impact is pretty minimal. But I agree with you, that looks like a bug.

Nice discussion @EastBaySource and @bar! And good to read that you guys working together to solve ‘our’ issue from happening to others. :100:

In the meantime we have uploaded the correct firmware and all is working as expected. We now have to calibrate and are struggling with the chain length, but nothing we cannot overcome for the moment.

1 Like

@bar and @EastBaySource, Do either of your versions support Holey calibration? Im not familiar enough with the code to be able to figure it out.

That is what I was working on.

ah, ok. when you said you were trying to get the EBS board to work with the 51.28 firmware, i took that to mean you were just trying to get 51.28 to recognize it. Im just guessing here but im assuming that once you got that to happen, then Web Control / Holey would work as well.

Firmware versions:

1.xx is triangular
51.xx is holey

1 Like

huh, i never made that connection with the version numbers before. That clarifies a lot.

1 Like

I’ve been working on this over the weekend.

My assumption this glitch didn’t exist in the v1.26 release was based in the fact it started to happen after updates to the master, but not in the v1.26.
I was wrong, the glitch is there also, just not noticeable as it does what it’s supposed to do which is check the motors/encoders/wiring without issues.

The difference between the two is the way 100% duty cycle is handled. In the v1.26 100% duty cycle still goes low on each period resetting the IC (as mentioned before) in contrast to master which 100% duty cycle stays high the entire period.

Here is the ramp code I’ve been testing to eliminate this glitch during motor test

Axis.cpp

// ramping up
for (int ramp = 50 ; ramp <= 255; ramp += 5) {
motorGearboxEncoder.motor.directWrite(ramp);
maslowDelay(25);
if (sys.stop){return;}
}
maslowDelay(1700); // let it spin at least one full revolution
//ramp down
for (int ramp = 200 ; ramp >= 0; ramp += -3) {
motorGearboxEncoder.motor.directWrite(ramp);
maslowDelay(25);
if (sys.stop){return;}
}
maslowDelay(300);

//move the motor in the other direction
for (int ramp = -50 ; ramp >= -255; ramp += -5) {
motorGearboxEncoder.motor.directWrite(ramp);
maslowDelay(25);
if (sys.stop){return;}
}
maslowDelay(1700); // let it spin at least one full revolution
for (int ramp = -200 ; ramp <= 0; ramp += 3) {
motorGearboxEncoder.motor.directWrite(ramp);
maslowDelay(25);
if (sys.stop){return;}
}

Still need to fine tune values to work properly with all three different shields IC’s (L298, TLE, TB), as it is they are all passing the test, but would like to speed up the ramp a bit more for the loaded test.

Also wanted to check if this glitch could happen during a cut (unloaded motors for now), but it did not.
Tested various 1” stressing cuts up/down/up…… left/right…… nonstop in the center, top-center and top-corners without triggering an error flag once. Even if it could, PWM is never 100% duty cycle which would clear an error instantly. I still need to test/stress everything under load.

1 Like

That makes perfect sense.

Nice job tracking down exactly what was going on.