logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Sterownik przemysłowy "GNUMASTER" - robimy ???

Teodor Otulak 06 Mar 2006 21:47 19924 108
  • #1 2383516
    Teodor Otulak
    Poziom 13  
    Posty: 82
    Ocena: 2
    Sterownik przemysłowy "GNUMASTER" - robimy ???
    Prosty sterownik.
    Od wielu lat projektuję specjalizowane sterowniki do różnych zadań. Są to produkty niszowe, wytwarzane w niewielkich a niekiedy pojedynczych ilościach. Z doświadczenia wiem, że wielu hobbystów i małe firmy działają w podobny sposób - wszyscy "odkrywamy koło". Każdy stara się stworzyć coś doskonałego, ale przy okazji popełnia te same szkolne błędy, które inni popełnili już wcześniej. Świat idzie do przodu, bo dawno odkrył skuteczność działań zespołowych. W tej sytuacji zdecydowałem się na wystąpienie z następującym apelem:
    Zróbmy wspólnie sterownik przemysłowy na licencji "GNU".
    W praktyce chodzi o to aby:
    1) Zaimplementować jak najstabilniejsze rozwiązanie hardwarowe
    2) Hardware musi gwarantować jak największą skalowalność
    3) Zrobić ogólnodostępną, pełną dokumentację
    4) Zaprojektować PCB oraz obudowę, tak aby były spełnione wymagania CE
    5) Udostępnić wszystkim zainteresowanym jak największą ilość gotowych aplikacji
    6) Jako mikrokontroler, proponuję zastosować ATMega128 + WinAVR
    7) Proponuję rozważyć konstrukcję modułową - coś ala tego co miały pierwsze komputery, czyli płyta główna w którą można wkładać różne specjalistyczne moduły.
    8) Architektura sterownika moim zdaniem powinna zapewniać możliwość uruchomienia zarówno systemów operacyjnych RTOS jak i prostych programów liniowych
    9) Sterownik od strony technicznej powinien nadawać się do zastosowań jak najbardziej profesjonalnych i komercyjnych

    Pytanie:
    Czy ktoś z kolegów jest chętny aby razem ze mną zaangażować się w ten projekt ?
    Czy taka inicjatywa ma sens ???

    Pozdrawiam: www.gnumaster.pl
    Sterownik przemysłowy "GNUMASTER" - robimy ???
  • #2 2384540
    markcomp77
    Poziom 13  
    Posty: 78
    Pomógł: 2
    Ocena: 3
    Teodor Otulak napisał:
    Zróbmy wspólnie sterownik przemysłowy na licencji "GNU".

    jestem ZA :)
    każdy otwarty projekt - to bardzo wielka pomoc dla projektujących... nawet jeśli nie jest adaptowany jako gotowiec do...
    jednak warto aby nasz gotowiec miał realną szansę powszechnego zastosowania w pewnych dziedzinach...

    Teodor Otulak napisał:
    6) Jako mikrokontroler, proponuję zastosować ATMega128 + WinAVR


    a może jednak jakiś ARM ?
    ARMy drogie nie są... soft GPL prawie "ten sam" co dla AVR został zrobiony -> WinARM

    Teodor Otulak napisał:
    Pytanie:
    Czy ktoś z kolegów jest chętny aby razem ze mną zaangażować się w ten projekt ?

    chętnie :)... na ile czas pozwoli

    Teodor Otulak napisał:
    Czy taka inicjatywa ma sens ???

    sens ma
    zobaczymy ilu zbierze się robotników do prac społecznych ;)
  • #3 2384646
    MirekCz
    Poziom 35  
    Posty: 2220
    Pomógł: 330
    Ocena: 62
    Ja jestem gotowy pomóc.
    W zasadzie też uważam, że ARM byłby lepszy (przyzwoita cena, duży sdram i lista rozkazów doskonale przystosowana do obliczeń na bramkach)
  • #4 2384776
    McRancor
    VIP Zasłużony dla elektroda
    Posty: 5326
    Pomógł: 479
    Ocena: 123
    Może Zbudować taki sterownik na zasadzie modułów, niech będzie podstawowa płyta, z kompletem I/O, optoizolacją wejść, ewentualnie wyjść, z przekaźnikami itp. poza tym układy zasilania i ewentualnie komunikacji.

    Procesor niech będzie na dodatkowej płytce, która w zależności od potrzebnej aplikacji niech zawiera ARM7TDMI (Analog rozdaje je teraz za free), AVRa, Pica czy co kto lubi.

    Obniży to koszty i nada projektowi elastyczności, po co komuś kto chce zrobić sterowanie klapką w kurniku RTOS, zewnętrzny RAM i hektar niewykorzystanej pamięci programu?

    Trzeba określić podstawowe wymagania, ile wyjść/wejść, jakie wymiary.

    PS. EKG nadal się buduje.
  • #5 2384847
    ko_rex
    Poziom 19  
    Posty: 253
    Pomógł: 38
    Ocena: 2
    Hmmm a co od strony użytkownika? Planujecie jakiś specjalny soft to programowania tego sterownika? No bo jakoś uzytkownik musi sobie tą klapkę od kurnika zaimplementować.
    Różnorodność procesorów...no obniża koszty...ale czy aby na pewno? Czas i wysiłek na opracowanie kilku platform chyba jednak źle się odbija na dopracowaniu projektu. Lepiej skupić się na jednej - dobrze opracowanej, przetestowanej. Ma to być w końcu profesjonalny projekt.

    W każdym razie ciekawa inicjatywa i chętnię bym się dołączył w miarę możliwości, czasu, umiejętności i wiedzy.
  • #6 2384886
    Teodor Otulak
    Poziom 13  
    Posty: 82
    Ocena: 2
    Jestem zdecydowanie za tym ,aby procesor był dowolnego typu. Powinien być w formie modułu wkładanego do płytki bazowej. Jednocześnie, płytka powinna zapewniać obsługę wielu procesorów jednocześnie, bo na przykład:
    1 procesor obsługuje ekran graficzny i touch panel
    2 procesor obsługuje TCP/IP i web serwer
    3 procesor obsługuje na przykład enkodery liniowe ( listwy pomiarowe)

    A każdy z nich może pracować niezależnie i w czasie rzeczywistym.
    W tym momencie rodzi się pytanie o magistralę systemową która umożliwi komunikację każdego procesora z każdym innym dowolnym a jednocześnie będzie 100% odporna na zakłócenia. Ja proponuję jako nośnik fizyczny zastosować RS-485 do przesyłu danych wzbogacone o dwie dodatkowe linie ___BUSY oraz ___MASTER_COMMAND, co znacznie uprości arbitraż taką magistralą :-)
    ___Busy jest ustawiane przez procesor inicjujący przesył danych i jest sygnałem dla innych procesorów, że magistrala jest zajęta.
    ___MASTER_COMMAND jest linią sterowaną przez procesor główny i jej ustawienie powoduje natychmiastowe przejście pozostałych procesorów w tryb RX.

    Ma ktoś lepszy pomysł ?
  • #7 2384910
    markcomp77
    Poziom 13  
    Posty: 78
    Pomógł: 2
    Ocena: 3
    ko_rex napisał:
    Hmmm a co od strony użytkownika? Planujecie jakiś specjalny soft to programowania tego sterownika? No bo jakoś uzytkownik musi sobie tą klapkę od kurnika zaimplementować.


    jedna platforma - uprości... ułatwi ładowanie programu (np. SAM-BA przez USB dla atmelowego at91sam7x) i debugowanie JTAG

    ko_rex napisał:
    Różnorodność procesorów...no obniża koszty...ale czy aby na pewno? Czas i wysiłek na opracowanie kilku platform chyba jednak źle się odbija na dopracowaniu projektu.

    zgadzam się - i głosuję za jedną platformą... najlepiej ARM
    zapewne albo Philips lpc21xxx albo at91sam7xxx
  • #8 2384950
    MirekCz
    Poziom 35  
    Posty: 2220
    Pomógł: 330
    Ocena: 62
    Ja mam takie pytanie, jakie funkcje miałby posiadać taki sterownik?

    Procesor dowolnego typu (przynajmniej w płytce głównej) mija się chyba z celem.

    Są dwa główne powody:
    1.Wkład pracy... jak każdy zacznie pracować na innym procesorze to pojawią się ew. niepotrzebne problemy, poza tym nagle jest kilkakrotnie więcej pracy do zrobienia...

    2.Koszty - stosując jeden, nawet droższy, procesor można zrobić 100 płytek drukowanych, rozesłać między uczestników, kupić 100 procków itd. i koszty są względnie małe. Jak zaczniemy kombinować z różnymi procesorami, to taka możliwość hurtowego/pół-hurtowego zakupu częściowo odpadnie. Poza tym stosowanie dwóch płytek bazowych (płytka z we/wy i płytka z CPU) mija się chyba z celem.

    Ja jednak bym proponował dobrać jakiś szybki, wszechstronny procesor i wokół niego zbudować płytke główną, która samodzielnie mogłaby robić za mały sterownik (np. taki do wymienionego kórnika). Troche wyższy koszt procesora byłby rekompensowany niższą ceną zakupu elementów.

    Druga sprawa to jest ustalenie modelu komunikacji płytki głównej z innymi podzespołami.
    Do komunikacji proponowałbym raczej coś w stylu I2C - przyzwoita prędkość i powinna w zupełności wystarczyć do podłączenia kilku modułów I/O (w modułach może siedzieć jakiś tani uC z dużą ilością I/O, który tylko by przekazywał dane).

    Poza tym na ARMie mamy 2 UARTY. Jeden może być wykorzystywany do łączenia z komputerem w celu zaprogramowania, drugi do komunikacji z innymi modułami głównymi takimi jak ekran graficzny z panelem dotykowym.

    Ewentualnie jeżeli ktoś chciałby zrobić sterownik-potwora to drugiego UARTa można przerobić na rs485 z obsługą wielu urządzeń i łączyć kilka/wiele płytek głównych razem. Pytanie tylko w ilu zastosowaniach będzie potrzebne więcej niż 1 płytka główna, 1 panel graficzny i ew. 1 łącze ethernet/radiowe/whatever ?
  • #9 2385009
    hunterhouse
    Poziom 26  
    Posty: 893
    Pomógł: 84
    Ocena: 3
    bardzo ciekawy pomysł. ale mam jedną wątpliwość.
    procesor ARM + ekran LCD z panelem dotykowym + moduł sieciowy + modół wejścia wyjscia = bardzo duzo kasy

    teraz jest pytanie czy to się opłaca robić bo koszty wyniosą pewnie w sumie z 1k PLN'ów a za tę kase to mzona by juz kupić coś gotowego.
    to jest tylko moja wątpliwość.

    po drugie to bardzo mi się podoba pomysł z jakimś wspólnym dziełem ze stajni elektroda.pl
    chętnie też bym się włączył ale niestety na arm'ach sie nie znam wcale.
    ale jak by było potrzeba coś na AVR to chętnie pomoge.

    pozdrawiam

    PS Atmega128 też duzo potrafi :D
  • #10 2385029
    Teodor Otulak
    Poziom 13  
    Posty: 82
    Ocena: 2
    Sterownik z punktu widzenia użytkownika jest to skrzynka do której podłącza różne druty sterujące elementami wykonawczymi. Dla niego jest ważne aby sterownik:
    1) pracował stabilnie w każdych okolicznościach
    2) był tani

    Dla konstruktora sterownik to elementy + oprogramowanie. Dla niego ważne jest aby:
    1) Hardware było odporne na zakłócenia
    2) Dawało się łatwo adaptować
    3) Posiadało dużo gotowych bibliotek oprogramowania
    4) Było tanie

    Jaki z tego wniosek ???
    Ano po pierwsze: Mieszanie rodzajów procesorów nie ma jednak żadnego sensu. Płyka bazowa powinna zawierać:
    a) procesor AT Mega 128 ( tani i już dopracowany)
    b) zasilacz
    c) we-wy cyfrowe o poziomie TTL
    d) przekaźniki wyjściowe na 230V
    e) We analogowe 0-10V
    f) Wy analogowe 0-0 V
    g) Złącze do wyświetlaczy LCD:
    - 2 x 16 linii + klawiatura
    - 320x240 punktów graficzny + touchpad
    h) mieć na pokładzie RTC z podtrzymaniem bateryjnym
    i) na płytce powinny być jeszcze dwa inne sloty na karty rozszerzające
    j) uproszczona komunikacja na SPI
    k) bootloder na RSie z Max232 do PC
    i) RS485 do połączeń na większe odległości

    Powyższe wyposażenie pozwala praktycznie na realizację sterowania dowolnym procesem.

    Teraz należałoby zadać sobie pytanie do czego taki sterownik może się przydać ??? Od tego w dużej mierze zależy co tak naprawdę należałoby w nim zaimplementować.
  • #11 2385041
    markcomp77
    Poziom 13  
    Posty: 78
    Pomógł: 2
    Ocena: 3
    hunterhouse napisał:
    bardzo ciekawy pomysł. ale mam jedną wątpliwość.
    procesor ARM + ekran LCD z panelem dotykowym + moduł sieciowy + modół wejścia wyjscia = bardzo duzo kasy

    zasadnicza część projektu to płyta procesora wraz z podstawowymi peryferiami... zewnętrza typu LCD - to opcja...

    hunterhouse napisał:
    teraz jest pytanie czy to się opłaca robić bo koszty wyniosą pewnie w sumie z 1k PLN'ów a za tę kase to mzona by juz kupić coś gotowego.
    to jest tylko moja wątpliwość.

    sama płyta procesora - wyniesie mniej...

    hunterhouse napisał:
    ...chętnie też bym się włączył ale niestety na arm'ach sie nie znam wcale.

    ależ to bardzo dobra okazja aby wreszcie się ARMów nauczyć ;)
  • #12 2385063
    hunterhouse
    Poziom 26  
    Posty: 893
    Pomógł: 84
    Ocena: 3
    markcomp77 napisał:
    hunterhouse napisał:
    ...chętnie też bym się włączył ale niestety na arm'ach sie nie znam wcale.

    ależ to bardzo dobra okazja aby wreszcie się ARMów nauczyć ;)


    no może i warto sie tego nauczyć, już nawet o tym myśle i troche czytałem ale żeby projekt był udany to raczej powinien być tworzny przez osoby z jakim doswiadczeniem.

    jak sie zdecydujecie na Atmega to sie może przydam

    ADD:

    A teraz drugie pytanie. bo w sumie elektronika to pikuś ale najtrudniejsz eedzie zbudowanie jakiś sensownego oprogramowania na PC. czy ma to być tylko zestaw bibliotek w c czy ma to być jakis kompilator i całe studio??
    jeśli miało by to być na AVR i mieć duzo popularność to trzeba by też napisać procedurki w bacomie.
  • #13 2385154
    MirekCz
    Poziom 35  
    Posty: 2220
    Pomógł: 330
    Ocena: 62
    Teodor:Jedno pytanko.. po co wyjście na panel 320x240 z ekranem dotykowym?
    Jak często jest coś takiego stosowane?
    No i najważniejsze... obsługa tego chyba by zjadła całą/większość mocy atmelka (chyba, że masz na myśli jakiś konkretny panel z własną pamięcią wew i procesorem obsługującym? link do dokumentacji?)

    Jeżeli nie ma jakiegoś gotowego modułu LCD z własną pamięcią to zdecydowanie zostawiłbym to do podłączenia jako komponent zewnętrzny z dedykowanym procesorem i połączeniem po rs232/485

    Może dobrym pomysłem byłoby przygotowanie na płytce głównej gniazda na dodatkową pamięc I2C/SPI typu fram - http://www.tme.pl/katalog/index.phtml?tme_ses...vpj8r9pil3m&sid=&f_szukaj=prom&f_radio=&idp=1
    Mogłyby z powodzeniem być używane jako pamięc operacyjna i dodatkowo jest to pamięc nie ulotna, więc w razie resetu można wrócić do poprzedniego stanu pracy (jeżeli nastąpił tylko krótki reset) lub wejść w bezpieczny stan wyjść, jeżeli prądu nie było dłużej
  • #14 2385160
    Teodor Otulak
    Poziom 13  
    Posty: 82
    Ocena: 2
    W środowisku GNU - WinAVR.
    Osobiście nie jestem zwolennikiem:
    a) wynalazków typu BASCOM - jest nieprzewidywalne
    b) skrobania w assemblerze - nikt oprócz Twórcy ( w chwili tworzenia) nie wie jak to działa

    Tak więc jedyną sensowną sugestią jest C. Aplikacje napisane w tym języku są przenośne, tak więc przy zmianie typu procesora wystarczy dostosować do jego specyfiki.

    Jako że sterownik ma być GNU to i programowany powinien być w dobrze się rozwijającym środowisku GNU, a takim bez wątpienia jest WinAvr.

    Dodano po 6 [minuty]:

    Po to aby nie trzeba było do każdej specyficznej aplikacji robić odzielnego front panelu z przyciskami. Wystarczy zmiana oprogramowania, aby użytkownik miał do dyspozycji takie przyciski, suwaki i potencjometry itd. jakich potrzebuje w danym konkretnym zastosowaniu.
    Jeżeli chodzi o obsługę tego, to jest prosta i wcale nie zżera dużo pamieci. O ile dobrze pamiętam, to oprogramowanie które robiłem jakiś czas temu, miało 11 ekranów menu i zeżarło razem z innymi dodatkami coś koło 67kB. Czyli toche ponad połowę pamięci ATMegi128. A było tam praktycznie wszystko, od flashów 1Mb po dallasy DS1820S. Tak więc procesor ma duuuży zapas :-)
  • #15 2385198
    metalex
    Poziom 14  
    Posty: 145
    Pomógł: 7
    Ocena: 26
    zapisuję się do projektu bardzo chętnie pomogę
  • #16 2385227
    MirekCz
    Poziom 35  
    Posty: 2220
    Pomógł: 330
    Ocena: 62
    Teodor:
    Napisz linka do tego panelu, chciałbym poznać jego datasheet no i mógłbyś podać jego cenę.
    Oprogramowaniem graficznym takiego panelu mógłbym się zająć, mam w tym duże doświadczenie więc możnaby porobić wszystko włącznie z wykresami i innymi pierdołami - co kto lubi.

    Co do programowania, no to chyba jedyne rozsądne rozwiązanie to tak jak podawał Teodor - język C + zestaw funkcji pomocniczych odpowiadających za oprogramowanie płytki głównej i dołączonych modułów.

    A co do pamięci, to chodziło mi o pamięć operacyjną a nie flash... atmega nie ma za dużo pamięci i tutaj fram byłby dobrym dodatkiem, no i dodatkowy bonus w postaci zachowania danych mimo resetu i możliwości kontynuowania pracy.
    Poza tym ta pamięc mogłaby być przylutowywana do płytki wg. potrzeb, więc wystarczy wyprowadzić kilka wyjść do obudowy so-8 i zadanie wykonane.

    Jest jeszcze jeden element, nie wiem czy przydatny - komunikaty audio?
    Wykorzystuje się coś takiego od czasu do czasu przy sterownikach?
    Można to łatwo zrobić za pomocą jednego-dwóch pinów w mikroprocesorze i kilku-kilkunastu kb pamięci flash na przechowywanie danych ( wystarczy na zapis kilku-kilkunastu sekund dźwięku typu głos ludzki)
  • #17 2385350
    Teodor Otulak
    Poziom 13  
    Posty: 82
    Ocena: 2
    W najbliższym czasie opublikuję w internecie schematy, pytki i źródła oprogramowania dla maszyny do straszenia ptaków wędrownych. Odtwarza ona dźwięki audio. Do tego jest oprogramowanie na PC umożliwiające ich wgrywanie.

    Nie jestem przekonany do pamięci FRAM w obudowie 8 pinowej. Przyczyna jest prosta- będzie ona zamulać pracę systemu. Jeżeli w takim RAMIE będą dane to ich odczyt ma się nijak do odczytu z normalnego RAMU. W praktyce ATMega128 potrzebuje zewnętrznego ramu dopiero przy stosowaniu RTOSA dużego kalibru. Te 8kB ramu które ma w sobie jest naprawdę optymalnie wykorzystywane przez GCC na różne zmienne. Jeżeli zachodzi koniecznośc przechowywania danych strumieniowych, to najprościej to zrobić stosując kawałek twardego dysku lub Flasha (IDE). Jeżeli są potrzebne duże ilości zmiennych o krótkim czasie dostępu, to doczepia się RAM. Tu uwaga: jak wykazuje praktyka, musi to być RAM o odpowiedni okrótkim czasie dostępu, bo wbrew pozorom, ATMega 128 pracujący na 16 MHz ma bardzo duże wymagania czasowe dla RAMu.
  • #18 2385416
    hunterhouse
    Poziom 26  
    Posty: 893
    Pomógł: 84
    Ocena: 3
    Teodor Otulak napisał:
    Te 8kB ramu które ma w sobie jest naprawdę optymalnie wykorzystywane przez GCC na różne zmienne. Jeżeli zachodzi koniecznośc przechowywania danych strumieniowych, to najprościej to zrobić stosując kawałek twardego dysku lub Flasha (IDE). Jeżeli są potrzebne duże ilości zmiennych o krótkim czasie dostępu, to doczepia się RAM. Tu uwaga: jak wykazuje praktyka, musi to być RAM o odpowiedni okrótkim czasie dostępu, bo wbrew pozorom, ATMega 128 pracujący na 16 MHz ma bardzo duże wymagania czasowe dla RAMu.

    Atmega128 ma 4kB ram(no chyba że liczysz z epromem) . a co do ramu to nigdy za wiele wiec zewnętrzny ram powienien być, można go zrobić modułowo.
    PS ja dałem do atmega128 zawnętrzny ram 70ns i zwykły zatrzask z seri hc i i śmiga na 16 Mhz chociaż w sumie nie powinno.
  • #19 2385572
    ko_rex
    Poziom 19  
    Posty: 253
    Pomógł: 38
    Ocena: 2
    Teodor Otulak napisał:

    Płyka bazowa powinna zawierać:
    a) procesor AT Mega 128 ( tani i już dopracowany)
    b) zasilacz
    c) we-wy cyfrowe o poziomie TTL
    d) przekaźniki wyjściowe na 230V
    e) We analogowe 0-10V
    f) Wy analogowe 0-0 V
    g) Złącze do wyświetlaczy LCD:
    - 2 x 16 linii + klawiatura
    - 320x240 punktów graficzny + touchpad
    h) mieć na pokładzie RTC z podtrzymaniem bateryjnym
    i) na płytce powinny być jeszcze dwa inne sloty na karty rozszerzające
    j) uproszczona komunikacja na SPI
    k) bootloder na RSie z Max232 do PC
    i) RS485 do połączeń na większe odległości

    Powyższe wyposażenie pozwala praktycznie na realizację sterowania dowolnym procesem.

    Czy to są założenia projektowe?
    Myślę, że są odpowiednio przemyślane i podparte długoletnim doświadczaniem. Jednak... jakie są jeszce argumenty, żeby nie używać jednak ARM? Sterownik byłby szybszy i odpada problem z ramem, bo za 35 zł mamy kostkę z 32kB SRAM i do tego bogatsze peryferia (np. USB).

    Jeśli zostajemy jednak przy mega128, to zawsze można zostawić miejsce na zewn. RAM (nawet w DIPie, choć to tragedia powierzchniowa jest).
    Magistrala 485 to chyba konieczność (jednym z założeń jest odporność na zakłócenia), a z szybkością jej też nie ma problemu, można ją mocno pogonić i bez problemu umieszczać odległe moduły I/O. Własnie... moduły można (trzeba!) opracować kilka modułów z wejściami ceyfrowymi lub/i analogowymi - jakieś małe uK na pokładzie z prostym niezawodnym softem. yyyyyyyyy zapomniałem co jeszcze...

    Jak mam rozumieć sprawę programowania? Mamy bootloader w sterowniku, a użykownik pisze sobei soft na mega128 używając odpowiednich bibliotek stworzonych przez nas? Czy to aby nie jest nasjłabsze ogniwo? Jak można w ten sposób zapewnić w miarę bezpieczne zachowanie sterownika?

    A może ATmega2560 ?
  • #20 2385723
    markcomp77
    Poziom 13  
    Posty: 78
    Pomógł: 2
    Ocena: 3
    Czym jest spowodowany brak akceptacji ARM ?
    Ja odnoszę wrażenie, iż wybór AVR spowoduje problemy... np. przy aplikacjach... przetwarzaniu video - budując taki IP-WebCam :(
    http://212.254.22.36:8080/
    http://forum.mikrokontrolery.net/viewtopic.php?t=392

    Dlaczego AVR ?
    bo większość z zabierających głos tak dobrze go już zna?
    przecież to nie jest projekt komercyjny - "szybko i tanio" ;)
    może być trochę wolniej... a w naszym dobrze rozumianym interesie jest się nauczyć się ARMa - ja na to liczę...
    aspekt edukacyjny projektów open source (hardware) to podstawa...
  • #21 2385924
    MirekCz
    Poziom 35  
    Posty: 2220
    Pomógł: 330
    Ocena: 62
    markcomp... jeżeli zbudujesz takiego webcama, to czy tak nie wrzucisz tego na procka będącego na płycie głównej, bo o obsłudze programu głównego mógłbyś wtedy zapomnieć.

    A moduł z kamerą i analizą obrazu opartą na armie możesz podłączyc pod rs485 i stosować jako "dodatkowy czujnik". AVR na płycie głównej w tym momencie niczemu nie przeszkadza, bo on tylko dowodzi tym ustrojstwem.
  • #22 2386057
    hunterhouse
    Poziom 26  
    Posty: 893
    Pomógł: 84
    Ocena: 3
    wydaje mi się że narazie powiniśmy zacząć od AVR a jednego powodu. AVR wszszycy znają i mają do niego dużo sprzętu i pogramów i narzędzi i doświadczenia.
    a kiedy cały system będzie gotowy można przerobić modół z CPU na ARM'a i wtedy tylko zmienić biblioteki a reszta systemu zostanie.
    lepiej robić coś małymi kroczkami bo jak weżmiesz za duzy krok to ze schodów spadniesz i nic nie wyjdze.
  • #23 2386418
    silkon
    Poziom 12  
    Posty: 26
    Ocena: 22
    Cześć Wszystkim

    Pomysł bardzo mi się podoba !

    Ze swojej strony proponuję aby uwzględnić w "genach" projektu
    jeszcze jedną opcję interfejsu : Ethernet.

    Najlepiej jako opcjonalny moduł.

    Pozdrawiam
  • #24 2386577
    Teodor Otulak
    Poziom 13  
    Posty: 82
    Ocena: 2
    Zaczniemy od najważniejszego - wyboru obudowy. Jak wiadomo, jest to podstawowy problem wszelakiej "małej" elektroniki. W zasadzie wybór jest niewielki... Wydaje mi się, że optymalna będzie obudowa na szynę DIN, ponieważ:
    1) jest bardzo tania
    2) zapewnia wentylację
    3) umożliwia budowę systemu rozproszonego, w którym każdy blok funkcjonalny znajdowałby się we własnej obudowie nawet bardzo oddalonej

    W przypadku obudowy na szynę DIN kluczowa staje się sprawa zasilania, nie zbyt wiele miejsca na pakowanie tradycyjnych transformatorów, proponuję zasilacz impulsowy na bazie TOP-SWICHA. Wychodzi to finansowo dokładnie tak samo jak transformator+prostownik+stailizatory, a daje większą moc i dwa napięcia +12 i +5 bez problemu. A jeszcze lepiej, to po prostu zastosować zewnętrzny zasilacz DC, typowy dla automatyki czyli na 24V. Wtedy w sterowniku wystarczy umieścić dwa stabilizatory impulsowe, co jest dużo prostsze i zajmuje najmniej miejsca.

    Tak się złożyło, że zostało mi sporo uniwersalnych klawiatur do wyświetlacza 2x16 właśnie na szynę DIN. Są one od jakiegoś projektu zdalnego manipulatora sprzed kilku lat, nawet nie bardzo pamiętam o co w nim chodziło... Ważne, że sąto przody na szynę DIN i są dostępne od ręki :-) Jest tam bodaj 9 przycisków funkcyjnych, rozmieszczonych dookoła wyświetlacza. Może to się przyda ?

    Projekty !!!
    Acha, jeśli chodzi o temat postu, to należy zauważyć, że projektując coś w grupie, trzeba się posługiwać tym samym oprogramowaniem do schematów i PCB. W tym temacie mam dwie propozycje:
    1) EAGLE - bo jest wersja freeware, co prawda daje tylko bardzo małe płytki PCB, ale schematy można rysować dowolnie skomplikowane.
    2) DiPTrace.PL - jest po polsku i w wersji edukacyjnej nie ma ograniczenia czasowego.

    Ja osobiście projektuję w EAGLU 4.17, chociaż jestem dystrybutorem DipTrace na Polskę i autorem spolszczenia w jednej osobie. W przypadku jednak tego sterownika, jestem skłonny przesiąść się na DipTrace.PL z prostej przyczyny: w ostatnim roku wiele placówek dydaktycznych rozpoczęło nauczanie DipTrace jako narzędzia do projektowania, bo jest po polsku i jest tanie. Tak więc jeżeli nasz sterownik miałby mieć walory edukacyjne, do dobrze by było aby schematy i płytki mógł sobie wykonać każdy. Unifikacja oprogramowania jest o tyle ważna, że każdy kolejny konstruktor może rozwijać dzieło od momentu w którym zostało ono przerwane, a nie wklepywać wszystko od nowa. Osobom, które zaangażują się w nasz projekt czynem a nie tylko słowem, zapewnię licencję użytkownika na DipTrace.PL taką samą jaką otrzymują placówki oświatowe. Zobaczcie o czym mówię: www.diptrace.pl
  • #25 2386624
    hunterhouse
    Poziom 26  
    Posty: 893
    Pomógł: 84
    Ocena: 3
    zasilanie - wydaje mi się że lepiej było by dać 24V z zewnątrz i stabilizator impulsowy (mam miłe doświadczenie z LM2576. 3,3V lub 5V lub 12V i 3A wiec powinno wystarczyć). nigdy nie lubiłem robić 220V w jednej obudowie z uP. i to niz z powodu że zakłócenia lub coś tylko juz kilka razy przy projektowaniu zostałem porażony. (nic przyjemnego :(( )

    wydaje mi się że układ powinien byc maxymalnie prosty bo co proste to niezawodne.

    to jaki w końcu procesor ??? ATMEGA128 czy coś innego.
  • #26 2386858
    MirekCz
    Poziom 35  
    Posty: 2220
    Pomógł: 330
    Ocena: 62
    Osobiście stosuje darmową wersje eagle, ale jeżeli 100x80 nie wystarczy to można się pobawić diptrace, szczególnie że projekt płytki to w głównej mierze będzie rozwijać jedna osoba, a inne będą raczej mówiły swoje uwagi... inaczej byśmy chyba do niczego nie doszli =)

    Teodor:może jedna uwaga.. jak już mówimy o konkretnym sprzęcie, to podawaj prosze namiary gdzie coś takiego mozna dostać/do dokumentacji. W ten sposób wszyscy możemy składać to samo z tych samych części, co bardzo ułatwi prace projektowe.
  • #27 2387073
    markcomp77
    Poziom 13  
    Posty: 78
    Pomógł: 2
    Ocena: 3
    jaki CAD do PCB ?

    KiCAD - do rozważań programu do PCB można dorzucić KiCADa
    http://www.lis.inpg.fr/realise_au_lis/kicad/
    jest GPL... a możliwe, że ktoś dorobić do niego komunikaty no polsku... jest równocześnie na Win32 i Linuksa (podobnie jak Eagle)

    Eagle wszyscy znamy... wiadomo co jest wart :)

    DipTrace - właśnie próbuję zrobić jakiś projekt... program jest całkiem fajny - choć troszeczkę inaczej idzie robota jak Eagle... częściej trzeba dorabiać coś w bibliotekach... wersja za darmo pozwala zrobić większą pcb niż Eagle - ograniczenie jest na ilość otworów (czy jakoś tak).. pracuję na wersji ściągniętej z
    http://diptrace.com/
    program warty rozważenie - cena jest do przełknięcia... bardziej niż Eagle
  • #28 2387129
    McRancor
    VIP Zasłużony dla elektroda
    Posty: 5326
    Pomógł: 479
    Ocena: 123
    Myśle że zamiast budować od razu panele masa*masa pikseli, powinniśmy najpierw zbudować prosty moduł, niech będzie na medze128, na początek bez ramu. Do tego kilka wejść i wyjść.

    Najtrudniej dojść do najprostrzego, zostawmy interfejs RS485 do kumunikacji, gdy uda się już opracować jakiś system, zajmiemy się wyświetlaczem, matrycami dotykowymi, ethernetami i innymi modułami. Na początek cokolwiek.

    Proponuje moduł - 8 wejść analogowych, 8 cyfrowych, 8 wyjść przekaźnikowych. DO tego niech będzie LCD i odpowiednia ilość przycisków.

    Gdy uda się dopracować i uruchomić taki sterownik, będziemy się martwić ile dołożyć ramu i jaka przekątna wyświetlacza.

    Jestem za Eaglem, znam go najlepiej i nawet lubie ;)
  • #29 2387397
    hunterhouse
    Poziom 26  
    Posty: 893
    Pomógł: 84
    Ocena: 3
    no to dobra.
    wyjścia przekaźnikowe:. przekaźniki można by sterować przez układu ULN2803A http://www.elenota.pl/d.php?id=62999&pdf=1536 bezpośrednio z portu mikrokontrolera.

    wejścia cyfrowe (standard 24V ??) trzeba by dać przez optoizolację.
    w tme znalazłem np 4N26 .
    na wejściu należało by dać rezystor ograniczający prąd i diodę zenera na 5,1V szeregowo z diodą w optoizolatorze żeby niskie napięcie nie powodowały włączenia tranzystora.
    foto tranzystor dać bezpośrednio na wejście uP i podciągać je do +5V prze z rezystor.

    wejścia analogowe ??? tu trzeba by albo dać zewnętrzny przetwornik albo skorzystać z wbudowanego w ATmege.
    układ wejściowy. np. dzielnik napięcie i diodę zenera za dzielnikiem aby obciąć nadmiar napięcia w przypadku awarii.
    dobrze by było dać też transile (albo jakoś tak to się nazywa) aby zabezpieczyć się przed impulsami wysokiego napięcia.

    należało by sie zastanowić czy nie trzeba by zastosować jakiegoś rozszeżenia pinów mikrokontrolera np przez I\O na I2C
    Ja tak to widzę.

    Natomiast nigdy nie stosowałem RS-485 i nie bardzo wiem z czym to się je. Czy można wykorzystać do tego Max’a i sprzętowy UART ???

    ADD:
    co do programatora to mam taki dziwny pomysł. zamiast dawać bootloader który będzie wgrywał program do uP to mozna zastosować przerobiony AVR-ISP ze strony http://www.mikrocontroller-projekte.de/
    oczywiście dać max232 zamiast tego dziwactwa do komunikacji przez UART. stosuje ten programator juz od długiego czasu i naprawde szybko programuje uP. w poruwnaniu z STK200 pewnie z 10razy szybszy.
  • #30 2387472
    silkon
    Poziom 12  
    Posty: 26
    Ocena: 22
    A co powiecie na "kanapkę" :

    płytka z I/O , zasilaniem, RS-485 i w nią wpinana
    płytka z procesorem, pamięcią, interfejsem do LCD i klawiatury.

    To może umożliwić wykonanie następnej wersji z innym
    procesorem ( ARM ) , większą pamięcią itp.

