Can I use the SimpleFOC library to drive syncronized axes in closed-loop?

Sorry about it, there is more to my project than I’ve explained. Lab automation is in my bigger picture, which can involve timing of events with millisecond or microsecond precision (e.g. illumination and acquisition in a microscope), and closed-loop control is also important in a variety of scenarios.

This is very long term. I’d like to do this with open source components, and I really like SimpleFOC and its community.

Yesss looks like step one! to me :slight_smile:

pinging @Copper280z for their extremely interesting klipper-commander using simpleFOC :smiley:

1 Like

Yup, it’ll do that, I just haven’t sorted out the last little issues like the apparent clock drift. I got distracted getting the milk-v duo up and running bare metal C instead of linux. Klipper has inherent latency when sending commands from the host to a motor, because the mcu caches motion commands which the host has scheduled in the future. This is part of the clock sync thing it does.

The G474 has the processing power to run 3 motors if you’re willing to do some hacking within the library, and write very efficient IO code. (and you’ll need both!) You will need one of the big ones, it seems you can do 3 motors with 6pwm on a g474vet, but I really see no reason 6pwm is a big advantage over 3pwm. You’ll need to make sure the drivers configure correctly, but as there are enough timers to put each motor on a dedicated one it should be fine. If you really need tightly synchronized motion, I assume you’ll want it to be relatively high performance motion, so you’ll want current sensing, getting that up and running with 3 motors will be tricky for sure. You should plan on basically writing your own hardware driver that the current sense classes call into to get data from the hardware. The H7 is for sure a better choice, but you’ll definitely need to write your own drivers for it as I don’t think anyone else has.

Now tuning it all to get good control bandwidth and stability for microscopy is gonna be a project all on it’s own!

1 Like


Perhaps a stupid question.

Isn’t current sensing generic enough to run on H7 out of the box? What makes you conclude that?


Inline current sensing is, but low side current sensing is not. Inline as it’s implemented now is pretty undesirable because of how stm32duino does analogRead.

Stm32duino totally reconfigures the ADC and starts a conversion for every call. I don’t remember the exact rate I got testing this in a tight loop, but it’s pretty slow.

The sfoc low side stm32 driver uses hardware features to schedule the ADC conversions synchronized with the timers, so it takes no CPU time at all and it becomes trivial to sample multiple motors at 20-40khz each.

You say inline is just an analog read call?

That’s really, really slow. Now I get it.

Why can’t we do the same for inline, to mimic low side but inline, who cares at what point the measurement is taken?


You can just use the low side class with an inline sensor, it works fine.

Depending on the inline sensor it’s good to avoid reading close to one of the pwm edges because most shunt amplifiers, even the really good ones, ring for a bit on the voltage transitions. The magnetic sensors don’t have this problem.

1 Like

My experience with the klipper project is that if you want to do something that is in anyway outside of a very narrow band of functionality dictated by project owner, you will be met with hostility and condescension. I was afraid it was just me, but I’ve since heard a similar experience from many others.

You might be interested in discussing this with others who are working on their own 3d printer firmware. One project (in rust, but concepts should be language agnostic) is pronthor

1 Like

I’m sorry to hear that, been there too. :confused:

I really like it’s front-page :slight_smile: GitHub - cbruiz/printhor: A 3dprinter/cnc firmware framework powered by rust embassy

Yeah, I have this little dream of a 2x2 linear motor 3d printer running on rust. I’m in the process of putting together the rust equivilent of sfoc at the moment, hoping that’s used.

What exactly do you mean by 2x2? I hate Rust, so we could only collaborate on hardware, but I have a dream of a printer using the Ultimaker style crossed rail gantry with two linear motors driving each axis. Ideally inverted from the Peopoly Magneto X, so the permanent magnets are on the moving parts and coils on the stationary rails so the motor wires don’t have to move. This is one of the potential uses for my stepstick-compatible board, along with making ultra-lightweight spiral extruders.

I’m pretty sure I could make the linear motors, but I don’t know what to do about encoders. It seems stupid to use belts to turn rotary encoders, but I don’t know of any low-cost linear encoders aside from vernier calipers, which may not be precise enough even if you can figure out how to get the reading from them in digital format.

check out the diy linear motor project: GitHub - cmore839/DIY-Linear-Motor.

The project owner has the same setup in mind as you regarding placement: Cross gantry, 2 lin-mot per axis.

