Serious FOCer (84V VESC 6 based controller)

[shaman]

Thanks everyone! I'm still open to ideas on how to have easily interchangeable connectors. That was part of the logic in having the separate connector panel as I could design different panels for different connector types/configurations and not have to alter the design of the control board.

[john61ct]

That's the point of my "one connector" idea, embed the different adaptations into different pigtail harnesses.

[shaman]

@john61ct I see what you're saying now.

Maybe something like the connectors linked below?
https://www.molex.com/molex/products/fa ... troduction

https://www.molex.com/molex/products/fa ... troduction

[john61ct]

Yep, that's the idea, all pins needed accommodated in one big block on the board.

Sell / spec one standard default harness, maybe another with long unterminated wires.

DIY users can make up their own to suit their use case

[shaman]

UPDATE SUMMARY:

Unreliable no-name USB connector is unreliable. The pinout isn’t standard and the datasheet doesn’t say anything about it. USB comms issues now resolved with rigged USB cable and jumpers

Had MISO and MOSI swapped on the DRV SPI comms. DRV was freaking out because of it (throwing every fault possible). I adjusted the code to compensate.

Worked out some more of my stupid code mistakes. Replaced the DRV with a fresh one after a I violated it with dysfunctional code. Got the controller to fire up with only one error. It’s throwing a “high current offset fault” which may(and hopefully) correct itself upon motor detection. The next step is to solder on some power/motor cables and see if I can spin something up.

[district9prawn]

Bummer DRV dead before you even put any power through the mosfets? Hopefully this new drv is more robust than the 8301/8302.

Cold joint on DRV current sense would cause it. This new DRV is leadless right?

[shaman]

Yeah the new DRV is leadless and has more fault detection. Really I believe it was a combination of having the MISO and MOSI swapped along with errors in my code that eventually led to the DRV failing. It was sinking a lot of current through some wrong pins which would eventually cause it to fail. I believe that once my errors are ironed out then this device will be fine. Tuning the IDRIVE is also key to keeping it alive and well based on some of TI's e2e forum posts.

[shaman]

it spins!.jpeg (127.89 KiB) Viewed 2817 times

And we have lift off!

Just BLDC mode (trapezoidal control). Running FOC motor detection through the wizard yields a sensor error (I’m running it sensorless right now so idk what’s that’s about yet). Doing FOC motor detection through the not-wizard just yields no response and claims bad detection. After the attempted FOC motor detection the current offsets shoot way high. I need to analyze the current sense part of the controller to make sure things are accurate...

I’ll figure out what’s going on with FOC for this thing…else I’ll have to change its name

[drdrs]

Which part of the not-wizard is failing, RL or the flux linkage? I recall being able to get the R and L measurements to work but having to tweak the omega/ERPM parameter to get the flux linkage to work.

[shaman]

It doesn't even make it through the RL. This may take some analysis in lab with am oscilloscope to see what's going on

[shaman]

Just got FOC to work! Turns out it was an issue with the DRV8323R initialization code. When the code executes to set the current amplifier gain it also writes values that cause the current sense reference voltage to be Vref(3.3V) instead of the proper Vref/2 for bidirectional current flow measurement (crucial for FOC). I fixed it in the drv8323h.c file, compiled, and ran it. Now I gotta highlight the issue on the Github for the firmware so it can fixed for everyone.

[SRFirefox]

Excellent work! That's pleasantly little debugging to get a motor spinning, let alone under FOC. Looks like all of the design review time with Marcos and the care you took in the design phase is paying dividends. I can't wait to see how this FOCer performs under load!

P.S. Are you using a microUSB plug or a USB-C for the onboard connector? Can I vote for C if you haven't decided yet?

[shaman]

I got micro USB on there right now. I originally was trying for USB C but then I was told about some certain resistors that have to go with it to identify orientation and then I got scared and then I abandoned it... I just need to go back over the design review notes that address this and look into how to correctly implement USB C. I'm sure it's not hard, I just didn't want to deal with it at the time.

[SRFirefox]

Check out ST's application note 5225. Section 10.1 describes the bare minimum to convert a USB 2.0 device to use a USB-C connector. In this case, you can simply use Vbus on its four pins as your 5V source, though it's not shown in that diagram.

https://www.st.com/resource/en/applicat ... 536349.pdf

[shaman]

Perfect! Looks like "Legacy device using USB Type-C™ receptacle" is the exact diagram I need. Time to work this into the design.

[john61ct]

https://hackaday.com/tag/usb-pd/

https://github.com/ReclaimerLabs/USB_PD

Sorry below not clickable

Screenshot_20191025-143536.jpg (55.77 KiB) Viewed 2754 times

[shaman]

image.png (175.52 KiB) Viewed 2693 times

Did some quick testing to verify hall sensor input and gather data at light load. This is just a little 350W hub motor with 236uH of inductance. Results aren't bad I guess. Will be do doing some tweaking in the DRV initialization to dial in slew rates and fault protection thresholds.

[wil]

It's out of scope of this project, but if you had a controller setup for USB C PD and ran power through a motor phase to use as a boost convertor you could have a nice little 100 watt charger available anywhere.

[shaman]

That would be cool. I've seen other motor controllers that have charging functions. Does any one have any documentation on how to use a motor controller as a buck and/or boost converter for charging applications?

[nieles]

the adaptto controller can function as a boost converter (input voltage lower than min pack voltage) i cant find any documentation on this, but its pretty straight forward.

the way they it works: disconnect a phase leads so you have access to the H-bridge
battery stays connected in the same way as if it were a motor controller.

on the the phase leads input your power supply(Ud) with caps (Cd) in parallel and inductor (L) in series. (referenced to BAT-)
Uo is the battery.
T1 is the bottom switch T2 is top switch

[john61ct]

Nucular
viewtopic.php?p=1495321#p1495321

[shaman]

@nieles So an external inductor would be needed? I was hoping to be able to utilize one of the motor phases as the inductor in the buck converter topology. Since the controller assesses the inductance of the motor, an ideal switching frequency could be found to make it work...maybe.

[nieles]

depending on the inductance and max phase current possible you *could* use the motor winding's.
there are several parameters that need to be considered:
pack voltage (given)
charge current
PSU voltage
Inductor value
max switch frequency
max inductor current (inductor saturation current?)

i did some calculations on all this for an LDC bias supply for a project at work. when i have some time i will find my notes or spreadsheets on this for you.

[nieles]

if you look at the wiring diagrams for the nucular controller you see he uses the motor winding's. if things overheat he suggests an external inductor in series.

i would at least add some input capacitors, but i don't see them in the nucular schematics. theoretically you can use the output caps of the PSU.

[Feist92]

So glad to see you've got this spinning a motor!
Definitely put my name down for one