Introduction

This article is prepared to give information about FOC-based (Field-Oriented Control) “Motor Control Example”. We aim to offer solutions in this field and to introduce the capabilities of netX 90 in Motion.

FOC Architecture

What is FOC?

Field-oriented control (FOC), also known as vector control, is a technique used to control Permanent Magnet Synchronous Motor (PMSM) and Brushless-DC Motor (BLDC). FOC provides good control capability over the full torque and speed ranges. The FOC implementation requires the transformation of stator currents from the stationary reference frame to the rotor flux reference frame (also known as the d-q reference frame).

Speed control and torque control are the most commonly used FOC control modes. The position control mode is less common. Most of the traction applications use the torque control mode in which the motor control system follows a reference torque value. In the speed control mode, the motor controller follows a reference speed value and generates a torque reference for the torque control, which forms an inner subsystem. In the position control mode, the speed controller forms the inner subsystem.

FOC algorithm implementation requires real-time feedback of the currents and rotor position angle. Measure the current and position by using sensors. The sensorless techniques can be used to estimate feedback values (by motor hall sensors and phase angles) instead of the actual sensor-based measurements. This technique is called Sliding-mode based rotor estimation.

More detailed information about FOC can be found on the https://www.mathworks.com/solutions/electrification/field-oriented-control.html, https://www.trinamic.com/technology/motor-control-technology/field-oriented-control/, https://www.pmdcorp.com/resources/type/articles/get/field-oriented-control-foc-a-deep-dive-article.

FOC Block Diagram

In Figure 1, the block diagram of the FOC is seen in detail. The Clarke transform converts the time domain components of a three-phase system (in abc frame) into two components in an orthogonal stationary frame (αβ). The Park transform converts the two components in the αβ frame to an orthogonal rotating reference frame (dq). Consecutively implementing these two transforms simplifies computations by converting AC and voltage waveforms into DC signals. Thanks to the DC quantities obtained by these transformations, we obtain the possibility of PI current control (on Id and Iq vectors) facility which allows for performing torque control.

Thanks to the feedback provided by the motor, the speed feedback(Encoder, Resolver, Hall Sensor, … ) is sent to the speed PI controller for the speed control of the motor. Likewise, after motor PI controls, these two components in the orthogonal rotating reference frame (dq) are converted to the two components in the orthogonal stationary frame (αβ) using the Inverse Park Transform. It is converted into time-domain components (in abc frame) using the Space Vector PWM Generator. You may have noticed the absence of the Inverse Clarke Transform. The Inverse Clarke Transform takes place indirectly during the Space Vector Modulation computation. Park Transform and Inverse Park Transform need the instantaneous rotor electrical angle[Θ]'s sin and cos values. Respectively, the instantaneous rotor’s mechanical angle is converted to its electrical angle with relevant calculations, and the sin and cos values of this angle are calculated.

Field-weakening or flux-weakening is a technique for increasing the speed of an electric motor above its rating at the expense of reduced torque. This concept is especially evident when operating at high motor speeds. More information can be found at the https://www.mathworks.com/solutions/electrification/field-weakening-control.html.

• ω_ref - Reference angular speed [rad/s]

• ω_fb - Angular speed feedback of rotor [rad/s]

• T_ref - Reference torque [N.m]

• i_d^ref, i_q^ref - Orthogonal rotating reference frame current components [A]

• i_d, i_q - Orthogonal rotating reference frame current feedbacks [A]

• v_d^ref_, v_q^ref - Orthogonal rotating reference frame voltage components [V]

• V_α, V_β - Orthogonal stationary frame voltage components [V]

• i_a, i_b, i_{c -} Currents flowing in the stator windings [A]

• v_a, v_b, v_c - Applied voltages to the motor [V]

• V_dc - DC Bus Voltage [V]

• θ_m - Instantaneous rotor mechanical angle [rad]

• θ_e - Instantaneous rotor electrical angle [rad]

• G_ah, G_al, G_bh, G_bl, G_ch, G_cl - A,B,C phase MOSFETs' Gate PWM duty cycles [%]

Changes in V1.1.0.0

