Optymalne strojenie PID dla silnika z enkoderem na Pi Pico zjawiska oscylacji?

Sat Jan 31, 2026 5:50 pm   

On Sat, 31 Jan 2026 13:19:25 +0100, Mirek wrote:

No tak to działa.
Nie udaje się trafić tak, żeby szybko dociągał i bez oscylacji?

Jeśli widzisz, że "wolniutko dociąga do celu", to chyba trzeba go
przyśpieszyć.


Obsluga enkodera w Pythonie?
A jakies maksymalnej częstotliwości kroków się spodziewasz?


A co się dziwisz, że analiza tekstu "in_ (x, 32)" trwa?
Szczególnie, jak jeszcze w Pythonie oprogramowane? :-)


Jak pisałem - z D jest pewien kłopot.


Dokładnie - wszystko dopuszczalne, tylko w drugiej wersji masz chyba
jakiś błąd, bo za dużo Ki.
Jeśli to Ki ma odpowiadać temu z teorii, to musi być w odpowiednim
miejscu wliczane, ale nie ma takiego obowiązku - wystarczy przeliczać
wartość zadaną przez użytkownika na używaną wewnętrznie do obliczeń
Gdzieś tam jest kwestia wygody ogranicznia wartosći całki - czy ma to
być na wartosciach błędu, czy wyjsciowych, może kwestia dokładnosci
obliczen numerycznych - szczególnie, jak sie chce to robić na liczbach
całkowitych, uwzględniania kroku czasu, jeśli zmienny, itp.


Czy to nie sa liczby zmiennoprzecinkowe u Ciebie ?


A jaki masz zakres wartosci wyjsciowych?
PWM ... 0-64K, czy np 0-1023

Bo od tego może zależeć, jak to sensownie ograniczyć ... no i żeby się
jakaś wartość nie przekręciła na ostatnim sumowaniu.

J.

Sat Jan 31, 2026 6:39 pm   

W dniu 31.01.2026 o 16:50, J.F pisze:





Nie, to nie to. Wydaje mi się, że samo StateMachine.get() czyta z bufora
o ile jest napełniony, jak jest pusty to czeka. Natomiast czemu
StateMachine.exec("in_(x, 32)") nie napełnia go natychmiast to nie wiem.
Sytuację trochę poprawiło umieszczenie tego w pętli kilka instrukcji
wcześniej, ale na tym zaoszczędziłem niewiele. Obecny kod zmienia to
radykalnie: bufor sam się napełnia jak jest zmiana, jak jest napełniony
to czytam, jak nie to znaczy że nie było zmiany.



Tak, myślałem o:
Integral = poprzednie_Integral + błąd*Ki
i na końcu:
I = Ki * Integral




Nie, bo z obliczonego wcześniej float robię int-a.


PWM jest 16-bitowe czyli 64k

A przy okazji - gość od tych filmików ma tam błąd, bo kierunek silnika
uzależnia od znaku błędu, co zwykle zadziała ale nie zawsze.
Ja ustawiam w zależności od znaku wyniku całego PID.


Przychodzi mi do głowy jeszcze jedna metoda, mianowicie jeśli sterowanie
osiągnie maksimum to zerować wartość I. No bo tutaj nic nie ma do roboty
- silnik kręci się z maksymalną prędkością i nie ważne jak to długo
trwa, póki samo P daje maksimum to nie ma co zbierać błędu. Może głupie,
ale sprawdzę jak to się zachowa.



--
Mirek

Sat Jan 31, 2026 8:40 pm   

On Sat, 31 Jan 2026 17:39:50 +0100, Mirek wrote:

Tak prawdę mówiąc, to mało pokazuje.
Jak masz np enkoder 2000 impulsów na obrót i do 200 obr/s,
to spora częstotliwość wychodzi.

A jak np 180 imp/obr i maks 5 obr/s, to może i Python sobie poradzi.


Prawdopodobne. A jak tak długo czeka i wstrzymuje pętlę regulatora,
to cuda mogą być.
ale masz to rx_fifo().


Ja się tam jednak podejrzliwie patrzę na ten parametr.
Jego dopiero trzeba zdekodować, co może być trudne lub łatwiejsze.

Ale ale - dokumentacja podaje, że można podać int zawierający gotowy
kod instrukcji PIO.

https://github.com/micropython/micropython/blob/master/docs/library/rp2.StateMachine.rst?plain=1#id3


Nadal wydaje mi sie, że masz Ki podwójnie.

