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:
not so common:
since your motor changes when you change cables, check the individual wires and either fix the broken wire or get another cable.
Thanks for your reply.
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!
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 
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.
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
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. 
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.
@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
huh, i never made that connection with the version numbers before. That clarifies a lot.
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.
That makes perfect sense.
Nice job tracking down exactly what was going on.
Has the PR been merged or the eastbaysource firmware version updated ? (I also have this problem, and my kit was bought from EastBaysource). ?
Much appreciate an update on this
Thanks
Ramdev
I had a successful motor test with holey firmware on Saturday and reset my chains and move the sled with the 1.5b shield and 51.29 beta firmware. I did not have time to complete calibration because I have a nonstandard Z motor and I’m playing with that to get it to work before I can calibrate. We are close.
Yes, it has been merged to master.
You need to install the correct firmware from HERE or the latest and merged version from HERE
Just in case someone else lands here, please note -
Our shield comes with the correct firmware already installed, no need to do anything, just plug and play, it will work right off the box with GroundControl and WebControl.
For those who prefer the holey calibration method over the original, they need to install the holey firmware from HERE or HERE
Hope it helps