1. The ”Motion Control State Machine” in “MCL layer Motion component” is removed and the motion control architecture has been transformed into an event-based architecture. Thus, the "Set Motor Speed", "Get Motor Speed" and “Get position” functions can be executed cyclically from the external application layer (such as ProfiDrive or EtherCat Motion) using hardware-assisted bus cycle (XCTRIGGERs) or logically defined timers. Thus, FOC works synchronously with the hardware-assisted bus cycle. This brings IRT mode support to FOC. (Operations such as Calibration and Coast Stop are called cyclically).

2. The HAL QEI (Quadrature Encoder Interface) capture position architecture has been modified to work properly with different bus-cycle periods. In the V1.0.0.0, the encoder position capture process was performed automatically with the timer interrupt which also drove the Motion Control State Machine. This timer was removed due to the change in the motion control structure and the need for flexible operation with different bus cycle periods. Now this capture function is indirectly triggered by using the Get Motor Speed function from the external application layer, thus positions are calculated according to the time elapsed between two consecutive capture functions.

3. MPWM synchronization support has been implemented. Thus, the PWM frequency is tuned dynamically and synchronization of MPWM with the hardware-assisted bus-cycle (XCTRIGGER) is ensured. So, the bus cycle jitter is compensated. As the MPWM frequency is compensated according to the bus cycle, the MPWM callback is always called at the same timeframe. This provides the deterministic operation required for IRT mode (see FOC Runtime Analysis).

4. Get position support has been added to FOC. The motor position feedback (currently encoder) information is get and processed. So this position information is provided directly to the external application layer thanks to the FOC API. It is currently being tested using the ProfiDrive AC4 example. However, it is designed to be universal and is expected to be compatible with EtherCat Motion (see FOC Position Interface Details).

5. Due to issues with the PLC in isochronous mode compatibility, the automatic encoder direction estimation algorithm has been temporarily removed. It will undergo reassessment in the next version, and a decision will be made regarding its future.

6. Motor calibration support is provided via the API function. Motor calibration can now be performed by setting calibration parameters externally (Motor self-calibration can pose a safety risk when the motors are linked to a mechanical mechanism because the drives begin to move).

Software Details

This chapter describes how the software is structured and how to configure it according to the requirements.

Folder structure

While the layers are in separate folders by design, the components of that layer are separated as *.c, *.h pair. The folder structure of the FOC project is shown in Figure 2.

Open

Figure 2 - Field-Oriented Control Software project’s folder structure

The FOC, MCL, and HAL components are initialized into the main.c file from lower to upper layers (HAL → MCL → CORE). The desired API function is used via handles obtained after FOC initialization. The MATH library is accessible from all layers. The public folder specifies the header files available to the user. The public folders contain the user-accessible header files.

Program Structure

The FOC application consists of four layers. The “Hardware Abstraction Layer“ (HAL) provides 6 components to communicate with the hardware. The “Timer” manages the motor self-calibration process and measures elapsed time for the timeout feature. It is also designed to be highly flexible and adaptable to future requirements (e.g. diagnostics). The “Analog-to-Digital Converter“ (ADC) provides information from the board sensors (input voltage, phase voltages, phase current, SinCos Resolver, board potentiometer, etc.). The “Motion Pulse-Width Modulation“ (MPWM) serves as the configured PWM for the motor. The “Gate Driver“ controls the driver chip that drives the motor. The “Quadrature Encoder Interface“ (QEI) accurately determines the rotor position and speed. The “Hall Sensors“capture information from the GPIOs connected to the Hall-Effect sensors built into the motor and indicate the current state of the rotor. They are mainly combined with the encoders to determine the rotor position. Their role is to determine the rotor starting angle. They are also used for speed estimation in the absence of an encoder. However, they don’t provide precise position control due to their poor resolution. The main purpose of the HAL layer is to provide feedback information to the higher layers and to transmit the control request it receives from there to the motor. And in doing so, the aim is to create an abstraction with hardware.