Werja 1
calka = calka+blad
I = Ki* calka

wersja 2
calka - calka+blad*Ki
I = calka

Pytanie, czy powinieneś tam uwzględniać krok czasu, czy nie trzeba, bo
stały.


Ale wartość całki sumujesz na float?

Ale to własnie to wewnętrzną sumę całki chcesz ograniczyc,
bo bedzie się długo utrzymywał błąd, wartość(suma) całki urośnie np do
miliona, Ty ograniczysz wyjsciową wartość I ... ale ta wewnętrzna
wartość całki bedzie potem dłuuugo wracała do sensownej wartości.


Ogólnie tak właśnie powinieś robić.

Pytanie, czy on tam aktywnie hamuje silnikiem, bo jak unika, to może
mu działa - albo sprawia takie wrażenie.
Bo nie pokazuje wykresu błędu :-)

No i przypadek dużego obciążenia zewnętrznego - powiedzmy,
że jakiś cięzar czy sprężyna chce kręcić silnikiem w prawo,
kontroler musi podawać prąd chcący kręcic w lewo,
i to w miarę niezależnie od błędu.


Też bym o takim czymś myślał, bo jak silnik się kręci szybko w jedną
stronę i nie nadąża, to nie ma co błędu całkować.

Ewentualnie ... to co Janusz pisał - nie skacz zadaną pozycją o dużą
wartość, tylko zadawaj mu stosowną trajektorię - stopniowy przyrost
pozycji, i jeszcze stopniowy wzrost i zmniejszenie prędkości.
Regulator będzie to naśladował, i błąd ma szanse być niewielki ....

J.

Sat Jan 31, 2026 9:50 pm   

W dniu 31.01.2026 o 19:40, J.F pisze:


Możliwe, że coś to przyspieszy, ale w tym momencie już bez znaczenia dla
mnie, bo nie używam tej metody.




A "I = Ki*(poprzednie_I + błąd*Ki)" - lepiej?

Przecież w poprzednie_I już jest Ki
a tak ma właśnie gościu na filmiku.




No, czyli moja pierwsza wersja na dwa sposoby.



No krok jest stały, ale jeśli chcielibyśmy stosować reguły Z-N to chyba
trzeba.


Ja chcę zrobić regulator uniwersalny - chcę żeby mi to działało tak jak
na tym pierwszym filmiku, który podlinkowałem. Widziałem jeszcze lepszy
filmik, ale nie mogę go znaleźć, gdzie gość trzymał w ręce taki
niewielki silnik z takim jakby patyczkiem jakby wskazówką. Gość wytrącał
go palcem a ten wracał do pozycji jakby był na gumce i o coś uderzał.
Potem zrobił kilka obrotów palcem i to samo - patyczek po prostu
pojawiał się natychmiast na pozycji.

Paradoksalnie najgorzej mi się to zachowuje jak powoli zmieniam nastawę
- tzn, w pętli dodaję mu do pozycji stałą wartość - powinien jechać ze
stałą prędkością a "kołysze" tą prędkością jak tylko trochę zwiększę Ki.
Jest taki moment, że wydaje się, że już szybciej dociąga do celu i jest
stabilny przy gwałtownych zmianach nastawy a przy powolnych zmianach
jednak się kołysze.

--
Mirek

Sun Feb 01, 2026 2:46 pm   

W dniu 31.01.2026 o 19:40, J.F pisze:

nie wyszło poza zakres a potem dopiero mnożyć przez współczynnik.
Funkcja cała pid-u tak wygląda

#include "pid.h"
#include "stdint.h"

/*! \brief Initialisation of PID controller parameters.
*
* Initialise the variables used by the PID algorithm.
*
* \param p_factor Proportional term.
* \param i_factor Integral term.
* \param d_factor Derivate term.
* \param pid Struct with PID status.
*/
void pid_Init(int16_t p_factor, int16_t i_factor, int16_t d_factor,
struct PID_DATA *pid)
// Set up PID controller parameters
{
// Start values for PID controller
pid->sumError = 0;
pid->lastProcessValue = 0;
// Tuning constants for PID loop
pid->P_Factor = p_factor;
pid->I_Factor = i_factor;
pid->D_Factor = d_factor;
// Limits to avoid overflow
pid->maxError = MAX_INT / (pid->P_Factor + 1);
pid->maxSumError = MAX_I_TERM / (pid->I_Factor + 1);
}


