The issue here is due to pin conflicts between the STM32 Nucleo DAC channels and the RT Box / LaunchPad Nucleo interface board.
A few basic debugging steps would have revealed this:
- Run your model in open loop (fix V_{dq})
- Connect a PLECS Scope to the Analog In channels of the RT Box and note the signals are not as expected.
- Connect a hardware scope to the pins. Test with the Nucleo connected to the RT Box and with the Nucleo floating.
The G474 can only use PA4, PA5, and PA6 as DAC output channels as you have correctly chosen. The RT Box interface board wasn’t designed to support DAC connections to the RT Box (as the RT Box analog input connector isn’t part of the interface). A table of the pin functionalities and resulting issues are below.
| STM32 Function | STM32 Pin | RT Box Function | Comments |
|---|---|---|---|
| DAC1_OUT1 | PA4 | AO2 | Will always conflict based on analog out setting. Also used for V_{pcc\_out} phase b. |
| DAC1_OUT2 | PA5 | DI27 | Functional. |
| DAC2_OUT1 | PA6 | DO1 | Will always conflict. RT Box DO always 0 or 3.3V. |
One resolution would be to electrically isolate the channels that conflict - say by header connectors with clipped pins. In this case an alternative would be to use SPI communication to send the setpoint values to the RT Box. See the attached model.
Closed_Loop_GFM_SPI.plecs (140.6 KB)
Another issue in your model worth pointing out is the role of the integrator blocks generating an angle. Those should have wrapping enabled from 0-2*pi. The issue will manifest for longer runs due to round-off error when a very small value (increment) is added to a large value (integrator state). You also could use the same angle for all DQ transformations to be more computationally efficient.