The “Motor Control Layer” (MCL) retrieves the latest speed setpoint and operation mode from the “Core Layer“ (FOC API). Depending on the active operation mode, it retrieves relevant feedback from the HAL, to process according to the FOC algorithm. This algorithm includes various blocks such as PI controllers, Transformation blocks, Space Vector Modulators, Low-pass filters, etc. The latest set speed is kept at the desired value by the Speed PI Controller using the motor's speed feedback. In addition, the motor’s torque is tried to be held at the maximum level thanks to the d and q Current Vector PI controller. The feedback given to the current PI controllers is the current vectors I_d and I_q obtained by transformations using the measured motor current values and the electrical angle[Θ]. Then the calculated dq vectors are converter into 3-phase modulated amplitudes and thus motor rotation is provided. The algorithm described above is executed in the MCL layer. The “Motion“ component includes motion-related functions. It is actually where all FOC application is coordinated. Motor Speed and Operation functions from the FOC API layer are received by this component, processed, and transmitted to the relevant components. It also coordinates the motor position determination in self-calibration and calibration with parameters. The “FOC Control” component provides the main FOC control. Operations such as Torque control, vector transformations, Space Vector Modulation, etc. are done. The “Calibration“ component provides the self-calibration and calibration using user calibration parameters. The self-calibration process associates the hall sensor sectors with the electrical rotor position angles. Calibration with user parameters is done using predetermined self-calibration parameters without any physical movement. The “Position & Speed Estimation“ (PSE) component makes the data received from HAL QEI and HAL Hall Sensors processed. It contains all position and speed estimation functions.

The “Mathematical Library“ (MATH) provides the FOC-based mathematical functionality used by all layers.

The “Foc Api(Core) Layer” contains the necessary API functions for FOC initialization and control.

The block diagram depicted in Figure 3 visually represents the components, their functionalities, and their interconnections.

Hardware Abstraction Layer (HAL)

The “Hardware Abstraction Layer“ (HAL) contains 6 components to communicate with the hardware. The HAL layer uses motor control-related peripherals embedded in the netX90 IC. More detailed information about these peripherals can be obtained from netMOTION and netX 90 in Motion. For even more detailed information, see section 5.14 from netX 90 - Technical data reference guide.

Timer

It manages the motor self-calibration process, measures elapsed time for the timeout feature and generates delay. It is also designed to be highly flexible and adaptable to future requirements (e.g. diagnostics).

ADC(Analog-to-Digital Converter)

It provides information from the netX90-MC board sensors (Temperature, Reference voltages, …), motor position feedbacks (Hall sensor sectors, Resolver, …), board voltages (DC bus voltage,…), and Gate driver feedbacks (Measured phase currents, measured phase voltages, …). In Table 1, the signals connected to the MADC matrix of the netX90-MC Rev. 3 board are shown. Green cells indicate signals used in this project are described in Table 1.

Gate Driver

It provides a Gate Driver control interface. The Gate Driver used in our netX90-MC Rev. 3 board is Texas Instruments DRV8323RSRGZR, 6 to 60V Three-Phase Smart Gate Driver. This driver also drives Texas Instruments' 60-V Half-Bridge Power Block Mosfets named CSD88599Q5DC (1 for each motor phase). More detailed information can be obtained from DRV832x 6 to 60-V Three-Phase Smart Gate Driver and CSD88599Q5DC 60-V Half-Bridge NexFET™ Power Block. It communicates with netX90 via the SPI channel. The Gate Driver component contains important functions such as fault detection, enabling/disabling the gate driver, coast stop, brake mode and auto current measurement offset trim mode (see Auto Current Offset Trim using DRV8323RS Gate Driver). Especially thanks to fault detection, the burning of the motor windings can be prevented in cases such as over-current conditions.

MPWM (Motion Pulse-Width Modulation)

The MPWM component is used to modulate the 3-phase PWM signal required for the motor control. Thanks to the “Event Counter Zero (ECZ)“, it generates events so that measurements, transformations, and PI controls are made and new SVPWM duty cycle values are adjusted. Event Counter Zero (ECZ) is the reduced frequency of the “Beginning of Period (BOP)” events variant. If the field evt_cnt_top of register mpwm_cfg is set to a value N, an ECZ event will be sent every N+1 period. MPWM can be synchronized to hardware-assisted cyclic network events. In this way, since the MPWM callback event will be synchronized with the Bus Cycle, jitter problems will be partially prevented and motor control will be realized in a determined way. For detailed information, see FOC Runtime Analysis and section 5.14.3 from netX 90 - Technical data reference guide.

QEI (Quadrature Encoder Interface)

