cancel
Showing results for 
Search instead for 
Did you mean: 

Can someone tell me what T-noise and T-rise are in the Current Sensing block of the Motor Control Workbench?

SCrum.1
Associate III

I am using the IHM17M1 power board which is not supported out of the box. I have it working quite well by configuring it as a custom board.

However I don't know how to set the t-rise and t-noise values. I can't find any reference to them in the documentation.

I also note the current sensing seems a little noisier that I think it should be, so wondered if these settings could have an effect.

Thanks.

18 REPLIES 18
SCrum.1
Associate III

Thanks. I have studied that section very closely yesterday. I have tried various settings for T-rise, T-noise, Min Dead time, HW Inserted Deadtime, and sampling time.

My current settings are:

Trise = Tnoise = 150nS.

Min dead time = 200nS

HW inserted deadtime = 300nS

Sampling time 3.0, giving a sampling time of 250ns.

But I have tried many other combinations.

What I have also seen through debugging, is that the function R3_1_SetADCSampPointSectX, choses one of 3 sampling strategies based on the values above and the current PWM edge times. Most of the time it is sampling in the middle of the PWM, and this is the one that works (the first strategy).

When the low duty cycle pwm becomes too narrow for this it switches to the second option, and sets the sample point to to be lowDuty - hTbefore, where hTbefore is 2 * sampling time + conversion time. This is the one that causes the big jump in current measurement. The noise is caused by rapidly switching between strategies 1 & 2.

I'm not sure where the conversion time is set, or quite where in the PWM cycle this second strategy is trying to set the sample point. Seems to be in the bit between the low & mid duty cycle pwm.

11235813
Associate II
SCrum.1
Associate III

I have done a lot of investigation in to this now and still don't have a solution. I note that the documentation for the MC SDK v4.3 gives a lot of info on the 3 shunt current sampling (in UM1052), but the same info is not available in the documentation 5.Y.4.

I noted also that the function R3_1_SetADCSampPointSectX determines the current sampling point within the PWM waveform. It then passes this sample point to the function R3_1_WriteTIMRegisters. This function however, does nothing with this sample point, so it has no effect. As such the code samples in the middle of the PWM under all circumstances.

Is this a bug in the code? Or is this the intended functionality that in 3 shunt topology, only sampling in the center point is supported? I find I have to throttle the modulation index quite heavily to allow sufficient space for the current sampling to fit in this mid point under all circumstances.

GMA
ST Employee

I don't catch your point about "It then passes this sample point to the function R3_1_WriteTIMRegisters. This function however, does nothing with this sample point".

Parameters are written on TIM HW registers and will be taken into account on next PWM cycle. Here for sampling point:

R3_1_WriteTIMRegisters( &pHandle->_Super, hCntSmp );

And

__weak uint16_t R3_1_WriteTIMRegisters(PWMC_Handle_t *pHdl, uint16_t hCCR4Reg)

...

 LL_TIM_OC_SetCompareCH4 ( TIMx, (uint32_t)hCCR4Reg );

May be that timing parameters do not fit on what you have on your boards, as I tried several ST boards configuration and I was not able to have such bad current values on non middle sampling point positions...

If you agree with the answer, please accept it by clicking on 'Accept as solution'.
Best regards.
GMA
SCrum.1
Associate III

In my generated code the line 'LL_TIM_OC_SetCompareCH4 ( TIMx, (uint32_t)hCCR4Reg );' was missing from __weak uint16_t R3_1_WriteTIMRegisters(PWMC_Handle_t *pHdl, uint16_t hCCR4Reg).

I suspect this might be because I started the configuration in MC Workbench using a 'custom board' for the power board.

I can re-create this issue by starting a new project in MC Workbench. Select the NUCLEO-F401RE control board, custom power board and the generic low voltage motor. If you generate the code without making any config changes (STm32CubeMX 6.4.0, ST32CubeIDE & STM32 FW V1.26.2) I think you get the function above with the line missing. Of course in my case I have carefully set up all the parameters and am using a motor profile from the Motor Profiler. However this problem is the same.

I also see the same problem with NUCLEO-F401RE & IHM16M1 - 3 shunt.

This is all with MC SDK 5.Y.4.

Thanks.

GMA
ST Employee

I agree with you, the line 'LL_TIM_OC_SetCompareCH4 ( TIMx, (uint32_t)hCCR4Reg );' is missing from __weak uint16_t R3_1_WriteTIMRegisters(PWMC_Handle_t *pHdl, uint16_t hCCR4Reg).

Unfortunately, it is not the case on all plateforms (e.g the ones I tested).

A ticket will be entered. Thank you for your investigation.

If you agree with the answer, please accept it by clicking on 'Accept as solution'.
Best regards.
GMA
THA.1
Associate II

Hi SCrum.1,

Could you share the result after fixing the above code defect(missing LL_TIM_OC_SetCompareCH4())?

After fixing it, the problem(current measurement) disappeared, or still some amount of noise appears compared to sampling at the middle of PWM period?

SCrum.1
Associate III

Hi,

I think there is always some difference in the current reading when switching between the different current sampling zones. If you examine the the current waveform with a scope you can check the timing of the t-rise and t-noise and the deadtime. But you can also see that the voltage level at the different sampling zones is different, so even when you have the software configured correctly such that it is not sampling some of the real electrical noise, the signal is different in the different zones. You have to remember that the current isn't constant through the PWM cycle. What we really want is the average current over the PWM cycle, but as we are only taking one sample, we try and sample at a point where it should be close to the average.

However note that the noise I had when configured correctly was about 20% of that when it was sampling some of the electrical noise. I think the resulting noise is also affected by the motor inductance. ie. lower inductance means the current rises and falls faster over the PWM cycle & therefore there is a greater difference between the different sampling positions. I am using very low inductance motors.

So if you want a nice clean current waveform, you can throttle the modulation index back so it only samples at the mid point, or if you want to get the most power out, then you have to accept some level of current sampling noise.

Some other points I noted were that

  1. The condition for setting the case1 position in SetADCSamplePointSecX makes the assumption that the duration of the switching and settling time (Deadtime + MAX (T-Rise, T-Noise)) is greater than the sampling time. Whilst this is true for most ST devices, this is not the case for STSPIN233. So I had to rewrite this logic.
  2. The amplifier gain on the NUCLEO-IHM17M1 is 1.53 which gives a current sampling range of approx 10 Amps. Given the motors I was using were drawing up to 0.5A this gives a low signal to noise ratio, so I tweaked the op amp gain up to 8. This also reduced the noise on the current waveform quite a bit. I'm not sure why ST have set this gain so low given the device can only handle 1.3A rms.
THA.1
Associate II

Thank you for your reply,

I agree with your above opinion.

ST(MCSDK, evaluation boards) looks like providing a reference-level one which mainly focuses on ST mcu & peripheral utilization(this is a good starting point), while leaving advanced or high-performance implementations to each user.