/*! \brief PID control algorithm.
*
* Calculates output from setpoint, process value and PID status.
*
* \param setPoint Desired value.
* \param processValue Measured value.
* \param pid_st PID status struct.
*/
int16_t pid_Controller(int16_t setPoint, int16_t processValue, struct
PID_DATA *pid_st)
{
int16_t error, p_term, d_term;
int32_t i_term, ret, temp;

error = setPoint -
processValue; //1

// Calculate Pterm and limit error overflow
if (error > pid_st->maxError){
p_term = MAX_INT;
}
else if (error < -pid_st->maxError){
p_term = -MAX_INT;
}
else{
p_term =
pid_st->P_Factor * error; //2
}

// Calculate Iterm and limit integral runaway
temp = pid_st->sumError + error; //3
if(temp > pid_st->maxSumError){
i_term = MAX_I_TERM;
pid_st->sumError = pid_st->maxSumError;
}
else if(temp < -pid_st->maxSumError){
i_term = -MAX_I_TERM;
pid_st->sumError = -pid_st->maxSumError;
}
else{
pid_st->sumError = temp; //4
i_term = pid_st->I_Factor * pid_st->sumError; //5
}

// Calculate Dterm
d_term = pid_st->D_Factor * (pid_st->lastProcessValue -
processValue);//6

pid_st->lastProcessValue = processValue; //7

ret = (p_term + i_term
+ d_term) / SCALING_FACTOR;//8
if(ret > MAX_INT){
ret = MAX_INT;
}
else if(ret < -MAX_INT){
ret = -MAX_INT;
}

return((int16_t)ret);
}

/*! \brief Resets the integrator.
*
* Calling this function will reset the integrator in the PID regulator.
*/
void pid_Reset_Integrator(pidData_t *pid_st)
{
pid_st->sumError = 0;
}

a definicja pid.h tak

#ifndef PID_H
#define PID_H

#include "stdint.h"

#define SCALING_FACTOR 128

/*! \brief PID Status
*
* Setpoints and data used by the PID control algorithm
*/
typedef struct PID_DATA{
//! Last process value, used to find derivative of process value.
int16_t lastProcessValue;
//! Summation of errors, used for integrate calculations
int32_t sumError;
//! The Proportional tuning constant, multiplied with SCALING_FACTOR
int16_t P_Factor;
//! The Integral tuning constant, multiplied with SCALING_FACTOR
int16_t I_Factor;
//! The Derivative tuning constant, multiplied with SCALING_FACTOR
int16_t D_Factor;
//! Maximum allowed error, avoid overflow
int16_t maxError;
//! Maximum allowed sumerror, avoid overflow
int32_t maxSumError;
} pidData_t;

/*! \brief Maximum values
*
* Needed to avoid sign/overflow problems
*/
// Maximum value of variables
#define MAX_INT INT16_MAX
#define MAX_LONG INT32_MAX
#define MAX_I_TERM (MAX_LONG / 2)

// Boolean values
#define FALSE 0
#define TRUE 1

void pid_Init(int16_t p_factor, int16_t i_factor, int16_t d_factor,
struct PID_DATA *pid);
int16_t pid_Controller(int16_t setPoint, int16_t processValue, struct
PID_DATA *pid_st);
void pid_Reset_Integrator(pidData_t *pid_st);

#endif


--
Janusz

Sun Feb 01, 2026 4:26 pm   

On Sun, 1 Feb 2026 13:46:07 +0100, Janusz wrote:

ograniczać zakres można i w wersji 2, pytanie tylko jak uwzględnic Ki
w granicach. A może nie trzeba, bo to problem użytkownika,
albo od strony wartości wyjsciowych to też jest dobre.


Tylko zauważ, że tu się boją, aby wynik obliczen nie wyskoczył poza
zakres INT.

**** wow - patrząc niżej, to strasznie wielki ten MAX_I_TERM
( (MAX_LONG / 2) ).


A tu, w członie D, jakby mniej się boją przekroczenia zakresu ...
ciekawe.


J.

Sun Feb 01, 2026 4:56 pm   

W dniu 1.02.2026 o 15:26, J.F pisze:


czyli 16bit i żeby sie nie "przekręciła"


wtedy za duże bufory kumulował.
Stąd wpierw normalizują wynik a potem mnożą przez współczynnik.


31 bitowy zauważ że wszystkie sumy są takie, ale potem długo się
zbiera jak za duży błąd skumuluje, ja zmniejszyłem do 16 bit jak robiłem
regulację prądu prostownika na pid-ie.


