Thanks guys, so what about the canbus cable? Dont want to blow up the vescs lol
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
18 Likes
And here is where the fan turns brown.
5 Likes
I started to write something in here several times but in the end it wasnāt worth the effort. I really hope you keep going with the 3.62 stable branch since this is the last one working for me. I have a FSESC dual mini working great with that but completely refusing 4.x, mysteriously it worked once but then the USB port became unavailable under Linux, on Windows I was able to reflash it with 1.25 VT. After that it was visible under Linux againā¦ On my 4WD Dual Maker X setup I ran fully into the CAN issue on FW 2.57, filed a bugreport, tested 2.58 which solved the issue mostly but detection. I wrote that detection failed to write back the values (detection itself seemed to work) but never heard anything from BV again apart from him closing the bug.
This is absolute crap and I hope for the OpenRoad to be a success, we need stability in our vehicles. HFI is a nice feature but is it worth risking FW integrity?
5 Likes
With 4.X firmware I also have trouble to have USB port available on Mac.
2 Likes
Can you elaborate a little bit more on this? OS? Is it just FW update that doesnāt work or USB connection or?
2 Likes
Sure, thanks @rpasichnyk! I should say that was a last minute effort before we called it. I pulled your latest release, and tried updating bootloader/firmware from 4.1 to 4.2 via USB, but was unsuccessful on both ESCs over 4 total attempts. The ESCs on 4.1 connected to the new tool (2.03) but came up as Limited mode. We then went through the set of detection testing steps as described above, with the only difference being that the manual direction/invert spin up functioned that time. Detection still failed otherwise in the same manner
I didnāt attempt a flash via stlink on v4.2 firmware as it was late and I was morally defeated.
Does that answer your questions?
5 Likes
Yes, thanks 
3 Likes
@Trampa I have the same issue as well with app setup wizard over canbus. I gave up on the wizard and did manual setup. That solved the problem. Brand new MKIIIs latest firmware on both
5 Likes
During detection I assume that can command are sent whilst motor is running. Itās very possible that some motors in various control modes could be causing electrical interference affecting messages on there can bus
3 Likes
Internal short to sensor board or to housing, GND Loop to other motor etc.
We have done quite a few setups in the last to days, tried a number of different FWs for Benjamin.
Running the Wizards was never an issue. Sometimes you get a OLD FW Message, but that is usuall gone on a second try. We use different phones, tables, Linux computersā¦
Anyway, a new FW is on the horizon, so jut be patient.
VESC tool in master branch still did not switch to 4.2 firmware. It does support 4.2, but when you hit upload, it will flash 4.1. I removed binaries to avoid confusion and will put them back after official release
6 Likes
Oupss
This appears to be consistent with what we observed.
We tested with/without sensors connected to remove this variable. I donāt believe the motors to be shorted as they respond exactly normal to detection + spinup individually. Itās only on canbus do they show these issues.
This does not reflect my own observations + what Iāve seen others report. This is something that happens commonly enough Iād call it reproducible across a number of different hardware. I have had very little success with the new wizards vs the older manual detection method.
7 Likes
This weekend I am going to see if I can reproduce the correct behavior that we managed to get from the 2nd set of motors. I may also try flashing fw3.62 again and run our testing procedure on the problem motor set. Will report.
5 Likes
Any chance to get scope shots of the TX/RX of both CAN transceivers as well as scope shots of the CAN bus? The idea is to try and see any discrepancies in the waveforms with one set of motors vs the other. If there are, this may point to the VESC hardware needing some hardware design changes. Like using more analog filtering on the bus or switching to an isolated CAN transceiver.
6 Likes
This is a great suggestion and is next on my list after we run through a bit more firmware testing/validation. Want to be completely sure this behavior is only present in 4.0+ before we bother to scope it.
Iām off to the coast for a getaway weekend, but when Iām back Iāll bust out the Saelae and take a look at whatās going on there.
Yaaas. This is your homework while Iām gone, Prospect. Iāll leave my Stlink in my drop box if you need it.
7 Likes
I have some new TB motors and a couple different escās we can test on also. Might help the process.
2 Likes
If hardware gets to be more of a suspect, then swapping the TJA1051 for a pin-to-pin compatible transceiver may be something to try that doesnāt require much effort. I think there is a variant of the TCAN1042 that is pin-to-pin.
The CAN portion of the design itself could be beefed up a bit in future hardware revisions. Splitting the termination resistors (spit termination) and placing a small cap to ground in between them helps with common mode performance. Adding TVS diodes to the CAN bus helps with high-voltage transients. In-line resistors and caps can be added for some light filtering as long as the RC cutoff freq stays clear of the max data rate.
The schematic for the EVM of the TCAN1042 is a prime example of how protect and filter a CAN bus to the max! http://www.ti.com/lit/ug/sllu234/sllu234.pdf
Just my 2 cents
7 Likes
I donāt know if its possible, but slowing down the CAN data rate in misbehaving systems might also be something to try.
4 Likes