[WIKI] Move before loopFOC

[Moddingear]

In move(), the current target is set.

In loopFOC(), it is acted on.

Many of the examples have loopFOC() before move(). While in their case it doesn't change a thing, it probably should be swapped around to avoid increasing control latency, unless there's something I'm missing.

[Moddingear]

In practice, especially with CDC enabled, this makes the motor much more stable and silent. I highly recommend.

[dekutree64]

It's a chicken-and-egg since loopFOC updates the sensor, which the motion PID needs. Theoretically the ideal would be sensor-move-loopFOC, but in reality that would increase lag between the sensor measurement and phase current setting, which is probably worse than lag between measurement and motion PID. In most cases the call order doesn't matter since the loop immediately repeats so there's really no difference, but like you say it does matter if there is time-consuming communication code after both calls. Changing the order would give motion PID an even more out-of-date sensor reading, but if you've tested and gotten better results that way, then maybe we should change it.

[runger1101001]

I see it like Deku does.

I sometimes switch the order of move and loopFOC for the reasons you mentioned, but other times I have not noticed an improvement.

I think it may also depend on the mode since angle and velocity mode depend on the sensor, but torque mode does not use it in the move function.

Also keep in mind that you’d normally run the move() function at a slower rate than loopFOC(), using the downsample. Then it really doesn’t matter so much if it’s before or after loopFOC in the code because loopFOC runs N times before move runs again anyway…

[thalesmaoa]

Have you guys tried a PLL? A simple PI will track it accordingly with using encoder feedback.