Problems with STM32 PMSM FOC SDK

[tatus1969]

Wait ... on file MCTasks.c, can you explain the logic to this? 

Code: [Select]

#if ((defined NO_SPEED_SENSORS)||(defined ENCODER)||(defined VIEW_ENCODER_FEEDBACK))
CSPD oVSS_M1;                         /* only if M1 is sensorless*/
#endif

Now it makes some sense.
They are not even initializing the encoder. Just like I thought ...

"encoder" is never defined.

The oVSS_M1 object is used during alignment. This is a "virtual" rotor feedback sensor, which they use to "inject" a certain measured rotor angle. If they, for example, set this to 90°, and apply motor current, then this will cause the motor to snap into that angle.

The important code that needs to be executed is for example

(line 550)
  oSpeedSensor[M1] = (CSPD)ENC_NewObject(&SpeednPosFdbkParamsM1,&ENCParamsM1); /* speed sensor STO, ENC, HALL xNew and xParamsM1*/

[tatus1969]

Wait ... on file MCTasks.c, can you explain the logic to this? 

Code: [Select]

#if ((defined NO_SPEED_SENSORS)||(defined ENCODER)||(defined VIEW_ENCODER_FEEDBACK))
CSPD oVSS_M1;                         /* only if M1 is sensorless*/
#endif

Now it makes some sense.
They are not even initializing the encoder. Just like I thought ...

"encoder" is never defined.

You can easily check if ENCODER is defined by adding

#ifndef ENCODER
fucked up!
#endif

somewhere in one of the source files

[Dave_PT]

Code: [Select]

unknown type name 'fucked'
You do not know ... but I know it well !!!

[Dave_PT]

Could the project not be including the "Drive parameters.h" file?

[tatus1969]

Code: [Select]

unknown type name 'fucked'
You do not know ... but I know it well !!!

you got a problem with your config/build/project. when i do it here i end up with #define ENCODER in "Drive parameters.h"

[tatus1969]

Could the project not be including the "Drive parameters.h" file?

is there a predefined constant "STM32F30X" in your project settings? There's only one #ifdef that can prevent that ENCODER inclusion, it is in "Parameters conversion.h". Sure you're compiling and flashing the same project as you think? In Germany we say, the devil is a squirrel.

[Dave_PT]

But the folder is there!

PS: I do not have in the whole project #include for "Drive parameters.h".
Should not I have #includes for the header files where the #defines are?

[tatus1969]

But the folder is there!

PS: I do not have in the whole project #include for "Drive parameters.h".
Should not I have #includes for the header files where the #defines are?

It's a bit ugly.
"MCTasks.c" includes "SystemNDriveParams.h"
"SystemNDriveParams.h" includes "Parameters conversion.h"
"Parameters conversion.h" includes "Parameters conversion_F30x.h" (if that "STM32F30X" definition is in your project)
"Parameters conversion_F30x.h" includes "Drive parameters.h"

[Dave_PT]

When I compile the program, it does not see the config files.

Now I'm sure.
But I do not know how to solve ...

[Dave_PT]

The eclipse is not working well ... but the encoder is declared.

I put this at the end of the file "MCTasks.c".
The message appears on the console.

Code: [Select]

#ifdef ENCODER
#warning "encoder declared!!!"
#endif

[Dave_PT]

I think I've already solved the problem.
Now I'm having trouble getting the motor in rotation ...
The calibration values are not right, because I've changed Fpwm and everything else.

[tatus1969]

I think I've already solved the problem.
Now I'm having trouble getting the motor in rotation ...
The calibration values are not right, because I've changed Fpwm and everything else.

great!
what happens now?

[Dave_PT]

great!
what happens now?

Now I'm having lots of feedback faults...

[Dave_PT]

Looks like the motor was making an acceleration ramp and then it stopped ... 

[Dave_PT]

Now I am actually using the encoder!

But I still have problems.

When I do "encoder align" the current rises to 100mA and the rotor moves a bit.
Then I start the motor and the rotor starts to spin. The rotor rotates about 2/3 times and stops. The current rises to 530mA.
If I do not do "encoder align" the rotor never rotates and the current immediately rises to 530mA.

[tatus1969]

great!
what happens now?

Now I'm having lots of feedback faults...

is this issue solved? I see that the motor stopped with a speed sensor error. This means that the library code that runs the encoder has detected a problem. I have checked the code, the only situation in this is signaled is a timer overflow. This happens at veeery slow speed, sub rpm, and permanent standstill. (In a robotic application, standstill is a normal situation, so this should not cause an error. Maybe an issue to solve later...)

