VESC Duet

The controllers have been tested and can reach the stated values for continuous and burst for a short period without additional cooling. As the current is regulated down as the controllers heat up the controllers protect themselves from damage due to overheating. However, in order to maintain the stated continuous current and to maximize the burst current duration additional cooling is required. Especially the continuous current that can be maintained will be significantly lower without an additional heatsink or water cooling block.

The regeneration (or braking) current can reach the same continuous and burst current ratings as the controller. However, the actual limit depends on your BMS and, more specifically, your battery cells, which determine how much current can safely flow back into the battery.

Additionally, the values for motor current, motor brake current, battery current, and battery regeneration current can all be individually configured using VESC Tool to suit your specific application, hardware or performance requirements.

The documentation for LispBM scripting can be found here:
https://github.com/vedderb/bldc/blob/master/lispBM/README.md

You can find CAN-bus documentation here:
https://github.com/vedderb/bldc/blob/master/documentation/comm_can.md

Further documentation for LispBM scripting can be found here:
https://github.com/vedderb/bldc/blob/master/lispBM/README.md

If your controller has a AUX 12V output, go to Motor Settings > General > Advanced Tab > Auxiliary Output Mode.
Change this setting from off to "On after 2 Seconds"

All Pronto-controllers shipped until 2026-03-15 have a hardware bug for the ABI encoder input, where the A and I signals are swapped. This can be resolved by swapping the A and I cables on the encoder. If the PCB is green it has this bug. PCBs shipped from late March and onward are black and do not have this bug - on them the ABI encoder can be connected normally.

The Maxim and Pronto controllers have the UART-pins shared with the hall sensor pins, so when using sensors the reverse and cruise control functions in the ADC app cannot be used at the same time as hall sensors or encoders. It is possible to use a simple lisp-script to simulate these functions with other pins depending on which pins you have available. The following example activates the reverse-button when the ACD2-input goes above 1V.

(app-adc-detach 2 1)
(loopwhile t {
(app-adc-override 2 (if (> (get-adc 1) 1.0) 1.0 0.0))
(sleep 0.01)
})

You can read more about those extensions here

https://github.com/vedderb/bldc/blob/master/lispBM/README.md#app-adc-detach
https://github.com/vedderb/bldc/blob/master/lispBM/README.md#app-adc-override

On the Maxim and Pronto controllers the motor sensors and UART share the same pins, so the UART app must be disabled when using sensors. This will affect the Hall 2 input as that is where UART TX is. In Firmware 7+ this should be done automatically, but on older firmware the UART-app must be disabled manually.

The shutdown behavior can be configured using the shutdown-mode in the app settings. By default it is set to ALWAYS ON, which makes the controller stay on until power is removed. Changing the shutdown mode to ALWAYS OFF means that it will turn off after disconnecting the EN-pin.

The controller current rating is for the phase current and the input current will always be lower than the phase current. You can read about that in our article here

Choosing a Motor Controller

However, if you are driving a low inductance motor close to full duty cycle it is possible that the input current will exceed the rating of the fuse and blow it, especially if you are using liquid cooling. In that case you have to use an external fuse and bypass the fuse on the controller with a bus bar. Unfortunately we have not found fuses in this size rated for more than 350A.

Our dual motor controllers (Duet and Duet XS) only support hall sensors on the sensor ports. Some encoders might work on Motor 1, but Motor 2 only works with hall sensors or sensorless. HFI works on both motors for motors that are suited for HFI.

Our dual motor controllers only support Field Oriented Control (FOC). Direct Current (DC) motors or trapezoidal commutation (BLDC) is not supported at the moment.

For the CAN-bus to work all devices on it need to have the same baudrate and different CAN IDs. If both of those conditions are not fulfilled the CAN-bus will be unreliable and often not work at all.

By default all our devices have CAN baudrate 500 kbps. The default ID is are

• Nanolog, RMCore, WCore, Link: 2
• BMS: 3
• Display: 4
• ESC: random, but not 2, 3 or 4

Due to the random ESC ID you need to check for collisions and change ID accordingly before connecting them together on the CAN-bus

Note
Changing CAN baudrate has to be done on each device individually without having other devices connected over CAN as having different baudrates on the same bus will make communication on that bus stop working completely. VESC Tool has a function that allows changing CAN baudrate on all devices at once; it can be found at the top of the CAN Tools page. Once the update is done using this method it will be stored in the non-volatile settings on each device.

Note
All our devices remember the CAN ID and CAN baudrate across firmware updates. This allows reaching all devices on the CAN-bus on the same baudrate and ID as before even after a firmware update.

Note on motor controllers with an ESP32
Our motor controllers that have an integrated ESP32 (Maxim, Maxim+, Pronto, Duet) have the USB and wireless interfaces connected to the ESP32. When changing baudrate on the motor controller it will no longer be reachable on the CAN-bus from the ESP32. To resolve this, the VESC Express page can be used to change to the same baudrate on the ESP32 - this should make the motor controller appear on the CAN-bus again. The same is true for overlapping IDs - if the motor controller ID is changed to the same as on the ESP32, the ID of the ESP32 can be changed in the VESC Express page to a different one to make the motor controller appear on the CAN-bus again.

When changing CAN-mode to UAVCAN (DroneCAN) the VESC CAN protocol will be disabled. This means that VESC Tool can't be used to configure and monitor ESCs or other VESC devices on the CAN-bus at the same time as UAVCAN is enabled. This is especially a problem on the Maxim, Pronto and Duet controllers as they access the STM32 using the ESP32 using VESC CAN. The later firmwares will therefore switch back to VESC CAN on reboot.

Earlier firmwares will not switch back on reboot, meaning that it is possible to lock yourself out from them (Maxim, Pronto and Duet) when changing to UAVCAN. If you have locked yourself out you can either try connecting using the UART-port with an USB-to-UART adapter and 115200 baudrate or you can use USB to reflash the STM32.

So, how do I use UAVCAN on Maxim, Pronto or Duet? Unfortunately we don't have a good solution for that now. As it is now UAVCAN is not widely used among our customers (and VESC-users in general), but if it becomes more popular we will look into improving UAVCAN-support in the firmware. Pull-requests on github are always welcome of course!

Yes, we offer a discount for all customers when ordering 3+ and 10+ units which can be seen on the website.
For order quantities over 25 units please follow the instructions on the request approval for a wholesale account page.
Once your account has been approved for wholesale, go to wholesale products which will show show the updated prices and lead times.

Yes, we do. Please contact us at info@vesclabs.com with your project requirements and specifications, and our team will assist you with tailored OEM or custom solutions.

Yes, we do. Please send the details of your project and institution to info@vesclabs.com, and our team will review your request.

Our partner Oliver, also known as Electricfox, offers paid consulting services for BMS and motor controller integration, setup, tuning and load testing. His website is

https://electricfox.de/

At the bottom of the page you can find different options to contact Oliver