Podsumowanie tematu

✨ Dyskusja dotyczy projektu otwartego, modułowego sterownika przemysłowego o nazwie "GNUMASTER" na licencji GNU, mającego na celu stworzenie taniego, stabilnego i skalowalnego urządzenia z pełną dokumentacją i zgodnością z normami CE. Proponowany hardware oparty jest głównie na mikrokontrolerze Atmega128 z możliwością rozszerzeń, w tym obsługą RS-485, RS-232, wyjściami przekaźnikowymi, wejściami analogowymi i cyfrowymi, a także opcjonalnym wyświetlaczem LCD z panelem dotykowym. Dyskutowano o wyborze procesora – dominująca opinia wskazuje na AVR (Atmega128) jako bazę ze względu na dostępność narzędzi i doświadczenie użytkowników, choć pojawiły się propozycje zastosowania ARM dla większej mocy i pamięci. Projekt ma być modułowy, z płytką bazową i wymiennymi modułami CPU, co umożliwi elastyczność i rozbudowę.

W zakresie oprogramowania podkreślano konieczność użycia języka C dla przenośności i stabilności, odrzucając BASCOM i assembler jako mniej przewidywalne. Proponowano stworzenie przyjaznego środowiska programistycznego, w tym edytora graficznego do programowania w języku drabinkowym (Ladder Logic) lub podobnym, z możliwością generowania kodu C lub maszynowego. Dyskutowano także o koncepcji maszyny wirtualnej jako warstwy abstrakcji, która umożliwiłaby niezależność od sprzętu i ułatwiła programowanie, choć pojawiły się obawy o wydajność i złożoność takiego rozwiązania.

