ODrive v3.5 not connecting in Windows

Support
1

Hello,

I’ve recently purchased a couple 48V ODrives v3.5 that I would like to use to drive 1.5kW BLDC motors.

I installed everything on Windows as instructed but I can’t seem to get the motor to show up in the odrivetool. When I turn the power supply on I get the following entries in the Device Manager

libusb-win32 devices
  ODrive 3.5 Native Interface (Interface 2)
  
Ports (COM & LPT)
  USB Serial Device (COM3)

However, when I start anaconda (as administrator) and run odrivetool --verbose, I get the following

ODrive control utility v0.4.1
Waiting for ODrive...
USB discover loop
USB discover loop
ConfigurationValue 1
        InterfaceNumber 2,0
                EndpointAddress 3
                EndpointAddress 131

Please connect your ODrive.
You can also type help() or quit().

USB device init failed. Ignoring this device. More info: Traceback (most recent call last):
  File "C:\ProgramData\Anaconda3\lib\site-packages\fibre\usbbulk_transport.py", line 195, in discover_channels
    bulk_device.init()
  File "C:\ProgramData\Anaconda3\lib\site-packages\fibre\usbbulk_transport.py", line 54, in init
    self.cfg = self.dev.get_active_configuration()
  File "C:\ProgramData\Anaconda3\lib\site-packages\usb\core.py", line 875, in get_active_configuration
    return self._ctx.get_active_configuration(self)
  File "C:\ProgramData\Anaconda3\lib\site-packages\usb\core.py", line 102, in wrapper
    return f(self, *args, **kwargs)
  File "C:\ProgramData\Anaconda3\lib\site-packages\usb\core.py", line 239, in get_active_configuration
    bConfigurationValue=self.backend.get_configuration(self.handle)
  File "C:\ProgramData\Anaconda3\lib\site-packages\usb\backend\libusb0.py", line 510, in get_configuration
    100)
  File "C:\ProgramData\Anaconda3\lib\site-packages\usb\backend\libusb0.py", line 593, in ctrl_transfer
    timeout
  File "C:\ProgramData\Anaconda3\lib\site-packages\usb\backend\libusb0.py", line 431, in _check
    raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] b'libusb0-dll:err [control_msg] sending control message failed, win error: The I/O operation has been aborted because of either a thread exit or an application request.\r\n\n'

If I start the odrivetool --verbose and then turn power on, I get

ODrive control utility v0.4.1
Waiting for ODrive...
USB discover loop
Please connect your ODrive.
You can also type help() or quit().

USB discover loop
USB discover loop
USB discover loop
ConfigurationValue 1
	InterfaceNumber 2,0
		EndpointAddress 3
		EndpointAddress 131

EndpointAddress for writing 3
EndpointAddress for reading 131
Connecting to device on USB device bus 0 device 1
In [1]:

and it sits there. Does anyone have a working 48V v3.5 on Windows 10?

Any help is appreciated.

Thanks,

Tom

2

What is on your tup.config file?

3

I don’t see a file named tup.config anywhere on my Windows PC. Should there be?

4

Is under firmware: make a cooy of tup.config.default and rename it as tup.config

5

https://docs.odriverobotics.com/developer-guide. Read the part Configuring the build

6

HI Tom, yes its frustrating, I tried for a day on Win10, and I have the EXACT same result. :tired_face:
Turned to Ubuntu and have connection (of sorts) but alas NO operation :unamused:

Strange how some are working well and others “like us” are having challenges to test us.

I hope there is a solution soon, as I’m sure the team is working on.

Regards Jerry.

7

Isn’t that for building the firmware for the ODrive? I wasn’t thinking I need to reflash the ODrive to connect via USB.

In addition, I can’t get a USB connection, so how would I use FDU to flash the drive?

Sorry about the typo, I meant DFU. Since I actually want the device to work on a Raspberry Pi, I’ve switched to that platform, RPI3, Model B+, built fresh from NOOBS. When I plug the USB cable into the PI and turn on the power, I get the following devices:

