Nodes with lower ID numbers are given priority on the bus, thats the standard CAN BUS convention, and this is what the Vesc follows.
This is largely due to the wire-AND convention, where a 0 bit data is encoded as dominant state ( Can high > Can low) and 1 bit data as recessive state (Can high < Can low). You can read more about it https://en.wikipedia.org/wiki/CAN_bus
1 Like
any idea how long till HFI on unity?? 
4 Likes
i’m also wondering this.
Oops, I misread it. My bad.
Still it’s worth to test keeping the master VESC at a lower ID than the slave one.
But still, the ID in VESC FW is coded on 8bit.
CAN bus convention is 11bit for CAN 2.0A and 29bits for CAN 2.0B.
This shows that the standard isn’t strictly respected here.
My concern is : are all mechanisms designed by the standard (bit-stuffing, Error frame, overload frame…) managed by the VESC ?
Thats ok, things gets confusing sometimes 
True, Vesc uses only 8 bits for the actual device ID instead of the full 11 bits or the extended version of 29bits, I guess thats because we won’t ever have more than 255 connected nodes anyway, that being said, it does use the extended 29bits format. The arbitration field is 32 bits, with 29 bits assigned for the identifier.
The Vesc FW uses the remaining bits to concatenate the commands packet IDs, you can see it here
if (rxmsg.IDE == CAN_IDE_EXT) { uint8_t id = rxmsg.EID & 0xFF; CAN_PACKET_ID cmd = rxmsg.EID >> 8;
And when sending CAN commands like duty cycle for example
void comm_can_set_duty(uint8_t controller_id, float duty) { int32_t send_index = 0; uint8_t buffer[4]; buffer_append_int32(buffer, (int32_t)(duty * 100000.0), &send_index); comm_can_transmit_eid(controller_id | ((uint32_t)CAN_PACKET_SET_DUTY << 8), buffer, send_index); }
The controller_id is the actual 8bit device id, set to the lower 8 bits, while CAN_PACKET_SET_DUTY is placed on the remaining upper bits.
That’s beneficial because it allows to embed the commands IDs without sacrificing the data field space, resulting in less frames required.
Some other fundamental inner workings of CAN itself are not handled by the vesc firmware tho, but by the CAN transceiver itself.
3 Likes
6 Likes
If 2.02 works well for me, there’s no reason to update it is it?
2 Likes
No, unless you absolutely have to try a new feature like HFI.
1 Like
There is a reason to update. Vesc Tool will tell you.
FW 4.01 isn’t in the list of firmwares that VESC tool would warn about, so I don’t think it “will tell you”.
5 Likes
Just to update everyone who was helping out, I believe I figured out the problem I was experiencing. I was scratching my head trying to figure out what would cause the motors to work perfectly fine when run as separate systems, but to not work at all when run in tandem. So on a hunch I tested for continuity across the two motors (phase from one motor to phase on the other motor). Beeped straight away. Proceed to poke around all over the drivetrain, and there was continuity from every phase wire on both motors to every other spot on the drivetrain and the other motor. Bingo
Houston, we got a short.
On @DerelictRobot’s advising I pulled the drivetrains apart, backed out the motor bolts one by one until the continuity went away. Turns out one of the bolts on each motor was about two threads too long, and was shorting against the stator. When only one motor was running, it was not a problem. As soon as current is going to both at the same time, BZZZT
Ground down the problem bolts, loctite, put em back in, no short.
Ran motor detection wizard (2 VESC6 MK3’s, FW4.1, Tool 2.02) and it worked first try. Ran App wizard, first try gave the “old firmware on one VESC” error but a disconnect and reconnect fixed that. App wizard worked second try, and the motors spin up and work correctly now! Threw a cardboard enclosure on and went for my very first ride on my first build!
Took it slow, just up and down the street. Got the FW-induced speed wobbles that others reported since I didnt change the time constant from 4000 to 1000. Got to fix that. Next up, enclosure!
Im kicking myself that it was something so simple, that eluded me for so long. Hopefully that was the only issue. Will definitely update if anything else crops up, but thanks to everyone that contributed suggestions and ideas for debugging, and especially @DerelictRobot for his hands on help and expertise, as well as the use of his workshop and alternate hardware to test against. I really hope I didnt fry any of your ESC’s Andrew!
17 Likes
Sometimes the simplest things get overlooked easily, glad you figured it out 
4 Likes
Fixed in FW 4.02, just update and redo detection
1 Like
I think im going to just manually change the time constant and re-run detection. I have had enough with changing variables in this build haha. It works, so Im going to stop touching it.
Pic of the temporary enclosure:
19 Likes
Well the changelog also mentions
- Improved axis decoupling and integrator windup protection. Should prevent wobbles.
I don’t know what exactly that means, but I would update if I were you.
3 Likes
This is an underused philosophy.
8 Likes
Yep
Every time I open that enclosure to make just a small adjustment something goes wrong
1 Like
5 Likes
Thanks Bill!
Just some irrelevant changes on the changelog I think?
3 Likes