NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Dlaczego odczyty z termopary MAX6675 są niestabilne przy różnych warunkach?
Mirek
Guest
Guest
Mon Feb 27, 2023 9:06 pm
Czy każda termopara ma obudowę połączoną ze złączem?
Np. taka:
https://botland.com.pl/czujniki-temperatury-wysokiej-precyzji/12504-termopara-max6675-czujnik-temperatury-spi-5904422307868.html
Podłączam toto - odczyt skacze jak głupi +-1stopień, do tego jest
różnica kilku stopni jak w pobliżu jest włączony monitor (!?)
To samo jak się dotknie ręką tej rurki, nie mówiąc już o połączeniu jej
do masy czy z uziemieniem.
Omomierz wskazuje, że obudowa nie jest odseparowana od termopary, Biorę
inną, taką z miernika, ale też w rurce metalowej - to samo.
Czy tak ma być, i ten układ ma to tolerować? - no jak, przy 3.3V zasilania?
A może układ mam uszkodzony?
--
Mirek.
Marek
Guest
Guest
Mon Feb 27, 2023 10:55 pm
On Mon, 27 Feb 2023 20:06:37 +0100, Mirek <mirek@null.dev> wrote:
Quote:
https://botland.com.pl/czujniki-temperatury-wysokiej-precyzji/12504-termopara-max6675-czujnik-temperatury-spi-5904422307868.html
Robiłem czujniki termopar na max31860k i tam problem z
fluktuacją/skaczeniem odczytu bardzo ładnie kompensowało się
blokowaniem styków złącza kondensatorem 10nF oraz kolejnymi do + i -.
Taki układ jest w którymś przykładzie aplikacyjnym Maxima. I
faktycznie po zastosowaniu kondensatorów w moim przypadku odczyty
stały się precyzyjne i stabilne.
Złącze było izolowane od obudowy.
--
Marek
Mirek
Guest
Guest
Wed Mar 01, 2023 9:05 pm
On 27.02.2023 21:55, Marek wrote:
Quote:
On Mon, 27 Feb 2023 20:06:37 +0100, Mirek <mirek@null.dev> wrote:
https://botland.com.pl/czujniki-temperatury-wysokiej-precyzji/12504-termopara-max6675-czujnik-temperatury-spi-5904422307868.html
Robiłem czujniki termopar na max31860k i tam problem z
fluktuacją/skaczeniem odczytu bardzo ładnie kompensowało się blokowaniem
styków złącza kondensatorem 10nF oraz kolejnymi do + i -. Taki układ
jest w którymś przykładzie aplikacyjnym Maxima. I faktycznie po
zastosowaniu kondensatorów w moim przypadku odczyty stały się precyzyjne
i stabilne.
https://botland.com.pl/czujniki-temperatury-wysokiej-precyzji/12504-termopara-max6675-czujnik-temperatury-spi-5904422307868.html
Robiłem czujniki termopar na max31860k i tam problem z
fluktuacją/skaczeniem odczytu bardzo ładnie kompensowało się blokowaniem
styków złącza kondensatorem 10nF oraz kolejnymi do + i -. Taki układ
jest w którymś przykładzie aplikacyjnym Maxima. I faktycznie po
zastosowaniu kondensatorów w moim przypadku odczyty stały się precyzyjne
i stabilne.
Troszkę pomogło, ale nie wiele.
Quote:
Złącze było izolowane od obudowy.
Będę musiał to rozwalić i spróbować odizolować albo kupić inną.
Walczę z picoReflow - wychodzą mi absurdalne współczynniki.
Czy tam z tym ki nie jest coś skopane?
https://github.com/apollo-ng/picoReflow/blob/master/lib/oven.py
O ile na zwiększanie kp przy ki=0 i kd=0 reaguje przewidywalnie, tak jak
tutaj:
https://en.wikipedia.org/wiki/File:PID_Compensation_Animated.gif
o tyle przy zwiększaniu ki idzie całkiem w maliny.
Zwiększenie kd, przy ki=0 coś tam poprawia, ale jak się przesadzi to
szaleje jak głupie, bo są zakłócenia z tej termopary i jest na przemian.
--
Mirek.
Marek
Guest
Guest
Thu Mar 02, 2023 12:44 pm
On Wed, 1 Mar 2023 20:05:33 +0100, Mirek <mirek@null.dev> wrote:
Quote:
Walczę z picoReflow - wychodzą mi absurdalne współczynniki.
Czy tam z tym ki nie jest coś skopane?
Czy tam z tym ki nie jest coś skopane?
Moje doświadczenia są trochę z innego procesu (piec przemysłowy
100kW) gdzie proces zmian temperatury jest dość powolny ale są spore
zakłócenia wynikające z sterowania grupowego mocą. W moim przypadku
kd jest 0 i do otrzymania charakterystyki dojścia do nastawy bez
oscylacji wystarczyło dobranie kp/ki, proces jest przy próbkowaniu
temp. 1s. W 99% przy tych samych ustawieniach pid charakterystyka
dojścia do nastawy jest bez oscylacji a w pozostałym 1% się zdarzają
niewielkie oscylacje szybko stabilizujące się.
Oczywiście stabilność odczytu temp. ma tutaj kluczowe znaczenie by
nie powstawały przesterowania regulacji choć w teorii kd powinno
stabilizować właśnie takie sytuacje.
W moim przypadku nieprawidłowe odczyty są po prostu ignorowane przez
algorytm. Nieprawidłowe czyli takie, które różnią się znacznie od
poprzednich i odbiegają znacznie od możliwości realnych procesu. W
moim przypadku to jest 2t stali rozgrzewane do 720stp więc nie jest
możliwe aby kolejny odczyt (po kolejnej sekundzie) różnił się więcej
niż 2-5stp. Każdy odczyt poza tym jest uznawany za błędny i
ignorowany.
Musisz opanować stabilność odczytu, bez tego trudno będzie dokonać (w
miarę szybko) tuningu pid a co za tym idzie prawidłowej regulacji.
--
Marek
J.F
Guest
Guest
Thu Mar 02, 2023 2:40 pm
On Thu, 02 Mar 2023 11:44:37 +0100, Marek wrote:
Quote:
On Wed, 1 Mar 2023 20:05:33 +0100, Mirek <mirek@null.dev> wrote:
Walczę z picoReflow - wychodzą mi absurdalne współczynniki.
Czy tam z tym ki nie jest coś skopane?
Moje doświadczenia są trochę z innego procesu (piec przemysłowy
100kW) gdzie proces zmian temperatury jest dość powolny ale są spore
zakłócenia wynikające z sterowania grupowego mocą. W moim przypadku
kd jest 0 i do otrzymania charakterystyki dojścia do nastawy bez
oscylacji wystarczyło dobranie kp/ki, proces jest przy próbkowaniu
temp. 1s. W 99% przy tych samych ustawieniach pid charakterystyka
dojścia do nastawy jest bez oscylacji a w pozostałym 1% się zdarzają
niewielkie oscylacje szybko stabilizujące się.
Oczywiście stabilność odczytu temp. ma tutaj kluczowe znaczenie by
nie powstawały przesterowania regulacji choć w teorii kd powinno
stabilizować właśnie takie sytuacje.
W moim przypadku nieprawidłowe odczyty są po prostu ignorowane przez
algorytm. Nieprawidłowe czyli takie, które różnią się znacznie od
poprzednich i odbiegają znacznie od możliwości realnych procesu. W
moim przypadku to jest 2t stali rozgrzewane do 720stp więc nie jest
możliwe aby kolejny odczyt (po kolejnej sekundzie) różnił się więcej
niż 2-5stp. Każdy odczyt poza tym jest uznawany za błędny i
ignorowany.
Walczę z picoReflow - wychodzą mi absurdalne współczynniki.
Czy tam z tym ki nie jest coś skopane?
Moje doświadczenia są trochę z innego procesu (piec przemysłowy
100kW) gdzie proces zmian temperatury jest dość powolny ale są spore
zakłócenia wynikające z sterowania grupowego mocą. W moim przypadku
kd jest 0 i do otrzymania charakterystyki dojścia do nastawy bez
oscylacji wystarczyło dobranie kp/ki, proces jest przy próbkowaniu
temp. 1s. W 99% przy tych samych ustawieniach pid charakterystyka
dojścia do nastawy jest bez oscylacji a w pozostałym 1% się zdarzają
niewielkie oscylacje szybko stabilizujące się.
Oczywiście stabilność odczytu temp. ma tutaj kluczowe znaczenie by
nie powstawały przesterowania regulacji choć w teorii kd powinno
stabilizować właśnie takie sytuacje.
W moim przypadku nieprawidłowe odczyty są po prostu ignorowane przez
algorytm. Nieprawidłowe czyli takie, które różnią się znacznie od
poprzednich i odbiegają znacznie od możliwości realnych procesu. W
moim przypadku to jest 2t stali rozgrzewane do 720stp więc nie jest
możliwe aby kolejny odczyt (po kolejnej sekundzie) różnił się więcej
niż 2-5stp. Każdy odczyt poza tym jest uznawany za błędny i
ignorowany.
Ech, pamietam zadanie ze studiow - znaleźć wartosci błędne w tabelce
funkcji, czyli "za bardzo odstajace od trendu".
Łatwe to nie było, przy braku innych założen.
A tak mi chodzi po glowie - na ile taki regulator jest wrazliwy
na nieliniowosci sterowania/procesu?
Tzn chodzi mi o to, ze "wspolczynniki wzmocnienia" ("różniczkowe")
w pętli mogą być różne dla innych nastaw, i układ jest stabilny np
dla 500C, a w 300C oscyluje.
W piecu elektrycznym ze sterowaniem grupowym raczej nie ma tego
problemu, ale juz np przeplyw gazu przez zawór w zaleznosci od stopni
odkrecenia wcale nie musi byc liniowy ..
J.
J.F
Guest
Guest
Thu Mar 02, 2023 4:15 pm
On Mon, 27 Feb 2023 20:06:37 +0100, Mirek wrote:
Quote:
Czy każda termopara ma obudowę połączoną ze złączem?
Np. taka:
https://botland.com.pl/czujniki-temperatury-wysokiej-precyzji/12504-termopara-max6675-czujnik-temperatury-spi-5904422307868.html
Podłączam toto - odczyt skacze jak głupi +-1stopień, do tego jest
różnica kilku stopni jak w pobliżu jest włączony monitor (!?)
To samo jak się dotknie ręką tej rurki, nie mówiąc już o połączeniu jej
do masy czy z uziemieniem.
Omomierz wskazuje, że obudowa nie jest odseparowana od termopary, Biorę
inną, taką z miernika, ale też w rurce metalowej - to samo.
Czy tak ma być, i ten układ ma to tolerować? - no jak, przy 3.3V zasilania?
A może układ mam uszkodzony?
Np. taka:
https://botland.com.pl/czujniki-temperatury-wysokiej-precyzji/12504-termopara-max6675-czujnik-temperatury-spi-5904422307868.html
Podłączam toto - odczyt skacze jak głupi +-1stopień, do tego jest
różnica kilku stopni jak w pobliżu jest włączony monitor (!?)
To samo jak się dotknie ręką tej rurki, nie mówiąc już o połączeniu jej
do masy czy z uziemieniem.
Omomierz wskazuje, że obudowa nie jest odseparowana od termopary, Biorę
inną, taką z miernika, ale też w rurce metalowej - to samo.
Czy tak ma być, i ten układ ma to tolerować? - no jak, przy 3.3V zasilania?
A może układ mam uszkodzony?
Hm, jesli wszyskie sa połączone ... to widac to nie przeszkadza
Moze odwrotnie kable podłączyleś
A uziemiles T- ?
https://pl.rs-online.com/web/c/automatyka-i-sterowanie/czujniki/termopary/
Tu te tansze faktycznie są "grounded"
Ale wyszukac tych innych to sie chyba nie da ...
J.
Mirek
Guest
Guest
Thu Mar 02, 2023 9:31 pm
On 2.03.2023 15:15, J.F wrote:
Quote:
A uziemiles T- ?
No właśnie to uziemienie powodowało największe zakłócenia.
Przyjrzałem się tej płytce - nie dość, że zamienione są wyprowadzenia:
gruba masa jest połączona z nóżką 2 a cienka ścieżka do zacisku T- idzie
od nóżki 1. A działa dlatego, że przy zacisku T- jest połączenie do masy.
Rozdłubałem to i podłączyłem wg noty aplikacyjnej i... nie działa. Tzn.
scalak się komunikuje, ale wskazuje 0stopni.
Wychodzi na to, że ten scalak to chamska podróba, która nie ma w ogóle
wejścia różnicowego. No więc nie może to działać dobrze - po prostu nie
ma fizycznie takiej możliwości. Dziwi mnie tylko dlaczego nóżka T- nie
jest połączona z masą wewnątrz układu... ale skoro nawet płytka nie
udaje poprawnej aplikacji tego układu to nie ma się czemu dziwić.
Teraz co do programu - ki jest ewidentnie skopane.
liczy go tak:
self.iterm += (error * timeDelta * self.ki)
output = self.kp * error + self.iterm + self.kd * dErr
a powinno być wg wikipedii tak:
integral := integral + error × dt
output := Kp × proportional + Ki × integral + Kd × derivative
Czyli przez ki mnożymy wynik a nie tylko timeDelta.
Znów nie chce mi się wierzyć, że nikt tego wcześniej nie odkrył i tylko
ja mam z tym problem.
--
Mirek.
Marek
Guest
Guest
Fri Mar 03, 2023 12:04 am
On Thu, 2 Mar 2023 13:40:02 +0100, "J.F"
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
Tzn chodzi mi o to, ze "wspolczynniki wzmocnienia" ("różniczkowe")
w pętli mogą być różne dla innych nastaw, i układ jest stabilny np
dla 500C, a w 300C oscyluje.
w pętli mogą być różne dla innych nastaw, i układ jest stabilny np
dla 500C, a w 300C oscyluje.
Trudno mi powiedzieć, ponieważ moje doświadczenia w tym procedie są
tylko z jedną temperaturą nastawy (720C), inne temperatury nie są
używane. Raz chyba było coś koło 500 ale na tych samych nastawach i
nie kojarzę by wtedy wystąpiły oscylacje.
Natomiast jak wspomniałem zdarzają się (mimo niezmiennych nastaw
ki/kp oraz zawsze takiego samego wkładu) czasami 2 lub 3 oscylacje
zanim się ustabilizuje.
Przykład bez oscylacji:
http://31.182.124.137/bins/piec1.jpg
Czerwona pozioma to jest nastawa, niebieska na dole to chwilowa
wartość mocy 0-100%. 3 wykresy nad nastawą to temp. grzałek.
Z osylacjami:
http://31.182.124.137/bins/piec2.jpg
--
Marek
Mirek
Guest
Guest
Mon Mar 20, 2023 9:13 pm
On 2.03.2023 20:31, Mirek wrote:
Quote:
Teraz co do programu - ki jest ewidentnie skopane.
liczy go tak:
self.iterm += (error * timeDelta * self.ki)
output = self.kp * error + self.iterm + self.kd * dErr
a powinno być wg wikipedii tak:
integral := integral + error × dt
output := Kp × proportional + Ki × integral + Kd × derivative
liczy go tak:
self.iterm += (error * timeDelta * self.ki)
output = self.kp * error + self.iterm + self.kd * dErr
a powinno być wg wikipedii tak:
integral := integral + error × dt
output := Kp × proportional + Ki × integral + Kd × derivative
Bzdury pisałem - wychodzi przecież na to samo.
Ale picoReflow nadal nie ogarnięty,
--
Mirek.
Ceat
Guest
Guest
Wed Mar 29, 2023 12:20 am
W dniu 28.03.2023 o 21:46, Mirek pisze:
Quote:
...
skrót:
integral += error * timeDelta * ki
Nie działa prawidłowo. ponieważ w przypadku niezerowego integral, a
zerowego error - wynikowe integral zostaje stałe, niezerowe.
Jeszcze gorzej to wygląda w przypadku wersji z Wikipedii.
W stanie ustalonym _całość_ sygnału na wyjściu pochodzi z integratora!
skrót:
integral += error * timeDelta * ki
Nie działa prawidłowo. ponieważ w przypadku niezerowego integral, a
zerowego error - wynikowe integral zostaje stałe, niezerowe.
Jeszcze gorzej to wygląda w przypadku wersji z Wikipedii.
W stanie ustalonym _całość_ sygnału na wyjściu pochodzi z integratora!
Części proporcjonalna i różniczkująca są zerowe.
Poczytaj dobre wyjaśnienie zawiłości:
http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/
Mirek
Guest
Guest
Wed Mar 29, 2023 9:01 pm
On 29.03.2023 00:20, Ceat wrote:
Quote:
W stanie ustalonym _całość_ sygnału na wyjściu pochodzi z integratora!
Części proporcjonalna i różniczkująca są zerowe.
Masz rację, przekombinowałem.
Części proporcjonalna i różniczkująca są zerowe.
Masz rację, przekombinowałem.
Jeżeli błąd jest zero, a jest jakaś siła zaburzająca to przecież output
nie może być zero. To jest oczywiste w przypadku grzałki. ale ja
ostatnio bawiłem się silnikiem z enkoderem i zacząłem drążyć temat czemu
PWM nie jest zero i silnik brzęczy skoro jest dokładnie na zadanej pozycji.
Quote:
Poczytaj dobre wyjaśnienie zawiłości:
http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/
http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/
No ciekawe - muszę sprawdzić to z derivative kick, bo przy małych
ruchach tak właśnie mam: silnik rusza z kopa i czasem przelatuje za daleko.
--
Mirek.
Ceat
Guest
Guest
Thu Mar 30, 2023 1:04 am
W dniu 29.03.2023 o 21:01, Mirek pisze:
Quote:
ostatnio bawiłem się silnikiem z enkoderem i zacząłem drążyć temat czemu
PWM nie jest zero i silnik brzęczy skoro jest dokładnie na zadanej pozycji.
PWM nie jest zero i silnik brzęczy skoro jest dokładnie na zadanej pozycji.
W znanych mi rozwiązaniach napędów DC z enkoderem silnik jest zasilany
przebiegiem prostokątnym bipolarnym. Po osiągnięciu pozycji docelowej
przebieg ma wypełnienie 50%, wartość średnią 0 ale wartość skuteczną
równą amplitudzie przebiegu. Dzięki temu rozwiązaniu silnik "stoi jak
zamurowany" (i nie ma spadku momentu/mocy przy małych prędkościach, co
występuje przy sterowaniu PWM unipolarnym).
Mirek
Guest
Guest
Thu Mar 30, 2023 7:32 pm
On 30.03.2023 01:04, Ceat wrote:
Quote:
W znanych mi rozwiązaniach napędów DC z enkoderem silnik jest zasilany
przebiegiem prostokątnym bipolarnym. Po osiągnięciu pozycji docelowej
przebieg ma wypełnienie 50%, wartość średnią 0 ale wartość skuteczną
równą amplitudzie przebiegu. Dzięki temu rozwiązaniu silnik "stoi jak
zamurowany" (i nie ma spadku momentu/mocy przy małych prędkościach, co
występuje przy sterowaniu PWM unipolarnym).
przebiegiem prostokątnym bipolarnym. Po osiągnięciu pozycji docelowej
przebieg ma wypełnienie 50%, wartość średnią 0 ale wartość skuteczną
równą amplitudzie przebiegu. Dzięki temu rozwiązaniu silnik "stoi jak
zamurowany" (i nie ma spadku momentu/mocy przy małych prędkościach, co
występuje przy sterowaniu PWM unipolarnym).
O widzisz - tego nie wiedziałem. Będę musiał popróbować.
Widzę dwa problemy: nie będę mógł skorzystać ze sprzętowego PWM -
znaczna komplikacja programu, będę musiał też jakoś ograniczać prąd żeby
nie przegrzać silnika.
Może trzeba jednak nie 50% w prawo i 50% w lewo tylko np 10% w prawo i
10$ w lewo i w ten sposób ograniczyć prąd?
Albo wykorzystać 2 PWM-y i jednym sterować kierunkiem a drugim regulować
prąd?
Sterownik ma wejścia prawo, lewo i enable - do tej pory na enable daję
PWM, a lewo lub prawo wybieram kierunek. Jeśli prawo i lewo ma ten sam
stan, to zwiera silnik i PWM-em można regulować hamowanie.
--
Mirek.
J.F
Guest
Guest
Thu Mar 30, 2023 8:50 pm
On Thu, 2 Mar 2023 20:31:07 +0100, Mirek wrote:
Quote:
On 2.03.2023 15:15, J.F wrote:
A uziemiles T- ?
No właśnie to uziemienie powodowało największe zakłócenia.
Przyjrzałem się tej płytce - nie dość, że zamienione są wyprowadzenia:
gruba masa jest połączona z nóżką 2 a cienka ścieżka do zacisku T- idzie
od nóżki 1. A działa dlatego, że przy zacisku T- jest połączenie do masy.
Rozdłubałem to i podłączyłem wg noty aplikacyjnej i... nie działa. Tzn.
scalak się komunikuje, ale wskazuje 0stopni.
Wychodzi na to, że ten scalak to chamska podróba, która nie ma w ogóle
wejścia różnicowego.
A uziemiles T- ?
No właśnie to uziemienie powodowało największe zakłócenia.
Przyjrzałem się tej płytce - nie dość, że zamienione są wyprowadzenia:
gruba masa jest połączona z nóżką 2 a cienka ścieżka do zacisku T- idzie
od nóżki 1. A działa dlatego, że przy zacisku T- jest połączenie do masy.
Rozdłubałem to i podłączyłem wg noty aplikacyjnej i... nie działa. Tzn.
scalak się komunikuje, ale wskazuje 0stopni.
Wychodzi na to, że ten scalak to chamska podróba, która nie ma w ogóle
wejścia różnicowego.
Ale co zarzucasz - Maxim popełnił błąd projektowy, czy na płytce jest
jakas podróba i to daleka od oryginału?
Kośc wymaga podłączenia T- do masy.
Ale owszem - wydaje się, ze "gruba" (cyfrowa masa) powinna byc
podłaczona do nózki 1.
A jak rozdłubales, to połączyles potem 2 do masy?
Wczesniej cos tam działało, to i teraz powinno.
Quote:
No więc nie może to działać dobrze - po prostu nie
ma fizycznie takiej możliwości. Dziwi mnie tylko dlaczego nóżka T- nie
jest połączona z masą wewnątrz układu...
ma fizycznie takiej możliwości. Dziwi mnie tylko dlaczego nóżka T- nie
jest połączona z masą wewnątrz układu...
Akurat czeste rozwiaązanie, ze układ ma dwie masy - cyfrową i
analogową, i w srodku nie połączone ...
Quote:
ale skoro nawet płytka nie
udaje poprawnej aplikacji tego układu to nie ma się czemu dziwić.
Teraz co do programu - ki jest ewidentnie skopane.
liczy go tak:
self.iterm += (error * timeDelta * self.ki)
output = self.kp * error + self.iterm + self.kd * dErr
a powinno być wg wikipedii tak:
integral := integral + error × dt
output := Kp × proportional + Ki × integral + Kd × derivative
Czyli przez ki mnożymy wynik a nie tylko timeDelta.
Znów nie chce mi się wierzyć, że nikt tego wcześniej nie odkrył i tylko
ja mam z tym problem.
udaje poprawnej aplikacji tego układu to nie ma się czemu dziwić.
Teraz co do programu - ki jest ewidentnie skopane.
liczy go tak:
self.iterm += (error * timeDelta * self.ki)
output = self.kp * error + self.iterm + self.kd * dErr
a powinno być wg wikipedii tak:
integral := integral + error × dt
output := Kp × proportional + Ki × integral + Kd × derivative
Czyli przez ki mnożymy wynik a nie tylko timeDelta.
Znów nie chce mi się wierzyć, że nikt tego wcześniej nie odkrył i tylko
ja mam z tym problem.
Jesli nie zmieniasz Ki w trakcie pracy, to na jedno wychodzi.
w wersji wiki jest on uwzględniony w output, w wersji programu w
w iterm, roznica wychodzi dopiero gdy Ki zmieniasz -
w wiki natychmiast mnozona jest cala całka, czyli suma z historii,
w programie tylko nowe dane maja nowy wspolczynnik.
Zakladam, ze Ki zmieniasz rzadko, więc to bez wiekszego znaczenia
J.
J.F
Guest
Guest
Thu Mar 30, 2023 9:03 pm
On Tue, 28 Mar 2023 21:46:05 +0200, Mirek wrote:
Quote:
On 20.03.2023 20:13, Mirek wrote:
On 2.03.2023 20:31, Mirek wrote:
Teraz co do programu - ki jest ewidentnie skopane.
liczy go tak:
self.iterm += (error * timeDelta * self.ki)
output = self.kp * error + self.iterm + self.kd * dErr
a powinno być wg wikipedii tak:
integral := integral + error × dt
output := Kp × proportional + Ki × integral + Kd × derivative
Bzdury pisałem - wychodzi przecież na to samo.
Ale picoReflow nadal nie ogarnięty,
Ja rozumiem, że nikogo to nie interesuje, albo nikt nie wie, a u tych,
którzy wiedzą mam już cichego plonka (zresztą z wzajemnością
), ale
mimo to podzielę się swoimi "odkryciami":
Jedyna wersja, która jako-tako działa:
integral = (ki * integral) + (error * timeDelta * ki)
następnie ograniczamy integral, np. od -1 do 1 żeby nie szybowało w
kosmos:
integral = sorted(-1,integral,1)[1]
On 2.03.2023 20:31, Mirek wrote:
Teraz co do programu - ki jest ewidentnie skopane.
liczy go tak:
self.iterm += (error * timeDelta * self.ki)
output = self.kp * error + self.iterm + self.kd * dErr
a powinno być wg wikipedii tak:
integral := integral + error × dt
output := Kp × proportional + Ki × integral + Kd × derivative
Bzdury pisałem - wychodzi przecież na to samo.
Ale picoReflow nadal nie ogarnięty,
Ja rozumiem, że nikogo to nie interesuje, albo nikt nie wie, a u tych,
którzy wiedzą mam już cichego plonka (zresztą z wzajemnością
), ale
mimo to podzielę się swoimi "odkryciami":
Jedyna wersja, która jako-tako działa:
integral = (ki * integral) + (error * timeDelta * ki)
następnie ograniczamy integral, np. od -1 do 1 żeby nie szybowało w
kosmos:
integral = sorted(-1,integral,1)[1]
Nie ma lepszej metody ograniczenia?
Bo jak na to patrze, to włos mi sie jerzy.
No i tu:
-jest istotne czy ten integral zawiera Ki, czy nie,
-czy zakres -1...+1 jest własciwy?
Quote:
skrót:
integral += error * timeDelta * ki
Nie działa prawidłowo.
integral += error * timeDelta * ki
Nie działa prawidłowo.
Stop. Zrobiłes cos zupelnie innego.
integral += error * timeDelta * ki
liczy w miare prawidło całke.
Tzn jesli integral wynosi np 0.5, a error dojdzie do 0,
to integral sie już nie zmienia.
w twojej wersji
integral = (ki * integral) + (error * timeDelta * ki)
w takim przypadku integral (początkowe 0.5) bedzie w kazdym kroku
mnozone przez Ki.
Dla Ki>1 bedzie uciekal w strone nieskonczonosci.
Dla Ki<1 (i >0) bedzie asymptotycznie dochodzil do zera.
Quote:
ponieważ w przypadku niezerowego integral, a
zerowego error - wynikowe integral zostaje stałe, niezerowe.
zerowego error - wynikowe integral zostaje stałe, niezerowe.
Ale taka jest wlasnie idea PID - jak error dojdzie do zera, to wlasnie
czlon całkowy ma zapewnic potrzebne wysterowanie wyjscia.
Quote:
Jeszcze gorzej to wygląda w przypadku wersji z Wikipedii.
Ogolnie tak samo dobrze.
J.
elektroda NewsGroups Forum Index - Elektronika Polska - Dlaczego odczyty z termopary MAX6675 są niestabilne przy różnych warunkach?