The QEI component provides information from the Quadrature Encoder, which is mounted on the motor. Method 4 was used as the speed estimation method (see section 5.14.4.11 from netX 90 - Technical data reference guide). It supports working with ENC0(QEI 5V TTL) and ENC1(RS422) encoder sources. The NXHX-DH adapter module serves to connect digital transmitters as TTL or RS422 (see section 3.4 from NXHX 90-MC). Also, this component supports the encoder direction inversion functionality. For detailed information, see section 5.14.4 from netX 90 - Technical data reference guide. Unlike V1.0.0.0, the QEI capture structure is changed. In the previous version, the encoder positions were captured using the GPIO TIMER trigger internally. But, because of the IRT compatibility reasons, this capturing is realized with a specialized function asynchronously. So, it must be synchronized with the external bus cycle. In this way, flexible operation with different bus cycle periods will be ensured.

Hall Sensor

The Hall Sensor component provides information from the Hall Sensors, which are integrated into the motor. The Rotor position can be known by the currently active Hall Sensor. The hall sensor inputs are directly connected to GPIOs and used to determine the active hall state.

Motor Control Layer (MCL)

The “Motor Control Layer“ (MCL) contains 4 components.

Motion

The “Motion“ component provides basic motion functionality. Unlike the previous FOC version V1.0.0.0, the structure of the Motion component had been changed. The main purpose of the change is to ensure motion synchronization with the Bus Cycle on the Application layer instead of Hal Timer. In this way, Isochronous mode support is provided.

At the new FOC, the Motion layer commands are categorized under two command types.

1. Acyclic: The first goal here is to make FOC ready for use with relevant operation mode commands and calibration is one of these examples. The second one is changing the operation modes dynamically: Coast mode, Start operation, etc. In Figure 4, the acyclic operations are depicted.

These functions are called directly from the Application through FOC API functions.

• MOTION - Coast Stop: The Coast Stop mode is designed to bring the MOSFET gates to Hi-Z (Gate driver outputs are switched to Hi-Z) and ensure that the motor will spin down at whatever speed the load imposes. It is generally used to perform the Pulse Disable operation on ProfiDrive. Likewise, the same process is performed on EtherCat Motion and its equivalents.

• MOTION - Start Operation: It disables the coast stop mode. In this way, the motor control PWM pulses are enabled. The speed controller starts to handle the speed setpoint value set by a related application. So speed and position control are activated.

• MOTION - Calibration with user parameters: Motor calibration can now be performed by setting calibration parameters externally (Motor self-calibration can pose a safety risk when the motors are linked to a mechanical mechanism because the drives begin to move). The calibration parameters acquired after a successful motor self-calibration are stored in the Remanent area on the Application (e.g. PLC). As long as there is valid calibration data in the remanent data on Application start-up, the calibration will be executed instantly by configuring these parameters (the motor will not move). More detailed information can be found here: PDMC AC1/4 Motor Calibration.

• MOTION - Start self-calibration: The operation of the Field-oriented control (FOC) component is highly dependent on determining the rotor position angle. For this, the FOC needs to know the hall sensor sequence and the corresponding rotor position for each hall sensor. The motor self-calibration is achieved by providing the FOC with the correct values of these parameters (given the specific motor and load). During the self-calibration process, the motor turns at low RPMs in clockwise (capture the start points) and counterclockwise (capture the endpoints) directions and the following parameters are measured. In addition, the hall sensor sequences of the motor are determined. The Start self-calibration function starts the internal timer when triggered from an App via the FOC API. Thanks to the timer callback, the self-calibration process starts to be performed cyclically. All necessary Foc Control, Calibration and PSE components are handled through timer callback within the scope of the self-calibration process. The started internal timer automatically stopped with the completed calibration process.

2. Cyclic: The associated cyclic process provides the motor speed and position control processes. In contrast to the V1.0.0.0, the timer performing the cyclic control has been moved into the external application layer. In this way, all motion control processes are synchronized with the Application. Full synchronization support is provided indirectly with the hardware-assisted bus cycle(by XCTRIGGER). In this way, IRT (Isochronous Real-Time) mode support is provided and jitters occurring in the Bus Cycle can be tolerated to a certain level (by MPWM Synchronization - FOC Run-Time Analysis). In Figure 5, the acyclic operations are depicted.

• MOTION - Set motor speed: The set motor speed is called cyclically by the external application timer. It is fully compatible with the different timer periods (The response of the speed and position control will vary depending on the period of the relevant external timer). The position control mentioned above is realised by the external application through the position feedback from the encoder. It logically generates a position path integrating the set motor speed including the ramp-up and ramp-down.

