Yes I am new to it. I have not been able to get the motor to reliably spin up. It works just fine in the wizard, but fails as soon as I try controlling it. As such analysis tools are kind of useless. I think the main issue is that most of the motors with hall sensors that are used with a VESC have around 14 motor pole pairs. This motor has two pole pairs. So when run in sensored mode the VESC is expecting the hall sensors to trigger more frequently. Pretty sure the fact that they were not made it think that there was a load on the shaft so it kept dumping more and more current into the motor because I had it on RPM PID control and it was stuck on 0 RPM.
As for braking, you do not want to feed voltage back into the power supply. Batteries can handle that just fine. MOSFETs not so much. The VESC is designed to work with batteries. Going through the interface of VESC tool there is no direct options for setting it up with a powersupply. Things like it does not ask you the voltage. It asks you the number of lipo cells.
One issue I have with the VESC is that while they have a UART interface, it is completely binary. That would be okay if they maintained libraries to interface with it, but they do not. Instead it is up to the community to maintain the libraries. The ‘stable’ Arduino library for it is able to interface with the 3.X firmware. The ‘dev’ Arduino library for it is able to interface with the 4.X. The current release version of the firmware is version 5.X
ODrive on the other hand has been designed to work with power supplies and batteries. They include a breaking resistor with the board so you do not need to worry about feeding power back into the power supply. They also have a human readable UART interface and they directly maintain the Arduino and Python libraries for interfacing with it. This means that my original goal of being able to provide detailed feedback on motor current and torque is very doable with the ODrive.
Probably should subtract at least 75% for continuous (vs. peak?) power output. Which is still probably enough. It would be best not to obstruct its vent holes though.
Luckily they’re “slotted” and not just holes on the end, so I think i’m ok. And at $23/pop I’m ok releasing the smoke. The interesting thing is all the bearing formats I came across. 5x16x5, used for many 3d printers (ender 3), which led me to 8x16x5. Those could be used on a motor with an 8mm shaft, like the ones used for electric skateboarding.
So one thing I just found out is that it is best to have as short of wires as possible to the “Battery” from the VESC. Weird shit can happen if you dont. So my 10 feet of 10 gauge wire from my Powersupply to the VESC was probably a bad idea. I just ordered supplies to move all the electronics outside my enclosure.
You may find that some electrolytic caps right next to the power input on the VESC help out there, they’re pretty necessary on many stepper drivers if you want things to work as planned, I guess that a LiPo battery acts as a local capacitor in normal RC style use.
Nice that the ODrive does away with the need to custom tailor a back-EMF sinking solution to protect the PSU.
At this point I have already ordered the stuff to move all of the electronics out of my CNC cabinet which will put the ESC (either VESC or ODrive) right next to the powersupply so it becomes mostly a non-issue. All I am worried about now is EMF from the motor wires interfering with the now 1.5 meter long hall sensor lines and the end stops wires that are going to be run right next to them. I am going to be using Cat7 wire for those signal lines which will hopefully fix that. Cat7 being individual twisted pairs shielded from each other and then a second layer of shielding over that.
It’s more the other bits of the Shapeoko picking up the EMI from the motor wires that might be the issue, guess you’ll find out when you wire it up though and you can always switch over to screened motor cable later.
Well got the ODrive wired up and configured the best I can. It goes through the calibration system and even spins the motor a little bit. It fails though when trying to configure the hall sensors. Hoping the 8 feet of wire for the hall sensors is not the issue.
Looks like the issue is in the driver code. I do not think they every thought the ODrive would be used on a motor with so few pole pairs. The calibration is spinning the motor only 1/16th of a turn, but the code is expecting 8 pulses from the hall sensors. This requires spinning the shaft 2/3rds of a turn.
Had to increase the calibration current. Now the only issue is that if I go above 1500 RPM the ODrive goes into an error state. I think this is because I do not have the velocity tuning parameters just right.
