Limit being reached causing error state shutdown?

Support
1

We have a problem with the oDrive v3.4 24v and 48v, firmware version 0.4.0, hitting some kind of limit as we increase the rpm and entering an error state shutdown and I don’t know how to get past this limit.

Also since this firmware version, we’re having lots of ChannelBrokenExceptions with the usb connection, so trying to read odrv0.axis0.error after a fault is pretty much impossible. I can usually recover the broken comms by cycling the power to the oDrive, but occassionally it requires a reflashing of the firmware with the STLink.

Regarding the limit we are hitting, we thought maybe the 580KV motor isnt up to the 12000 rpm we are aiming for, so we ran it from a 60A Simon K series ESC and acheived twice the 6000 rpm that we are managing from the oDrive, using the same 24vdc @50A power supply.

So then we thought maybe the encoder (2000 cpr) signals are maxing out at this speed, so we ran sensorless and still hit this error state at the same 6000 rpm.

I have odrv0.axis0.motor.config.current_lim = 50.0

Are there any oDrive default settings that could be limiting us getting the performance we are trying to acheive?

Regards,
Neil

2

I’m seeing something similar with an oDrive v3.5 24v firmware 0.4.0 and a keda 63-64. Installed a cui 102-v set to 8192 CPR for closed loop control. I can not drive the motor above a certain rpm or the drive shuts down.

When odrv0.axis0.controller.config.vel_limit is set above 350000 and I command motor position, the motor accelerates as it moves to position. When it hits a particular speed, the oDrive stops driving the motor and the motor is allowed to freewheel to a stop. It does not reach its position. I can still communicate to the driver afterwards, but so far only cycling the power and re-initializing will allow me to command the motor again.

when odrv0.axis0.controller.config.vel_limit = 350000 the driver will often shutdown as I command position, when it’s set to 400000, it will always shut down before the motor reaches its commanded position.

I’m still reading the documentation and doing tests. If I determine anything else of interest, I’ll add it here.

On anything below these speeds, I must say the oDrive works well so far.

3

Did you also update the odrivetool to the latest version? Which version are you running?
We will need to read the error values to decide what to do next.

4

@motor80 Can you try to read the error codes?

5

Yes, it was a new pc installation, so no previous version had been installed. ODrive control utility v0.4.0.dev
It seems to be the 24v version of the V3.4 board that has prolific problems with ChannelBrokenExecptions. The 48v version of V3.4 doesnt seem to suffer with this.
Using the 48V version I was able to recover fault codes,
odrv0.axis0.error = 65
odrv0.axis0.motor.error = 8
odrv0.axis0.encoder.error = 0
Thanks.

6

With regard to the ChannelBrokenExceptions. …

You’ll want to run odrivetools with the --verbose option and reproduce the error and then provide the console log/output. Alternatively, if you’re programming against the odrive python object, you can override the logger argument on find_any() and replace it with a logger that has verbose mode enabled and you’ll similarly get more information.

def find_any(path="usb", serial_number=None,
    search_cancellation_token=None, channel_termination_token=None,
    timeout=None, logger=Logger(verbose=False)):

The ChannelBrokenException error can be caused by an error in the core usb library, particularly errors 19 and 32 (“no such device” and “pipe error” respectively), a TimeoutError during discovery (prior to fetching endpoint 0) and when the retries and timeouts are exhausted while waiting for an ACK to a request. That’s everything I see, anyhow.

You could resort to changing the timeout and retry counts and observing, black-box like, any changes in behavior/duration to see if it’s erroring in that area of the logic - but you’re way better off getting verbose logging going.

1 Like
7

Thanks metanoic, I have verbose mode enabled now.

This error suddenly occured whilst connected and motors idle…

Exception in thread Thread-1:
Traceback (most recent call last):
File “C:\Users\njs\AppData\Local\Continuum\anaconda3\lib\threading.py”, line 916, in _bootstrap_inner
self.run()
File “C:\ODrive\tools\gui.py”, line 115, in run
actual(self.name)
File “C:\ODrive\tools\gui.py”, line 119, in actual
text = Text(app, text=" " + str(int(odrv0.axis1.encoder.pll_vel * factor)) + " rpm ", grid=[2,1])

Upto here is my GUI code, below is oDrive code

File “C:\ODrive\Firmware\fibre\python\fibre\remote_object.py”, line 201, in getattribute
return attr.get_value()
File “C:\ODrive\Firmware\fibre\python\fibre\remote_object.py”, line 74, in get_value
buffer = self._parent.channel.remote_endpoint_operation(self._id, None, True, size)
File “C:\ODrive\Firmware\fibre\python\fibre\protocol.py”, line 311, in remote_endpoint_operation
raise ChannelBrokenException() # Too many resend attempts
fibre.protocol.ChannelBrokenException

8

Going back to the oDrive hitting some kind of limit and shutting down, I’ve been experimenting with controller.config.vel_gain.
In particular, I had controller.config.vel_gain = 0.001 when the oDrive was tripping a shutdown at about 6000rpm, but at the other extreme we also wish to run at about 50rpm, the motor was struggling to turn smoothly with this setting, so I increased controller.config.vel_gain to 0.007 which improved this greatly, however this setting then caused the oDrive to trip at about 3500rpm. Much less than before.
Natuarally, I tried reducing controller.config.vel_gain to 0.0001 to see what effect that would have to my top speed, but unfortunately not much luck.

1 Like
9

Motor error 0x8 when turning up gains and/or pushing higher currents/speeds is a symptom of this flaw of the v3.4 design:

Are you able to do the mod suggested in that post? If not, DM me and we can find a different solution.

10

Hi Oskar, welcome back from your vacation and thanks for your reply. I have made those changes to the capacitor grounds and tried again with same results, odrive tripping out as it approaches 6000rpm. I’ve also swapped out to a different 500KV motor with the same results.

Should I be reducing the vel_gain dynamically as higher velocities are being commanded?

Thanks,
Neil

11

Further tests show that the ODrive shutting down at high speeds may be being caused by the power supply. I’ve had several power supplies connected up and had different cut off speeds. When monitoring the supply on an oscilloscope, the supply begins to oscillate with 5v pk-pk ripple then the ERROR_DRV_FAULT occurs and the motor shuts down. What power supplies are the community using? I’ve used a Mean Well DRP-240-24 which outputs 24vdc at 10A. A Turnigy 1200W psu 15-30vdc at 50A. A TTI EX354RD 280W bench power supply and even a Turnigy 4S 10C battery pack. The psu which allowed the motor to run the fastest was the TTI bench power supply. The Turnigy 1200W psu has some pretty hefty capacitors inside it as it takes several seconds to switch off.
Any suggestions?
Thanks, Neil.

12

Hi, sorry I missed your post back in mid July.
The DRV_FAULT is a known hardware issue with ODrive v3.4. Since you tried the fix and it didn’t work, the only remaining option is to replace your board with a v3.5. We’d be happy to send you a replacement, just email us and include your original order number.

Sorry about your frustration,
Cheers,
Oskar

13

Ah I see, thanks Oskar, no worries.