Programowalne instalacje elektryczne - wątek dla entuzjastów

[ravbc]

No to może faktycznie tylko gusty, ale:

1) serwery webowe istnieją od kilkunastu lat rozmaite. Technologia się w tym czasie szczególnie nie zmieniła, mimo że znacznie wzrosły jej możliwości. Nowe przeglądarki tak samo dobrze wyświetlą stare strony, jak ówczesne browsery. Oczywiście same skrypty które coś tam mają przygotowywać treści serwowane moga wymagać nieznacznych modyfikacji, ale jeśli tylko będą dobrze zaprojektowane, to nie będzie z tym wielkiego problemu (bo to tylko co najwyżej dostosowanie do nowszysch wersji i to tylko przy założeniu, że będziemy chcieli aktualizować wersję softu "pod spodem")

2) Napisanie całego klienta (wyświetlania, logiki i komunikacji) to znacznie więcej roboty, niż wygenerowanie HTMLa. Utrzymanie tego klienta w sprawności przy zmieniającym się "środowisku" to jeszcze więcej roboty (jeszcze 2 lata temu na topie był iOS z iPhonów, a teraz iPadów, obecnie jest to już raczej Android, ale przeniesienie aplikacji z jednego na drugiego jest praktycznie niemożliwe - trzeba ją napisać od nowa). O ile utrzymanie wersji oprogramowania na serwerze jest całkiem realne (wystarczy zrobić sobie obraz tego systemu i nawet jak padnie, to go dokładnie w tych samych wersjach odtwarzać), o tyle utrzymanie wersji oprogramowania na urządzeniach klienckich będzie bardzo trudne (jesli padnie taki tablet, może być bardzo trudno zdobyć podobny z taką samą wersją systemu).

3) Rezygnacja z warstwy pośredniej oznacza ograniczenie funkcjonalności niestety. Kontrolowanie stanu PLC to według mnie tylko fragment tego, co powinien dawać taki "Home UI". Pomijam już fakt, że zbudowanie instalacji, w której wszystkie dane są wprost dostępne dla PLC (nawet nie do wykorzystania operacyjnego, ale choćby dla samej prezentacji tych danych) będzie bardzo drogie, ze względu na koszt "nietypowych" peryferiów (jak np. stacja meteo - wersje z modbusem istnieją, ale kosztują krocie).

 

Krótko mówiąc: ja twardo idę w HTMLa i to HTMLa bez "udziwnień" w rodzaju Flasha, bo to tak na prawdę tylko kolejny problem...

[Depi]

Wiesz - tak naprawdę to kwestia definicji. Jakiś tam klocek pomiędzy urządzeniem klienckim, a elementem wykonawczym musi być. civic9 chyba ma, albo przynajmniej on pokazywał takie małe komputerki, co się wpina do gniazdka (wygląda to jak duża ładowarka). Wewnątrz jest linux i Twój webserwer. Jeśli tak - to czemu nie. Webserwery są już w NASach i innych urządzeniach.

 

Ergo - czy dedykowane urządzenie, czy jakiś mały komputerek z webserwerem to już kwestia wtórna. Najważniejsza jest tu integracja z urządzeniami mobilnymi, badź quasi-mobilnymi (wifi). Jak już kiedyś pisałem - masz panel 10 cali (sic!), full color, zdolny wyświetlić i zanimować prkatycznie wszystko, co dusza zapragnie (i zdoła zaprogramować ), za jakieś 500 PLN, czyli tyle, co jeden guzik KNX. Możesz to powiesić na ścianie, możesz zdjąć, wziąć ze sobą, objerzeć na tym podgląd z kamer, poświecić tym w nocy, zdzielić intuza przez łeb.

 

Hey - dla mnie kosmos. A Ty mi tu o webserwerach. Gdzie Twója marzycielska, innowacyjna dusza?

 

PS. A HTML5 to nie bajery?

[ravbc]

Depi: chyba się nie rozumiemy

