High speed not possible with active monitoring

I am running simple FOC with a 170MHz CPU, and a very high speed BLDC with abs encoder.
I am able to reach 1600 rad/sec (approx. 16000 RPM) but at these speeds the monitoring function (printing to UART) is hindering the motor’s performance because printing is taking a lot of resources and its prohibiting the FOC algorithm to run smoothly.
motor.monitor_downsample = 100;

Is there anyone who tried multithreading with SimpleFOC? I am thinking it’s the only way to go…
Or any other solution?

Thanks

Hey @Geronimo,

Those are some impressive speeds :smiley:

Hmm, an obvious answer would be to further downsample the monitoring. >1000
Another approach would be to do the monitoring asynchroniously, using the commander and as for each value with the commander

MMG0  # target
MMG1 # voltage q
....
MMG6 # angle

ANother approach might be to reduce the decimal places that are output with the monitor, at the moment it is fixed at 4, for example:

The multi-threading is an excellent question and so far I am not aware of someone that has done it.

Hi @Geronimo

I think there have been some posts in the forum about using threads on ESP32… but don’t underestimate the difficulty of synchronizing multiple threads correctly.

But for the job of monitoring, I think it can definitely be done. However, you have to be sure the problem is the monitoring itself and not the serial line speed - no matter whether you use threads or not, you have to be able to move the data out fast enough, or your buffers will overflow and you have to either block or drop packets…

Normally the serial code just writes to a buffer, which is asynchronously processed onto the serial line by the hardware. So normally the writing to Serial completes quite quickly, and it is only when the buffer is full that it has to block until some bytes are written out and space becomes available.

In that sense, the monitoring downsampling is a very simple approach that works well in practice - increase downsample value until the loop runs well, and that’s the speed at which serial can write the data out. Moving to multiple threads won’t really change that.

On the other hand if the loop-time is being significantly used by the “processing” of the monitoring data, then moving it to another thread will have good results.

Also good is of course reducing the amount of data sent.

There’s also been some interesting research done recently by @Juan-Antonio_Soren_E regarding the SerialUSB class, and writing the data multiple or single packets - this depends a lot on the hardware you are using, but is a potential optimisation we will look at for SimpleFOC.

1 Like