[Dave_PT]

is this issue solved?

It happens less.
Once in a while it goes fault again.
But okay, there is not much problem.
We can solve it after configuring everything to use the encoder.

But I'm not getting the rotor to rotate more than 2/3 times ...


Some doubts:
When is the primary and secondary sensor used?
When does the controller stop using the primary sensor and start using the secondary sensor? And vice versa?

[tatus1969]

Now I am actually using the encoder!

But I still have problems.

When I do "encoder align" the current rises to 100mA and the rotor moves a bit.
Then I start the motor and the rotor starts to spin. The rotor rotates about 2/3 times and stops. The current rises to 530mA.
If I do not do "encoder align" the rotor never rotates and the current immediately rises to 530mA.

Do you mean motor phase current or supply current? Please check the current Iq during encoder alignment. Does it rise to 1.5A (or the value you set in the startup parameters)?

Also put the rotor angle on the screen (measured electrical angle). Turn the motor manually a few turns, is the display consistent (the displayed angle value must be the same every time the shaft repeats a certain orientation)? I suspect that there is still a mismatch between encoder angle measurement and actual angle.

[tatus1969]

is this issue solved?

It happens less.
Once in a while it goes fault again.
But okay, there is not much problem.
We can solve it after configuring everything to use the encoder.

But I'm not getting the rotor to rotate more than 2/3 times ...


Some doubts:
When is the primary and secondary sensor used?
When does the controller stop using the primary sensor and start using the secondary sensor? And vice versa?

I thought that you were not configuring a secondary sensor? In this case, the software sticks to the primary.

[Dave_PT]

Some doubts:
When is the primary and secondary sensor used?
When does the controller stop using the primary sensor and start using the secondary sensor? And vice versa?

I thought that you were not configuring a secondary sensor? In this case, the software sticks to the primary.

Yes, I am not configuring the secondary sensor.

It was just a question.
Basically the controller will always use the main sensor?
Is there a time when the controller makes the switch?

[tatus1969]

is this issue solved?

It happens less.
Once in a while it goes fault again.
But okay, there is not much problem.
We can solve it after configuring everything to use the encoder.

Could be a problem with the encoder signals, maybe they pick up noise from the motor phases. You can try a shielded cable, or add more filter capacitance to GND on the nucleo power board.
For a series design I recommend to use differential signaling.

[tatus1969]

Some doubts:
When is the primary and secondary sensor used?
When does the controller stop using the primary sensor and start using the secondary sensor? And vice versa?

I thought that you were not configuring a secondary sensor? In this case, the software sticks to the primary.

Yes, I am not configuring the secondary sensor.

It was just a question.
Basically the controller will always use the main sensor?
Is there a time when the controller makes the switch?

If primary=encoder and secondary=null, the controller will use the encoder after alignment. I do not know how it should behave, if alignment has not been executed. Probably it depends on your luck. If the physical rotor angle is null when the software starts up, then you could run the motor without alignment.

[Dave_PT]

Do you mean motor phase current or supply current? Please check the current Iq during encoder alignment. Does it rise to 1.5A (or the value you set in the startup parameters)?

These values are shown by power supply.

The alignment lasts approx 700mS. I do not know what is the Iq to Vout ratio of the DAC. But I measured a peak of 0.5V (2.15V - 1.65V).
I have configured it for 1A.

Also put the rotor angle on the screen (measured electrical angle). Turn the motor manually a few turns, is the display consistent (the displayed angle value must be the same every time the shaft repeats a certain orientation)? I suspect that there is still a mismatch between encoder angle measurement and actual angle.

I took a picture of the oscilloscope.
I had to put the controller at zero speed to be able to rotate the rotor manually.
The DAC outputs (in this version) only come into operation after make "start motor.

Could be a problem with the encoder signals, maybe they pick up noise from the motor phases. You can try a shielded cable, or add more filter capacitance to GND on the nucleo power board.
For a series design I recommend to use differential signaling.

Noted!

If primary=encoder and secondary=null, the controller will use the encoder after alignment. I do not know how it should behave, if alignment has not been executed. Probably it depends on your luck. If the physical rotor angle is null when the software starts up, then you could run the motor without alignment.

Thank you.
I was wondering what this exchange between sensors would be like ...

[tatus1969]