/dev/serial/by-id/usb-ODrive_Robotics_ODrive_3.5_CDC_Interface_206736743548-if00

/dev/bus/usb/001/026

the last number (device number?) in the second device changes each time but the first device always appears the same. When I run odrivetool the devices vanish after about 50 - 60 seconds and odrivetool never connects the odrive. I’ve also tried to start it odrivetool --path usb:1:26 with the same results.

8

Hi Tom

Sorry to hear your having trouble, getting things up and running on windows can be frustrating at times. I have a working 48V V3.5 board running on windows 10 so I can confirm it is possible. Are you able to confirm a few things for us:

  • What power supply are you using?
  • When you power on the board with it connected to your PC do you get the usual ‘device connected’ chime from windows 10?
  • Did you install odrive using standalone python or through Anaconda and do you know if you have any other versions of Python installed?

You may also want to try reapplying the USB drivers with Zadig as windows can be funny with drivers sometimes depending on what order you install things.

9

I sent this yesterday from gmail but it doesn’t get through back to here

Hey Richard,

Thanks for the response. First, to answer your questions:

I have two power supplies, one is a Mean Well 48V 32A, the other is a Mastech bench supply that can do 48V at 6A. I use the bench one to see the current draw or an ammeter on one of the supply wires for the Mean Well.

I don’t have speakers on the Windows PC I’m using, but I can see the ODrive come up every time when I turn it on after it’s connected. Right now, it comes up as COM3 and as a libusb-win32 device in the Device Manager.

I installed odrive through Anaconda and there aren’t any other versions of python on the PC.

Second, some odd things. When I first attached the ODrive to the PC and started using it, everything went fine for about a day, I got to where I would issue the

odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE

command and I would get an axis error 257 (0x101: ERROR_ENCODER_FAILED | ERROR_INVALID_STATE) and an encoder error 2
(0x2: ERROR_CPR_OUT_OF_RANGE). As I tried to start solving this problem, the ODrive would no longer connect to the PC. The ODrive is still by Windows and the devices are created when I plug it in and turn on the power but odrivetool never sees it, if I run it --verbose, I get a fault in the python usb at bulk_init. I did try redoing the zadig stuff, it made no difference that I could tell. And the libusb-win32 ODrive device shows up every time.

Third, one of the guys I’m working with has a 24V ODrive working perfect down in Florida, I’m in PA, and we’ve been trying to compare to find why his works and mine doesn’t. Also, he has a little NEMA 24 size motor and I have a 2 HP 110mm monster.

Fourth, since we want the motors to work off Raspberry Pis, I gave up on Windows and tried the Pi. It turns out if you take a NOOBS disk and let it do the update / upgrade, the Linux setup is good, python3 is there, you have to say sudo pip3 install odrive, do the udevadm stuff and that’s it. The Pi also creates devices when you plug in the ODrive (/dev/serial/… and /dev/bus/usb/001/…) and turn it on. My ODrive still fails when you start the odrivetool, with --verbose it also shows a fault in the usb bulk_init.

Fifth, this is really getting long, I bought two ODrives and Vince (FL guy) said I should try the other one. So, I did and it connects immediately on the Pi. I get the exact same error as before with my big drive and I’m worried that there’s some problem with using 48V and a big motor. So, I’m turning the voltage down to 24V and getting a small BLDC to see if I can get that working. I also bought a 24V ODrive to test with.

That’s my current progress, I’d be happy for any advice or to answer any questions.

Thanks again,

Tom

10

Hi @tomgroshans, sorry you are having problems.

First of all, you can ignore the stuff about tup.config, that’s indeed only relevant if you are modifying the firmware yourself.

I think this is the big hint. Can you try plugging the 2nd (works on Rpi one) into your Windows machine, and see if it will also connect there?

If this works, we have more evidence that it’s something that’s persistently broken with the 1st ODrive. You can try to do a factory reset of your 1st ODrive by doing the DFU procedure, including the “How to force DFU mode (ODrive v3.5)” part.

I don’t think there is something about big motors that would break the ODrive’s ability to communicate, so don’t worry about 48V and big motors.

11