Żeby ten panel mógł cokolwiek wyświetlić, to trzeba mu jakoś dane do wyświetlenia zapodać i jakoś oprogramowac ich wyświetlanie. Można to zrobić w całości samodzielnie tworząc aplikację, która się skomunikuje z instalacją, pobierze sobie dane, a potem je zaprezentuje. Ale ta plikacja stanie się cześcią tego panelu. Zmiana panelu na "nowszy model" niemal na pewno będzie wymagała zmiany aplikacji. A jak se do tego wymyślisz, żeby zamiast na śmiesznych 10 calach wrzucić podgląd z kamer na 40 cali w TV, to kicha - musisz robić wszystko od początku. Jeżeli zamiast tej aplikacji na jeden konkretny OS z tabletu, zrobisz "zwyczajny" serwis webowy, to będziesz mógł go oglądać na tym samym tablecie (bo wszystkie mają juz teraz całkiem sprawne przeglądarki webowe), telewizorze w saloonie, laptopie w gabinecie, telefonie w podróży, czy kafejce internetowej na wakacjach. I to _wszystko_ bez zmiany choćby jednej linijki kodu i babrania się w bebechach! A na czym to będzie serwowane to na prawdę nie gra roli, byle tenże serwer umiał się dogadać ze wszystkimi urządzeniami, z których dane ma pokazywać lub którymi ma sterować. Dlatego u mnie to będzie zwykły pecet. Jakby nawet zdechł, to padnie mi wizualizacja, ale to nie zabije całości. A odtworzenie, to wzięcie "z półki" innego peceta i rozpakowanie tam obrazu systemu, czyli robota na kwadrans.

A ten HTML5 to dlatego, że znacznie ułatwia osadzenie tych wodotrysków o których piszesz, ale jest znaczniej bardziej realny niż pisanie aplikacji na każdy "wyświetlacz" na którym zechce mi się cos pokazać. Choć fakt, ze trzeba na niego jeszcze chwilę poczekać, więc do tego czasu moja "aplikacja webowa" będzie wyglądać ciut gorzej w niektórych miejscach i/lub na niektórych urządzeniach - ale będzie działać!

[jka222]

Mój PLC posiada web serwer. Wizja moja podobna do tej kolegi ravbc, dowolne urządzenie z przeglądarką ...

Po uruchomieniu ...

Problem pierwszy mała ilość pamięci w sterowniku, na osadzania wodotrysków, zwykłe pstryczki ok., ale zdjęcie jako podkład, już ciężko, co mówić dalej.

Problem drugi, każde z urządzeń - inna rozdzielczość, moim zdaniem nie sposób pogodzić dużego monitora i telefonu.

Wnioski, albo będzie to prosta strona - "maszyna w fabryce", albo pomiędzy Serwer na pececie, który dorobi stronę wizualną.

[macek123]

Też mi się wydaje że wersja PLC + osobna wizualizacja to najlepsza opcja.

Zresztą, w systemach przemysłowych tak właśnie jest, plc robi swoje, scada swoją drogą. Wiadomo że to dom jednorodzinny ale i tak koncepcja mi się wydaje jak najbardziej słuszna, choćby ze względu na elastyczność np. kombinacje z różnymi sposobami wizualizowania.

Pozatym www wiadomo w przemysle to nie bardzo, ale w domu super rozwiązanie imho.

[civic9]

widzę, że znowu mnie z powiadamiania forum wypisało i minęło kilka stron wątku :/

no, ale trochę zajęty (innymi sprawami) i tak byłem. w wolnej chwili poczytam.

 

tymczasem... właśnie odpaliłem nawadnianie na moim fateku.

