Hello @claire OKU , hello @Community member
I´ll try to do my best xD Ok, 1st the promised screenshot, while debugging and searching...
As you can see, it stopped at breakpoint in line 170 of trajectory_ctrl.c. In lines 160 and 167, the struct members Omega and OmegaPrev are equally set to the value of the previous calculated (and never altered afterwards) omega variable and therefore should be equal. Also Theta and ThetaPrev in lines 159 and 168 ... Theroretically set to the given function parameter "Angle", which also isn´t altered inside the function. Of course the calculation of "omega" and "acceleration" in lines 150 and 155 rely on ThetaPrev and OmegaPrev ...
Problem here: As far, as i understand the reading of the pHandle struct at the moment, the program stopped, something definitely has happened to the members, while execution.
Correct me, if i´m wrong, but my 1st thoughts went to some other functions, which are able to alter these values, when they are called within an interrupt somewhere between setting them originally and the stop at the breakpoint. It´s very suspicious, that this doesn´t happen all the time. It needs some luck to "catch" that.
At the moment, i took the screenshot, all the original files have been on their original state (exept a) main.c, where i set the target angle and call MC_ProgramPositionCommandMotor1 for the movement and HAL_Delay(1) afterwards , b) the three altered files from the original bugreport) The routines in main are:
void setStepDirPosition()
{
uint16_t timCounterTemp = TIM2->CNT;
STP_PULSES= timCounterTemp;
if (STP_PULSES != STP_LAST_VALUE)
{
STP_PULSES &= 0xC000;
STP_LAST_VALUE &= 0xC000;
if (STP_PULSES == 0 && STP_LAST_VALUE == 0xC000){
STP_CNT_OF++;
}
if (STP_PULSES == 0xC000 && STP_LAST_VALUE == 0){
STP_CNT_OF--;
}
}
if (STP_CNT_OF < 0)
stepPosition = ((STP_CNT_OF + 1) * (0xFFFF +1)) - ((0xFFFF + 1) - timCounterTemp);
else
stepPosition = (STP_CNT_OF * (0xFFFF +1)) + timCounterTemp;
STP_LAST_VALUE = timCounterTemp;
}
//End of mainloop:
setStepDirPosition();
targetDeg = ((float)stepPosition /1024 *360);
targetDeg *= 12; // ~around 3200 rpm @ given external step frequency
fTargetPos = ((float)(targetDeg) * (float)(M_PI)) / 180.0f;
MC_ProgramPositionCommandMotor1(fTargetPos, 0);
HAL_Delay(1);And here the problems "began" xD :
As i understand from documentation, this should work. But anyway the motor did not really move like expected. Of course it was following the given position... Just the movement was very "rough" and even worse:
When it ran for a while (like in the video from the post above, just with faster rpm), at the end (motorposition 44800 on that touchscreen, i use to produce the stepsignals) it should stop for a moment (there´s also a deceleration ramp in the generated step signals) and then move on. At low rpm, this works nice (exept the "roughness"), but at high rpm, at this moment, MC_GetOccurredFaultsMotor1 didn´t return 0 anymore and the motor was switched off...
After playing with PID settings, i quickly found, that these settings didn´t work, like expected ... And of course, i took a look into pid_regulator.c also... Well... Let´s say, i have been "a little bit shocked 😉 ", when i saw, how you handle the Kd-Parameter:
wDeltaError = wProcessVarError - pHandle->wPrevProcessVarError;
wDifferential_Term = pHandle->hKdGain * wDeltaError;
wDifferential_Term >>= pHandle->hKdDivisorPOW2;
pHandle->wPrevProcessVarError = wProcessVarError;
wTemp_output = PI_Controller( pHandle, wProcessVarError ) + wDifferential_Term;Hmmmm..... Ok ....... Not really, what i would expect from a differential calculation 😉
Ok, digging around more and more (and very late at sunday night...) i gave up at some point...
My last try was:
Ok, TC_PositionRegulation is called indirectly from sysTick isr...
So without changing the target angle, it works.
If i try to move the motor by hand, it regulates back to the position, where it should be.
everything needed for that is: hTorqueRef_Pos = PID_Controller(pHandle->PIDPosRegulator, wError);, where wError is derived from pHandle->Theta and applying that...
So why not just updating pHandle->Theta without any further calculations or "workarounds" and let´s do the PID (more or less) it´s job....
What shall i say: This works, as intended, but anyway: The PID results still lead to the same problem: A BEMF spike, when it should decelerate and therefore a shutdown of the motor
I´m really sorry, that i´m not so experienced in that... And also english isn´t my 1st language (i´m german...). I have just seen: Something definitely goes wrong here xD For example: Just debug pid_controller.c, move around with the motor a bit and watch pHandle->wProcessVarError... Even with a given input error of near 0 it stays at very high values and just get´s balanced by wPrevProcessVarError 😉 So also try Kd at zero... You´ll experience some surprises 😉
Edit: Nearly forgotten: These "if (pHandle->ReceivedTh > ***)"-statements in lines 144, 154 and then 161... After two calls of the function, they are senseless... And also not necessary at all 😉 For "ReceivedTh", in the whole library, these are the only times, where it´s used. So i think the whole thing could be deleted...
