Interfacing Quadrature Encoder with Motor Workbench

[msalazar]

Hi,

I am currently utilizing the MC Workbench (6.4.2) with an B-G431-ESC1 to drive a custom DC brushless motor. I've been able to successfully to control the motor and generate a motor profile when using the sensor-less option for speed control but when I select Quadrature and generate a package I can't seem to get the motor spin.

I realize that there is lot of information that is needed to debug this problem so let's start simple, is there a guide or what steps can I take to successfully generate code from with sensor option being selected, is the bring-up for getting the motor to spin just as simple? Typically something along the lines of is sufficient if the motor does not fault:

MC_ProgramSpeedRampMotor1(1500, 1000);
MC_StartMotor1();

I can provide the entire project if needed but I am not to sure if this is a firmware or hardware problem. From reading logs generated by the uC's UART channel I can see that M1_ENCODER_Z is behaving correctly and I believe the same is true for M1_ENCODER_(A/B).

Note that the "Encoder" log in the PuTTy screenshot is updated if the motor is rotated physically without the coils being energized i.e. device is only powered through the Micro-USB port.

while (1)
  {
    if (!initMotor)
    {
        HAL_UART_Transmit(
            &huart2,
            (uint8_t*)msg,
            strlen(msg),
            100
        );

        MC_ProgramSpeedRampMotor1(1500, 1000);
        MC_StartMotor1();

        initMotor = 1;
    }

    static uint32_t lastPrint = 0;

    if (HAL_GPIO_ReadPin(M1_ENCODER_Z_GPIO_Port, M1_ENCODER_Z_Pin))
    {
       HAL_UART_Transmit(
            &huart2,
            (uint8_t*)z_msg,
            strlen(z_msg),
            100
        );
    }

    if ((HAL_GetTick() - lastPrint) >= 1000)
    {
        lastPrint = HAL_GetTick();

        char debugMsg[128];

        sprintf(
            debugMsg,
            "State=%d Fault=0x%04X Encoder=%ld\r\n",
            MC_GetSTMStateMotor1(),
            MC_GetCurrentFaultsMotor1(),
            (int32_t)__HAL_TIM_GET_COUNTER(&htim4)
        );

        HAL_UART_Transmit(
            &huart2,
            (uint8_t*)debugMsg,
            strlen(debugMsg),
            100
        );
    }

    /* USER CODE END WHILE */
    
    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */
}

[GMA]

Hello @msalazar,

Verify that the U, V, and W motor phases are correctly associated with the U, V, and W pins on the board connector. Verify that the A, B, and Z signals are correctly associated with the A+, B+, and Z+ input connector.

Use the main speed sensor as the STO-PLL and the auxiliary speed sensor as the quadrature encoder. Using MC Pilot, display the STOPLL_EL_ANGLE and ENCODER_EL_ANGLE signals, and verify that both signals are aligned.

[msalazar]

Hi @GMA,

Thanks for your response. Here is an update on the situation currently. I've verified the connectors are associated with the corresponding pins for both the motor controller and encoder. I've re-generated the project such that STO-PLL is the main sensor and auxiliary is the quadrature.

Regarding the final step, I am not to sure what GUI is needed to display the STOPLL_EL_ANGLE and ENCODER_EL_ANGLE (screenshots would be appreciated). Additionally, from those changes I've successfully been able to get the motor to spin but now my question is what is quadrature really doing in this case? Does it have a direct impact on the ability to control lower RPMs that might not be achievable if the back-emf is not strong enough? I am just curious about how the auxiliary sensor interacts.

[GMA]

Hello @msalazar,

When the auxiliary speed sensor is set to quadrature encoder mode, the system computes the angle and speed from the encoder signals but does not use them to control the motor. This test verifies that the STO-PLL and the encoder report the same values.

Use the Motor Control Software Development Kit (MCSDK) Motor Pilot tool to display the electrical angle value.