Author Topic: ST MCSDK, PMSM FOC - profiling low L motor, starting problems  (Read 239 times)

0 Members and 1 Guest are viewing this topic.

Offline TinkeringSteveTopic starter

  • Frequent Contributor
  • **
  • Posts: 289
ST MCSDK, PMSM FOC - profiling low L motor, starting problems
« on: January 15, 2024, 02:39:26 pm »
Hello,

I'm trying out STMicro's MCSDK 6.2. Tried the last available 5.x before, where profiling and running a motor form the workbench sorta works, but the code generator has problems.
So, now using 6, where the generator works for me - well, it produces code.

But... after pressing the user button on the board, the motor will start after minutes, not milliseconds.
I guess that could be a profiling problem?
Then again, in the profiling state, the motor did run, though it did complain about R and L of the motor being lower than the 1Ohm, 1mH that are at least expected. According to datasheet, it should be 1R and not the 0.8 the profiler claims, and 0.32mH not 0.1mH like it claims. But it's lower than 1mH, ok.

EDIT:
looks more like their generated code has problems...
If I put a MC_StartNMotor1(); delay(2000); MC_StopMotor1(); in main loop, it will start and stop spinning for a while, but after minutes, it stops working for msysterious reasons.
The MC_* calls are still being made, but they don't work anymore.

Also, in the 6.2 version, which works very differently in some regards from 5.x, the profiled motor does not show up in the workbench after profiling. And importing the json stored from the profiler as a new motor also doesn't work: "wrong format".
So I cobbled together something from a copied stock motor file, with the values from the profiler json... I re-checked, should be allright.
The code generated from that is the one giving me the "starts after minutes" oddity.

Btw, I have a bunch of very different PMSM motors as candidates for different tasks, from small gimbal thingy to big clunky door stop, and all of them are claimed to be lower than the 1R, 1mH values by the profiler...

My setup is:
  • the IHM16M1 motor board from ST, and their
  • Nucleo-G431 devboard, with the MCU said to be "designed for FOC motor control", with all its extra math stuff. So I wasn't skimping, I guess
  • default Workbench setting for Speed Sensing of Observer+PLL for now.
(in 5.x, I also enabled the externally mounted encoder & had to hack the motor profile to allow it, as the SDK does not know the concept of externally mounted encoder - seemed to work. But let's start small with this new SDK version...)

I'm aware of ST's community forums, but with questions that are not embedded programming beginner questions, and apparently especially in the motor control sub forum, there's not much luck getting help, it's full with unanswered questions from weeks or months.

I saw someone using & asking about older ST FOC stuff on here, so maybe a few on here have experience with their current stuff also :)

So my questions, so far, would be:
  • can the profiling with a not-optimal motor for this profiler, be a reason for this to not work? (though, with MCSDK 5.x, the motor ran fine in the Workbench, after profiling with the 5.x profiler, which uses a different file format, alas)
  • how would I profile a motor "by hand", if the tool can't do it? (coil values are in the datasheet, but no Back-EMF constant and other stuff the profiler determines)
« Last Edit: January 15, 2024, 10:37:10 pm by TinkeringSteve »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf