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

Linux w roli mastera sieci RS-485. Inteligentna pracownia.

MES Mariusz 27 Aug 2009 10:31 3083 13
Optex
Reply | New topic
  • #1
    MES Mariusz
    Level 36  
    Kiedyś poruszyłem zagadnienie Linuksa w roli logera danych napływających na port COM ( http://forum.freesco.pl/viewtopic.php?t=17394
    https://www.elektroda.pl/rtvforum/topic1177138.html ).

    Teraz potrzebna mi jest większa funkcjonalność. Otóż uruchamiam Inteligentną pracownię z wieloma urządzeniami pracującymi w sieci RS-485 nasłuchującymi komunikatów z centrali. Jako centralę mógłbym opracować odrębne urządzenie na uP, ale po co ładować się w z góry bardzo ograniczone (niewielkie zasoby pamięci mikrokontrolera) i mało wygodne w rozbudowie urządzenie elektroniczne, jeśli do tego celu można wykorzystać NND pracujące na maszynie w tym samym pomieszczeniu.

    Przydałoby się coś w rodzaju crona, z drugiej nieco bardziej rozbudowanego. Z jednej strony, aby program wysyłał o określonych godzinach zaprogramowane komunikaty na port COM, a z drugiej, aby była możliwość programowania procesów nieco bardziej złożonych logicznie (decyzje logiczne na podstawie danych odebranych z urządzeń w sieci (temperatura, poziom oświetlenia itp.).

    Idealną sytuacją byłoby sprowadzenie wszystkiego do pojedynczego skryptu konfiguracyjnego. Cała inteligencja byłaby wtedy pod wygodną i przejrzystą kontrolą, i zawierała by się w łatwo modyfikowalnym skrypcie.

    Jakieś pomysły? A może chęci do współpracy nad projektem? :-) Jak widać, jedyny mój problem / jedyne ograniczenie to nieumiejętność / niezdolność władania składnią i kompilatorami języka C dla Linuksa.

    Pozdrawiam
    Mariusz
  • Optex
  • #3
    MES Mariusz
    Level 36  
    avatar wrote:
    chodzi ci o skrypt w bashu zapisujacy i odczytujacy komunikaty z portu ttysX?

    To byłby rozsądny punkt wyjścia, od tego wypadałoby zacząć. W przyszłości trzeba będzie zaimplementować operacje decyzyjne na podstawie informacji zbieranych z urządzeń pracujących wewnątrz sieci. No chyba, że się okaże, że wszystko da się zrobić w bashu :-)

    Może się jednak okazać, że nie da się uciec od napisania softu w C, wczytującego plik skryptu konfiguracyjnego zawierający całą inteligencję pomieszczenia, który zawierałby coś w stylu:

    - Oczekuj stringu "start" na porcie COM (sygnał otrzymywany z systemu alarmowego po rozbrojeniu)
    - Wyślij string "A10" (żądanie odczytu temperatury do urządzania X)
    - Obierz daną, która napłynie i przyporządkuj zmiennej temperatura
    - Wyślij string "A11" (żądanie odczytu poziomu oświetlenia do urządzania X)
    - Odbierz daną, która napłynie i przyporządkuj zmiennej poziom_oświetlenia
    - Jeśli poziom_oświetlenia mniejszy od zadeklarowanej stałej wyślij na COM string "111" (zaświeci się światło główne)
    - Jeśli temperatura większa od zadeklarowanej stałej wyślij na COM string "121" (uruchomią się wentylatory)
    - Codziennie godz. 21.50 wyślij na COM string "B10" (z głośników popłynie komunikat o zbliżającym się końcu zajęć, przypomnienie procedury porządkowej itd.)

    Jak widać, jedyny mój problem / jedyne ograniczenie to nieumiejętność / niezdolność władania składnią i kompilatorami języka C dla Linuksa (w tym obsługa portu COM, czytanie zewnętrznego pliku konfiguracyjnego).

    I mam dwie opcje, albo naumieć się programowania w C i obsługi dedykowanych kompilatorów (zajmie sporo czasu i nerwów, ale da największe możliwości), albo wynająć programistę i... dobrze mu zapłacić. Chyba że po drodze znalazłby się profesjonalista, który miałby ochotę uczynić to w myśl idei Open Source (soft pisany przez początkującego programistę będzie miał raczej wątpliwą jakość...)
  • Optex
  • #4
    Szymon Tarnowski
    Level 27  
    Ja mam następującą wizję jak to zrobić, przynajmniej planuje kiedyś zaimplementować to w swoim systemie inteligentnego domu. Należy zaprojektować coś w rodzaju frameworku albo automatu PLC. System opiera się o reguły budowane jako wyrażenie logiczne typu "jeśli X to Y" gdzie X jest wyrażeniem logicznym. "Pod spodem" systemu znajduje się warstwa komunikacyjna która okresowo odpytuje urządzenia i wysyła im dane. Dodatkowo konieczna jest lista/baza przypisująca do urządzeń i ich "pól" danych określone nazwy np "termometr1.temperatura" albo "wyłącznik3.przycisklewy". Moim zdaniem trzeba maksymalnie izolować architekturę sprzętową od logiki automatu sterującego i zapewnić zamienność i uniwersalność urządzeń. W prostym systemie praktycznie wystarczą wyrażenia logiczne tak/nie oraz testowanie poziomu sygnału > lub <. Jeśli będą konieczne jakieś specjalne funkcje np regulacja "PID" albo "zegar RTC" należy je zaimplementować jako kod wykonywalny operujący na wirtualnych (nie związanych bezpośrednio z fizycznymi elementami) nazwach.
    Całość można zrealizować na dwa sposoby:
    1. maszyna sterująca oparta o język skryptowy. Można to zrobić budując prosty parser z wykorzystaniem np flex/bison który będzie przetwarzał np co 100ms skrypt i podejmował działanie
    2. zaprojektować odpowiednie makra i kompilować pseudo-język do kodu binarnego, jeśli są to proste funkcje matematyczno-logiczne, to powinno się to łatwo konwertować do C. Wtedy wystarczy zmodyfikować skrypt, zrobić make all i make download i potem już wyłączyć komputer a cały automat pracuje w uP nawet 8bitowym.
  • #5
    Dr.Vee
    VIP Meritorious for electroda.pl  
    Prosto i elastycznie:
    1) komponent serwera odpowiedzialny za komunikację z urządzeniem/urządzeniami.
    1.a) zmiana stanu urządzenia jest publikowana do systemu rozgłoszeniowego
    1.b) żądanie zmiany stanu urządzenia jest odbierane z systemu rozgłoszeniowego i wykonywane.
    2) komponenty decyzyjne - po jednym do danej funkcji hardwareowej
    2.a) rejestrują zainteresowanie danymi komunikatami w systemie rozgłoszeniowym
    2.b) po odebraniu komunikatu/notyfikacji przetwarzają go i ew sygnalizują komponentowi sterującemu żądanie wykonania zadanej akcji

    Komunikaty można traktować jak zdarzenia z parametrami i obsługiwać np. maszyną stanów. Przy dalszej rozbudowie systemu można dodać komponenty świadczące różne usługi, np. alarmy, timery itp.

    W uproszczeniu cały system jest zestawem asynchronicznie komunikujących się automatów skończonych (i tak można go oprogramować, również językiem graficznym).

    Wszystko można szybko i sensownie zaimplementować w języku skryptowym, na wątkach lub bez itp, można też użyć gotowych systemów rozgłoszeniowych typu DBUS, ale to chyba lekka przesada dla takiej aplikacji.

    Pozdrawiam,
    Dr.Vee
  • #6
    korneliuszo
    Level 17  
    Zastanawiałem się nad podobnym problemem i skupiłem się na razie nad warstwą komunikacyjną.

    Mamy 2 możliwości kiedy dane są przesyłane.
    1) urządzenia informują o zmianie stanu.
    2) ciągłe wypytywanie o stan.

    Zakładając, że nie tylko komputer będzie wysyłał żądania musimy wybrać jeszcze sposób kontroli nad magistralą
    1) nadawanie w razie potrzeby i wykrywanie kolizji
    2) przekazywanie tokena

    Ciekawią mnie panele operatorskie ponieważ od nich będzie zależeć użyty protokół.

    Osobiście posiadam panel operatorski i jedynym łatwym do oprogramowania protokołem był MODBUS. (może pracować jako master lub slave)
    Dla mnie mankamentem był fakt że chciałem mieć wiele masterów pracujących niezależnie. (wyłączenie dowolnego nie było by problemem)

    Rozwiązałem to przekazując między urządzeniami funkcję MASTER.

    W twoim przypadku użycie protokołu MODBUS zmusi do ciągłego odpytywania i jedynymi eventami będą zmiany wartości.

    Dr.Vee poleca rozwiązanie, że to urządzenia wysyłają eventy i komputer tylko je odbiera.

    problemem będzie zapewnienie by 2 urządzenia siebie nie zakłóciły wysyłając zgłoszenia.

    Gdy panel operatorski umożliwia napisanie swojego protokołu to polecam wykorzystanie eventów.

    Jak panel umożliwia tylko używanie standardowych protokołów to opiszę dokładnie swoje dokonania (wymagają poprawek)
  • #7
    Dr.Vee
    VIP Meritorious for electroda.pl  
    korneliuszo wrote:
    Dr.Vee poleca rozwiązanie, że to urządzenia wysyłają eventy i komputer tylko je odbiera.

    problemem będzie zapewnienie by 2 urządzenia siebie nie zakłóciły wysyłając zgłoszenia.


    Źle mnie zrozumiałeś. Szczegóły komunikacji z fizycznymi urządzeniami jest zaszyta w jednym module systemu. Ten moduł miałby jedynie przeprowadzać translację: stan urządzeń <-> eventy.

    Pozdrawiam,
    Dr.Vee
  • #8
    MES Mariusz
    Level 36  
    avatar wrote:
    chodzi ci o skrypt w bashu zapisujacy i odczytujacy komunikaty z portu ttysX?

    Swoją drogą, wiesz jak to zrobić / da się? Z konsoli / bash-a wysłać na port ttysX jakiś string przy określonych parametrach transmisji ?
  • #10
    avatar
    Level 36  
    MES Mariusz wrote:
    avatar wrote:
    chodzi ci o skrypt w bashu zapisujacy i odczytujacy komunikaty z portu ttysX?

    Swoją drogą, wiesz jak to zrobić / da się? Z konsoli / bash-a wysłać na port ttysX jakiś string przy określonych parametrach transmisji ?

    swoja droga to da sie to zrobic nawet z php ... sklecam arytkol na ten temat
    sterowanie z PHP przekaznikami w linuxie ... jak allach pozwoli i czas to zaniebawiem sie pojawa moje wypociny - o ile moderator ich nie usunie :)
  • #11
    MES Mariusz
    Level 36  
    Chętnie przeczytam, daj znać jak wrzucisz :-)
  • #14
    gothye
    Level 33  
    dorzucę coś od siebie ,o to prosty program w C ,z obsługą RTS portu czyli jednoczesnie sterowanie nadawaniem na szynie rs485 dzieki czemu układ konwertera rs232/485 ogranicza się do układu max232/max485 ;)
Reply | New topic