As for inverting the coils/magnets, that’s a thinker. It would significantly inclease the moving mass, and you wold need a way to set which phase triplets to activate. You wouldn’t have enough default gpio-pins available, so you would probably need a multiplexer of some sort. I could see heat disapation being a massive advantage, assuming you can share the coil-energisiation across more than just 6 coils, but the wire advantage, I don’t see as being much of an advantage. With reasonable cable management, it should be a near non-issue. I would be keen to hear your thinking on it.

Making linear motors, as per the DIY linear motor I linked, seems quite straight forward, they’ve even got a coil supply setup if that part of the project doesn’t appeal. As for encoding, there’s linear encoder options:

  • HEDS: similar to what’s typically used in printers. affordable, suitable accuracy, works great with pulse counters. Has issues with environmental exposure (dust build up).
  • glass rod linear encoders. TTL lines, found them on aliexpress for about twice the price. don’t know much about them.
  • industrial style: great, but massively expensive.

The rotary encoders are probably more than suitable for prototyping, at least.

I hate Rust

I love the language for a lot of reasons. I love klipper, but the project owner is, in my experience, and it seems quite common among those that I’ve spoken with, is driven by ego, and filters the community such that he is surrounded by sycophants. The community and industry deserve better, and if something else comes along, I feel that it deserves to be in a modern language.

1 Like

Ah, that looks more realistic than what I had in mind. The rails would be like an unrolled outrunner stator, with coils wound around teeth. The moving part would be two rectangle magnets stuck to a piece of iron, so moving mass would be extremely low. It’s true that wires and cable chain aren’t that heavy, but it lacks the elegance of my pie-in-the-sky machine :slight_smile:

Thanks for the encoder recommendations, but I forgot the main reason it’s such a problem is that it also needs to be inverted so the sensors are on the rails, else the carriage will still have to drag wires around. That will have the advantage of giving an absolute position reading, but I doubt there are any commercially available solutions for it. I feel like the answer will involve a vernier pattern, using capacitance, magnetic field, light, or electrical contact.

Regarding selectively activating coils, I had considered it but I don’t think it’s really necessary. It will be producing a lot of unnecessary magnetic field, but since nothing will be pushing against it the only energy consumption should be in the resistance of the copper wire, and since that won’t be moving you can use a lot of it to minimize resistance. Although cost could be an issue.

Something I recently have been looking into is trying to replicate and improve the work on this project, which does not have fantastic resolution but depending on your number of pole pairs, could possibly work : Project | DIY Digital Caliper |


Magnificent! I found about it last week, I really want it to move forward.

The only thing about capacitive encoders that I’m not too sure about is their sampling rate, and if they are any good measuring while in (“fast”) motion.

There is also the cheap-o-self-mixing laser interferometer:

There is also optical strips and magnetic tape for linear encoders:

I’m just starting to explore these options for a stick-slip piezoelectric nanopositioner (i.e. not recommending those products or suppliers).

Haha! We are living the same life on two separate halves of the planet… I have been obsessed with trying to build a << 1um resolution encoder for use with a nanopositioner also… I watched this video and the Sam Zeloof one recently. I think they are actually maybe too impractical for the stage you/me are talking about.

At my work we use the optical tape with very high pitch for closed loop motor control, but even this tape is like $100 per inch or soomething like that.

Did you read the paper in HardwareX also? I just ordered the parts to try and build it, I think that using some of those 28-bit inductive sensors might be the best method to set up a closed loop. I will dm you :slight_smile:

1 Like

Interesting, can I ask for a link to the specs?

I was thinking about using this kind of things as “optical tape”:

Or these:

Would they be useful?

I’m also not sure what sensor can be used to read from them. I imagine that either a very fine laser point (like the ones in OPUs) could work, or maybe the sensor from a high-DPI computer mouse (e.g. this thesis).

Hoping the rough ideas are useful. Implementation is out of my reach ATM.

FYI Magnetic encoders from RLS can get to 250nm/count for around $100/ea for tape and readhead, this is the cheapest “high” resolution encoder I know of from a non-ali type source.


I laid out an adapter board for a nucleo-144 that connects 4x ali drv8301 driver boards, and has SE/differential encoder inputs, along with some SPI/UART/gpio broken out to connectors. It’s laid out around the H723 peripherals, but I think nucleos are designed to be pretty interchangeable so hopefully the F7 and U5 I also have will at least partly work.