STSPIN32G4: No spin with encoder as main sensor

[ClyneModa]

[PN]: STSPIN32G4 (custom board), AMT103 encoder
[VERSION]: MCSDK v6.4.1
[TOOL]: MC WB

[DETAILS]:
I need to implement torque control for my custom board and BLDC motor using a quadrature encoder as the primary feedback sensor.

First, I successfully profiled my motor in sensorless mode using the SDK and incorporated those values into my Workbench project. When using this sensorless configuration outside of the Profiler, I can reliably drive my motor in both torque and speed control modes (using MC_FOC_SDK.qml). At this point I have also configured the encoder as an auxillary sensor, and can see its measured RPM in Motor Pilot match the sensorless RPM feedback. This encoder has an index pin, but I am not using it in my configuration since I do not want to run in Position Control mode.

Now, I have reconfigured my project to use the encoder as the primary sensor and "sensorless" as the auxillary. The result in torque control mode is that the rotor locks into place and resists manual spinning. This resistance increases alongside increased torque reference. If I use the Motor Pilot GUI to switch to sensorless mode, then the motor finally spins up. Switching back again to the encoder will make the motor stop and lock into place. In speed control mode the torque reference will creep up towards the motor's maximum rated current while the rotor remains locked into place.

I believe my problem lies in the encoder's "Start-up parameters", but adjusting the alignment angle or current ramp value does not seem to make a difference. Happy to test again if someone has insight to share here.

Any suggestions on what might be missing (or incorrect) in my configuration?

[EXPECTED BEHAVIOR]: When starting the motor with an encoder as the primary sensor, the motor should spin up in a way comparable to sensorless mode.

[HOW TO REPRODUCE]: The MC Workbench project file is attached to this post.

[GMA]

Hello @ClyneModa,

Check that the motor phase U, V, and W, and the encoder phase A and B are correctly connected.
Using the speed sensor main as STO-PLL and the auxiliary encoder, plot both EL_ANGLE signals. Check that both signals are aligned.

[federico.rodighiero87]

motor profiler has its limit, try to tune motor manually and set encoder pulse correctly, remember the se the right pulse number, there are the typical x2,x4 scaling of CPR,PPR what front you read and so on.

[ClyneModa]

Yes, I believe the motor and encoder phases are connected "correctly". The motor is spinning in the positive direction and the encoder is showing positive RPM to match. I did notice that my pole pair count was off by one; making that fix improved the angle readings but did not fix the below:

With STO-PLL as main sensor and encoder as auxiliary, the EL_ANGLES do not align. The two signals phase in and out of alignment at a constant rate, briefly re-aligning every 10 seconds or so. I have the motor spinning at 360 RPM (rated max is 1500 RPM); the RPM measurements by the encoder and STO-PLL are in perfect agreement so there is little error aside from this drift in phase.

The encoder has "Pulse per mechanical revolution" set to 2,048. This is to match the encoder hardware which is configured for 2,048 PPR ("quadrature resolutions"). The encoder's datasheet notes that "all resolutions are listed as pre-quadrature, meaning the final number of counts is PPR x 4". Setting "Pulse per mechanical revolution" to 8,192 gives incorrect RPM and angle measurements by the encoder, off by roughly a factor of four compared to STO-PLL.

Given that the encoder configuration appears correct, are there setting(s) for the STO-PLL angle calculation which I can adjust to eliminate the drift in EL_ANGLE?

Otherwise, what should I try next to get the motor to spin with the encoder as the main sensor?

[GMA]

Hello @ClyneModa,

As the main sensor STO-PLL use case is fully functional, encoder drift can result from an incorrect pulses per mechanical revolution parameter or from mechanical drift between the motor shaft and the encoder itself.
Is it an additional sensor or an embedded sensor?

[ClyneModa]

Hi @GMA,

The encoder is additional, not embedded within the motor, but both are held into place by a custom 3D-printed enclosure.

Would drift in pulses per mechanical revolution prevent the SDK from spinning up the motor with encoder as the main sensor?

[ClyneModa]

Hi @GMA ,

Can you confirm if MCSDK is able to spin up a motor with an encoder as the main sensor?

I need the motor to be able to maintain constant torque at low or zero RPM, and be able to spin back up once the load is removed. I hope that this is something MCSDK is able to support using an encoder since sensorless control does not handle low/zero RPM well.

Any advice would be appreciated. Encoder RPM matches STO-PLL during sensorless operation, so I am confused as to why the motor halts when I attempt to switch sensors during RUN.

Thanks,
Clyne

[GMA]

Hello ,

When using the STO-PLL as the main sensor and the auxiliary encoder, decreasing the motor encoder pulses per mechanical revolution parameter by one results in the same drift on the electrical angles. The encoder speed appears correct; however, the motor magnetic field and the encoder are no longer aligned. Switching sensors, the motor stops.

[ClyneModa]

Hi @GMA ,

Okay.

Can you provide direction on how to spin up a motor with the encoder as the main sensor?

I have disabled the auxiliary sensor, so the firmware should only rely on the encoder now. When I press START, the motor begins to spin slowly, then decays to zero RPM with no fault. If I manually turn the motor, it begins to spin very slowly again, but still decays to zero RPM. On occasion, the motor will spin up again on its own again for a few seconds before stalling.

What are the relevant parameters for maintaining spin based on only the encoder? Can you make some recommendations on possible solutions to this problem?

[GMA]

Hello @ClyneModa,

As the position of the encoder shifts relative to the position of the motor's magnetic pole, it will reach a point where the generated field no longer corresponds to the motor's field position, and the motor will stop.
The recommendation is to first resolve the drift between the STO-PLL and encoder electrical angles observed in STO-PLL main sensor and encoder auxiliary mode use case.