Problems with STM32 PMSM FOC SDK

[tatus1969]

Overvoltage starts to be a problem.

I came back to see your recommendation to use a zener diode.
When the motor decelerate, the VBus rises to 35V.

One zener diode of 27V, 5W should be enough to control, right?

As a precaution I will use a 24V TVS as well.

it depends on the mass that you are decelerating. calculate the stored energy of the rotating mass at full speed, that gives you an estimate of how beefy your zener or tvs needs to be. larger bus capacitance also helps.

[Dave_PT]

I've been thinking better and I'm going to use a zener to close a MOSFET and dissipate everything in a power resistor ...

I will have to draw the PCB again to support this ...

[tatus1969]

I've been thinking better and I'm going to use a zener to close a MOSFET and dissipate everything in a power resistor ...

I will have to draw the PCB again to support this ...

didn't you say that your system was battery powered? should only be a problem when you power it from a psu. maybe simulate your circuit, as you describe it sounds like you will be operating the transistor in its linear and dissipative region.

[Dave_PT]

Yes, you are right.
But apparently this is going to take many bench tests using the bench power supply ...
So by prevention, and since I have free space on the PCB, I'm going to set up this circuit.

When Vbus rises above 29V (Vzener + Vth) the MOSFET closes and dissipates the energy in excess in a resistor of 56R (35W D2PAK).
These events should be sporadic so the heat should not be a big problem.

[tatus1969]

Yes, you are right.
But apparently this is going to take many bench tests using the bench power supply ...
So by prevention, and since I have free space on the PCB, I'm going to set up this circuit.

When Vbus rises above 29V (Vzener + Vth) the MOSFET closes and dissipates the energy in excess in a resistor of 56R (35W D2PAK).
These events should be sporadic so the heat should not be a big problem.

The circuit will not work as intended, because you'll operate the transistor in its linear region, it will not saturate. The transistor will dissipate the energy, not the resistor. I suggest to remove/short the resistor, and use a larger D(2)PAK MOSFET instead, and let that handle the heat.

[Dave_PT]

In my simulation practically the whole power is dissipated in the resistance ...
I'm assuming that the voltage increase is fast (~10mS).

In the chart:
Red Line - Vbus
Green Line - Energy dissipated by resistance
Blue Line - DISSIPATED MOSFET (~ 4W).

[Dave_PT]

R(j-a) = 120ºC/W

4W = 360ºC

This is going to crack 

Everything will depend on how long the MOSFET will be ON... if the generated energy dissipates fast, then it will work, but if too much power is generated, it will warm up!

[tatus1969]

In my simulation practically the whole power is dissipated in the resistance ...
I'm assuming that the voltage increase is fast (~10mS).

In the chart:
Red Line - Vbus
Green Line - Energy dissipated by resistance
Blue Line - DISSIPATED MOSFET (~ 4W).

It seems that your simulator doesn't handle the rising edge properly. There's MOSFET dissipation there as well (attached pic). Your solution will also work as it only has to dissipate the inertial rotor energy, and that is limited. But how about using a GPIO pin to control the MOSFET, and use the bus voltage ADC and some interrupt driven code to form a comparator that enables the MOSFET when Vbus > Vthreshold?

[Dave_PT]

I do not know what's happening now...

Now I have the following problem: everything ready to work with the encoder, align the motor (it moves!), but when I click start it does not run. Tremble 1 second and then do nothing else.

What could be the problem this time?
The encoder is correctly set to 500 ppr...

In sensorless the motor rotates ... so the electronics is fine.

[tatus1969]

maybe wrong turning direction? what happens if you swap two motor phases?

[Dave_PT]

I have not done this yet, but in the encoder setup I already tested with "reverse". The result is the same ...

Reverse direction in the encoder setup (in the configurator) should not work?

The encoder signal is perfect ... but it looks like the control will not start. On the other hand I do not get any error message ...

Stupidly, I just changed the PCB ... the entire circuit is the same as I've tested and put it into proper operation 

The motor has the numbered phases (1 2 3), which I connected to (U V W).


EDIT:

maybe wrong turning direction? what happens if you swap two motor phases?

In that case, would the sensorless control work?
It's that the engine runs on sensorless ... but with the encoder I'm not lucky.

[tatus1969]

I have not done this yet, but in the encoder setup I already tested with "reverse". The result is the same ...

Reverse direction in the encoder setup (in the configurator) should not work?

The encoder signal is perfect ... but it looks like the control will not start. On the other hand I do not get any error message ...

Stupidly, I just changed the PCB ... the entire circuit is the same as I've tested and put it into proper operation 

The motor has the numbered phases (1 2 3), which I connected to (U V W).


EDIT:

maybe wrong turning direction? what happens if you swap two motor phases?

In that case, would the sensorless control work?
It's that the engine runs on sensorless ... but with the encoder I'm not lucky.

swapping two phases is the same as reversing encoder direction by configuration, both work equally. The sensorless algorithm works same after swapping phases, the motor will just run in opposite direction.