czy ktoś przerabiał jakieś czujniki wilgotności gleby, który można by zastosować? (tylko bez samodzielnej budowy z dwóch elektrod proszę

gardena ma taki jeden, dość rozsądnie wyceniony (poniżej 200 pln), ktoś może wie jakie to ma wyjście? jeżeli OC to czy wytrzymie 24VDC? (z układu wejściowego fateka). w gardenie oczywiście piszą i mówią, że to tylko z ich sterownikami współpracuje

[manieq82]

ja też tu gościnnie raz na kilka miesięcy

od 4 msc mieszkam i .. jak zaprogramowałem klawisze tak nic nie ruszam

drugi potomek też od czterech msc się wydziera (ona), posesja jeszcze nie ogrodzona a starszy ma fantazje ruszać w świat

więc prace ogrodowe trwają a plc ino światło zapala

ale radzi sobie z tym wspaniale

 

wrócę do was niebawem

pozdr

[civic9]

Całkiem fajne rozwiązanie (no przynajmniej w ogólnym zarysie, bo do szczegółów bym się przyczepił, ale to już zboczenie zawodowe). Ma niestety jedną oczywistą wadę: serwer linuksowy musi być stosunkowo blisko Fateka (zasięg RS-232 to normalnie tylko kilka, maks kilkanaście metrów). Niemniej może to rozwiązanie całkiem poważnie uprościć programowanie Fateka, więc warto zapamiętać.

Aha, teoretycznie powinno dać się to samo osiągnąć ze strownikami z portem 0 wyprowadzonym jako USB, ale ze względu na (nie)stabilność samego USB będzie ono raczej znacznie bardziej zawodne (no i odległość między serwerem a sterownikiem będzie jeszcze bardziej ograniczona niż przy RSie, choć paradoksalnie łatwiejsza do niewielkiego przedłużenia).

 

Działa także z portem 0 wyprowadzonym jako USB. Wpinam go do linuxa, i tam jest widziany jako rs232.

Reszta jak kolega wcześniej podał. Opisywałem to tutaj zresztą chyba ze dwa lata temu.

Ja stosuję jeszcze do tego ser2net. Bardziej mi przypadł do gustu od socata.

Modbus też chodzi w ten sposób - przynajmniej odmiana szeregowa, czyli trzeba złapać wyjście z aplikacji modbusowej do portu szeregowego i przekazać do serwera linuxowego. Pod windowsem robi to darmowy "HW Virtual Serial Port", a pod linuxem także socat.

[ravbc]

Fatekowy Port0 w wersji USB, to de facto wbudowana przejściówka na układzie ftdi wpięta w normalny port szeregowy (tj. konstrukcja jednostki głównej niczym się nie różni, po prostu dodana jest prejściówka, która jest elementem niezależnym). Takie przejściówki oczywiście można także zanabyć w formie oddzielnych produktów, nie zmienia to jednak faktu, że USB potrafi być kapryśne i używanie tego "na stałe" także może powodować niepotrzebne zgrzyty (co wcale nie znaczy, że się nie da).

[civic9]

no jak mówię co najmniej 2 lata intensywnie z tego w ten sposób używam, bez problemów. czasem się coś tam rozłączy, ale łączy się bez problemowo na nowo (to może być równie dobrze efekt wifi, bo w dodatku przez wifi z tego korzystam).

[ravbc]

tymczasem... właśnie odpaliłem nawadnianie na moim fateku.

 

A możesz opisać z grubsza pomysł? Ja właśnie jestem w trakcie oprogramowywania tego, no i koncepcji przerobiłem już w sumie kilka (albo raczej rozwijam coraz bardziej jeden pomysł), ale jak na razie ciągle nie do końca jestem zadowolony z efektów. Aha, ja założyłem sobie, że będę w stanie wpisać w PLC praktycznie kompletny program nawadniania na cały rok, co w połączeniu w minimum kilkoma sekcjami do obsługi powoduje całkiem spore zamieszanie.

 

czy ktoś przerabiał jakieś czujniki wilgotności gleby, który można by zastosować? (tylko bez samodzielnej budowy z dwóch elektrod proszę

gardena ma taki jeden, dość rozsądnie wyceniony (poniżej 200 pln), ktoś może wie jakie to ma wyjście? jeżeli OC to czy wytrzymie 24VDC? (z układu wejściowego fateka). w gardenie oczywiście piszą i mówią, że to tylko z ich sterownikami współpracuje

 

Kiedyś hobby-boards sprzedawało czujniki wilgotności gleby, ale aktualnie też ich nie mają. Cena wychodziła chyba ciut niższa niż 200zł, ale to dla mnie i tak za dużo za pojedynczy czujnik...

[ravbc]

Z USB jest niestety tak, że jak się kiepsko trafi, to określenie "stabilna praca" jest w dłuższym okresie czasu w zasadzie tylko marzeniem. O ile do programowania sterownika spokojnie można z tego tak korzystać (bo nawet jak się rozepnie, to można to łatwo spiąć ponownie) o tyle do automatycznej komunikacji (choćby modbusa) w ramach instalacji domowej, to już słabo to widzę. Nic tak nie męczy, jak nadzorowanie najbardziej podstawowych elementów, żeby te wyższego poziomu mogły wykonywać swoją pracę. Oczywiście to tylko mój punkt widzenia, ale ja jeszcze nie widziałem USB, które działało by bez wpadek przez przynajmniej kilka mesięcy non-stop (to jest z resztą efekt założeń przyjętych przy projektowaniu magistrali USB). Ja komunikację miedzy częściami automatyki puszczam (albo raczej mam plan puścić) po TCP oraz RS485, w ostateczności RS232 i liczę, że będzie prawdziwie stabilna. Jedynym wyjatkiem od tego będzie prawdopodobnie stacja meteo, bo te w iększości robią już teraz na USB tylko...

[civic9]

nie znam się na USB, więc nie będę bronił bo może coś ma za uszami. ale moje GUI (via WWW) do fateka też po USB (bo tylko takie porty mam w serwerku) i modbusie chodzi stabilnie od ok 2 lat. być może coś tam się dzieje, czego nawet nie zauważam (np. rozłączenie i automatyczny reconnect). ale skoro nie zauważam, tzn. że jest ok do tych zastosowań zresztą mam nie tylko fateka, mam na USB także 1-wire, pogodówkę, dyski, integrę... wszystko działa ok i jest podłączone do jednego malutkiego serwera (sheevaplug) za 350 zł z dodatkowym hubem za kolejne kilka dych. i to jest zaleta usb. prostota (w użytkowaniu), powszechność i niskie koszty. oczywiście usb nie zaryzykowałbym pomiędzy elementami wykonawczymi ani jako główną magistralę systemu automatyki. ale do interfejsu www naprawdę wystarczy.

[civic9]

A możesz opisać z grubsza pomysł? Ja właśnie jestem w trakcie oprogramowywania tego, no i koncepcji przerobiłem już w sumie kilka (albo raczej rozwijam coraz bardziej jeden pomysł), ale jak na razie ciągle nie do końca jestem zadowolony z efektów. Aha, ja założyłem sobie, że będę w stanie wpisać w PLC praktycznie kompletny program nawadniania na cały rok, co w połączeniu w minimum kilkoma sekcjami do obsługi powoduje całkiem spore zamieszanie.

 

Na razie zrobiłem nawadnianie i podłączyłem pod sterownik. Mogę włączyć i tyle, albo zaprogramować podlewanie wg jakiegoś harmonogramu. To świeży dla mnie temat. Moim zdaniem (aczkolwiek to mój pierwszy ogród, więc z punktu widzenia laika) - skoro większość ludzi podlewa prostymi sterownikami z harmonogramem (albo w ogóle nie podlewają) i żyją - to nie ma co bardziej kombinować.

 

W celach oszczędnościowych jedynie bym dorzucił wspomniany czujnik wilgotności, żeby nie podlewać gdy gleba jest dość wilgotna. Mogę to oprzeć też na podstawie opadów (typu: jeśli spadło X mm w ciągu ostatnich Y godzin to nie podlewaj), ale myślę, że z czujnikiem będzie bardziej precyzyjnie i lepiej dla roślin. Ponadto chciałbym dorzucić do tego element prognozy - nie podlewać, jeśli w prognozie jest deszcz w ciągu następnych X godzin. ICM daje wystarczającego i odpowiednio trafne do tego prognozy, przy czym tylko w formie graficznej. Wysłałem pytanie o udostępnienie danych numerycznych.

 

Można pokombinować, żeby ilość wody i odstępy czasowe pomiędzy nawadnianiami myślę skalkulować na podstawie średniej temperatury, ale nie wiem czy to ma sens. To już bardziej wiedza ogrodnicza, której na razie mi brak.

 

Kiedyś hobby-boards sprzedawało czujniki wilgotności gleby, ale aktualnie też ich nie mają. Cena wychodziła chyba ciut niższa niż 200zł, ale to dla mnie i tak za dużo za pojedynczy czujnik...

[Depi]

(sheevaplug)

 

O! O tym właśnie pisałem!

 

ravbc - właściwie to why not - jeżeli jesteś w stanie zmieścić ładny server wraz z eleganckim interfejsem w takim sheevaplugu to zgadzam się, że to jest dobre

 

Z wielką przyjemnością i zaciekawieniem czytam wpisy o komunikacji Fatek-Linux, bo właśnie zamiarzam wykasować ostatnią jeszcze działającą w moim otoczeniu instalację Windozy i stanę się zupełnie i w 100% FOSS Mam w związku z tym pytanie: czy któremuś z Kolegów udała się ta sztuczka z Satel Integrą?

[ravbc]

Depi: niestety programowanie trzeba robić z Windy (aczkolwiek spokojnie wystarcza wirtualizowana). Ja nie mam w domu ani jednego Widowsa, poza jedną instancją maszyny wirtualnej vmware do programowania Integry i Fateka właśnie. Aczkolwiek już sam program tworzę tą samą aplikacją windzianą uruchomioną pod wine (uzyskać sprawnej komunikacji pod wine jeszcze mi się nie udało - choć być może w wersji przez TCP to się jednak da zrobić)

[ravbc]

Na razie zrobiłem nawadnianie i podłączyłem pod sterownik. Mogę włączyć i tyle, albo zaprogramować podlewanie wg jakiegoś harmonogramu. To świeży dla mnie temat. Moim zdaniem (aczkolwiek to mój pierwszy ogród, więc z punktu widzenia laika) - skoro większość ludzi podlewa prostymi sterownikami z harmonogramem (albo w ogóle nie podlewają) i żyją - to nie ma co bardziej kombinować.

 

To niestety bardzo zależy od... ogródka, czyli rodzaju gleby i rosnących w niej roślin. Ja ciągle jeszcze nie mam automatycznego sterowania nawadnianiem (aczkolwiek głównie ze względów kosztowych - nie mam kompletu elektrozaworów), no i niestety w tym roku mam już kilka strat związanych z nieodpowiednim nawadnianiem. A większą liczbę "programów nawadniania' planuję wcisnąc właściwie głównie dlatego, że się da i nie będę musiał pamiętać o ich aktualizacji (proste sterowniki wymagają przestawienia co jakiś czas przynajmniej "pory roku", bo jednak inaczej podlewa się w środku lata, a inaczej jesienią).

 

W celach oszczędnościowych jedynie bym dorzucił wspomniany czujnik wilgotności, żeby nie podlewać gdy gleba jest dość wilgotna. Mogę to oprzeć też na podstawie opadów (typu: jeśli spadło X mm w ciągu ostatnich Y godzin to nie podlewaj), ale myślę, że z czujnikiem będzie bardziej precyzyjnie i lepiej dla roślin. Ponadto chciałbym dorzucić do tego element prognozy - nie podlewać, jeśli w prognozie jest deszcz w ciągu następnych X godzin. ICM daje wystarczającego i odpowiednio trafne do tego prognozy, przy czym tylko w formie graficznej. Wysłałem pytanie o udostępnienie danych numerycznych.

 

Można pokombinować, żeby ilość wody i odstępy czasowe pomiędzy nawadnianiami myślę skalkulować na podstawie średniej temperatury, ale nie wiem czy to ma sens. To już bardziej wiedza ogrodnicza, której na razie mi brak.

 

Czujniki wilgotności mogły by być fajne, ale musiało by ich być kilka (przynajmniej u mnie). Inaczej wysycha trawa na słońcu inaczej w cieniu, a już zupełnie inaczej jakieś większe krzaczory, o owocach czy warzywach nie wspominając. No a jeśli używać pojedynczego czujnika wilgotności to tylko jako "korektora" programu, a to chyba równie dobrze da się robić tylko na podstawie temperatury i opadów (oraz być może wiatru).

Natomiast w "wyliczanie" nawadniania to już za bardzo nie wierzę. Łatwiej jednak korygować tylko istniejący program (automatycznie na podstawie warunków pogodowych, tudzież prognoz, albo ręcznie na podstawie doświadczeń z tygodni i lat poprzednich - tu się przyda historia meteo). Kalkulacja parametrów podlewania jest niemal nierealna w obrębie PLC, trzeba by to robić "na zewnątrz", a to już zdecydowanie zbyt skomplikowane się robi. Z resztą zamiast kalkulacji wszędzie używa się po prostu większej liczby czujników wilgotności gleby i lisci, bo one są pewniejszym źródłem wiedzy (tylko ta cena).

 

 

PS. A tak bardziej w szczegółach możesz opisać w jaki sposób definiujesz "harmonogram podlewania" i jak go w PLC weryfikujesz? Chodzi mi bardziej o bebechy, bo chciałbym porównac nieco moje pomysły. Mi wyszło, że do pojedynczego "programu podlewania" potrzebuję 5 słów (10 bajtów): miesięcy, dni, godzin i minut startu i stopu (po jednym bajcie na każdą wartość, czyli razem 8bajtów, czyli 4słowa) oraz 1 słowo na wskazanie sekcji, których dany program dotyczy (co daje automatycznie obsługę maks 16 sekcji). pozostaje problem jak w sterowniku szybko i wygodnie zweryfikować, które programy są aktywne, albo raczej ustalić po prostu porządany (na dany moment) stan każdej sekcji. Na razie użyłem tu funkcji 112 (BKCMP) i 18 (AND), ale to trochę dużo markerów m zjada. Alternatywą jest użycie np. funkcji 37 (ZNCMP), ale wtedy wypada zrobić już pętlę FOR, a to troszkę upierdliwe. Dla dużej liczby programów nie znalazłem jak na razie lepszej metody (ja celuję w minimum 32 programy, co przy tych maks 16 sekcjach da raptem dwa wpisy na sekcję).

[Depi]

Bueeee... Kutwicy dostaję, jak widzę winzgrozę. W pracy niestety muszą z nią żyć, chyba, że swojego lapka przytaszczę. Nie wyobrażam sobie jak będzie chodzić mi Vista w maszynie wirtualnej, jak już w stanie obecnym jest na marginesie używalności i to po wyłączeniu wszystkiego, co się dało.

Innego obrazu nie mam, a nie będę kupował przecież licencji. Chyba muszę storrentować jakieś XP

Ja w wine uruchamiałem już WinProLadder ale np. EasyBuilder po prostu nie startuje....

[civic9]

Z mojego subiektywnego odczucia - wbrew pozorom, na dobrej maszynie wirtualnej lepiej pójdzie Windows 7 (host i VM 64bit, więc guest też 64bit) niż Windows XP (w szczególności jeśli mamy tylko wersję 32 bit na 64bitowym hoście, a to jest w zasadzie koniecznością jeżeli chcemy mieć więcej pamięci, choćby na te wirtualne maszyny) . Pod warunkiem, że mu przydzielimy ze 3-4 GB RAMu (może na 2GB też, ale to tak na styk, więc nie gwarantuję).

[Depi]

Primo - Win7 też trzeba mieć.

Secundo - wydaje się niemożliwe, aby Win7 chodził na tym samym sprzęcie SZYBCIEJ niż XP, chociażby z powodu poniższego

Tertio - Sprzęt! Jakby nie było XP potrzebuje znacznie mniej zasobów, niż W7. M. in. po to się ma linuxa, żeby nie było potrzebne sto gazylionów terabajtów RAM! Akurat maszyna, która stoi pod Fatekim i byłaby idealna ma 1GB, więc do wirtualizacji się nie nadaje. ETH do Fateka nie brałem, bo wydawało mi się zbędne, ale jak widzę nie mam wyjścia. Chyba, że 4GB RAM będzie tańsze, niż moduł ETH

Ta cała szopa z Windą mnie mocno wkur...

 

Jest to nieprawdopodobne, że na tym samym sprzęcie najnowszy Linuch z wodotryskami w stylu Compiza działa jak marzenie, a napisany kosztem miliardów USD system ledwo wstaje. Co to mówi o debilach kodujących to gówno za grube pieniądze?