• MOTION - Get motor speed: The get motor speed is called cyclically by the external application timer the same way. It returns the actual estimated motor speed. Triggering this component cyclically is of vital importance as it performs the speed and position estimation process by the PSE component. The PSE component has been modified to work flexibly with different bus cycle periods. Unlike V1.0.0.0, the PSE component calls the capture QEI (Quadrature Encoder Interface) function by the PSE estimate speed function to calculate estimate speed. Please don’t forget the trigger Get Motor Speed function through FOC API cyclically to ensure error-free motion control.

These related functions are implemented in the “Components\Hal\Sources\Mcl_Motion.c”.

FOC Control

The “FOC Control“ component takes care of the vector part of the FOC application. It allows the motor to be driven with closed-looped(current vector control) and open-looped(voltage vector control). With the closed-loop control, it is ensured that the maximum torque value is reached by making the I_d and I_q vectors orthogonal by the current PI controllers for the set speed (Figure 1). In open-looped control, on the other hand, the v_d and v_q vectors are directly determined and given to the Inverse Park Transform block to control the motor, and maximum torque cannot be guaranteed. It is used in our application during calibration and will be implemented for more precise position control. Above, the MPWM ECZ event is mentioned while explaining the MPWM component. The ECZ counter value is 2 in your application. That is, 1 ECZ event will occur in every 2 BOP events and the MPWM Event Callback will be handled. The functions handled (Figure 6) each time the MPWM event callback is invoked are described below.

• HAL GATE DRV - Gate Driver Operation State Machine: The Gate Driver component plays a crucial role in controlling the FOC. This state machine processes the operation control command given to the Gate Driver. These are respectively to enable/disable the Gate Driver, write the desired configuration registers, read the status registers, and perform fault detection. Since the Gate Driver is responsible for measuring the current flowing through the motor windings, it's essential to trim this offset value to minimize any potential measurement errors. For trimming these offset values, The current offset compensation algorithm trims these offset values into the Foc Control component. However, this algorithm compensates for all cascaded offsets generated by the ADC input offset and other onboard components. When compensating the gate driver's current measurement offset value before entering the ADC, reduces the risk of measurement error. Because this separated offset values from ADC and other parasitic effects, only ADC errors and these parasitic effects will be filtered with the offset compensation algorithm in Foc Control. More detailed information can be accessed at the relevant link: Auto Current Offset Trim using DRV8323RS Gate Driver. The corresponding HAL Gate Driver operation state machine is shown in Figure 7, and the states' behaviour is explained in detail in Table 3. HAL Gate Driver Operation State Machine is implemented in the Hal_GateDrvCyclicRoutine(…) function in the “Components\Hal\Sources\Hal_GateDrv.c”.

• MCL FOC Control - FOC Control Main State Machine: This state machine is a large-scale state machine providing the FOC control. The state transitions of this state machine are indirectly controlled by the Motion component using the Transit state function. That is, its control is performed indirectly by the MCL Motion component. Please keep this in mind when examining it. The corresponding FOC Control Main state machine is shown in Figure 8, and the states' behaviour is explained in detail in Table 4. IDLE state stops all FOC operation including stopping MPWM when the motor is not operating. The purpose of the VOLTAGE CONTROL state is to provide open-loop vector control for the calibration process (It will be used with implemented torque control). The aim is not to reach the maximum torque but to keep the torque constant for accurate measurement during calibration. The CURRENT CONTROL state provides the desired closed-loop vector control. This is the behaviour we want during motor control. It keeps the motor torque at the maximum level at set speed thanks to the dq current PI controllers it contains. It is the state that is active when the motor is operating. The FAILED state is triggered after a critical error in the Motion Control State and MPWM is stopped. Then it is checked whether there is an error in the Gate Driver Unit and if there is an error, Fault Handling is performed. If necessary, the Gate Driver Unit is restarted. MCL Foc Control Main State Machine is implemented in the Mcl_FocCtrlMainSMCtrl(…) function in the “Components\Mcl\Sources\Mcl_FocCtrl.c”. It is transited with the Mcl_FocCtrlTransitMainSMState(…) function on the same path.