Bo tu się za bardzo nic nie kumuluje, to jest tylko całka ostatniego
kroku, więc nie ma
obaw o przekroczenie zakresu. A nikt rozsądny nie robi współczynnika na
tysiące czy więcej.

--
Janusz

Sun Feb 01, 2026 11:14 pm   

On Sun, 1 Feb 2026 15:56:24 +0100, Janusz wrote:

IMO - ograniczanie wartości całki jak najbardziej ma sens.
Inaczej to np każesz wykonac dużo obrotów, i zanim tam dojedzie, to
całka zakumuluje sporą wartość, a potem będzie długo przeszkadzać.
Tu Mirek ma rację - przerwać czy nawet zerować całkę przy osiągnięciu
maksymalnej prędkości, a moze nawet przy zbyt dużym błędzie,
czy choćby ograniczyć jej możliwą wartość do sensownych wartosci.


Może o to chodzi.
Ale ... lastProcessValue-processValue teoretycznie może przekroczyc
MAX_INT.
No dobra - w realu absolutnie nie powinna, bo to znaczy, że obiekt
przeskoczył w jednej skrajnej wartosci w drugą, w jeden cykl.
A to się nie powinno zdarzyć.
Choć jak piszesz o regulowaniu prądu .. może. Prąd ma małą bezwładnosć
:-)

J.

Mon Feb 02, 2026 12:31 pm   

On Sun, 1 Feb 2026 22:14:13 +0100, J.F wrote:



Hm, tak sobie zacząłem sprawę analizować, i wychodzi mi, że
przesterowanie jest niemal nie do uniknięcia.
Mirku - jak to u Ciebie było - "powoli dochodził do zadanej pozycji",
ale od pierwotnej strony, czy powoli wracał po przekroczeniu?

J.

Mon Feb 02, 2026 9:58 pm   

W dniu 2.02.2026 o 11:31, J.F pisze:


Zwykle jest lekki przerzut, czasem się zdarza że prawie trafi albo jest
tak mały że go nie zdążę zauważyć. Nie mogę za CHRL uzyskać takiego
przetłumienia, żeby hamował dużo wcześniej i potem dochodził. Tzn, mogę
to zrobić z zerowym Ki i bardzo małym wzmocnieniem, tak że dochodzi
łagodnie ale nie osiąga celu, błąd jest na końcu ogromny.

Co do integral, zrobiłem tak jak tu gość tłumaczy:
https://youtu.be/NVLXCwc8HzM?t=492
Czyli przestaje dodawać błąd jak wynik jest nasycony i znak błędu i
wyniku jest zgodny. Generalnie po strojeniu działa to nieźle, w miarę
szybko kasuje błąd do zera, ale czasem występują denerwujące szarpnięcia
- bardziej je słychać niż widać po silniku. Wygląda na to, że
odpowiedzialny za nie jest człon D. Jak zmniejszę Kd, szarpnięcia
zanikają, ale zaczynają się oscylacje.
Najciekawsze jest to, że jeśli robię jazdę np. od 0 do 50000, to jeśli
zwiększam w tempie 1 na 100uS - jedzie gładko. 2- gładko... aż tak do 7-
zaczynają się szarpania, przy 10 jest koszmar, a tak od 15 znowu
szarpania zaczynają zanikać. Coś mam jeszcze nie tak.
Próbowałem też filtr na samo D - efekt jest podobny, albo nie ma wpływu
albo wprowadza niestabilność.


--
Mirek

Tue Feb 03, 2026 1:14 am   

On Mon, 2 Feb 2026 20:58:18 +0100, Mirek wrote:

No własnie tak sobie uzmysłowiłem.
Załóżmy, że silnik ma pozycję 0 - zadaną i rzeczywistą.
I zmieniamy nagle nastawę na 100.

cykl 1:
eror E=100 pochodna R=0 całka C=0

celowo abstrahuję od konkretnych nastaw Kx - ale wyjscie powinno się
pojawic jakies dodatnie, i ruszyc silnik we własciwą stronę.

Cykl 2:
powiedzmy, że pozycja S wynosi 5.
A więc E=95, R=-5 C=95
pochodną dałem ujemną, bo ona ma działać w przeciwną stronę na
wyjsciu - im szybciej się silnik porusza, tym słabiej jest
sterowany.
Całka ... do dyskusji czy to ma być dodane 95 z biezącego błędu, czy
100 z poprzedniego, to mało istotne.

