Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Multisterownik/ multikontroler kotłowni na Raspberry Pi B+

abwg 08 Jan 2015 14:41 41862 134
Optex
  • #31
    User removed account
    User removed account  
  • Optex
  • #32
    abwg
    Level 13  
    SZA wrote:
    Witam jestem bardzo zainteresowany tym projektem.

    Bardzo mi miło.

    SZA wrote:
    Czy naprawdę jest szansa na uzyskanie źróbeł projektu?

    Opracuję jakiś "install", dodam komentarze, umieszczę na githubie. Jak się domyślacie trochę czasu jest na to potrzebne a są to już nudne zajęcia ;)

    SZA wrote:
    Co to za karta przekaźnikowa? Godna polecenia?

    Tak, godna jak na 25 zł bo za tyle możesz ją kupić od chińczyków. Wejdź na www.aliexpress.com, wpisz "8 relay 5V". Można też w Polsce już bez problemu, trochę drożej ale z szybsza dostawą (i gwarancją).

    SZA wrote:
    Co jest podłączone obok karty przekaźnikowej?

    Moduł termopary robiący przy pomocy MAX6675 za przetwornik analogowo-cyfrowy. A to wszystko żeby czytać temperatury nawet ok 1000 st. C, wg. producenta układu do 1200 st. C.

    SZA wrote:
    Transmisja odbywa się przez Ethernet, a co odbywa się przez ukryte USB? ;

    Przez Ethernet lub przez wifi to bez znaczenia. To USB to połączenie z DATA portem zasilacza awaryjnego APC BACK UPS CS 500. Dzięki serwerowi apcupsd można obserwować stan naładowania baterii i czas od zaniku zasilania i odpowiednio wcześnie uruchomić proces wyłączania systemu. Nie pamiętam tylko jak jest z wracaniem zasilania ale to jeszcze sprawdzę.

    SZA wrote:
    Jak dla mnie co całości szczęścia brakuje obsługi nadmuchu i byłoby idealnie.

    Szkoda, że się pozbyłem bo pewnie bym się pokusił o napisanie dodatkowego modułu.

    SZA wrote:
    Całość bez dwóch zdań świetna!!!

    Bardzo dziękuję.
  • #33
    Hetii
    Level 16  
    Fajny projekt :)

    Jeżeli bym robił coś podobnego to zapewne użył bym jednego skryptu w pythonie jako kontrolera i serwera http zamiast php+apache.

    Z ciekawszych projektów polecam zapoznać się z:

    https://code.google.com/p/webiopi/
    https://twistedmatrix.com/
    http://flask.pocoo.org/
    https://www.djangoproject.com/

    Pozdrawiam.
  • #34
    abwg
    Level 13  
    Hetii wrote:
    Fajny projekt :)

    Dziękuję.

    Hetii wrote:
    użył bym jednego skryptu w pythonie jako kontrolera i serwera http zamiast php+apache.

    Możesz to rozwinąć? To jest napisane w Pythonie a apache to serwer http przecież. Może Ci chodziło, że użył byś innego serwera http niż apache.
  • #35
    jaca_76
    Level 12  
    Bardzo ciekawy projekt . Sam myślę o podobnym tylko do akwarium z wyświetlaczem 7" i małą siecią RS485 . Jak pozostali czekam na kod. No i gratuluje smykałki do programowania w kilka godzin ogarnąć Pythona by wystartować serwer.
  • Optex
  • #36
    abwg
    Level 13  
    jaca_76 wrote:
    No i gratuluje smykałki do programowania w kilka godzin ogarnąć Pythona by wystartować serwer.

    Z programowaniem jest jak z jazdą samochodem. Jak już wiesz jak się jeździ to do czego byś nie wsiadł ...
  • #37
    Hetii
    Level 16  
    abwg wrote:
    Możesz to rozwinąć? To jest napisane w Pythonie a apache to serwer http przecież. Może Ci chodziło, że użył byś innego serwera http niż apache.


    Oczywiście, że mogę. Każda ze wspomnianych bibliotek pythona umożliwia serwowanie treści za pomocą protokołu http:

    Np taki oto kod za pomocą twisteda będzie w pełni obsługiwał żądanie GET protokołu http:
    Code: python
    Log in, to see the code


    Można jeszcze prościej za pomocą czystego pythona:
    Code: python
    Log in, to see the code


    Także nie potrzebujesz żadnych dodatkowych serwerów, wszystkimi żądaniami może zajmować się python. Dodatkowo możesz wyeksponować API np RESTful-a i sterować za pomocą innych urządzeń jak tablet/telefon.

    P.S.
    I tak jeszcze sobie myślę że mysql do tego rodzaju zadania to trochę za dużo.
    Zwykły plik bazy sqlite3 w pełni by sprostał twoim oczekiwaniom.
  • #38
    abwg
    Level 13  
    Hetii wrote:
    I tak jeszcze sobie myślę że mysql do tego rodzaju zadania to trochę za dużo. Zwykły plik bazy sqlite3 w pełni by sprostał twoim oczekiwaniom.

    Już kiedyś pisałem oprogramowanie pod sqlite i niestety przy dużych bazach musiałem przechodzić na coś "większego". Sqlite nie dawał rady (był za wolny). Od tamtego czasu pewnie sporo się zmieniło ale wybór mysql'a nic mnie nie kosztuje więc po co.
  • #39
    abwg
    Level 13  
    @Hetii , poczytałem troszkę i widzę, że troszkę się zmieniło od czasów SQlite 1 :) przede wszystkim "SQLite is the only one known to this author that allows multiple applications to access the same database at the same time". Pomyślę i może spróbuję aczkolwiek dużo musiałbym zmieniać od strony frontendu.

    Dodano po 5 [minuty]:

    Ale tylko w zastosowaniu kiedy tylko jeden pisze a reszta czyta.
  • #40
    gbd.reg
    Level 21  
    Polecam zmienić apache na nginxa albo lighttpd. Apache jest dość sporym serwerem i posiada wbudowanych wiele funkcji, których z pewnością nigdy w takim projekcie nie wykorzystasz. nginx i lighttpd zużywają zdecydowanie mniej zasobów, a oferują funkcjonalność z pewnością wystarczającą do takich projektów (a nawet i do pełnowymiarowych witryn). Za Apachem stoi właściwie tylko i wyłącznie łatwiejsze wdrożenie, bo domyślna jego instalacja i instalacja PHP nie wymagają zmian w konfiguracji, działają od kopa ;)
  • #41
    abwg
    Level 13  
    gbd.reg wrote:
    Polecam zmienić apache na nginxa albo lighttpd

    Zostawmy już wybory serwerów czy to http czy sql'a. Znakomicie zdaję sobie sprawę z tego, że można wybrać coś lżejszego jednak ja starałem się wybrać rozwiązanie jak najbardziej uniwersalne a takim na pewno jest apache+php+mysql. Nie jest dla mnie żadnym problemem skonfigurować ten czy inny serwer tylko, gdy load nie przekracza 0.15 nie widzę takiej potrzeby a już na pewno szkoda mi na to czasu.
  • #42
    JedenZero
    Level 9  
    Tak czytam o tych przekaźnikach, które przestają się włączać. Może dać termometr za pompą i porównywać temperaturę po włączeniu pompy z ostatnim odczytem. Przy braku różnicy (+/- mała delta) to od razu alarmować i nie czekać na górny limit temperatury.

    Dla wszystkich, którzy pytają o źródła - naprawdę zobaczcie sobie webiopi - tam jest najczarniejsza robota zrobiona (webserwer, obsługa czujników i przekaźników, prosty UI na www). Dla nas zostaje tylko konfiguracja, zrobienie logiki i fajniejszego interfejsu użytkownika.
  • #43
    Hetii
    Level 16  
    Jeżeli chodzi o problem przekaźnikowy to w starym numerze Elektroniki Dla Wszystkich był opisany "wieczny przekaźnik".

    Idea polegała na równoległym podłączeniu przekaźnika z triakiem/tyrystorem dzięki czemu nie było efektu wypalania się styków.
  • #44
    tplewa
    Level 39  
    [b]@Hetti[\b]

    Jak sie tak bawic to robic juz na polprzewodnikach lub zastosowac gotowe przekazniki polprzewodnikowe..
  • #45
    abwg
    Level 13  
    Za 2, 3 tygodnie będę miał kolejny moduł 8p i zrobię test. Podłącze jakieś obciążenie np. żarówkę 100W (więcej niż pompa co) i zobaczę ile wytrzymują te przekaźniki. Może rozmowa o ich awaryjności nie jest potrzebna. Zamówię też przekaźniki RELPOL i porównam. Jestem ciekawy wyniku takiego eksperymentu.
  • #46
    tplewa
    Level 39  
    Powiem tak u mnie nie do nich byly na styki podlaczone LED-y (po sztuce na przekaznik), bo jak mowie to bylo w celach testowych jednego ukladu... aby tylko byla wizualizacja... Ale jak mowie nie ma co panikowac, jak dziala to ok... jak padnie to sie wymieni. Moze ja mialem jakies wadliwe i tyle, czasami tak bywa przy sciaganiu z Chin od roznych osob...
  • #47
    abwg
    Level 13  
    Wracając do tematu awaryjności przekaźników. Mam rozwiązanie. W programie umożliwiłem uruchamianie dowolnej ilości wyjść w przypadku zajścia zdarzenia np. osiągnięcia temp. żeby uruchomić pompę. Ustawia się to zmienną gpio np. gpio = 22 co oznacza wyjście GPIO nr 22. Jednak umożliwiłem też uruchamianie kilku niezależnych urządzeń podając po przecinku kolejne wyjścia np. gpio = 21, 18, 24. Więc krytyczne urządzenia np. pompę co można podpiąć pod dwa wyjścia równolegle np. gpio = 21, 18, wtedy jak jeden przekaźnik nie zadziała to drugi będzie w pogotowiu.
  • #48
    maras77
    Level 21  
    W układzie sterującym kotłownią powinien być dodatkowy, zewnętrzny układ watchdoga.

    Jak się program zawiesi lub będzie przekroczona jakaś temperatura powinien wygasić kocioł i sprowadzić układ do stanu bezpiecznego.
  • #49
    abwg
    Level 13  
    @maras77, nie będę podawał konkretnych modeli dla porównania ale powiedz mi, który sprzedawany na rynku "sterownik" np. pomp ma dodatkowy zewnętrzny(!) układ watchdoga. Oczywiście wiemy, że coś takiego by się przydało ale gdzieś musi być granica zdrowego rozsądku.

    Piec piecem ale jak zawieźć zimą dziecko do szkoły samochodem bez zewnętrznego watchdoga układu hamulcowego? ;)
  • #50
    maras77
    Level 21  
    abwg wrote:
    @maras77, nie będę podawał konkretnych modeli dla porównania ale powiedz mi, który sprzedawany na rynku "sterownik" np. pomp ma dodatkowy zewnętrzny(!) układ watchdoga. Oczywiście wiemy, że coś takiego by się przydało ale gdzieś musi być granica zdrowego rozsądku.

    Piec piecem ale jak zawieźć zimą dziecko do szkoły samochodem bez zewnętrznego watchdoga układu hamulcowego? ;)


    Układy ABS mają watchdoga poza mikrokontrolerem.
    Co do sterowników kotłowni na rynku - nie wiem.
    Ale na pewno mój kociołek ma nie tylko watchdoga ale i reseter - raz na 24 h robi pełen sprzętowy restart z wyłączeniem zasilania włacznie.

    W tym zastosowaniu być może wystarczy watchdog w mikrokontrolerze - aczkolwiek decyzję trzeba podjąć samemu zależnie najgorszych możliwych skutków awarii sterowania. Jak jest w kotłowni tylko kocioł gazowy z własnym sterowaniem, to najwyżej nie będzie grzania lub przegrzeje się podłogówka.

    Ale jeśli jest układ z kotłem np węglowym, sterowane zawory, pompy obiegowe to awaria sterownika może się zakończyć np. wybuchem kotła.


    Dobrze jest też całą kotłownię zaprojektować tak, aby sama fizyka uniemożliwiała poważną awarię.
  • #51
    abwg
    Level 13  
    maras77 wrote:
    Układy ABS mają watchdoga poza mikrokontrolerem.

    ABS to dodatek. Myślałem o czymś równie krytycznym dla modelu jak pompa CO czyli hamulcach ;)

    maras77 wrote:
    Ale na pewno mój kociołek ma nie tylko watchdoga ale i reseter - raz na 24 h robi pełen sprzętowy restart z wyłączeniem zasilania włacznie.

    OK, mój poprzedni sterownik też żeby działał musiał mieć takie rozwiązanie lub ręczne. Obecny działa prawidłowo.

    maras77 wrote:
    Dobrze jest też całą kotłownię zaprojektować tak, aby sama fizyka uniemożliwiała poważną awarię.

    U mnie tak jest - może dlatego się aż tak na razie tym nie przejmuję.

    Myślę nad czymś w rodzaju raportowania z każdego wątku obsługującego dany moduł do wątku (głównego) odpowiedzialnego za kontrolę raportowania. Jeżeli brak raportu to restart wątku. Dodatkowo zewnętrzny program, który będzie czekał na sygnał z głównego wątku i jak nie ma sygnału to restart pi lub samego serwera.
    Ale to wprowadzę troszkę później na razie mam pomysł na wprowadzenie trybu lato/zima i obsługi wszystkiego co z tym związane.
  • #52
    tplewa
    Level 39  
    IMHO mozna dac standardowy wathdog... tutaj powiedzmy ze najbardziej zawodna jest czesc sterujaca - wiec w przypadku np. niekontrolowanego wzrostu temperatury lub naglej jej zmiany (uszkodzenie czujnika, odlaczenie) itp. wprowadzic jakies akcje. Jakie nie wiem - bo nie mam pojecia o sterowaniu piecem ;)

    Natomiast sama kontrole zawieszenia sie skryptow itp. to juz mozna na wiele sposobow realizowac...
  • #53
    abwg
    Level 13  
    tplewa wrote:
    najbardziej zawodna jest czesc sterujaca

    Wracamy do tematu przekaźników? Zobacz post #47.
  • #54
    jack63
    Level 43  
    maras77 wrote:
    Ale na pewno mój kociołek ma nie tylko watchdoga ale i reseter - raz na 24 h robi pełen sprzętowy restart z wyłączeniem zasilania włacznie.

    Mógłbyś napisać co to za kocioł i jak "doszedłeś" do takich wniosków?
    @abwg Jesteś super programistą, co się chwali. Jednak jak widać jesteś marnym automatykiem i do tego niepoprawnym optymistą bez wyobraźni.
    Koledzy zwracają Ci uwagę na zagrożenia a Ty je zbywasz argumentami typu :
    abwg wrote:
    takiego by się przydało ale gdzieś musi być granica zdrowego rozsądku.
    lub
    abwg wrote:
    jak zawieźć zimą dziecko do szkoły samochodem bez zewnętrznego watchdoga układu hamulcowego?

    Jak Ci udowodnił kolega @maras77 ABS ma zewnętrznego watchdog'a a większość procesorków stosowanych w sterownikach ma wewnętrznego. Trzeba go tylko ....użyć!
    Do tego małe procesorki mają mają małą pamięć programu. Program ma stosunkowo mało linii kodu i jest duża możliwość wychwycenia błędów.
    Przy Raspberry już tak cacy nie jest. System operacyjny (pytałem o niego - nie odpowiedziałeś!) to tysiące linii kodu. Kompilatory, interpretatory, biblioteki, skrypty i całe mnóstwo gotowego oprogramowania z którego korzystasz nie wnikając w to ile ma błędów. A błędy muszą być. To prosta statystyka. Nawet jakby to co sam napisałeś było idealne, to nie masz wpływu na narzędzia, którymi się posługujesz.
    Dlatego niema co zbywać krakaczy jak ja czy @maras77 ale zastanowić się jak przeprojektować Twój ciekawy projekt, aby stał się bardziej bezpieczny.
    Była długa dyskusja o marnych przekaźnikach, ale to tylko czubek góry lodowej.
    Może zostać uszkodzony (np. zawilgocony) czujnik temp. Może zostac uszkodzona pompa, pomimo sprawnego przekaźnika. Może być cale mnóstwo innych przypadków. Oczywiście jedne są bardziej a inne mniej prawdopodobne, ale wybieramy tylko takie które stwarzają największe zagrożenie dla układu a przez to dla ludzi(!).
    Dlatego każdy program sterownia musi uwzględniać przynajmniej część prawdopodobnych zagrożeń i umieć na nie zareagować zapewniając max bezpieczeństwo.
    W większości sterowników jest zaimplementowana procedura kontroli stanu dołączonych do nich urządzeń pomiarowych lub wykonawczych. Tak procedura z reguły odbywa sie po włączeniu zasilania lub resecie. Dlatego też koledzy wspominali o watchdog'u.
  • #55
    tplewa
    Level 39  
    @abwg

    Nie tylko o to chodzi... nie wiem czy jest sens dublowac przekazniki... po prostu reakcja w programie na sytuacje awaryjne zalatwi wszelkie problemy nawet na pad przekaznika... do tego jakas informacja dla uzytkownika o stanie awaryjnym.

    Jak juz chcesz to robic mniej zawodnie to juz lepiej dac jakies polprzewodnikowe przekazniki... ale pamietaj ze one tez moga zostac uszkodzone np. jakies anomalia w sieci zasilajacej itp. popma tez moze pasc. Wiec zabezpieczenie w software zalatwi sporo problemow.
  • #56
    maras77
    Level 21  
    jack63 wrote:
    maras77 wrote:
    Ale na pewno mój kociołek ma nie tylko watchdoga ale i reseter - raz na 24 h robi pełen sprzętowy restart z wyłączeniem zasilania włacznie.

    Mógłbyś napisać co to za kocioł i jak "doszedłeś" do takich wniosków?


    Kociołek Ulrich Wandich Futura 24+
    Jest to opisane w instrukcji oraz kilka razy widziałem, jak kociołek w czasie pracy po prostu się na kilka sekund wyłącza, gaśnie wyświetlacz, wyłączają się dmuchawy , pompy, i za chwilę startuje ponownie.

    Jest to zabezpieczenie przed tym, że z jakiegoś powodu zablokuje się palnik (zabezpieczenie), np nie odpali przy 5 próbach (brak gazu, wiatr), albo chwilowo się przegrzeje. Pół biedy, gdy jesteś w domu - zresetujesz palnik z panelu sterowania, jak zrobi się zimno. Ale jak jesteś akurat na nartach na 2 tyg , to już masz problem, bo wymrozi chałupę.
    Więc jest reseter, który co 24 h po prostu wyłącza na chwilę zasilanie kotła i załącza z powrotem.
  • #57
    abwg
    Level 13  
    jack63 wrote:

    @abwg Jesteś super programistą, co się chwali. Jednak jak widać jesteś marnym automatykiem i do tego niepoprawnym optymistą bez wyobraźni.

    Ciekawy sposób prowadzenia rozmowy. Braku wyobraźni mi nie zarzucaj. Automatykiem nie jestem.

    jack63 wrote:
    Koledzy zwracają Ci uwagę na zagrożenia a Ty je zbywasz argumentami typu

    Zdaję sobie sprawę z zagrożeń, dlatego w kilku miejscach już pisałem, że przymierzam się do jakiegoś rozwiązania ale odkładam to na dalszy etap, ponieważ - nie ukrywam - jest to na razie dla mnie za mało ciekawe a w moim konkretnie przypadku zagrożenie jest żadne i dopóki nie umieszczę publicznie kodu nie mam na to parcia.

    jack63 wrote:
    System operacyjny (pytałem o niego - nie odpowiedziałeś!)

    Raspbian. Gdzieś przeoczyłem ale chyba nic strasznego się nie stało! :) Wybacz ale wolę prowadzić rozmowę trochę bardziej pół żartem pół serio niż w sposób jaki Ty wprowadzasz. Nie wiem po co.

    jack63 wrote:
    Dlatego niema co zbywać krakaczy jak ja czy @maras77 ale zastanowić się jak przeprojektować Twój ciekawy projekt, aby stał się bardziej bezpieczny.

    Jak już wcześniej pisałem - na pewno coś dorobię. Nie chcę i nie pozbywam się Was. Pomimo, że mogłoby się wydawać nie zgadzam się z Wami to na ten temat dużo myślałem i mam plany :)

    Dobrze a teraz może żeby zmienić temat i uspokoić kolegę :) podpowiedzcie mi, jakiego rozwiązania użyć:
    Mam termoparę w czopuchu i chciałbym ją odizolować elektrycznie od metalu ponieważ robi mi się tzw. "podwójne uziemienie" lub "pętla uziemienia" ze względu na podłączony data port od zasilacza awaryjnego i mam błędne odczyty z termopary. Myślałem nad jakąś ceramiczną redukcją, którą mógłbym wkręcić pomiędzy czopuch a termoparę ale nie znajduję jakiegoś spopularyzowanego rozwiązania.
  • #58
    maras77
    Level 21  
    Zewnętrzny watchdog to dość prosty układ - są specjalizowane układy, ale można też użyć po prostu timera, który resetuje się jednym wyjść procesora. Jak się nie zresetuje, to robi np odcięcie zasilania na chwilę.
  • #59
    jack63
    Level 43  
    abwg wrote:
    Braku wyobraźni mi nie zarzucaj.

    A jak mam to rozumieć? :
    abwg wrote:
    jest to na razie dla mnie za mało ciekawe a w moim konkretnie przypadku zagrożenie jest żadne

    Wiem ze zabezpieczenia są mało ciekawe, bo ich nie widać, a przez to są mało spektakularne i nie można się nimi pochwalić.
    Sam piszez że:
    abwg wrote:
    Do tej pory do sterowania pompami kotła na paliwo stałe (drewno/ węgiel)
    Wytłuszczenie moje.
    Już sam kocioł na paliwo stałe jest zagrożeniem. Obiekt trudno-sterowalny o bardzo dużej pojemności cieplnej rozpalonego (czasami bez woli palacza - patrz silny wiatr!) paliwa. Czyżbyś miał wężownicę schładzającą? A może też zawory termostatyczne na grzejnikach?
    Sorki, że się czepiam, choć wcale nie jestem zaniepokojony o Ciebie, ale Te posty czytają tez inni i mogą potraktować takie "odsuwanie w czasie prac nad zabezpieczeniami" jako zachętę do ich zupełnego olania.
    abwg wrote:
    Raspbian. Gdzieś przeoczyłem ale chyba nic strasznego się nie stało!

    Pewnie że się nie stało. :D przecież to Twój układ da nie mój.
    O ile się dobrze zorientowałem, nie jest to Real Time OS. Czy tak?
    Jeżeli tak, to jaką masz gwarancję, że oprogramowanie niezależne od Ciebie, np. jakaś część systemu nie zawłaszczy sobie całkowicie zasobów na np. aktualizację i .... oleje Twój proces regulacyjny w jakimś dla niego istotnym momencie??? Nic nie musi się wieszać.
    Czy brałeś to pod uwagę??? Tu znowu wracamy do watchdog'a i pewnej niezależności części systemu automatyki od układu nadrzędnego (Pi). Np. jakis termostat mechaniczny podający zasilanie na pompę lub zawór węzownicy schładzającej lub coś tam w zależności od sytuacji.
  • #60
    tplewa
    Level 39  
    @maras77

    Nie potrzeba zewnetrznego watchdog-a... juz pisalem ze uklad BCM2835 posiada taki i wystarczy go tylko uzyc. W przypadku zawieszenia sie systemu itp. uklad zostanie restartowany i system startuje na nowo...

    Zewnetrzny mozna stosowac do uC ktorych takowego nie posiadaja...