The CURRENT OFFSET state is used for current offset bias calculation. Phase currents are AC by nature, that is they are bidirectional currents. However, the integrated ADC we measured is DC, so it is unidirectional. Measuring the phase currents with the ADC and interpreting it assigned in the variable, we need to make the Current Offset Bias calculation and compensate for the measured values. The state machine manages the current offset bias calculation in the CURRENT OFFSET state. The corresponding FOC Control Main state machine is shown in Figure 9 and its states' behaviours are explained in detail in Table 5. MCL Current Offset Bias Calculation State Machine is implemented in the mcl_FocCtrlCurrentOffsetSMCtrl(…) function in the “Components\Mcl\Sources\Mcl_FocCtrl.c”.

Calibration

The purpose of the MCL Calibration component is to make the correct position estimation. It can be performed in two different ways.

1. Motor self-calibration: The motor self-calibration provides associate position information from the feedback device (Encoder, Resolver, etc.) related to each motor hall sensor sector for both rotation directions(CW and CCW). The purpose of rotating the motor in two directions is to compensate for the Hysteresis effect by determining the start and end positions of each Hall Sensor sector. Then it is validated whether the position values obtained for the six Hall Sensor sectors are within certain limits in both directions. After successful validation, the values obtained in both directions in each Hall Sensor sector are averaged and recorded for the correct position estimation. The corresponding Calibration state machine is shown in Figure 10, and the states' behaviour is explained in detail in Table 6. MCL Calibration State Machine is implemented in the Mcl_CalCyclicRoutine(…) function in the “Components\Mcl\Sources\Mcl_Cal.c”.

2. Motor calibration using user parameters: This feature was implemented with V1.1.0.0. Hall Sector sequence and position values obtained through previously successful self-calibration are required to perform this functionality. These values can be obtained and recorded in the remanent area in the external Application. This allows the motor to be calibrated instantaneously without moving the rotor. (Motor self-calibration can pose a safety risk when the motors are linked to a mechanical mechanism because the drives begin to move)

PSE (Position & Speed Estimation)

The PSE component transforms the data it receives from the relevant feedback devices(Encoder, Resolver, Hall Sensor from HAL layer) into meaningful and provides speed and position information for FOC control. Speed and position information is currently only provided by the encoder (with the QEI interface) and the Hall sensors.

The PSE component has been modified to work flexibly with different bus cycle periods. Unlike V1.0.0.0, the PSE component calls the capture QEI (Quadrature Encoder Interface) function by the PSE estimate speed function to calculate estimate speed. Thus, synchronization with the external Application is possible.

In the future, various encoder interfaces and resolvers (SinCos) will be supported.

FOC API Layer (CORE)

The “Foc Api Layer“ provides an interface for the user to control the FOC application. The following functions can be accessed from the “Targets\Common\Include\Foc_Api.h” file.

Initialize FOC layer

Initializes the FOC. After successful initialization, creates resources, starts the FOC, and returns the handle to the user.

Deinitialize FOC layer

Deinitializes the FOC. It stops the FOC and frees up the resources for the corresponding handle.

Set Motor Speed

Sets the motor speed in RPM. This function must be set cyclically using either the hardware-assisted bus cycle callback (XCTRIGGER) or a timer callback you have created. Because the speed controller indirectly handled using these callbacks.

Get Motor Speed

Gets the actual motor speed in RPM. The get speed is estimated through the encoder by default. The Hall sensor can also be used for speed estimation, although this is not our recommendation. Resolver support will be available in the future as well. This function must be set cyclically using either the hardware-assisted bus cycle callback (XCTRIGGER) or a timer callback you have created. Because the speed is indirectly estimated using these callbacks.

Set Operation Mode

Sets the FOC’s operation mode. It allows FOC to perform different operations. The function ”Set operation mode” activates the related mode acyclically. Related operation mode descriptions can be found in Table 7.

Get Operation Mode

Gets the motion control state machine's state. The enum type “MCL_MOTION_CTRL_STATE_E“ shows the current operation mode. Related motion control states' descriptions can be found in Table 8.

Set Reference External Trigger Period

Set the reference external trigger period. The reference external trigger (XCTRIGGER or Timer callback) period information set by the user is used to synchronize the PWM event with the external trigger. As mentioned above, the IRT mode was introduced with FOC V1.1.0.0 and must be synchronised with MPWM to ensure deterministic synchronised operation.

Get Reference External Trigger Period

Get the reference external trigger period. This is the reference external trigger (XCTRIGGER or Timer callback) period last set by the user.

Get Motor Position

