yes, there are quite a few designs on this forum using this chip, it’s a real winner!
I am a fan of this chip, it appears to have very nearly all that is needed for a driver in the class commonly required by people speaking on this forum, and also the code base already works fairly well with it due to prior efforts on the b-g431b-esc1 board, definitely a good move by ST micro to make that board available.
1 Like
This project seems to have a lot of similarities with https://community.simplefoc.com/t/the-field-stack-stspin32g4/3032/1
1 Like
Hey @AntonX , welcome to SimpleFOC!
I take it the CLN17 is your creation? It looks like an awesome project, and a beautiful website for it!
I think people are asking about FOC capabilities because that’s what we’re focused on here. But achieving good field oriented control on stepper motors is very demanding due to their high pole count, requiring a fast MCU and precise position sensor.
I think that you’re right that a good dedicated stepper driver like the trinamics will be hard to beat 
So I think you should continue in your path and see where the project goes, and in the mean-time, since we’re all doing open source there may be aspects other than the motor control scheme that we can share or learn from each other.
Very glad you like my project!
This is my first somewhat complex project that I’m releasing to the community. I understand that this might not be the right forum for this project, but I believe there are common ideas, such as closed-loop control, etc. Perhaps even an overlay for SFOC that will work with stepper motors and the Step-Dir interface would be a useful extension.
The project seems truly vast in terms of code volume, so I would be very grateful for mutual support of projects so that great ideas don’t gather dust just because of a lack of time, resources, or energy (unfortunately, I have a significant deficit of these).
I’m all for implementing more advanced functionality on the driver, even FOC, but only if it truly makes sense, offers tangible advantages, and doesn’t overload the microcontroller. I’m designing the project not just as a driver, but as a system with a large margin of computational power and interfaces. This way, everyone can make any (even if not the most optimal in terms of speed) additions to the functionality, which won’t conflict with the main tasks due to the memory/speed reserve, etc.
Moreover, these drivers could become something like the distributed brains of a printer or another CNC, eliminating the need for additional boards.
It’s all there in the realm of Duet3D and RepRapFirmware. There are also Chinese brands like Mellow or BigTreeTech with closedLoop stepper drivers running RRF
Mellow/Fly and Duet3D are open source. You can check their code and port it to the G431.
I see there’s a GitHub, but I don’t see any code? I’m curious specifically how you implement closed loop control with the 2209.
I’m also curious about the (sub-full-step) positional accuracy under accelerations or otherwise varying loads?
As it is with simple-foc, I’ve implemented a closed loop stepper on a 3d printer, using the step-dir listener class, and have tracked the positional accuracy during accelerations and constant velocity moves. Overall it seems very good, but I haven’t done the same test with a classic stepper driver. I’m not sure how the driver behaves, since microsteps are not necessarily precise as mentioned above.
I’ve noted that high jerk sections of a motion profile have instantaneously high positional error, and will probably require an acceleration feed forward term in the control loop to solve.
1 Like
Yes, I have seen these boards and they are good in terms of extruder boards (mellow). But in my opinion they are not the best option for tasks other than 3D printers due to overloading.
If we talk about S42B / S42C - there are much more problems there, and as far as I know they worsen the printing compared to TMC2209. Good comparison here. And it has no open firmware, which is a serious disadvantage for me.
I’m not sure if they are the benchmark for firmware
Unfortunately I don’t have a printer or anything to accurately measure the deviations, as I have left the country because of the war. So I am not able to provide this information now.
The uniformity of the subfield pitch is quite difficult to determine, because the driver itself (and its interpolator) works according to its own algorithm. I use the TMC2209 at 1/128 pitch all the time (not sure if 1/256 makes any real sense at all). And accordingly I can set the pulse rate to roughly what it needs to move properly.
The position recalculation goes at 8196Hz. There are 2 factors to this:
- The mechanical response of the stepper motor system is on the order of milliseconds, so that should be enough.
- The driver’s shim control frequency is 20-40kHz. So above 15kHz there is no point in controlling at all.
At high speeds, more than 1000RPM, it is difficult to talk about microshims at all.
So far I am testing the firmware and focusing on calculation of acceleration/jerk displacement. I plan to add S-shaped ramp. But for now not in closed loop, but in supervisor mode, not as real time correction, but control that there are no errors and signalling if it is the other way round. I hope I can publish the firmware soon if it works properly).
I see, so your control algorithm uses an integrator to drive what would classically be called the position setpoint of the 2209 in order to develop torque in the desired direction? So this is achieving something similar to foc, in a rather roundabout way?
For comparison on control frequencies, I’ve measured simple foc loop rates of 36KHz, and position controller loop rates of 16khz on an 84MHz stm32f401, which was using 50KHz pwm frequency on some drv8876 full bridge drivers.
I’ve been using the simple foc motor as a standalone servo, only setting safety limits for acceleration and velocity, and have been using Klipper as the high level motion planner.
I hope you’re doing well in this bad situation, this is interesting sounding work and I’m looking forward to seeing more about it.
Didn’t quite understand the question. But the general idea (in the current phase of starting the adventure of the project) is the same approach as printers, that if we gave a command to come to the right position, the motor will come. But with an important difference - with a supervisor on the encoder side. This can already solve a lot of problems of classical drivers.
But I would be happy to experiment with different functions, clipper, etc., but I don’t have time to do this amount of work and learn programming at the same time).
I’m interested to see how TMC2209 works in stealschop at high speeds (4000rpm+) to understand what distortion there is in relation to sine and accordingly what is the frequency of actual current control. But I will be able to do this in a week at the earliest…
About FOC, I’m not sure that full motor control (position, current, and PWM generation from the sine table) is fast enough to leave the microcontroller time to work with other tasks (even if it is a fast controller). If I’m wrong, please correct me, I don’t know very well the ways of optimising code on HAL and especially LL…
By the way I would be very glad to see you in the project community. Ideas, discussions and constructive criticism are invaluable for the development of the project! [because I’m not sure I can do everything solo]
I think I understand now. I think other controllers I’ve used have called that stepper position maintenance mode.
As far as MCU load, it’s difficult to say what “overloaded” is, it generally depends on the end user application. Like previously mentioned, with the STM32 hardware encoder interface, I’ve measured loop rates around 36KHz, I think with the g431 others have pushed this to 50KHz. These are obviously faster than required, as the PWM frequency is usually between 35-50KHz as well. Meaning that there is time for the MCU to do other tasks.
In some sense, with FOC, there’s LESS to do than when commanding a step-dir interface because the PWM is handled by a hardware peripheral, I’ve never worked directly with the 2209, which I think uses UART or SPI for communication, so I’m not sure how the overhead compares. All the (FOC) library needs to do is read a couple of registers, a handful of multiplications and adds, an array lookup, then update a few registers per cycle. SFOC is written using floats, so an MCU like the stm32f4/g4 can do floating point add/multiply in one clock cycle.
Additionally, at least in my case, I’ve decided to limit the required tasks for the motor control MCU. I’m only going to make it control the motor and handle (usb)serial data, and possibly expose some simple, slow, on/off GPIO. The rest of the motion planning will be handled on the host, then position/velocity/acceleration vs time data will be transferred to the MCU for it to execute.
In the current simple code version I update the PWM frequency after recalculating the step frequency from acceleration and speed. That’s all) This is enough to control the motor.
But if you need to update parameters like current or something else, it can also be done via uart periphery. However, for some reason it is not yet possible to configure work with SPI or UART in the mode of automatic writing to the buffer…
In any case, one write command is about 140us, and read + write is 320us. If you use this with hardware peripherals, it will be much faster.
At the same time proper driver configuration does not require very frequent updates, so it’s at most 10 times per second. So the main load is exactly position calculation and processing of interfaces (e.g. encoder). When working with a clipper or step-dir interface, no calculations are required at all (almost)