Holy crap, reading through these comments I’ve regained at least a shred of sanity.
@BenjaminF and I spent some more time digging in this evening. Hardware Gremlins were out in numbers.
I am currently at a loss as to exactly what the fuck is going on, but I took good notes and we had very consistent testing procedures. I’m going to distill our testing procedure and results here.
Same pair of VESC6 MK3. Still running 4.1 firmware (60_MK3).
Peripherals involved: Maytech PWM remote, canbus cable, 12S battery (confirmed good), 6374 190kv Saite BLDC motors.
Ran each test multiple times as they produced varied results.
Test Process
- FOC Setup Wizard - 2 different results, “Old Firmware” Error or failure to detect flux linkage. FOC detection sounds were irregular/cogging and/or hysteresis behavior present.
- Manual FOC Motor detection - canbus cable disconnected, each ESC detection run individually, successfully.
- Input Wizard - 3 different results =, “Old Firmware/You must update firmware” error, OR, Input setup wizard completed successfully but only Master ESC side would spin up, OR Input setup wizard completed successfully but neither motor would spin correctly, cogging, similar behavior to the incorrect FOC detection during the FOC Wizard setup.
Note: Checking app settings on slave ESC showed that when only master would spin up with slave unresponsive, slave ESC had CAN_STATUS_MESSAGE_MODE set to 0 (expected behavior, but this was after Input wizard had completed successfully. When the cogging behavior was present after input wizard completed, it was noted that CAN_STATUS_MESSAGE_MODE was set to 1_2_3_4. Turning it back to 0 would revert it to non-responsive behavior, as expected. - Attempting to spin up the motors on General Screen to check direction would spin the master ESC motor correctly, however cogging/stuttering was present on the slave ESC motor spin-up towards the max rpm it uses for that test.
- Tested single-motor setup, no canbus, pwm receiver input configured through wizard or manually, both ESCs spin up the motor without issue. It is only when ‘multiple vescs over canbus’ actions, or a wizard that uses canbus comms comes into play, that things go wrong. More on this later.
- Detection with/without sensors made no unexpected differences.
- We made sure to load default settings/confirmed settings being written.
Note: At a future point when all else failed, we tested VESC TOOL 2.03 (firmware 4.2) from @rpasichnyk’s fork, however firmware updating would not work at all over USB, even with bootloader reflashed. We tested the above steps using 2.03 VESC TOOL (firmware 4.1) to the same exact results with one exception- the spinup/direction test on the General Motor tab actually worked for both motors.
So you might be thinking this sounds like a pretty cut and dry canbus issue right?
I thought so too, but here’s where reality started to get fucky on me. Now take the entire testing scenario I detailed above, and change out only one thing:
The motors. DIfferent manufacturer, similar size/KV. Functional as well.
“Old Firmware Error” would still come up randomly, and the FOC Wizard is failing to complete, but we manually ran detection on each motor and then ran the Input wizard successfully, and both motors spun up successfully and responded as expected. We only tested this second set, but switching back to our original set of motors produced the same failures again on canbus comms.
Anyone have any idea what could cause one set of motors to have canbus-related failures while the other doesnt? @Trampa @Deodand