ParameterID#
The ParameterID is a toolbox to identify common permanent magnet synchronous motor parameters based on different code-generated Stateflows. This page explains the general structure of the ParameterID. To set the ParameterID up in the UltraZohm software, see Setup and functions of the ParameterID. For further information visit, Structs for ParameterID_Data, Change control algorithm for ParameterID, Custom uz_GUI for ParameterID and Guide to create a new ID-state.
Overview#
Fig. 285 Schematic overview of the ParameterID signal flow
The ParameterID encapsulates a ControlState
and all subsequent Identification-states
(short ID-states
).
The ControlState
is the brain of the ParameterID and controls the system by determining which ID-state
is entered next, based on the user-request and the acknowledgment flags of other states.
The individual ID-states
are completely independent of each other. They only directly communicate with the ControlState
.
The uz_ParameterID_Data_t struct is used to communicate with the ParameterID. It includes all necessary in- and outputs.
The ParameterID operates independently of an underlying control algorithm and therefore is indifferent to what specific type the controller is.
This means that the ParameterID outputs reference values, which the controller can use to control the hardware.
On top of that, the ID-states
inside the ParameterID are separated into two different groups:
OfflineID states
OfflineID states represent identification Stateflows, which are to be used before the general operation of the motor is started. They can not be executed parallel to the general motor operation because they take active control of the machine. They, for example, tell the external control algorithm which reference currents or speeds it is supposed to target. Thus only one OfflineID-state can be active at the same time.
OnlineID states
OnlineID states represent identification Stateflows, which are used during the general operation of the motor. They are designed as an observer of some sorts of the machine. This means they use all existing measurements during normal operation and identify their parameters this way. They, therefore, don’t have to actively control the machine. Thus, they can operate parallel to the general operation of the motor.
Note
All states have been configured in such a way that they are independent of the sampleTime.
This works if the sampleTimeISR
member of the Global config struct equals the sampleTime of the function call.
This has been confirmed for an ISR-frequency of 10kHz and 20kHz.
Signalflow in the ParameterID#
Fig. 286 Schematic overview of the ParameterID
The ParameterID has three global structs (highlighted in orange), which are shared inputs for all identification states. For detailed information about these structs, click on the appropriate hyperlink. These are the following:
ActualValues struct, which carries all the measurement values.
GlobalConfig struct, which carries general configuration variables which affect multiple or all states.
ControlFlags struct, which carries all flags to turn the individual states on and off.
On top of that, each unique ID-state
has its own individual structs and signals:
uz_StateIDConfig_t
(i.e. for ElectricalID uz_ElectricalIDConfig_t), which is meant for all configuration values, which are unique to this specificID-state
.
uz_StateID_state_output_t
(i.e. for ElectricalID uz_ElectricalID_state_output_t), which is meant for the identified output variables and supporting variables.
enteredStateID
flag for OfflineID- and OnlineID-states, which signals that the state has been entered.
finishedStateID
flag for OfflineID-states, which signals that theID-state
is finished and another can be started.
OnlineID-states do not necessarily have a finishedStateID
flag, since they can be designed as an infinite loop.
Further information#
General information & explanation#
Further documentation which explains the structure of the ParameterID in detail.
Stateflows#
Listed are the individual states which are part of the ParameterID.