Poruszono kwestie zasilania (preferencje dla 24V DC z impulsowymi stabilizatorami), izolacji galwanicznej wejść i wyjść, zabezpieczeń przeciwzakłóceniowych (transile, diody Schottky’ego), a także standardów napięć wejściowych i wyjściowych (24V DC, 230V AC dla przekaźników). Dyskutowano o konieczności modularności, elastycznej magistrali komunikacyjnej (RS-485 z dodatkowymi liniami BUSY i MASTER_COMMAND) oraz oprogramowaniu bootloadera i bibliotekach ułatwiających programowanie i debugowanie.

Wielu uczestników podkreślało znaczenie koordynacji projektu, podziału pracy i wykorzystania narzędzi CAD (Eagle, KiCAD, DipTrace) do projektowania PCB. Zwracano uwagę na potrzebę dokumentacji, testów i zgodności z normami przemysłowymi. Projekt ma charakter społecznościowy, z otwartym forum dyskusyjnym i repozytorium materiałów, choć pojawiły się problemy z funkcjonowaniem forum i organizacją pracy zespołu.

W dyskusji pojawiły się także przykłady istniejących sterowników przemysłowych (np. Relpol NEED, Siemens S7-224XP) oraz modułów komunikacyjnych (Propox, Charon2), które stanowią punkt odniesienia dla projektu. Podkreślano, że sukces projektu zależy w dużej mierze od jakości oprogramowania i łatwości programowania dla użytkowników niebędących programistami, co może wymagać stworzenia intuicyjnych narzędzi i środowisk graficznych.

Podsumowując, projekt GNUMASTER ma na celu stworzenie otwartego, taniego i elastycznego sterownika przemysłowego z modułową budową, opartym na Atmedze128, z komunikacją RS-485, możliwością rozbudowy i przyjaznym środowiskiem programistycznym, z naciskiem na stabilność, skalowalność i dostępność dla hobbystów oraz małych firm.
Wygenerowane przez model językowy.
REKLAMA