ODrive v3.5 not connecting in Windows

Support
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!

21

Glad you got everything working!

To answer this question:

The default for the 48V version of the firmware should be dc_bus_overvoltage_trip_level = 51.84. I don’t know how you ended up getting the value that’s intended for the 24V version.

22

I’m having the issue of Windows (Anaconda) not recognizing the ODrvie 3.5!
Using Zadig, I did install the usb driver and it does shows up in my device manager!

temp1
temp1.jpg810×1288 178 KB

However, odrivetool in Anaconda does not find the odrive!
Searching in the community comments, I found that some people resolved this through disabling Odrive CDC (which is what I have done, per the snapshop above), some resolved the issue through flashing the device using the ST tool, which is what I did, but still no hope!
All I get is Anaconda asking me to connect the odrive!

I also tried a different computer. The issue in that one was even worse! :slight_smile:
On that computer odrivetool wouldn’t run. It would give the error message of:
[TerminalIPythonApp] WARNING | File not found: ‘C:\Users\Username’

BTW, I’m not modifying the firmware or anything! Just trying to run odrive for the first time, using Windows and Python!

Any help is appreciated!

23

Can you try running odrivetool in verbose mode, and let us know if there is any additional information?
odrivetool -v

24

Hi,

Thanks for the response. That command gives the message of “no response - probably incompatible”.
here what I see when I use that command:

C:\Users\install>odrivetool -v
ODrive control utility v0.4.6
Waiting for ODrive…
USB discover loop
Please connect your ODrive.
You can also type help() or quit().

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 2

no response - probably incompatible
USB discover loop
USB discover loop
USB discover loop
USB discover loop

25

BTW, I tried using arduino for running the device and spinning a motor (for the first time), but that also did not work!

It does the initial tuning (pressing 0) and the motor turns by a fraction of a turn. And also it does read the encoder. But, when I press “s” for “test move” it does nothing!

I hope you can help, as I have not been able to do anything with the purchased ODrive yet!

Thanks

26

Can you try flashing the new firmware version 0.4.7?

27

Today it just worked, without flashing! Thanks