Gets the provided position information obtained and processed by the relevant peripheral modules. In V1.1.0.0 this peripheral module is QEI (Quadrature Encoder Interface). The position information data details are described in Тable 9.

Get Motor Position Format

Gets the provided motor position format information. It gives automatically calculated bit lengths depending on the resolution of the position estimation sensor integrated into the motor. This format’s structure details are described in Тable 10.

Set Motor Calibration Parameters

As mentioned above, V1.1.0.0 supports motor calibration using the User Parameters feature. This function sets the motor calibration parameters. It should not be forgotten that the motor calibration parameters must be obtained during the previous self-calibration process (MCL_PSE_NUM_OF_HALL_SECTORS: 6) and must be valid. The calibration parameters' structure is described in Table 12.

Get Motor Calibration Parameters

This function gets the motor calibration parameters obtained by previous valid calibration. (MCL_PSE_NUM_OF_HALL_SECTORS: 6). The calibration parameters' structure is described in Table 11.

Mathematical Library(MATH)

Contains all the transform and calculation functions of the FOC. You may be wondering why some general mathematical functions are also included here. They are optimized for speed.

This layer is accessible from all layers. In Figure 3, the functions included in the MATH library are shown.

Targets

It is the place where all layers of the FOC component are initialized, configured, started, etc.

The “Targets\Common\Include\McBoardHwConfig.h” file contains the board definitions (voltage divider resistors, shunt resistors, etc.) associated with the netX90-MC board used by the FOC. Thus, definitions can be configured easily after new board revisions.

The “Targets\NXHX90-MC\Sources\main.c” file is where all the initialization, configuration, and motor demo functionality resides. Only the parameters that users can modify will be discussed here.

Board configuration

The MCL_MC_BOARD_CFG_PRM_T structure contains some board-specific parameters. It provides the ability to change configurations based on hardware changes and is initialized in “Targets\NXHX90-MC\Sources\main.c”. Normally these parameters are not supposed to be modified because they are tuned for the current NXHX90-MC board which is not expected to be changed once configured properly. Related parameters are shown in Table 12.

Motor-specific Configuration

The Motor-specific parameters are typically found in the Manufacturer's specification for the motor. In the PROFIdrive example, this configuration is found in the structure. Related parameters are shown in Table 13.

(in Targets/NXHX90-MC/main.c).

FOC System Configuration

These parameters, situated in the lower layers (MCL, HAL) of the FOC, are crucial for ensuring the effective operation of its algorithms. The MCL_FOC_SYS_CFG_PRM_T structure contains these parameters.

They are initialized in “Targets\NXHX90-MC\Sources\main.c”. Normally they are not supposed to be modified because they are tuned for the current FOC algorithm. Related parameters are shown in Table 14.

(in Targets/NXHX90-MC/main.c).

FOC Demo

Demo behaviours

There are two demo modes:

1. Cyclical demo mode: This demo is created to demonstrate the speed control capabilities of the FOC. Additionally, the coast-stop functionality is added to the demo to be understood and observed by the user. Figure 11 shows the exact behaviour of the demo. The specific times from t₁ to t₁₄ are not provided due to the possibility of changes with new updates.

2. Demo mode with potentiometer: The motor speed is adjusted with the potentiometer on the board.

The desired demo mode is activated from the “Targets\wscript” file by manipulating the __USE_DEMO_POTENTIOMETER parameter.

Open

Figure 11 - FOC Ramp Demo motor speed variation diagram over time.

Figure 12 shows the FOC Demo Run-time diagram including the behaviour of the FOC. Using two job timers is to adapt the Demo to isochronous mode. The Bus Cycle Emulation process was performed with these two timers. Additionally, the FOC details mentioned above are summarized in Figure 12.

Initialization

1. Configures the structures mentioned in Targets according to the selected target.

2. Initializes the FOC modules and gives the user the FOC handle after the successful initialization.

3. Initializes the FOC job timers.

4. Sets the reference external trigger period to give feedback for MPWM synchronization.

5. Realizes the calibration process dependent on the __USE_MOTOR_CALIBRATION_WITH_PARAMS parameter’s value and waits until it is completed.

6. Sets the operation mode with the Start Operation parameter and waits unit it is completed.

7. Start selected demo mode dependent on the __USE_DEMO_POTENTIOMETER parameter’s value.

Abbreviations