Elektroda.pl
Elektroda.pl
X
TermoPasty.pl
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

narasta 13 Lut 2010 02:23 10126 16
  • [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

    Witam. Jako, że nie było ostatnio tego typu urządzeń na eletroda.pl pozwolę sobie przedstawić mój najnowszy projekt. Ta nietuzinkowa konstrukcja, to uniwersalny sterownik z komunikacją przez RS-485. Inaczej można to nazwać modemem.

    Sterownik taki składa się z następujących sekcji:
    - zasilania
    - sterownika
    - konwersji protokołu RS-232 na RS-485
    - pamięci nieulotnej

    Ogólny opis
    Sercem sterownika jest 8-bitowy mikrokontroler ATMEGA8 taktowany zegarem 12MHz. Płyta ma wymiary 65x35 mm.

    W skład sekcji zasilania wchodzi LM78L05 + tranzystor zapewniający wyższą wydajność stabilizatora, kontrolka zasilania - LED, elementy filtrujące RC oraz diody zabezpieczające przeciw przepięciom. Cała sekcja zasilania to źródło napięcie +5V o wydajnosci około 800mA. W kolejnej wersji sterownika dioda prostownicza i zennera zostaną zastąpione przez transil 18V.

    Sekcja sterownika składa się z mikrokontrolera ATMEGA8, zegara 12MHz, 3 kontrolek LED ogólnego zastosowania oraz wyprowadzeń różnych portów oraz szyny zasilania +5V w formie styków z prawej strony PCB.

    Sekcja odpowiedzialna za komunikacje sterownika to złącze RJ-45, konwerter 232-485 - SN75176 (analogiczny do MAX485).

    Sekcja pamięci to EEPROM 1kB - AT24C08 podłączony przez i2c.


    Projektowanie
    Płytka została zaprojektowana w programie ExpressPCB (darmowy i niesamowicie praktyczny - ma wszystko co potrzebuję i posiada 0 zbędnych dodatków). Zaprojektowanie PCB zajęło mi około tygodnia w wolnych chwilach podczas sesji. Grubości ścieżek od 8 do 30 milsów (0,2 do 0,76 mm).

    Zdecydowałem się na całkowite wykonanie płytki w formie montażu powierzchniowego. Jako, że planuje wykonać wiele takich sterowników uznałem, że wykonanie każdej płytki z montażem przewlekanym zajęłoby mi zbyt wiele czasu. Dzięki montażowi powierzchniowymi uniknąłem wiercenia i udało się zmneijszyc wymiary płytki do minimum. Starałem się tak rozmieścić ścieżki, aby elementy były możliwie ciasno poukładane co znowu zmniejszyło wymiary płytki i przy okazji skróciło ścieżki co pozytywnie wpłynie na jakość pracy sterownika.

    Obudowy elementów użyte w sterowniku według rozmiaru : 0603, 0805, 1206, SOT23, SOIC8, TQFP32.

    Ponieważ jest to montaż całkowicie jednostronny nie obyło się bez zworek. Role zworek pełnią tu 'rezystory' OΩ 0,125W w obudowie 1206 - w sterowniku jest ich 8. Dzięki temu można było przeprowadzić pod spodem zworki nawet dwie ścieżki grubości 8 mils.





    Nie obyło się oczywiście bez błędów (wykrytych oczywiście już po uruchomieniu gotowego układu).
    Pierwszy błąd który się pojawił (już przy montażu elementów) to zbyt blisko zamontowana dioda prostownicza zapobiegająca uciekaniu zmagazynowanej w kondensatorach energii z powrotem do linii zasilania. Przy minimalnym wychyleniu złącza rj-45 o mały kat może dojść do zwarcia masy z dodatnia szyną zasilania.
    Kolejnym błędem było zamienienie linii RxD z TxD idących do konwertera 232-485 (częsty błąd w moim wykonaniu)
    Brakuje także rezystora terminującego przy konwerterze 232-485 na linii różnicowej (rzędu 150Ω).

    Poprawki zostały już uwzględnione w projekcie wersji V.1.1 sterownika.

    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0
    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

    Płytka PCB
    Płytka została wykonana poprzez umieszczenie mozaiki ścieżek wydrukowanej z drukarce laserowej na laminacie szklano-epoksydowym. Następnie płytka zostałą wytrawiona w popularnym roztworze nadsiarczanu sodu B-327. Wykonanie samego PCB zajęło mi dość dużo czasu - w zasadzie całe popołudnie. Albo płytka została za mało podgrzana i toner odpadał, albo z kolei za bardzo i ścieżki się rozlewały co przy tak małym rastrze dyskwalifikuje płytkę. W końcu opracowałem system podgrzewania płytki - najpierw płytka od strony laminatu szklano-epoksydowego przez 45 sekund, potem od strony miedzi przez 30 sekund, następnie po nałożeniu kartki z tonerem od strony laminatu przez 15 sekund i wreszcie od strony papieru przez 10 sekund. Dzięki tak dobranym czasom podgrzewania nie przypalił się laminat, nie przegrzała się miedź, ścieżki z tonera ładnie przyległy do miedzi i sam papier się nie przypalił.

    Płytki od strony miedzi nie pokryłem na na razie żadną warstwą ochronną - część ścieżek zostaną tylko pocynowana. Nie umieściłem także opisu płytki na jej powierzchni ponieważ toner nie chciał się przykleić do laminatu - pozostawał tylko tam gdzie była miedź - było to dziwne ponieważ kiedyś umieszczałem już napisy na całej płytce bez większych problemów.

    Wykonanie kolejnych egzemplarzy PCB zdecyduję się już powierzyć jakiejś firmie profesjonalnie się tym zajmującej - może prototypy.com - dość niskie ceny a zaoszczędzi mi to sporo roboty.

    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

    Gotowy sterownik
    Złożenie całego układu (czyli samo lutowanie) zajęło mi dłuższą chwile - po raz pierwszy przyszło mi się zmierzyć z rastrem 8 mils czyli atmegą8 w obudowie TQFP32. Z przylutowaniem układu poradziłem sobie w prosty sposób - nakładając cynę najpierw tylko na ścieżki w obrębie styków, następnie przyciskając układ scalony do polutowanych ściżek przygrzałem każdą nóżkę z osobna tym samym sprawnie montując układ na PCB. Do lutowania wykorzystałem stację lutowniczą Solomon z regulacją temperatury i możliwie cienkim grotem.

    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0
    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0
    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

    Działający sterownik
    Samo uruchomienie układu sprawiło mi pewien problem - do tej pory nie wiem co było powodem ale już nigdy się nie dowiemy... Z niewiadomego powodu, nie mogłem się połączyć z megą8 przez ISP. Programator nie chciał odczytać nawet sygnatury urządzenia. Kilkukrotne sprawdzenie połączenia programatora bezpośrednio z procesorem i wyszukanie ewentualnych zwarć lub przerw ścieżek nie przyniosło żadnych efektów, ponieważ wszytko było w pożądku. Dopiero wymiana mikrokontrolera na nowy egzemplarz przyniosła pożądany skutek. Po utracie dobrych kilku godzin na sprawdzaniu układu i nerwach z uśmiechem na twarzy zobaczyłem na ekranie monitora prawidłowo odczytaną sygnaturę.

    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0 [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

    Transmisja
    Transmisja odbywa się poprzez RS-232 rozszerzone o RS-485 co pozwoliło maksymalnie wydłużyć długości połączeń pomiędzy sterownikami. Sterownik pozwala na transmisję w obydwie strony, ale nie jednocześnie. Normalnie sterownik przełącza się na nasłuch odpowiednio ustawiając w SN75176 linie odpowiedzialne za wybór pomiędzy nadawaniem a odbiorem. W momencie, gdy sterownik ma wysłać dane, na czas samej transmisji przełącza się w tryb nadawania i dopiero wtedy nadaje wiadomość, po nadaniu której znowu powraca w nasłuch.

    O samym protokole komunikacji - Dane wysyłane są w ramkach - ramka składa się z adresu nadawcy, adresu odbiorcy, liczby określającej ilość nadchodzących bajtów samej komendy/wiadomości, sumy kontrolnej oraz znaku terminującego transmisję. Jest to ramka przypominająca tą używaną w sieci Ethernet.

    Topologia sieci sterowników
    Wszystkie sterowniki połączone zostaną poprzez skretkę YnTKSy 2x2 w ekranie. pierwsza para jest wykorzystana do przesyłu zasilania, druga zaś do transmisji Half-Duplex (jedna para różnicowa).

    Cała sieć zasilana będzie z 12V - tak aby ewentualne spadki napięć nie pozwoliły na obniżenie napięcia już w danym sterowniku poniżej 8V (tak aby nadal dało się wystabilizować napięcie do 5V poprzez LM78L05).

    Sieć nie potrzebuje habów lub tym podobnych urządzeń. Przewidziałem tylko ewentualne expandery sieci 485 - ponieważ konwertery pozwalają na podłączenie do maksymalnie 32 urządzeń do jednej linii transmisyjnej - jest to spowodowane ograniczoną wydajnością prądową samych konwerterów 232-485).

    Każdy sterownik posiadać będzie swój unikalny MAC będący jego adresem.

    Sieć nie będzie zorientowana tylko w kierunku jednego głównego sterownika. Same sterowniki będą mogły się także porozumiewać pomiędzy sobą. Cała komunikacja będzie się odbywać na zasadzie wysłania wiadomości z zakodowaną komendą oraz danymi następnie otrzymując kolejną wiadomość będącą odpowiedzią od adresata na wcześniej wysłane dane.

    Jaki jest sens budowy takiego sterownika?
    Same sterowniki nie spełniają konkretnej roli - są to modemy pozwalające na komunikację pomiędzy innymi sterownikami. Do sterowników zostaną podłączone dopiero elementy (bądź całe układy o różnych zastosowaniach). Te które są w fazie projektowania to np:
    - 6-krotny przetwornik ADC
    - 6-krotny przetwornik DAC
    - 8-krotny zestaw przekaźników elektromagnetycznych
    - Linia 1-wire pozwaląjacą na podłączenie np popularnych termometrów cyfrowych 18b20
    - miernik prądu AC w obwodach ~230V dla prądów do 30A
    - potrójny sterownik PWM ze stopniem mocy
    - konwerter USB<->RS-485 pozwalający podłączyć całą sieć do komputera poprzez USB
    - RTC
    - Expander linii 485 (pozwalający podłączyć do 32 kolejnych urządzeń)
    - Regulator fazowy bądź grupowy do sterowania odpowiednio np oświetleniem lub grzałkami dużej mocy.

    Oprogramowanie
    Na razie oprogramowanie jest w proszku dlatego nie ma sensu go tu umieszczać. Program pisany jest w C w środowisku AVRStudio z kompilatorem WinAVR. Rozwój oprogramowania jest na razie na takim etapie, że moduł poprawnie odbiera ramkę, analizuje ją a następnie zwraca w postaci pokazującej jaki jest adres nadawcy i odbiorcy oraz długość wiadomości. Obliczona i sprawdzona także zostaje suma kontrolna.

    W pamięci EEPROM (512b) procesora (nie tej dodatkowej) jest zapisany adres MAC w postaci 48 bitów (6 bajtów). Wewnętrzny EEPROM kontrolera wykorzystywany będzie tylko do zapisu danych konfiguracyjnych modemu. Wszelkie dane potrzebne do pracy samego dedykowanego modułu (czyli jednego z tych które wymieniłem wyżej) zapisywane będą na bieżąco w zewnętrznym EEPROM'ie AT24C08 (1kB).

    Kosztorys
    Ciężko powiedzieć ile dokładnie kosztowało zbudowanie pojedynczego sterownika, ponieważ kupując części zaopatrzyłem się w większą ich ilość aby wykorzystać je w kolejnych egzemplarzach/wersjach sterownika. Niektórych części nie dało się kupić pojedynczo - np rezystorów bądź kondensatorów SMD - w sklepie w którym sie zaopatruję można kupowac po minimum 20 sztuk danej wartości.

    Pojedynczy sterownik nie licząc PCB to około 20-30 zł prawdopodobnie.


    Z innej beczki
    Czy ktoś z Was ma jakieś doświadczenia na temat prototypy.com? Jaka jest jakoś wykonywania płytek jak i samych usług? Jeśli macie jakieś płytki wykonane przez tą firmę, to byłbym niezmiernie wdzięczny za ewentualne zdjęcia płytek i wszelkie informacje.
    Dzięki za dotychczasowe informacje na temat produkcji płytkach drukowanych. Proszę o skupienie się na głównym temacie.


    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • TermoPasty.pl
  • #2 13 Lut 2010 10:10
    ziras
    Poziom 16  

    narasta napisał:
    Transmisja
    Transmisja odbywa się poprzez RS-232 rozszerzone o RS-485 co pozwoliło maksymalnie wydłużyć długości połączeń pomiędzy sterownikami. Sterownik pozwala na transmisję w obydwie strony, ale nie jednocześnie. Normalnie sterownik przełącza się na nasłuch odpowiednio ustawiając w SN75176 linie odpowiedzialne za wybór pomiędzy nadawaniem a odbiorem. W momencie, gdy sterownik ma wysłać dane, na czas samej transmisji przełącza się w tryb nadawania i dopiero wtedy nadaje wiadomość, po nadaniu której znowu powraca w nasłuch.

    W jaki sposób rozwiązujesz problem kolizj w momencie gdy na nadawanie przełączy się naraz 2 lub więcej modułów? Co w momencie gdy nadaje jeden moduł a inny chce rozpocząć transmisję?

  • #3 13 Lut 2010 13:31
    __Maciek__
    Poziom 19  

    Z opisu wynika że chcesz stworzyć coś w rodzaju różnych modułów automatyki. Pomysł wg. mnie bardzo dobry, ale ...
    - Dlaczego nie rozważyłeś jakiegoś gotowego i rozpowszechnionego protokołu transmisji danych ?? np. MODBUS ??
    - Jak wspomniał kolega wyżej ... jak zamierzasz ( rozwiązałeś ) arbitraż ??
    - Czy wziąłeś pod uwagę montaż gotowego zestawu w jakiejś obudowie ?? ( W przypadku modułów automatyki wygodne i popularne są obudowy na szynę DIN )
    - Jeśli nie mają być to typowe elementy automatyki to jakie zastosowania przewidujesz ?? ( Idom ? )

  • #4 13 Lut 2010 13:49
    narasta
    Poziom 21  

    Dzięki za dotychczasowe informacje na temat produkcji płytkach drukowanych. Proszę o skupienie się na głównym temacie.

    Jeśli chodzi o gotowe protokoły, to tak - myślałem o MODBUSie ale założeniem całego projektu stworzenie wszystkiego samemu od podstaw. Z resztą, podejrzewam, że wdrożenie gotowego protokołu zajęło by mi więcej czasu niż napisanie własnego protokołu. Tak to mam duże pole manewru i nie jestem uzależniony od z góry przyjętych cech modbusa.
    Poza tym, gdzie wasza ambicja? :P

    Obudowa to na razie najmniej przejmująca mnie część projektu - zajmę się tym w swoim czasie.

    Pierwszym pomysłem który przyszedł mi do głowy i spowodował, że stworzyłem cały projekt jest właśnie idea inteligentnego domu.

    Jeśli chodzi o kolizję - pewnie zrobię to tak, że gdy dwa moduły wyślą jednocześnie dane i w wyznaczonym czasie (czasie wyznaczonym losowo) nie otrzymają odpowiedzi, zapytanie zostanie wysłane ponownie. Dlaczego losowo? Ano dlatego, żeby uniknąć kolizji po raz kolejny i kolejny.

    Typowe zastosowania?
    Jeśli weźmiemy pod uwagę np. dom to można rozważyć np sterowanie oświetleniem (moduł odbiorników irda , z triakami (regulator fazowy) lub przekaźnikami), jakimiś grzejnikami np elektrycznymi (regulatory grupowe), pomiar temperatury w danych pomieszczeniach (1w ds18b20), lub zrobić nawet własny system alarmowy (system czujników etc...).


    Tak swoją droga to jeszcze przewiduje kilka modułów ale na razie są tylko zamysłem, ponieważ muszę się bardziej przyglądnąć sprawie. Np.:
    moduł z odbiornikiem GPS
    moduł z modemem GSM
    moduł z dużą pamięcią w postaci karty SDHC z FAT16/32
    moduł terminala - klawiatura podłączona pod PS/2 oraz wyświetlacz jakiś

  • TermoPasty.pl
  • #5 13 Lut 2010 14:46
    Olo999
    Poziom 21  

    ziras napisał:
    narasta napisał:
    Transmisja
    Transmisja odbywa się poprzez RS-232 rozszerzone o RS-485 co pozwoliło maksymalnie wydłużyć długości połączeń pomiędzy sterownikami. Sterownik pozwala na transmisję w obydwie strony, ale nie jednocześnie. Normalnie sterownik przełącza się na nasłuch odpowiednio ustawiając w SN75176 linie odpowiedzialne za wybór pomiędzy nadawaniem a odbiorem. W momencie, gdy sterownik ma wysłać dane, na czas samej transmisji przełącza się w tryb nadawania i dopiero wtedy nadaje wiadomość, po nadaniu której znowu powraca w nasłuch.

    W jaki sposób rozwiązujesz problem kolizj w momencie gdy na nadawanie przełączy się naraz 2 lub więcej modułów? Co w momencie gdy nadaje jeden moduł a inny chce rozpocząć transmisję?

    narasta napisał:
    Dzięki za dotychczasowe informacje na temat produkcji płytkach drukowanych. Proszę o skupienie się na głównym temacie.
    Jeśli chodzi o kolizję - pewnie zrobię to tak, że gdy dwa moduły wyślą jednocześnie dane i w wyznaczonym czasie (czasie wyznaczonym losowo) nie otrzymają odpowiedzi, zapytanie zostanie wysłane ponownie. Dlaczego losowo? Ano dlatego, żeby uniknąć kolizji po raz kolejny i kolejny.


    A nie lepiej zrobić transmisje master-slave? Tzn. jeden moduł master pozostałe slave. Master odpytuje po kolei slav'y.

  • #6 13 Lut 2010 15:18
    zgierzman
    Poziom 20  

    Olo999 napisał:
    A nie lepiej zrobić transmisje master-slave? Tzn. jeden moduł master pozostałe slave. Master odpytuje po kolei slav'y.

    Z nieznanych pobudek autor nie chce tego robić, o czym pisał w pierwszym poście. Taka idea "inteligencji rozproszonej" do mnie nie przemawia, bo każdy moduł będzie musiał mieć specyficzny program w zależności od zastosowania. Dwa identyczne moduły będą musiały mieć dwa różne programy... Do tego każdy z modułów będzie musiał znać adresy innych łącznie z ich rodzajem/funkcją. Każda modyfikacja systemu będzie się łączyć z przeprogramowywaniem wszystkich modułów, albo potrzebna będzie skomplikowana komunikacja, z ramkami rozgłoszeniowymi, gdzie każdy z modułów będzie się innym przedstawiał i podawał adres, typ, funkcje, miejsce zainstalowania (np. termometry) i wiele innych informacji potrzebnych do działania całości. Zapanowanie nad czymś takim to będzie niezła rzeźba.

    narasta, może objaśnisz nas co tobą kierowało kiedy rezygnowałeś z centralnego sterownika i jaką masz koncepcję funkcjonowania całości? Napisz kilka zdań - bardziej szczegółowo, niż "Sieć nie będzie zorientowana tylko w kierunku jednego głównego sterownika. Same sterowniki będą mogły się także porozumiewać pomiędzy sobą. Cała komunikacja będzie się odbywać na zasadzie wysłania wiadomości z zakodowaną komendą oraz danymi następnie otrzymując kolejną wiadomość będącą odpowiedzią od adresata na wcześniej wysłane dane."
    Jak moduły mają się wzajemnie rozpoznawać, znać swoje funkcje w systemie i reagować na pojawienie się nowych czy zniknięcie istniejących modułów?

    Inna rzecz, to zapisanie adresu na stałe w EPROMie. Dlaczego tak, a nie ustawianie adresu na zworkach, czy DIP switchach? Wymiana uszkodzonego modułu na inny będzie wymagała przeprogramowania procka. Bez sensu, moim zdaniem.

  • #7 13 Lut 2010 15:23
    narasta
    Poziom 21  

    Jeśli chodzi o kolizje to można by to rozwiązać w pewien sposób - tokeny. Nie konieczny nawet będzie master. Można to tak zrealizować, że moduły miedzy sobą przekazują token. Posiadacz tokena ma zezwolenie na transmisję. Sekwencje nadawania będą bardzo krótkie - 99,9% czasu moduły będą spędzać na nasłuchu. Mała szansa na kolizję aczkolwiek możliwa i też będę musiał temu zapobiec.

    Właśnie cały zamysł systemu jest taki, że wszystkie urządzenia mają mieć równe uprawnienia. W przypadku MODBUSa musiałbym już korzystać z master-slave, czego nie chcę.

    Jako namiastkę mastera przewiduję sterownik połączony z komputerem przez USB oraz aplikację napisaną np. pod windows. Nie będzie to stricte master, ponieważ sieć działać będzie mimo wyłączenia komputera. Komputer pełnić będzie tylko rolę terminala z umieszczonymi różnymi opcjami sterowania konkretnych urządzeń.

    Nie trzeba będzie przeprogramowywać wszystkich modółów - ewentualnie sam eeprom zewnętrzny który będzie miał zapisane adresy urządzeń z którymi ma w jakiś sposób wymieniać informacje.

    zgierzman, w zasadzie jest prawda w tym co piszesz. Zobaczę jak to wyjdzie w praniu. Może zrobię jeden moduł pełniący role centralnego sterownika - będzie on wymagał jednak już "większego" procesora tj z większą pamięcią flash i jakiegoś sensownego eepromu.

    EEPROMy nie będą programowane tylko raz. Na pewną zrobię możliwość programowania ich z zewnątrz tj z terminala (np PC).

    Ostatecznie pewnie skończy się to tak, że moduły będą mogły pracować autonomicznie z tym, że będzie jednostka centralna panująca nad całym bałąganem.
    Powiedzmy, ze mamy jeden moduł zamontowany w żyrandolu w postaci regulatora fazowego i drugi zamontowany w puszce z włącznikiem - nie ma sensu, żeby zarządzał tym jakiś master. Z powodzeniem moduły same mogą się porozumieć. Oczywiście tez można będzie nimi sterować z zewnątrz.
    Dlatego właśnie zależy mi na własnym protokole bo mogę wszytko tak zaprojektować w 100% według moich potrzeb oraz zamysłu.

  • #8 13 Lut 2010 15:49
    zgierzman
    Poziom 20  

    No tak, połączenie ze sobą dwóch elementów nie będzie problemem, ale idea "inteligentnego domu" w moim rozumieniu jest taka, że można z jednego miejsca zarządzać wszystkimi funkcjami.

    Przykład z regulatorem w żyrandolu nie jest najszczęśliwszy, to to realizuje się montując regulator w wyłączniku, i w handlu dostępne jest pod nazwą "ściemniacz".
    Jeśli jednak połączysz wszystkie ściemniacze jakąś magistralą i uzyskasz możliwość ich zdalnego sterowania, to musisz wiedzieć, gdzie który ściemniacz jest zainstalowany i jaką funkcję akurat realizuje. A dostęp zdalny nie wyklucza zainstalowania lokalnego enkodera na przykład, którym sobie światełko ściemniamy bez potrzeby angażowania centralnego sterownika.
    Ale jest to typowy moduł slave, może pracować autonomicznie, bez kontaktu ze światem, regulację robisz ręcznie enkoderem. Jeśli ten moduł podłączysz jednak do sieci, to jego funkcją będzie "wyspowiadanie" się z aktualnego natężenia światła, lub przyjęcie zdalnej komendy. Taki moduł nie musi, a nawet nie powinien samodzielnie inicjować transmisji, bo nie ma takiej potrzeby, a tylko zaśmiecałby magistralę...

  • #9 13 Lut 2010 16:03
    sobieraj_100
    Poziom 12  

    Jeżeli dobrze zrozumiałem to urządzenie praktycznie nie działa. Ciężko tu coś ocenić.
    Proponuje uzupełnienie tematu jak kolega napisze oprogramowanie obsługujące. Na razie to gdybanie i fantasmagorie :-)

  • #10 13 Lut 2010 16:13
    narasta
    Poziom 21  

    Cytat:
    Jeżeli dobrze zrozumiałem to urządzenie praktycznie nie działa. Ciężko tu coś ocenić.
    No tak do póki nie ma się pojęcia o tego typu urządzeniach to prawda - nie działa. Z fantasmagoriami to 'kolega' chyba nasłuchał się za dużo Akuratu. Na razie czekam na koniec sesji i wtedy zabiorę się za skończenie softu. Póki co chciałem zaprezentować już część projektu - czyli hardware. Jak to mawiają "miernota lepsza od niczego". Ok, koniec - wracając do tematu:

    Przytaczając przykład żyrandola miałem na myśli więcej niż jedną żarówkę. Każda sterowana osobno. W tym momencie np w moim pokoju mam zainstalowane na suficie oświetlenie składające się z 6 żarówek halogenowych i nie zawsze jest sens zapalać wszystkich bo to aż 300W, czasami chcę mieć tylko punktowe oświetlenie w danym miejscu pokoju np. na biurko.

    Cytat:
    Przykład z regulatorem w żyrandolu nie jest najszczęśliwszy, to to realizuje się montując regulator w wyłączniku, i w handlu dostępne jest pod nazwą "ściemniacz".
    Jeśli jednak połączysz wszystkie ściemniacze jakąś magistralą i uzyskasz możliwość ich zdalnego sterowania, to musisz wiedzieć, gdzie który ściemniacz jest zainstalowany i jaką funkcję akurat realizuje. A dostęp zdalny nie wyklucza zainstalowania lokalnego enkodera na przykład, którym sobie światełko ściemniamy bez potrzeby angażowania centralnego sterownika.
    Ale jest to typowy moduł slave, może pracować autonomicznie, bez kontaktu ze światem, regulację robisz ręcznie enkoderem. Jeśli ten moduł podłączysz jednak do sieci, to jego funkcją będzie "wyspowiadanie" się z aktualnego natężenia światła, lub przyjęcie zdalnej komendy. Taki moduł nie musi, a nawet nie powinien samodzielnie inicjować transmisji, bo nie ma takiej potrzeby, a tylko zaśmiecałby magistralę...

    Na razie rolę centralnego sterownika przejmie komputer, dopóki nie znajdę sensowne wyświetlacza (może nawet coś z panelem dotykowym :)). Zrobienie terminala to już sprawa wymagająca głębszego przemyślenia. Nie wszystko na raz.

  • #11 13 Lut 2010 17:10
    korneliuszo
    Poziom 16  

    Rozwinięty podobny projekt.

    http://yakko.sourceforge.net/

    Sam myślałem o czymś podobnym. Mam nawet fajny panel. Ma protokół MODBUS. Myślałem o bezpośrednim podłączeniu go do sieci, ale teraz uważam, że lepiej poświęcić jednego procka by go obsługiwał w całości.

  • #12 13 Lut 2010 21:01
    bolek
    Specjalista - oświetlenie sceniczne

    trochę taki "fiołkowy" ten projekt. Obyś zrobił z tym coś sensownego z taką pompą jak te płytki i opis. ;)
    Do takiego modemu można spokojnie wsadzić soft który będzie realizował od razu odpowiednią funkcje. A tak to jest tylko jakiś pośrednik. MACi też chyba nie potrzebnie takie duże, Skoro możesz przewidzieć że nie będzie ich w takiej instalacji więcej jak setka to adres można zrobić na
    Zamiast tego można pomyśleć o jakiejś dobrej i ogólnej transmisji, do której można dokleić odpowiednie funkcje urządzenia. Nie zgodze się tez że rozgryzanie i implementowanie gotowych prokołów jest mało ambitne, a przynajmniej mniej niż napisanie czegoś własnego.

    Sposoby walki z kolizjami właśnie tam są dobrze rozgryzione, poza tym każdy sposób jest dobry, pod warunkiem że skuteczny. Przekazywanie tokena kolejnemu klockowi też nie jest takie proste bo poprzednik musi wiedzieć kto jest po nim (ale też jest to do zrobienia). Można dać mastera który będzie tylko prowokował odpowiedzi (a reszta będzie słuchać i robić z tym co chce), albo zrobić tak jak w CANie, sprzężenie z magistralą. Czyli na karnego jeżyka idzie to kto wystawił na linie 1, a po sprawdzeniu linii okazuje sie że jest tam 0.

  • #13 14 Lut 2010 10:46
    narasta
    Poziom 21  

    Dzięki dużym MACom będę mógł zmieścić w adresie pewne informacje nie koniecznie sam adres ale np typ urządzenia, wersje, numer egzemplarza, pozostają jeszcze 3 bajty na numer który zamierzam przydzielać kolejno każdemu urządzeniu ogólnie.

    Z tymi tokenami masz rację. W sumie skąd poprzednie urządzenie ma wiedzieć komu następnemu ma go przekazać... Bez jednostki centralnej chyba się nie obejdzie. Wyjdzie w praniu.

    A żeby nie być gołosłownym co do modułów, pozwolę sobie wrzucić kilka schematów zaprojektowanych urządzeń.

    Linia 1-wire
    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

    6-krotny ADC
    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

    sterownik 8. przekaźników elektromagnetycznych
    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

    Źródło zasilania sieci 485
    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

    RTC
    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

    Potrójny driver PWM 3x8bit
    [NSystems] - Uniwersalny sterownik z obsługą RS-485 / V.1.0

    Schematy muszą poczekać na koniec sesji :P

  • #14 14 Lut 2010 11:25
    bolek
    Specjalista - oświetlenie sceniczne

    narasta napisał:

    Z tymi tokenami masz rację. W sumie skąd poprzednie urządzenie ma wiedzieć komu następnemu ma go przekazać... Bez jednostki centralnej chyba się nie obejdzie. Wyjdzie w praniu.


    powiedzmy ze n+1 kończy i daje zgode n+2. Jeśli n+2 się nie odezwie w ciągu np pół sekundy, to n+1 ponownie wysyła zezwolenie, jednak tym razem dla n+3...

    n+3 się odezwie i wystawi tokena dla n+4 itd

  • #15 14 Lut 2010 12:37
    sobieraj_100
    Poziom 12  

    W obecnej sytuacji dyskusja wydaje się być jałowa. Widzieliśmy pięknie narysowane schematy , niektóre graniczą ze zdrowym rozsądkiem i bezpieczeństwem użytkownika ( brak bezpieczników itp. ). Proponuje zamknąć temat do czasu prezentacji gotowego systemu , tudzież oprogramowania dla sterowników. Dla mnie to wygląda na prowokację.
    Pozdrawiam

  • #16 14 Lut 2010 12:46
    narasta
    Poziom 21  

    Cytat:
    W obecnej sytuacji dyskusja wydaje się być jałowa. Widzieliśmy pięknie narysowane schematy , niektóre graniczą ze zdrowym rozsądkiem i bezpieczeństwem użytkownika ( brak bezpieczników itp. ). Proponuje zamknąć temat do czasu prezentacji gotowego systemu , tudzież oprogramowania dla sterowników. Dla mnie to wygląda na prowokację.
    Pozdrawiam

    Zawsze wrzucić to można do DIY niedokończone.
    A schematy? Możecie mnie poprawić i zasugerować poprawki.

    Owszem wypadałoby dodać zabezpieczenia w zasilaczu w postaci chociażby bezpiecznika.