I would double check the encoder operation here:
- during alignment, is the motor shaft stiff after the current has ramped up? (you can extend the alignment duration to a few seconds to test this)
- can you check the rotor angle output via the analog output test signal? It should vary also when turning the motor by hand
- do you control the motor via STMCWB? No error signaled there?
- sure that the number of poles, and the number of encoder counts per mech revolution is absolutely correct? A mistake there would have exactly that effect.

[Dave_PT]

- during alignment, is the motor shaft stiff after the current has ramped up? (you can extend the alignment duration to a few seconds to test this)

I changed the alignment to 5 seconds. The current goes up and then the alignment ends.

- can you check the rotor angle output via the analog output test signal? It should vary also when turning the motor by hand

This is a problem.

I tried yesterday do this ... but at the output of the DAC I do not have variations.
It seems to me that it is not reading the encoder, but the encoder is correctly connected, to the right pins of the MCU and generate a perfect wave ...

- do you control the motor via STMCWB? No error signaled there?

Yes, I am using STMCWB, but no error is shown.

- sure that the number of poles, and the number of encoder counts per mech revolution is absolutely correct? A mistake there would have exactly that effect.

The motor configuration is right. The encoder configuration, could have some problem, but I already switched by the encoder I had to work on the other PCB.
I will continue to check this situation and see if there may be a problem here ...

[tatus1969]

I tried yesterday do this ... but at the output of the DAC I do not have variations.

I know for sure that you should have DAC output after successful alignment when manually turning, motor enabled, Id=Iq=0. I do not know if the library generates a rotor angle signal *before* alignment, nor what happens when then motor is not in "started" condition.

[Dave_PT]

The DAC works only in "run mode".
When I click "start" motor, the rotor got stuck and I could not turn by hand.
I disconnected the motor connections and then turn the shaft by hand.

I do not have any RPMs measured either in STMCWB or in DAC 

[tatus1969]

The DAC works only in "run mode".
When I click "start" motor, the rotor got stuck and I could not turn by hand.
I disconnected the motor connections and then turn the shaft by hand.

I do not have any RPMs measured either in STMCWB or in DAC 

Can you give me the STM32 pinout and port assignment? Also what's reported by STMCWB when you hit the "pin assignment" button? Maybe there is a hidden conflict, or a compatibility problem with the micro. Also make sure that you always use the *primary* rotor feedback in the configuration, the secondary has no use in this setup.

[Dave_PT]

I checked the pins and got the right connections ...

I have to find a way to make sure the MCU can receive the signals from the encoder.

https://meocloud.pt/link/e8c879ee-96e5-4a4b-9171-f9cf74030922/FOC%20SDK.rar/

[Dave_PT]

Wait....

Wait...

Inspection loupe is talking to me!

[Dave_PT]

I'm a f**ing idiot, with a f**ing blindness!

I measured all the signals on the MCU pins (because I had already learned from past mistakes). But by pressing the MCU pin with the oscilloscope probe, the pin made contact with the pad.
When I took the probe away, the pin was raised.

With the inspection magnifying glass I could see that something was not right ...
 

[tatus1969]

  reflow process stability  +  leadfree solder = &%()§$$"§ ? 

[Dave_PT]

The values I'm changing on the monitor are divided by the constants in Drive Settings, right?




Now I'm having trouble keeping up the rotation.
The motor starts to spin and after a few seconds it loses rotation and stops.

[tatus1969]

The values I'm changing on the monitor are divided by the constants in Drive Settings, right?

exactly. But I don't think that it is the velocity controller causing these problems. If the gains are too low, then it will react slowly but still reach steady state. If they are too high, then it will oscillate.

Your observation is somewhat different. The motor starts, it should instantly reach target speed. I assume no shaft load, so that should normally be not more than a few ten to 100 milliseconds depending on the motor. In your case it does never reach target speed, so you have two possible problems:
1) the motor current amplitude is not high enough
2) the motor current does not have the right phase (orientation with respect to rotor)

Does the motor run properly in sensorless configuration? Can you load the shaft then, does it maintain target speed then? You could measure one of the phase currents to see if it reaches the nominal value of 4A that you configured for the motor. If all this is correct, then this rules out option 1. To sense the motor current, I recommend this one here. I bought it a few weeks ago, incredible price/performance ratio and does its job well: http://www.hantek.com/en/ProductDetail_15_77.html

[Dave_PT]

Does the motor run properly in sensorless configuration? Can you load the shaft then, does it maintain target speed then?[/url]

Right now I've been testing with sensorless and it works.


When I returned to control with encoder feedback, the motor starts to spin, but after a few seconds it stops ...
* Yellow: encoder alignment
* Green: motor start

[Dave_PT]

I was able to keep the motor running for more than a few seconds ... but when I changed the speed reference to see the control running, it did the opposite action.
Weird...

[tatus1969]

there is only one reason for this that i can think of: the encoder does not do 500 counts per mech rev. even 501 or 499 would lead to exactly this result.