openinverter forum

I'd like to move away from needing to change the gui whenever parameters change so am thinking about changing it so that the user can enter say any 10 parameters by name and then edit them from the gui.

The main issue with this is the sim would need to call the standard Openinverter param::change function whenever a value changes. Unfortunately this is currently in the same file as Openinverter's main and I doubt Qt will be very happy having two mains!

Would it be possible to move param::change into a param_prj.cpp file in the standard OI build to avoid this?

Not a bad idea, want to PR?

Had a bit more of a think about this and have decided that the current gui could really do with a proper update, the fixed OI parameter fields were nitially quick to do but are now too inflexible and too easily broken by OI code changes. The above idea goes some way to fixing, and the param::change move will still be needed, but I think there is a better solution.

The plan now is to change the OI parameters section of the gui to show a collapsible tree view of the full OI parameter set in much the same way as the OI web interface. This will allow full access to any current or future parameters. The downside is it also exposes a lot of the parameters that are irrelevant to the simulator but the collapsible view should help with that. I'd also like to get the parameter description to show in tool tips if possible (if not it will go in an extra column).

While doing this I'll also add a json parameter import and export using the same format as the web interface functions to make it easier to transfer setups between real installs and the simulator configurations. Probably also make it so that it automatically loads the last json on startup to avoid having to edit the param_prj.h file too.

The last change will be to add import and export for the motor parameters, again using the json format, and the creation of motor files for the common motors (Leaf, Outlander, MGR, etc) to make it easier to switch between setups.

This is probably going to take a few weeks to get to though so in the meantime I suggest sticking with 5.24 for simulation.

Edit - Might not be as big a job as I first though, just had a quick play with the Qt QTreeView widget and it does most of what's needed (even the tooltips!) :

There is now a new build of the simulator on the "combined" branch. This supports both F103 and F405 builds so will hopefully simplify my life maintaining it in the future.

This should be a bit more robust to changes in parameter definitions in the OI project. Instead of having specific parameters bought out on the gui it now displays all parameters in a tree view, this means that the gui shouldn't be affected by OI parameter addition, removal or name changes.

The new interface looks like this: Any field can be edited but only the low level ones will affect the simulator (most of the Motor and Testing ones, a few from Inverter and throtcur).

The Vehicle and OpenInverter panes are now completely independent of each other.

The Vehicle fields, Torque Demand, Mode and Direction are still persisted between program runs.

The OI parameters are initialised from the OI project param_prj.h file on program start. Either edit this file to suit your defaults or use the new Load button to re-initialise them.

Buttons have been added to allow parameters to be saved or loaded.

The OI parameters buttons use the same format as the web interface so should be compatible (although warnings will occur if moving between different OI versions with different parameter sets).

The Motor buttons just load or save Lq, Ld, Rs and Flux Linkage. The idea is to generate files for each of the common motors but that will have to wait till another time.

@johu - at the moment Param::change is in a params_prj.cpp file in the Qt build directory. There are a couple of issues to sort out with the CAN class access so I haven't tried to integrate it into the OI build. Once that's done though it should be possible to just delete the Qt version of the params_prj.cpp file and use the one in the OI project instead.

This version will work with 5.24R but does need one line editing so for the moment if you want to simulate 5.24 stick with the main branch version of the simulator. The combined branch version of the simulator has been tested with 5.27R and will be pushed to main once the changes have been made to the OI firmware.

The lack of persistence on parameters was bugging me so now fixed - it saves all the parameters to a .paramPersist.json file on closing and then reloads them on opening.

While there I also made it remember the last path used for loading and saving json files and added persistence for the torque, mode and directions fields (somehow missed them before).

Have also added a subdirectory containing the motor parameters that have been found to date using the calculator viewtopic.php?p=52763#p52763

If anyone wants to post inverter parameter sets that they have found to work well with specific motors on the simulator I'll add them too.

Really sorry pete .... idiot alert!!!

I'm getting the following error trying to compile .... i'm assuming i don't have a (string) module installed here are the modules i have installed any ideas which one it might be in.
Many thanks in advance on this, when we work out what it is ill update wiki

PS i know how much of pita this is.. all i can say is thank you for all you have done.

No problem, thanks for testing it.

Think I might know what that is, saw something similar yesterday but the proper fix needed a few dozen references to an enum to be changed that conflicts with one defined in the libraries. Thought I'd found a quick workaround but obviously not!

Need to update my Qt version! Got a new SSD waiting to go in the PC so that I can put a newer OS but not got round to it yet

Just pushed a fix up to github, let me know if it helps?

Should have done it that way to start with, far quicker to do than I expected!

OK got it working....updated my qt whilst i was there ...

i got an error

Could not load the Qt platform plugin "xcb"

but managed to fix this following https://github.com/NVlabs/instant-ngp/discussions/300 (google is your friend)

if anyone else is running linux could they have a go... im one of the oddballs that like LTS OS' (debian) if its a repeatable error ill add a note in the wiki, however suspect it might be very os speciffic.

edit: yes code fixed it (first bug,second bug was qt)

Glad you got it working