The alignment lasts approx 700mS. I do not know what is the Iq to Vout ratio of the DAC. But I measured a peak of 0.5V (2.15V - 1.65V).
I have configured it for 1A.

I have two issues with this picture: (For the next photos, it would be nice to include the timebase and all vertical settings. Guessing 100ms timebase here, right?)
- is that really Iq? It doesn't look like it should. I would have expected a constant 1A value for that 700ms (or a linear ramp)
- the encoder seems to misbehave beginning with horizontal division 9. There seems to be some high frequency 'overlay', if we can assume that the motor is slowly accelerating.
Iq voltage conversion should be 0V <--> -max measurable current, 3.3V <--> +max measurable current. STMCWB calculates max readable current of +-3.268A (power stage, current sensing). So +1A would be 1.65V + 1.65V*(1.0A / 3.268A) = 2.15V. It seems like the current controller is reaching that level for a short time, when looking closely at the beginning (~ div 1).

It looks to me that the current PI control loop is oscillating. I suggest working on the motor current before looking at encoder feedback. You can use/repeat the alignment procedure to investigate that.

Also put the rotor angle on the screen (measured electrical angle). Turn the motor manually a few turns, is the display consistent (the displayed angle value must be the same every time the shaft repeats a certain orientation)? I suspect that there is still a mismatch between encoder angle measurement and actual angle.

I took a picture of the oscilloscope.
I had to put the controller at zero speed to be able to rotate the rotor manually.
The DAC outputs (in this version) only come into operation after make "start motor.

looks okay. But the objective here is: does the encoder count correctly? If you paint a reference mark on the shaft, and turn it a random number of complete revolutions (fast or slow), and then carefully align to the painted reference mark again, then the shown voltage (or value, if you do it directly in STMCWB) for "measured electrical angle" *must* be identical all the time. Have you checked that? *And* you must see exactly *one* triangle sweep per mechanical revolution. It is not allowed to "lose" one single tick count now and then, because that will put everything out of sync over time.

From the first scope picture, I am concerned that the encoder output may be corrupted. (Magnetic interference? wrong field strength of permanent magnet?)

[Dave_PT]

I have two issues with this picture: (For the next photos, it would be nice to include the timebase and all vertical settings. Guessing 100ms timebase here, right?)

You're right. My mistake.
The blue trace represents the current (Iq), the other traces are the encoder outputs.
The vertical scale of the blue trace is visible, the horizontal scale has a timebase of 100mS.

- is that really Iq? It doesn't look like it should. I would have expected a constant 1A value for that 700ms (or a linear ramp)

Yes. I configured the DAC channel to represent the current Iq ...
For about 5/10us it draws a pulse, but then begins to oscillate.

- the encoder seems to misbehave beginning with horizontal division 9. There seems to be some high frequency 'overlay', if we can assume that the motor is slowly accelerating.

In fact, after 700mS I should not have any more pulses on the encoder ...
At this point I have no explanation for that. Tomorrow I will test more closely to see if I can find an explanation.

Iq voltage conversion should be 0V <--> -max measurable current, 3.3V <--> +max measurable current. STMCWB calculates max readable current of +-3.268A (power stage, current sensing). So +1A would be 1.65V + 1.65V*(1.0A / 3.268A) = 2.15V. It seems like the current controller is reaching that level for a short time, when looking closely at the beginning (~ div 1).

Oh of course! 

It looks to me that the current PI control loop is oscillating. I suggest working on the motor current before looking at encoder feedback. You can use/repeat the alignment procedure to investigate that.

Okay. I'll repeat the procedure and analyze the results.
The control stabilizes initially, but then oscillates so I'll try adjust the PI values.

looks okay. But the objective here is: does the encoder count correctly? If you paint a reference mark on the shaft, and turn it a random number of complete revolutions (fast or slow), and then carefully align to the painted reference mark again, then the shown voltage (or value, if you do it directly in STMCWB) for "measured electrical angle" *must* be identical all the time. Have you checked that? *And* you must see exactly *one* triangle sweep per mechanical revolution. It is not allowed to "lose" one single tick count now and then, because that will put everything out of sync over time.

From the first scope picture, I am concerned that the encoder output may be corrupted. (Magnetic interference? wrong field strength of permanent magnet?)

Okay. I understand.
I'll check this.
My problem is that I have to do "start motor" to be able to generate DAC outputs. But if I start to rotate manually the rotor, the controller (after some time) will start reacting because it should be at zero speed and the feedback tells it that it is running.
Tomorrow I will try to get around to this situation.


Thanks for all the help