Hey Oskar,

Thanks for looking at this. This is the device manager after I power on the ODrive.

image
image.png427×591 21 KB

It’s almost the same for the one that doesn’t work and the one that does. The “broken” one gets set to COM3 and the working one gets set to COM4. When I run Anaconda against the “working” one, the drive is recognized immediately, YEAH! It also calibrates the very light weight BLDC motor I have attached (15V, pulls about an amp at 600 rpm) That works fine. I’m getting a middle sized motor to try out and see how that goes.

I tried the odrivetool dfu command, it just hangs at Waiting for ODrive. So I put the board in DFU mode and it connected and started rewriting it and then failed with the following:

image
image.png979×928 30 KB

I’m including the text below in case the png is unreadable:

(base) C:\temp>odrivetool dfu
ODrive control utility v0.4.1
Waiting for ODrive...
Found ODrive 206736743548 (v3.5-48V) with firmware [unknown version] in DFU mode
Checking online for newest firmware... found v0.4.2
Downloading firmware v0.4.2...
The configuration cannot be backed up because the device is already in DFU mode. The configuration may be lost after updating. Do you want to continue anyway? [Y/n] y
Erasing... done
Flashing... (sector 0/6)
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
C:\ProgramData\Anaconda3\Scripts\odrivetool in <module>()
    140         print_version()
    141         import odrive.dfu
--> 142         odrive.dfu.launch_dfu(args, logger, app_shutdown_token)
    143
    144     elif args.command == 'liveplotter':

C:\ProgramData\Anaconda3\lib\site-packages\odrive\dfu.py in launch_dfu(args, logger, cancellation_token)
    448     firmware = FirmwareFromFile(args.file) if args.file else None
    449
--> 450     update_device(device, firmware, logger, cancellation_token)
    451
    452

C:\ProgramData\Anaconda3\lib\site-packages\odrive\dfu.py in update_device(device, firmware, logger, cancellation_token)
    379         for i, (sector, data) in enumerate(touched_sectors):
    380             print("Flashing... (sector {}/{})  \r".format(i, len(touched_sectors)), end='', flush=True)
--> 381             dfudev.write_sector(sector, data)
    382         print('Flashing... done            \r', end='', flush=True)
    383     finally:

C:\ProgramData\Anaconda3\lib\site-packages\odrive\dfuse\DfuDevice.py in write_sector(self, sector, data)
    185             status = self.wait_while_state(DfuState.DFU_DOWNLOAD_BUSY)
    186             if status[1] != DfuState.DFU_DOWNLOAD_IDLE:
--> 187                 raise RuntimeError("An error occured. Device Status: {!r}".format(status))
    188
    189     def read_sector(self, sector):

RuntimeError: An error occured. Device Status: (0, 2, 0, 0)

(base) C:\temp>

I then tried it on the Pi and got

pi@raspberrypi:~ $ odrivetool dfu
ODrive control utility v0.4.1
Waiting for ODrive...
Traceback (most recent call last):
  File "/usr/local/bin/odrivetool", line 142, in <module>
    odrive.dfu.launch_dfu(args, logger, app_shutdown_token)
  File "/usr/local/lib/python3.5/dist-packages/odrive/dfu.py", line 450, in launch_dfu
    update_device(device, firmware, logger, cancellation_token)
  File "/usr/local/lib/python3.5/dist-packages/odrive/dfu.py", line 257, in update_device
    serial_number = device.serial_number
  File "/usr/local/lib/python3.5/dist-packages/usb/core.py", line 830, in serial_number
    self._serial_number = util.get_string(self, self.iSerialNumber)
  File "/usr/local/lib/python3.5/dist-packages/usb/util.py", line 314, in get_string
    raise ValueError("The device has no langid")
ValueError: The device has no langid

I have some experience with programming microprocessors and would be happy to reflash this one using the ST-Link if you think that is a good idea. I just bought the gear and I’m going to be gone till Thursday, I could do it then. Let me know what you think would be good.

Thanks again for looking at this,

Tom

12

Awesome, glad to hear it!