Wyjscie znow zależy od konkretnych nastaw Kx, ale generalnie dalej
ma być dodatnie bo do zadanej pozycji daleko.
Człon P mniejszy niż poprzednio, człon D ujemny człon I większy niż
poprzednio

Cykl 3:
powiedzmy że pozycja wynosi 15
E=85 R=-10 C=180
opis - jak poprzednio. P mniejszy, I większy, D bardziej ujemny

Cykl 4: niech pozycja wynosi 25
E=75 R=-10 C=255
opis prawie jak wyżej

no i powiedzmy, że podobnych cykli będzie kilka i mamy np
Cykl 7: niech pozycja = 81
E=20 R=-10 C= ... mniejsza o to, ile dokładnie, powiedzmy 500 dla
równego rachunku
na wyjsciu - człon P już znacznie mniejszy,
człon I ... załóżmy, że Ki niezbyt duże, więc i człon I niezbyt
duży, człon D ujemny ... ale chyba nie na tyle, żeby zmienić wyjscie
na ujemne. Tym niemniej suma mniejsza niz poprzednio i silnik zwalnia
.... haha - zwalnia, jak są straty energii, bo jak ciągle dostarczamy
energię, to nie zwalnia, tylko się słabiej rozpędza.
Ale niech zwalnia

Cykl 8: niech pozycja = 88
E=12 R=-7 C=512
na wyjsciu P mniej niż poprzednio, D - mniej ujemne niż poprzenio,
I - ciut większe.
Razem ... niech będzie, że nadal zwalnia, Kd przydało by się duże

Cykl 9: niech pozycja = 93
E=7 R=-5 C=519
opis niech będzie jak wyżej - no bo chcielibyśmy, aby zwalniał,
aczkolwiek to od nastaw K zalezy.


Cykl 10: niech pozycja =96
E=4, R=-3 C=523
no i i po tym przydługim wstępie wyłania sie clou imprezy:
Człon P będzie dochodził do zera, bo błąd się zmniejsza.
Człon D będzie dochodził do zera (minus) bo prędkośc spada.
Ale człon I bedzie dodatni, bo całka całkiem spora i dodatnia.

i dopiero trzeba przesterowania, aby całka zaczęła spadać.

czyli przesterowanie jest w zasadzie nie do unikniecia.

Jedyna potencjalna możliwośc, to tak małe Ki,
żeby ta spora całka dawała na tyle małe wyjscie, że silnik się
jednak nie ruszy, z powodu tarcia. Ale chyba nie o to chodzi.

A Kd jak widac - musi być na tyle duże, żeby silnik zaczął zwalniać
odpowiednio wczesnie przed końcem.


pozostają jeszcze dwie alternatywy:
a) wyłączać całkowanie, gdy prędkość ruchu jest większa niż pewne
minimum - niech dopiero na koncu zajmie się wyzerowaniem błędu.

b) jak Janusz pisze - nie zmieniac skokowo zadanej pozycji,
tylko płynie. Z uwzględnieniem maksymalnej prędkosci napedu, i
możliwych przyspieszeń.
Wtedy regulator będzie miał możliwośc osiągać zadaną pozycję,
i całka wprowadzi tylko drobne poprawki.

I to b) wydaje mi się prawidłowym rozwiązaniem.


I jeszcze jedna sprawa - czy masz tylko jeden silnik/jedną oś ruchu?

Bo weźmy np frezarkę czy ploter XY, chcemy np od pozycji (100, 100)
przejsc do pozycji (200, 300), czyli o wektor (100, 200),
i tu nam nie wystarczy, że osiągniemy zadaną pozycję - często chodzi o
to, żeby poruszało się to po linii prostej, i os Y ruszała się dwa
razy szybciej niż X (przy tych wartościach).

J.

Wed Feb 04, 2026 9:38 pm   

W dniu 3.02.2026 o 00:14, J.F pisze:



