Direct DQ current reference control for motor mapping

[filssavi]

In one of our labs we are using (among others) a VESC 100/250 Inverter on a back to back converter rig for electrical machine testing and characterization. This is usually done by configuring the brake machine to run at a constant speed while producing a torque with the Machine under test (controlled by the VESC).

To simplify and speed up the whole mapping procedure we need directly set both D and Q axis current references, giving us absolute certainty the exact operating point in the speed torque characteristic.

Right now I have a draft implementation of the feature which will be tested in the near future. If there is any interest I can create a merge request to contribute the feature to the wider community

[nitrousnrg]

I've seen the need of D/Q mapping many times. When you commission a motor design, I was kind of expected to run the motor according to the simulated D/Q tables provided by the designer that drives the motor at optimal efficiency. A stub in the code that can use a programmable lookup table would be great for those kind of developments.

[filssavi]

Given that the firmware is already large and uses a fair bit of ram as is (compiling with the default options) I don't know if there is enough space to fit a meaningfully large LUT, so I am thinking of just extending the comm protocol to allow direct access to the DQ currents (when the relevant mode is selected).

[nitrousnrg]

if the table is stored as part of a lisp script it would be stored in the second part of the flash memory, that's nearly 500kb. QML UIs are stored there as well.

I also created custom terminal commands that store extra config information in the emulated eeprom (it's just the mcu flash), but idk if it is ok to store a large table there.

Discord might be a good place to have a discussion, in any case I do second the idea of adding the feature.