Yes, please go ahead and try flashing it with the ST-Link

13

Ok, as soon as I’m back and have the gear, I’ll work my way down that route. Then I’ll start seeing about the larger motors and 48V. I’ll keep you posted,

Thanks again,

Tom

1 Like
14

Alright, a variety of things.

First, the Firmware doesn’t build under the current version of Raspian on the Pi. I think it’s minor stuff but I didn’t run it down because the PC version works fine.

Second, the Firmware builds fine on the PC with VSCode and I can flash the board with the ST-Link device. Even with the new firmware on the board, odrivetool dfu does not work. Either in Run mode or DFU mode. Both boards connect and work when flashed with the new firmware. As a side note, you MUST run Anaconda as an administrator on my PC and I have to reinstall the ST-Link drivers each time I restart my PC.

Lastly, I’m going to start experimenting with the large motor today and tomorrow, I’ll keep you posted,

Thanks,

Tom

15

We found a different tool that can flash the ODrive in DFU mode. It’s not as sleek and automated as the dfu command in odrivetool, but hopefully it can help if you are getting errors.

Instructions here

16

That’s cool, I’ll try it soon. Right now I’m trying to get my big motor to work. I built the .elf file with the following tup.config:

# Copy this file to tup.config and adapt it to your needs
# make sure this fits your board
CONFIG_BOARD_VERSION=v3.5-48V
CONFIG_USB_PROTOCOL=native
CONFIG_UART_PROTOCOL=ascii

# Uncomment this to error on compilation warnings
#CONFIG_STRICT=true

But the odrv0.config looks like this:

config:
  brake_resistance = 50.0 (float)
  enable_uart = True (bool)
  enable_i2c_instead_of_can = False (bool)
  enable_ascii_protocol_on_usb = True (bool)
  dc_bus_undervoltage_trip_level = 8.0 (float)
  dc_bus_overvoltage_trip_level = 25.920001983642578 (float)

Can I set the dc_bus_overvoltage_trip_level to 49.9V or so? I have a 48V board and I’d like to use that.

17

Ok, working on the big motor, shown here,

http://gemsmotor.com/nema-42-brushless-dc-motor, it’s the GM110BLF140-430.

I have been unable to get it to calibrate. Right now, I set the calibration_current to 15 and get error 0x101 on the axis and error 0x02 on the encoder. When it runs the calibration it spins the axis around twice counterclockwise. On a working calibration on another motor, it spins the axis once CCW and once CW. Also, when I set the direction = -1, in motor.config, it doesn’t switch directions in the calibration.

When the calibration fails, the motor config looks like this:

pre_calibrated = False (bool)
pole_pairs = 7 (int)
calibration_current = 15.0 (float)
resistance_calib_max_voltage = 10.0 (float)
phase_inductance = 6.228371057659388e-05 (float)
phase_resistance = 0.029296014457941055 (float)
direction = 1 (int)
motor_type = 0 (int)
current_lim = 10.0 (float)
requested_current_range = 70.0 (float)
current_control_bandwidth = 1000.0 (float)

So, the problem seems to be that it can’t switch the direction of the motor. Any suggestions?

Thanks,

Tom

18

The spec sheet on that motor says it has 8 poles - I’m assuming they mean pairs. Try setting your config.pole_pairs to 8.

19

I tried 8 and it made no difference but 4 worked, thanks, that’s really a big help. Just to have a complete description available:

I have a large BLDC motor, http://gemsmotor.com/nema-42-brushless-dc-motor the GM110BLF 140-430, that I could not get to calibrate.

I would get a variety of errors but the two I would see most were:

axis.error 0x41 and motor.error 0x11
or
axis.error 0x101 and encoder.error 0x02

for my motor, if you set the calibration current too high, >30, you get the first error, too low, <12, you get the second error. Also, I had the pole count wrong, I left it the default 7 when it should have been 4 (thanks metanoic). This caused the ODrive to be unable to reverse direction after running about two rotations in the calibration. Now the motor calibrates and seems to be working. Onward!

2 Likes
20

Awesome. I’m happy I was able to help!