If i use hex(odrv0.axis0.error) before I put it into closed loop mode it returns 0x0 . If i use it after i get no response.
If use odrv0.axis0.current_state before i put it into closed loop mode it returns 1. If i use it after i got no response.
Can you show us a screenshot of what it looks like when you don’t get a response?
Hi,
Thanks for your help.
This is what it looks like when it freezes.
It doesn’t allow me to input anything.
I just tried again and for some reason I was able to move the motor a couple of times before it became unresponsive again! Very strange, i didn’t change any of the physical setup or any settings.
As you can see i was able to move the motor back and forth 5 times before it became unresponsive again.
FYI When the drive becomes unresponsive it still holds its position if i try and move the motor by hand.
Thanks again!
When it’s in the frozen state, can you do ctrl+c and then post a screenshot of the entire stacktrace?
Thanks
---------------------------------------------------------------------------
KeyboardInterrupt Traceback (most recent call last)
~\Anaconda3\lib\site-packages\fibre\shell.py in <module>()
----> 1 odrv0.axis0.controller.pos_setpoint = 10000
~\Anaconda3\lib\site-packages\fibre\remote_object.py in __setattr__(self, name, value)
250 if isinstance(attr, RemoteProperty):
251 if attr._can_write:
--> 252 attr.set_value(value)
253 else:
254 raise Exception("Cannot write to property {}".format(name))
~\Anaconda3\lib\site-packages\fibre\remote_object.py in set_value(self, value)
76 buffer = self._codec.serialize(value)
77 # TODO: Currenly we wait for an ack here. Settle on the default guarantee.
---> 78 self._parent.__channel__.remote_endpoint_operation(self._id, buffer, True, 0)
79
80 def _dump(self):
~\Anaconda3\lib\site-packages\fibre\protocol.py in remote_endpoint_operation(self, endpoint_id, input, expect_ack, output_length)
295 self._my_lock.acquire()
296 try:
--> 297 self._output.process_packet(packet)
298 except ChannelDamagedException:
299 attempt += 1
~\Anaconda3\lib\site-packages\fibre\usbbulk_transport.py in process_packet(self, usbBuffer)
96 def process_packet(self, usbBuffer):
97 try:
---> 98 ret = self.epw.write(usbBuffer, 0)
99 if self._was_damaged:
100 self._logger.debug("Recovered from USB halt/stall condition")
~\Anaconda3\lib\site-packages\usb\core.py in write(self, data, timeout)
385 For details, see the Device.write() method.
386 """
--> 387 return self.device.write(self, data, timeout)
388
389 def read(self, size_or_buffer, timeout = None):
~\Anaconda3\lib\site-packages\usb\core.py in write(self, endpoint, data, timeout)
946 intf.bInterfaceNumber,
947 _interop.as_array(data),
--> 948 self.__get_timeout(timeout)
949 )
950
~\Anaconda3\lib\site-packages\usb\backend\libusb0.py in bulk_write(self, dev_handle, ep, intf, data, timeout)
531 ep,
532 intf,
--> 533 data, timeout)
534
535 @methodtrace(_logger)
~\Anaconda3\lib\site-packages\usb\backend\libusb0.py in __write(self, fn, dev_handle, ep, intf, data, timeout)
614 cast(address, c_char_p),
615 length,
--> 616 timeout
617 )))
618
KeyboardInterrupt:
Hope this helps.
Thanks
Hm are you at all able to try connecting from a different PC?
Hi! I’m having the same issue in both V0.4.7 and V0.4.5 of odrivetool and firmware.
I’m running an ODrive v3.3 on Windows 10.
I’ve also tried on a different PC with Windows 7 with the same results.
This is repeatable for me in both cases, and only happens once closed loop mode has been entered.
What happens if you set the startup_closed_loop_control flag to true before enabling the axis rather than setting the requested_state separately? Do you still get the unresponsive behavior?
Yep same result unfortunately
Sorry for the delay in answering: do you still have this problem?
I have the same problem when I use longer cables for the motor
I’m also having this problem. I’m using the setting <axis>.config.startup_closed_loop_control = True for the race sim I’m developing. After settings this to True and rebooting, the Odrive isn’t available anymore in odrivetool.
I can use serial commands to control the position of the motors, but after a while this also becomes unresponsive. And because the odrive isn’t available in odrivetool, I can’t see any errors.
Please solve this problem.
I have the same issue with the 3.6 56V version. I have updated the firmware & all drivers. Unfortunately this leaves me dead in the water, is this just a defective unit or a known issue?
I had the same issue as described in the first post. My problem ended up being solved by putting a ferrite on the usb cable. The usb cable didn’t touch the motor wires but was inside a metal enclosure with them.
Hope this helps.
1 Like
I’ve exactly the same trouble !!! Any suggestion ?!!! I try on two different PC W10 & Ubuntu and a Mac
Best regards
Hi @Jean-Robert_Humbert, can you describe (or better, take a picture of) your setup? ODrive’s USB communication can be somewhat sensitive to grounding and other noise issues. Braiding your motor cables, using ferrite beads on the 3 wires together, properly grounding (or isolating, depending) your motor casing, etc can all have an effect on the USB performance.
Have someone tried to add a couple of TVS diodes between TP1/TP3 and TP2/TP3 pads?
A noise reduction should be pretty reliable for the usb connection at reasonable bounds, but high voltage spikes can ruin it all.
Hello everyone. I am starting to work with Odrive and the same problem happens to me, while I am configuring, calibrating and working with odrivetools, I have no problem, but when I run the command:
odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL
odrivetool starts out with problems. First it freezes the command for about 25 [s], and then it enables me a new command line, it does this a few times until it reaches a point where odrivetool directly freezes, and does not reset again. Among so many tests, I noticed that when it is frozen, if in that state I disconnect the USB cable, the odrivetool immediately enables me a command line, it is as if the communication between the odrive and the pc, through the communication cable, remained in an infinite loop without solving something … something that I don’t know what it is !!!
Please I need help inmediately!!!
Thank you very much to all!!!
Hello, although my comment is quite late, but I hope you can help !!!
As I had posted, I had the same problem. The characteristics of my engine are:
- Type: BLDC with encoder
- Voltage: 48 [Vdc]
- Nominal current: 20 [A]
- Encoder without pulse-index
But another characteristic that I think influences this issue a lot is the length of the motor cable, which in my case is 6 [meters]. When I started with this problem, I afflicted Anaconda, after doing a super cleaning on my PC, and reinstalling Python from scratch, in a Standalone way, when I ran Odrivetool again, the same thing happened to me, after executing:
odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL
Odrivetool was freezing me.
SOLUTION: Install a ferrite core in the power cables. Unfortunately I only got a toroid to which I could get 2 turns of cables (and not 3 as recommended), and that this toroid has a material that works in the range of up to 100 [MHz] (up to 300 [MHz] is recommended ).
In the same way, it was enough so that the Odrivetool no longer freezes! Then I must keep testing and testing !!!
SUCCESSES and I hope I have been able to help a little!
3 Likes