Just to clarify did the code change fix the first bug and then the environment variable fixed another bug that was introduced when updating Qt?

just tried to build with current sim and current oi firmware, was hopping to simulate the different id and iq ki gains, but just get build errors like:

Y:\home\steve\IPMMotorSim\IPMMotorSim\mainwindow.cpp:141: error: 'curkp' is not a member of 'Param'; did you mean 'curki'?
..\IPMMotorSim\mainwindow.cpp: In constructor 'MainWindow::MainWindow(QWidget*)':
..\IPMMotorSim\mainwindow.cpp:141:65: error: 'curkp' is not a member of 'Param'; did you mean 'curki'?
141 | ui->CurrentKp->setText(QString::number(Param::GetInt(Param::curkp)));
| ^~~~~
| curki

Finally managed to get my old Linux partition running in the hope that I can get the simulator working on it as my Mac is too old....
When installing QT it seems the installer has changed from what it was when the guide was written. The options that seem closest to what is mentioned on the install guide are as pictured...
but it would be nice if this could be confirmed?
Also, given there are newer installation options, would it be beneficial to install one of these or is it best to stick with 6.4?


UPDATE: I went ahead and installed the above and compiled the GIT hub stuff, opened it in QT but it seems to throw up a couple of errors that won't allow the IPM simulator to run... I've attached a screenshot below
Thanks

I went ahead and installed the above and compiled the GIT hub stuff, opened it in QT but it seems to throw up a couple of errors that won't allow the IPM simulator to run... I've attached a screenshot below

I tried a fresh install a couple weeks ago and ran into the same issue. All I can think of for now is to try and grab a version closer to what was out when the guide was last updated (not long ago, but long enough that the versions immediately available in the installer didn't work for me).

Pete9008 wrote: ↑Thu May 11, 2023 11:58 am I'm more wondering whether it is a harmonic/saliency. It would be interesting to see whether it is phase locked to the motor current?

1.5 years later and with Pete already amiss I went at this again.

It looks like the oscillation is phase locked to rotor angle and runs at twice the electrical speed

Anyone still watching?

I think I'm up against something else. In the article Pete posted the disturbance looked like this: So 6x the motor frequency and sinusoidal. The disturbance in my plot as triangular shape and 2x motor frequency. Could it be some other artefact?

Still watching but a lot of what you and Pete worked out is still over my head!

I'm still watching, but understand very little of it

Not sure if this is the correct thread, but it seems the most fitting.
My 101 on motor drives and commutation is still under construction, but while dwelling deep in to zombifying a motor drive, I fell in to PWM modulation scheme efficiency rabbit hole.

I read the YANGDI HE Masters thesis on PWM strategies and it looks directly relevant to stm32-sine in FOC mode.
If my LLM assisted stm32-sine codebase discussions are correct, right now stm32-sine is basically continuous SVPWM via the standard min/max midpoint offset, plus short pulse suppression near 0 and 100 percent. It leaves efficiency on the table in the exact places where our my motorcycle IGBT brick suffers- high current and high temperature.

The thesis compares continuous PWM vs discontinuous PWM families (DPWM). Main takeaway is that DPWM can reduce switching losses substantially, but usually increases harmonics compared to continuous PWM at low speed. Which DPWM variant is best depends on operating point, basically the phase angle between voltage and current:

near unity power factor, DPWM1 tends to give lowest switching loss

for larger positive phase angle, DPWM2 tends to win

for larger negative phase angle, DPWM0 tends to win

among DPWM variants, DPWM2 had better THD than DPWM0 in their results, and at higher speed it can even look very good on THD

This suggests a practical improvement for stm32-sine: add selectable modulation modes in FOC, and optionally a simple runtime selector instead of picking one scheme forever. We already have everything needed inside FOC to estimate phase angle from alpha beta voltages and currents, so the firmware could pick DPWM0 or 1 or 2 depending on phi, and fall back to continuous SVPWM at low speed where THD matters more.

Implementation wise this can be clean, because stm32-sine already centralizes the common mode injection in CalcSVPWMOffset. That function could be generalized into a common mode generator supporting continuous SVPWM and DPWM variants, without touching the rest of the FOC loops. This is interesting for my old IGBT because reduced switching loss is directly tied to lower inverter heat in summer, which is the main killer for these aging PM300 bricks. There's a few academic papers covering DPWM improving the thermal stresses on IGBT bond wires, so I guess some sort of implementation of dynamic PWM mode switching could greatly improve reliabilty of most inverters. And even though most IGBTs have proper fin cooling, the immediate heating stresses between die and substrate def shortens their lifespan. I am not sure if heat is a problem in a water cooled inverter, but the above sims got 14% switching loss reduction, which, at many kW is a lot of heat, resulting in a very low single digit efficiency gain overall.

Sounds good. Anyone want to give it a try, i.e. implement and test?

Just out of curiosity, do you have some graphs showing the difference between the PWM patterns? I think this topic is worth splitting off into a new one

I would like to test this on one of my projects, but I'm just a practitioner. . programming is beyond my control. if someone creates a firmware file for the O.I. board that takes into account the described control methods, I will be happy to test them.