Na razie nie odniosę się do tego, bo walczyłem z innym problemem.
Mianowicie nurtowało mnie, że przy wolnych jazdach, kiedy dodaję do
zadanej pozycji np. 5 kroków na cykl obliczania PID, słychać jakby
regularne stukanie - silnik się kręci w miarę równo, ale coś stuka.
Po całej serii testów, wychodzi na to, że winny jest tu odczyt z
enkodera i np. mamy w kolejnych odczytach przyrost:
5,5,4,6,4,5,5,5,4,5,6,4,5,6,5,5,56,4,5,6,5,5...
dziwne jest to 56 prawda?
Tak samo jak dodaję 7 kroków mamy:
7,7,6,6,8,7,6,7,6,7,6,87,7,6,8,6,7,7,7,7,6,7,7...
Co jest do cholery grane?
Pozycja enkodera to 32-bitowy signed int. Nie sądzę, żeby przy błędzie
konwersji albo jakichś błędach bitów można było uzyskać taki efekt.
Ta wartość wygląda na skumulowany zapis z dwóch odczytów - jakby ktoś
nie zauważył.
Podobnie dzieje się w drugą stronę tylko znak się zmienia. Ta błędna
wartość wygląda na to, że występuje raz na ileś tam kroków - przy
jeździe 5 kroków na 1ms pyka tak mniej-więcej 2 razy na sekundę. przy
szybszej szybciej. Nie jest to wielokrotność obrotu enkodera. Co ciekawe
również nie udało mi się zauważyć błędu (rozjechania się pozycji 0)
enkodera. Pętla odczytująca też w miarę równo chodzi - testowałem ją
przy pomocy micros() i odczyty są w granicach 997-1003us i nie ma
jakichś anomalii przy tych zawyżonych odczytach.


--
Mirek

Wed Feb 04, 2026 11:01 pm   

On Wed, 4 Feb 2026 20:38:17 +0100, Mirek wrote:

Dziwne jest, że to się tak składa z cyfr, które w ciagu występują.


No własnie - moze to nie bląd enkodera, ani jakas kumulacja odczytów,
bo chyba dane są binarne, tylko np błąd raportowania - gdzieś Ci znika
separator, i zamiast 5, 6, jest 56.
Albo jakies zajechanie/nakładanie buforów w pamięci ...


J.

Wed Feb 04, 2026 11:24 pm   

W dniu 4.02.2026 o 22:01, J.F pisze:


To bym nie miał stukania. Stukanie brało się z tego, że działało Kd.
Później zacząłem szukać zacząłem wypluwać na terminal różne dane. Kiedy
wyplułem if DeltaError > 10: Print(DeltaError) wszystko stało się jasne
- zaczęło wypisywać w rytm stukania. Przy Kd=0 nie stuka, ale wypluwa
rytmicznie dalej - czyli jest to przyczyna a nie skutek.



No ciężko mi to sobie wyobrazić jak by to miało działać.
Jutro jak będę miał na to czas, to spróbuję wyłapać surowe odczyty a nie
przyrosty i sprawdzę dokładnie czy nie przekłamuje enkoder przy kręceniu
tylko w jedną stronę. Bo przy kręceniu tam i z powrotem błędy mogą się
niwelować.

--
Mirek

Thu Feb 05, 2026 9:38 am   

On Wed, 4 Feb 2026 22:24:20 +0100, Mirek wrote:

Ale przy takim błędzie, człon P też powinieni stukać.


Nie wiem, na ile dobrze masz zrobioną obslugę enkodera w PIO,
ale potrafię sobie wybrazić, że jak jest gdzieś na granicy, to może
jeden sygnał dużo drgań wytwarzać, a kiepski program do enkodera
(inkrementalnego?)sobie z tym nie radzi. Ale wtedy:
-błędy pozycji byłyby, a nie masz,
-błędy byłyby jakieś losowe, a nie tak 5, 6, 5, 56 ..

Jak Ty go sterujesz? Wysyłasz mu nową pozycję, on ma dojsc i stać,
a pod koniec generuje taki ciąg błędów?

Czy mu wysyłasz narastające pozycje, 5, 10, 15, 20, 25, ... i patrzysz
co się dzieje.

Czy może mu wysłasz polecenie zmiany: "+5" .... "+5" ...."-7" ?

Bo może problem jest gdzies tu od strony zadawania- wysyłasz
20 25 30 35 40 45
cos ginie, czy przekłamuje, RPI odbiera np
20 25 90 35 40

i bład 55 przez chwile jest.
Ale to raczaj znów nie pasuje, to tego co pisałes.


A to "Print(DeltaError)" to jak pokazuje? port COM symulowany na USB?
Może tu jest jakiś problem - nie nadąża wypluc, i gdzies z dwóch robi
się jeden komunikat ... ale chyba nie - bo małych błędów nie
raportujesz.

No i jeszcze jedno może to "drukowanie" czasem czeka na transmisję,
zatrzymuje pętlę regulatora, silnik się dalej kręci, i za chwilę
regulator wypluje duży błąd ... ale znow jakiś bardziej losowy
powinien być ...

J.