1 ACCEPTED SOLUTION
Accepted Solutions
Hello @Claire OKU ,
and again an other weekend xD ... Unfortunately (for a "noob", like me...) it´s very hard to "disassemble" the libraries and to find the reasons for some "strange" behaviours. Atm i don´t have my laptop with the toolchains here but i try to "recall", what i found (or not... xD) Of course, this evening i can check all this and also send some screenshots from debugging, photos and so on.
Ok, the story so far:
to get reliable (and unaffected) timings and behaviour of the f031, i simply connected step/dir signals to PA15 / PB6 via the provided TP´s. For debugging, i just use the step signals, directly evaluated in TIM2 (external trigger) counter. All the modbus / usart stuff, according timers / interrupts are just disabled. This gives me a "testing environment", where i can be (more or less) sure, if something is wrong, it comes from the mcsdk 😉 I attached a picture of the soldering and an "early" video, where partly the dir signal is still active to give you an impression, how it works.
I haven´t had much time this weekend, to further investigate, what´s going on below the surface, bat as far, as i remember, in trajectory and in pid controller is a lot of "weird" stuff. Example: TC_FollowCommand, that "ReceivedTH" member of the pHandle struct: In my eyes simply useless... In follow mode, the functions shall be called repeatedly (in main loop ?). So after two loops, it reches the max. possible value of 2 and therefore the "if (pHandle->ReceivedTH > ***)" statement is definitely useless after two loops. Even at 1st call, it´s not necessary and could save some valuable flash space (and maybe one or two cpu cycles xD).
In PID control, the "D"-part also is "a little bit strange". As i already said: Not enough time this weekend :( I did a quick and dirty try to get rid of that "estimate acceleration, speed and so on" stuff in TC_FollowCommand, because in TC_FollowExecution the saved values are (as it looks like so far) just reverse calculated and added then. I replaced all the content of TC_FollowCommand with a single pHandle->Theta = Angle and removed also the content of "TC_FollowExecution", as this is the one and only member, used by PID position regulation. So far, it seems, that these "TC_xxxx" functions partly do the job of a (correctly implemented) pid control, which has some problems itself or it is just "luck", that it works partly. Be honest: The "calculation" of the D component in PID is more than "strange" 😉
Maybe somebody should check all that stuff... Atm it looks like "quickly written" and never debugged or revised :(
Before i forget it: these calculations (needed or not) in TC_FollowCommand" rely on formerly stored values... Unfortunately it´s possible, these values get edited somewhere else (maybe from an isr ?) between two loops of that function. On my laptop, i have a screenshot. I´ll attach it here, when i´m back home this evening =)
