For anyone using the RazorsEdge branch on my fork, if you’re having weird USB behaviour…
I addressed the issue where the entire configuration was being initialized on the comms thread, and was able to reduce the size of the comms thead’s stack from 32KB to 2KB. Unfortunately there was no good way for me to know exactly how much the comms thread was “actually” using, and it seems 2KB was too small. The stack size has been doubled to 4KB. In testing, one user found that his comms thread used 2052 bytes (4 bytes too many for the original 2KB).
Fixing this comms stack issue has cleared up all of this user’s “strange” behaviour and lock-ups when closing a serial stream. If you’re experiencing these same issues, please update to the newest version of RazorsEdge.
In other news, RazorsEdge is going to be ported over to master at some point. We’re in the process of setting up a test plan and I hope to have the testing done by the first of the year (but no guarantee there).
Thank you, thank you, thank you!!
This brought the connection time for odrivetool from several minutes (best case, worse case it would never connect) to reliably connecting in about 15s. I’m so happy
For reference I’m on macOS Catalina 10.15.2. I will do some more testing and let you know if this really does fix all the USB related issues I was having.
Happy to hear RazorsEdge is undergoing testing for merging. If you want some help let me know! I’d be happy to help, time permitting
Does this update apply to the Endstops branch as well? I’ve been having weird USB dropouts and lock-ups. Thank you!
@tomsepe Did a brief check and it looks like this is only on RazorsEdge. You could pretty easily add these changes to your local Endstops branch though, there’s not too many changes.
thanks for the response… is this the commit that has the changes I’d need to make?
@Wetmelon Hmm I’m still seeing very long connection times in odrivetool (near a minute).
The ODrive itself shows up instantly in my USB devices, but after starting odrivetool I need to wait anywhere between 30 seconds and a minute for odrivetool to recognize it. Same goes if I do something like odrivetool backup-config…
@kedvall the delay you are seeing is the firmware configuration being sent over. This is intended behaviour, and lets python know which functions are available on the odrive. If you are confident the firmware won’t change you can hack the python library to buffer to the configuration.
Sure, that makes sense. In that case, why is the delay so inconsistent? When connecting I’m seeing delays anywhere from 15 seconds to over a minute. The ODrive is showing up on my Mac’s device tree as soon as it’s connected. How long is the expected delay?