I’m new to FOC, but I have a new art project underway and I’m trying to select a BLDC motor. The mechanism will be similar to one I’ve already built with a stepper motor and TMC2209 driver.
For an idea of the desired motor size and torque, the existing design runs pretty well with a high-torque 65Ncm Nema 17, although even with microsteps it still creates an unacceptable level of whining noise.
So, an updated motor will ideally run with almost silent operation at rather low speed (max 200rpm) and with variable speed within each revolution. I’ve seen numerous references to gimbal motors with FOC for robotics and other applications, but this motor needs to have a shaft (ideally 5mm) for linkage.
Thanks for considering this!
I wouldn’t dismiss gimbals immediately because of linkage issues. You might be swapping linkage problems for torque/gearing problems.
Can you redesign what you are connecting to or do some sort of shim so that shaftless gimbals can still be used? Googling “motor shaft flange coupler” might give to some ideas
What have you tried to make the tmc2209 quiet? My 3d printer is pretty quiet after i enabled silent chop in firmware.
Another avenue to explore is continuing to use your nema17 with simple foc (it supports steppers too). You could have a play with a cheap stepper driver
Fyi: I’ve struggled getting steppers past 400rpm (closed loop) using simplefoc but I’m not an expert
Thanks for these ideas. I will look into silent chop. I was only aware of the basics of microsteps with the tmc2209.
I wondered about a flange → shaft coupling for the front of the gimbal. Can you recommend a gimbal motor that can handle load torque comparable to this stepper I’m using? Just something to get started with?
I was able to get completely silent motion out of my stepper motor with a tmc2209 just with default settings. There it a feature called microplyer which smooths the motion to the same as 256 microsteps which is enabled by default. I was never able to get the arduino or any other driver to work so I could never change the default settings. They can’t just make it a simple interface, there is all kinds of crazy requirements for the data frame etc. and they don’t really want to tell you the exact details.
The UART interface (to 2209) for configuring the registers is not so complicated… you can just compose this message by appending the appropriate bytes into an array and then sending it off with the standard UART (Serial) library from Arduino. They also provide the code for generating the CRC, see ch. 4: https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC2209_Datasheet_V103.pdf
exactly what bytes to do what though? That’s the thing. The arduino library doesn’t work, if it is so easy I don’t know why they aren’t able to make a working driver… manufacturers should always provide exact driver code written in C, or a complete detailed specification with everything in one place. All the details you need should be in the datasheet, but there was a lot of stuff missing when you really got down to it and needed to know exactly what byte values to send etc.
it’s all in the datasheet… chapter 4 gives you the packet structure, and chapter 5 gives you the register names and valid values.
Just for the record: You can use classic jumpers to config the TMC2209. There is a pretty complete description here. But read carefully, there are different board revisions and wrong pin-descriptions. But in the end they clarify that!
@Owen_Williams the reason, why you couldn’t spin them faster could be, the chip was still in stealth-chop mode. In RRF we switch over to spreadcycle at a certain speed.
There are unfortunately many parameters you cannot set with the jumpers.
If you believe it’s easy to write a driver perhaps we could pass the hat and contract with you to fix up the existing driver for arduino so it actually works, and reliably. One for micropython would be nice too. I think there might be one but if there is it doesn’t work because I would have tried it and never got anything working.
The features I particularly wanted were the coolstep and the missed step detection so I could do sensorless homing and other stuff like that.