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

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

Teodor Otulak 15 Mar 2006 11:03 18343 108
  • #61
    Smoczy
    Poziom 18  
    Nie chcę nikogo urazić tym porównaniem, ale jeżeli inni kradną to czy my też musimy? i czy uważa Pan, że ktoś kto stworzył np. środowisko GCC, z którego notabene sam Pan kożysta, zrobił to w 5 min?, a przecierz nie pobrał nikt od Pana "punktów" za to, że Pan ściągnął to z sieci?, może się myle. Jeżeli mamy pracować "Społecznie" to powinniśmy to robić społecznie, czyli ZA DARMO, za SATYSFAKCE(która jest bezpostaciowa, bo ponoć jest to odczucie psychiczne), za FRIKO, dokładając do tego swój czas, zdolności i możliwości intelektualne, sprzętowe i inne. Jednak Pana postawa nasuwa pewne pytania, których nie chce tutaj przedstawiać bo mogę być posądzony o działanie wywrotowe. Nie jest moim celem rozwalenie całej ideii GNUMASTER, którą popieram, jak napisałem wyżej, tylko rzeczywiste podejście GNU do projektu.
    Pozdrawiam.
  • Relpol przekaźniki
  • #62
    crazy_phisic
    VIP Zasłużony dla elektroda
    Hmm potyczka słowna o 2 punkty ..... kolego Smoczy napisanie powyższych postów przyniosło ci zysk 2 punktowy, widze że to straszna cena jaką trzeba zapłacić za wiedze innych, ideologia GNU ideologią ale zwykłe uszanowanie pracy innych pozwala na czerpanie z niej satysfakcji...
    Wracając do tematu ... widze spore zastosowanie sterownika, nawet w najprostrzej formie w wiekszości doświadczeń fizycznych, gdzie (w wiekszości wypadków) większość pomiarów i nastwaień dokonywana jest ręcznie
  • #63
    marqa
    Poziom 12  
    Witam, pomysł GNUMastera bardzo ciekawy, chciałbym dorzucić zatem swoje trzy grosze.

    Co do software'oewj części, narzuca mi się pomysł stworzenia prostej maszyny wirtualnej postawionej na platformie. Pozwoliłoby to na uniezależnienie się w dużym stopniu od sprzętu (procesor, liczba we/wy itp.). Rozwiązało by w dużej mierze problem z programowaniem. W przypadku użycia mieszanki kompilator + bootloader - istniałoby ryzyko uszkodzenia - możliwy bezpośredni dostęp do portów itp. Jeśli chodzi o środowisko programowania łatwo dałoby się stworzyć zarówno środowisko graficzne jak i język programowania np. podzbiór "C" dla bardziej wymagających.

    Zalety te (jak mniemam) niestety trzeba by okupić wydajnością - co w wielu przypadkach nie byłoby wielkim problemem.
  • Relpol przekaźniki
  • #64
    marekpast
    Poziom 11  
    ...pomysł stworzenia prostej maszyny wirtualnej postawionej na platformie. Pozwoliłoby to na uniezależnienie się w dużym stopniu od sprzętu (procesor, liczba we/wy itp.)...

    Witam. Proszę powiedz jak uniezależniłoby w dużym stopniu od sprzętu, wyobraź sobie że np koło siłownika hydraulicznego albo silnika krokowego zamiast małego sterownika, stawiasz cały komputer ;)

    ...Jeśli chodzi o środowisko programowania łatwo dałoby się stworzyć zarówno środowisko graficzne jak i język programowania np. podzbiór "C" dla bardziej wymagających. ...

    I słusznie, przy programowaniu można tak zrobić, nawet przetestować na symulatorze, ale w efekcie końcowym trzeba program załadować do sterownika, potem trzeba mieć z nim komunikację a on ma wykonać to co zostało mu zadane.
    Pozdrawiam Marek
  • #65
    marqa
    Poziom 12  
    Witam:D
    Powyższe wypociny to tylko luźne rozważania. Co do tej maszynki wirtualnej :) może byłem za mało konkretny. Ta maszynka to miałoby by coś w stylu Java VM, tyle, że dużo prostsze. Wykonywała by wirtualny kod maszynowy - generowany przez środowisko instalowane na PC-cie, potem ładowane poprzez np RS485 do sterownika (myślę że, bez problemu mógłby byc zapisany w wewnętrznym flashu procka).
    Od tego momentu sterownik stałby się autonomicznym urządzeniem wykonującym meta-kod. Pecet nie byłby potrzebny do jego działania.
    Bez znaczenia czy mamy do czynienia z siłownikiem czy silnikiem krokowym, wszystko zależy od programu.
    [/code]

    Na załączonym obrazku jest skrobnięta uproszczona architektura takiego softu - oczywiście do przemyślenia. W skrócie:
    HAL stanowi warstwę pośrednią między sprzętem a maszynką :). Byłby zależny oczywiście od typu procesora, ilości i typu wejśc, wyjsc itp. W mniejszym stopniu uzależnienie to tyczyłoby się VM - co do meta kodu byłby taki sam bez względu na procek - mowa oczywiście o kodzie który ma robic konkretną rzecz (np. sterowanie ww siłownikiem) - czy mamy sterownik z ARMem czy ATMega, tworzymy kod w jednym środowisku ( "GNU Master GUI" :) ), ładujemy go do sterownika (do czego służyc miałby BootLoader) np po RS485, i... gotowe.
    Można też dodac pewne opcje do debugowania tegoż kodu - ale to juz wodotrysk :)

    Wydaje mi się, że coś takiego możnaby już postawic na wspomnianym ATMega128. ARM byłby pewnie lepszy :)

    Sie rozpisałem....
    Mam nadzieję że przybliżyłem swoją koncepcję - nie jest pewnie bez wad - chciałem tylko podzieli sie produktem mojej zwyrodniałej wyobraźni :) software'owca praktyka, hardware'owca hobbysty.
  • #66
    marekpast
    Poziom 11  
    Cytat:
    ...- chciałem tylko podzieli sie produktem mojej zwyrodniałej wyobraźni software'owca praktyka, hardware'owca hobbysty....


    Witam. Wybujała wyobraźnia wcale nie jest przeszkodą, a wręcz przeciwnie.
    Przeczytaj pomysł Teodora Otulaka na gnumaster.pl, podziel sie swoimi pomysłami, spróbuj zrealizować pomysł ....
    Idea GNU w znacznej swej części opiera sie właśnie na hobbystach-entuzjastach.
    Pozdrawia również hobbysta Marek
  • #67
    marek_Łódź
    Poziom 36  
    rezonator napisał:
    jeszcze zróbcie "kit" i sprzedawajcie w sklepach elektronicznych. Najlepiej odebrać pracę i mozliwość zarobku komu się da.

    Zrobienie prostego i TANIEGO mikrosterownika PLC zapewniającego niezawodność porównywalną np z SIMATICem nie jest zadaniem specjalnie skomplikowanym (uwzględniając również soft). Sterownik taki kosztując poniżej 50-100 PLN (zależnie od mocy procesora i interfejsów) mógłby skutecznie wyprzeć z wielu zastosowań droższe sterowniczki (np. LOGO, a może i coś większego), a ze względu na szerszy zasięg (niska cena) mógłby stworzyć nowe nisze zastosowań (np pracownie fizyczne czy chemiczne w szkołach, indywidualne aplikacje - "inteligentny dom").

    Pomysł stworzenia kita nie jest głupi. Przy niskiej cenie mogłoby TO być dostępne tak szeroko jak np. przekaźniki. Nadal twierdzę, że bazą jest oprogramowanie, które pozwoliłoby w prosty sposób skonfigurować (napisać) program nawet niezbyt rozgarniętemu technikowi mechanikowi, czy rozgarniętemu uczniowi gimnazjum. Gdyby taki sterownik znalazł zastosowanie w przemyśle, wypierając gdzieniegdzie inne sterowniki - należy tylko się cieszyć, pieniążki zostaną w małych firmach i w kraju. Dodatkowo kit jest sposobem na obejście badań na deklarację zgodności CE, co jest szczególnie istotne w przypadku małych producentów i niezamożnych odbiorców.
    Zresztą przy szerszym rozpropagowaniu sterowników GNUMASTER można by pewnie znaleźć sposób na spełnienie wymogów formalnych np na CE również przy produkcji i sprzedaży jednostkowej.

    Cytat:
    GNU jest dobre ale dla odbiorców i konsumentów.
    A dla kogo ma być dobre? Wolny rynek polega na dogadzaniu konsumentom, tak aby ich najwięcej przechwycić. Jeśli się boisz, że zniknie Twoje miejsce pracy (co akurat w tej branży jest nieprawdopodobne), to weź się za coś innego (np. sprzedaż pietruszki) albo przenieś na białą ruś.

    Z własnego doświadczenia mogę stwierdzić, że najwięcej satysfakcji mam z instalacji, w których udało mi się namówić klienta na rezygnację z rozwiązań drogich i powszechnie uważanych za standardy na rzecz , wielokrotnie tańszych rozwiązań dedykowanych mikrokontrolerów, które często dają również znacznie lepszy efekt techniczny. Sterownik GNUMASTER jest szansą na realizację tej filozofii na skalę masową (no, zapędziłem się).

    Jeszcze tego nie napisałem, więc może już pora - uważam temat GNUMASTER za najlepszy i najciekawszy pomysł, jaki udało mni się wyczytać na forum elektroda.pl i myślę, że wszyscy, którzy mają coś do powiedzenia w temacie powinni go wspierać swoją wiedzą i pracą (w miarę swoich możliwości). Mam nadzieję, że nie zabrzmiało to jak apel o realizację planu pięcioletniego w PRL?

    marqa napisał:
    Ta maszynka to miałoby by coś w stylu Java VM, tyle, że dużo prostsze. Wykonywała by wirtualny kod maszynowy - generowany przez środowisko instalowane na PC-cie, potem ładowane poprzez np RS485 do sterownika (myślę że, bez problemu mógłby byc zapisany w wewnętrznym flashu procka).
    A dlaczego nie JAVA? Tym bardziej, że są procesory wspomagające sprzętowo ten język włącznie z tym, że ATMEL wchodzi w ten temat. Oczywiście w układach silnie uwarunkowanych czasowo dobrze by też zrealizować wersję kompilowaną.

    Tak naprawdę sterownik tego typu powiinien być programowany w języku problemowo zorientowanym (LogicMAster, AnalogMaster, STEP) operującym blokami operacyjnymi lub konfigurowany parametrycznie przy pomocy specjalnie skonfigurowanych formularzy w skrajnym przypadku rezydujących w sterowniku, tak żeby nie trzeba było używać peceta. Tworzenie języka niskiego poziomu typu C, podzbiór C czy JAVA stwarza barierę dla przeciętnego użytkownika i ogranicza zakres zastosowań.
  • #68
    Teodor Otulak
    Poziom 12  
    Na początku, gdy przyszedł mi ten pomysł do głowy, całkowicie oczywiste było dla mnie, że ma on być programowany w C ( nawet nie w C++). Chodziło mi przy tym o jak największą przenośność kodu i łatwość jego modyfikacji. Język C nie stawia użytkownikowi żadnych barier, jedynym ograniczeniem jest jego wyobraźnia i doświadczenie !!!
    W przypadku programowania w jakichkolwiek "wyższych" językach, a na dodatek "maszynach wirtualnych" , świadomy użytkownik będzie sprowadzony do roli "męczennika" walczącego z twórcami kolejnego gniota.. Najprawdopodobniej, czytając ten tekst masz przed sobą ekran "wirtualnej maszyny". Spróbuj na tej maszynie napisać prosty program, generujący falę prostokątną na jakimś pinie portu LPT. Jeżeli masz NT,2000,XP to zobaczysz co Ci wyjdzie (bez NT DDK nawet nie zaczynaj :-))Po prostu maszyna wirtualna ogranicza możliwości użytkownika. Po co zatem tworzyć taką maszynę ??? Moim zdaniem, należy pozostać przy czystym C i jedynie zrobić przyjazne środowisko graficzne aby użytkownik mógł wybrać z pośród gotowców konkretną aplikację i ją załadować. Ten kto ma zamiar tworzyć własne aplikacje musi znać elementarz jakim jest C. A ten kto nie zna C i nie ma gotowego programu do zaladowania, będzie mógł na forum takowy sobie zamówić na drodze licytacji - kto z "wtajemniczonych" taniej mu go napisze. To tyle. Pozdrawiam !
  • #69
    marqa
    Poziom 12  
    Jeśli chodzi o automatykę i programowanie sterowników moje doświadczenie jest niewielkie więc nie będę się upierał przy swoim :)
    Mimo to jeśli chodzi o aspekt edukacyjny... to ciekawe wyzwanie :)

    Szacuneczek :D dla znawcy tematu
  • #70
    marek_Łódź
    Poziom 36  
    Teodor Otulak napisał:
    Na początku, gdy przyszedł mi ten pomysł do głowy, całkowicie oczywiste było dla mnie, że ma on być programowany w C ( nawet nie w C++). Chodziło mi przy tym o jak największą przenośność kodu i łatwość jego modyfikacji. Język C nie stawia użytkownikowi żadnych barier, jedynym ograniczeniem jest jego wyobraźnia i doświadczenie !!!

    Używanie gniota typu C, BASCOM czy asembler jest wygodne dla grupy tzw wtajemniczonych, bo pozwala stworzyć barierę, przez którą nie przedrą się ludzie nie związani z programowaniem.

    Dla normalnego, znającego dogłębnie swój problem użytkownika wybór pomiędzy tzw C czy C++ a np. takim odpowiednio skonfigurowanym i wyposażonym w odpowiednie moduły np LabView jest jednoznaczny. Żaden normalny człowiek nie będzie się uczył C po to, żeby sobie np. ustawić eksperyment. Natomiast w momencie gdy dostanie rozwiązanie intuicyjne, zrobi to w 15 minut (mam na myśli np. pracownika uczelni czy ucznia szkoły średniej przeprowadzającego jakiś eksperyment).

    Rozwiązań jest kilka, że wymienię tylko 2

    1. Wspomniane LabView z odpowiednimi modułami zapewniającymi komunikację ze sterownikiem. Piszę w tym momencie nie o konkretnym narzędziu, za które w tym przypadku trzeba płacić, ale o idei.

    2. Konfigurację sterownika można spokojnie zrealizować przy poomocy wyposażonego w odpowiednie biblioteki programu do projektowania układów elektronicznych takiego jak Protel, czy Eagle.

    W obu przypadkach tworzenie rozwiązania docelowego ma charakter intuicyjny i opiera się na połączeniu kilku elementarnych bloków z którymi można się zapoznać w kilkanascie minut. Uczenie się C czy c++ do skonfigurowania prostego sterownika jest bez sensu. Rozumiem ten Twój ból z softem. Sam też tak mam, że potrafię wytrzepać z rękawa kilka rozwiązań sprzętowych dziennie (łącznie z drukami), a oprogramowanie do tego powstaje w bólach. Ale w momencie gdy chcę stworzyć produkt najpierw stawiam się na pozycji potencjalnego użytkownika i staram się go zrozumieć. W tym przypadku C nie jest dla mnie ŻADNYM rozwiązaniem. 10% siły urządzenia cyfrowego siedzi w sprzęcie, 90% to oprogramowaniu. Chcesz dać użytkownikowi protezę, czy funkcjonujący produkt?


    ps. nadal nie wiem jak dokończyć rejestrację na forum GnuMaster.pl
  • #71
    LordBlick
    VIP Zasłużony dla elektroda
    Nie wierzę w bajki o przenośności kodu w C na mikrokontrolerach. Wielu o tym mówi, a niewielu widziało. Każda platforma ma specyficzną dla siebie nomenklaturę portów/rejestrów. Śmiem nawet twierdzić, że "przenośne" C też w pewnym stopniu ogranicza możliwości na danej platformie w stosunku do asemblera... ;)
    Oczywiście jakiś kompromis trzeba przyjąć, czy to Java, czy C, najważniejsze to doprowadzić do końca pomysł... ;) Nie ma co dorabiać legend, można w sumie stworzyć możliwości dla kazdego języka, jesli ustali się jakiś kanon programistyczny. W końcu z powodzeniem nawet w Windows można całkiem fajne programiki (tak, tak, okienkowe z WinAPI) stworzyć, pisząc zarówno w asm, jak i C, C++, VB itd.
  • #72
    marek_Łódź
    Poziom 36  
    Light-I napisał:
    Nie wierzę w bajki o przenośności kodu w C na mikrokontrolerach. Wielu o tym mówi, a niewielu widziało. Każda platforma ma specyficzną dla siebie nomenklaturę portów/rejestrów. Śmiem nawet twierdzić, że "przenośne" C też w pewnym stopniu ogranicza możliwości na danej platformie w stosunku do asemblera... ;)
    Oczywiście jakiś kompromis trzeba przyjąć, czy to Java, czy C, najważniejsze to doprowadzić do końca pomysł... ;) Nie ma co dorabiać legend, można w sumie stworzyć możliwości dla kazdego języka, jesli ustali się jakiś kanon programistyczny. W końcu z powodzeniem nawet w Windows można całkiem fajne programiki (tak, tak, okienkowe z WinAPI) stworzyć, pisząc w asm.
    Witamy kol. Daniela w temacie. Takim rozwiązaniem w miarę przenośnym jest teoretycznie JAVA, co oczywiście i tak się rozłazi na poziomie łącz zewnętrznych (np. portów). W każdym przypadku konieczne jest stworzenie elastycznych bibliotek załatwiających tę warstwę, a reszta to faktycznie sprawa fantazji twórcy. Tyle, że jedne rozwiązania będą bardziej przyjazne dla setki wybrańców, a inne dla dziesięciu tysięcy wybranych z dowolnej łapanki.

    Warto sobie uświadomić, że te rozwiązania "wyższego poziomu" będą też zrealizowane np. w C, więc zapewnią stosowny poziom przenaszalności kodu między platformami sprzętowymi, zdejmując jednocześnie z końcowego użytkownika koniecność operowania tak dziwacznym i mało efektywnym narzędziem jak C czy asembler. Zauważmy, że w tym przypadku koszt przeniesienia softu z jednej platformy na inną spada na autora sprzętu, więc rozkłada się pomiędzy użytkowników.
  • #73
    LordBlick
    VIP Zasłużony dla elektroda
    Nawet Java nie jest prostym językiem, a jej implementacja w niektórych µC trudna, lub niemożliwa. W każdym przypadku obsługujacy musi się zapoznać ze sposobem programowania, czy to bedzie wtykanie sekwencyjne liści do obudowy, machanie rękoma, czy to bedzie pisanie poleceń... nie ma co popadać w skrajności, nie da się stworzyć doskonale intuicyjnego interface, każdy człowiek jest inny i trochę inaczej odbiera otoczenie, ale to już temat z psychologii...
  • #74
    marek_Łódź
    Poziom 36  
    Light-I napisał:
    Nawet Java nie jest prostym językiem, a jej implementacja w niektórych µC trudna, lub niemożliwa. W każdym przypadku obsługujacy musi się zapoznać ze sposobem programowania, czy to bedzie wtykanie sekwencyjne liści do obudowy, machanie rękoma, czy to bedzie pisanie poleceń... nie ma co popadać w skrajności, nie da się stworzyć doskonale intuicyjnego interface, każdy człowiek jest inny i trochę inaczej odbiera otoczenie, ale to już temat z psychologii...


    To może konkretniej. Jakie jest Twoje zdanie na temat softu do projektu typu GNUMASTER, co sądzisz o

    1. Użyciu ASM z makrodefinicjami tworzącymi biblioteki do sterowania obiektem
    2. Użyciu C w analogicznej konfiguracji
    3. Zaimplementowaniu maszyny wirtualnej JAVA czy coś w podobie
    4. stworzeniu języka problemowo zorientowanego (czy grupy języków) typu np. STEP na simaticu
    5. konfigurowania układu przez interfejs graficzny (rysowanie schematów ideowych czy drabinek)
    6. Konfigurowaniu sterowania obiektem z formularzy (specyficzna forma języka typu STEP).
    7. Jakieś inne pomysły???
  • #75
    szeryf_wojciech
    Poziom 12  
    Witam

    Z mojego punktu widzenia (laika,jesli chodzi o programowanie µC) mysle, że użycie systemu takiego jak w sterownikach Simatic - STEP byłoby świetnym rozwiązaniem. Nie bardzo wiem jak wygląda to od strony programisty, ale STEP nawet dla nieco rozgarniętego człowieka jest do opanowania.

    pozdrawiam i dopinguje
    wojtek
  • #76
    LordBlick
    VIP Zasłużony dla elektroda
    Jeśli już by tworzyć coś problemowo zorientowanego, to mi najłatwiej byłoby przysiąć i zakodować to w asm, komu innemu w C itd. Sztuką byłoby stworzenie uniwersalnego portu dla każdego bardziej powszechnego języka programowania. STEP-a nie znam, "ladder-a" na S4 trochę liznąłęm w szkole, ale praktycznie nie pamiętam. Asm na AVR znam, bo był w nocie katalogowej i był dobrze wspierany przez producenta (AVRStudio)... ;)
    Po za tym GNUMASTER dla mnie jest dość egzotycznym pomysłem. Aby to doszło do skutku w rozsądnym czasie, trzeba by się zjechac w jedno miejsce na miesiąc, mając zapas gotówki na własne utrzymanie i dostęp do kilku egzemplarzy prototypu. Porozumiewanie sie poprzez forum jest zbyt czasochłonne i nieefektywne, w takim tempie efekt bedzie mozna zobaczyć za rok, może dwa, jeśliby nie w międzyczasie ze wzystkich entuzjastów pozostała garstka...
  • #77
    lbugiera
    Poziom 21  
    Myśle, że najlepszym rozwiązaniem dla użytkowników będzie język drabinkowo-podobny zamieniany przez program-kompilator z graficznym GUI na kod C. Napewno nie jest to zadanie proste do zrealizowania i jest pracochłonne, ale łączy w sobie te dwa skrajne przypadki : ucznia/studenta, który w 15 minut połączy kilka bloków lub innych drabinek i dostanie to co chce oraz zawziętego/doświadczonego speca, który z każdego sprzętu stara się wycisnąć co sie da i napisze sobie to w C (lub zmodyfikuje kod wygenerowany przez kompilator)

    Ponieważ założeniem głównym projektu jest także niezawodność to jakość tego kompilatora może tą niezawodność mocno podważyć. Mówie tutaj o tym, że wygenerowany w C kod, kompilowany na końcu przez gcc bedzie generował błędy przy bardziej wymyślnych konstrukcjach drabinek i bez znajomości C sie nie obejdzie. Także dlatego takie środowisko tłumaczące bloki/drabinki na kod C napewno nie jest łatwe do napisania.

    Ale wtedy można tez w miare łatwo zaproponować wersje GNUMASTER'a z ARM'em w roli głównej (co było też często w tym temacie podnoszone), ponieważ dużą część wszystkcih różnic pomiędzy AVR'em a ARM'em zniweluje kompilator C, który jest dostępny (WinARM). Reszte tych róznic musi wspierać program/kompilator drabinek.

    W koncepcji GNUMASTERA widać tez dużą chęć, aby był on jak najbardziej uniwersalny, wręcz o oniegraniczoncyh możliwościach. Tutaj trzeba by narysowac granice tej uniwerslaności, bo nie da się dla przykładu zrobić robota, który będzie równie dobry w ekploracji marsa i spawaniu karoseri samochodowych. Co najwyżej, o ile wogóle da się to jakoś pogodzić, to wyjdzie że taki robot będzie równie koszmarnie spawał te karoserie jak i przeszukiwał marsa ( sory za porównanie wzięte z kosmosu :) ).
    Pogodzenie elastyczności i łatwosci programowania będzie w tym wypadku trudne, ale być moze mozliwe własnie poprzez taki "kompliator drabinek". Język drabinkowy operuje na zbiorze podstawowych czynności (ustaw port, odczytaj wartość, wyśłij znak itd), więc juz w jakiś sposób ogranicza użytkownika. Dla zaawansowanych, którzy nie chcą być ograniczanie pozostaje napisać wszystko w C, a jak nawet im będzie leppiej to w asemblerze.

    Zgadzam się ze stwierdzeniem, że soft programujący sterownik jest ważniejszy niz sprzet. Bo to głównie decydował o dwóch głównych cechach elastyczności i łatwości obsługi. Ograniczenia powodowane, przez mikrokontroler, ilość i rodzaj peryferiów, przypisanie ich do konkretnych portów mikrokontrolera, ilość pamięci, szybkość IC są niczym przy stosunku elastyczność/łatwość obsługi.

    Mam nadzieje, że starczy Wam zapały na dowiezienie projektu do końca. (sam niestety do czerwca nie mam czasu na takie projekty - narazie stałem się niewolnikiem pracy dyplomowej :) )

    Będe tryzmał kciuki !!! :)

    Boogie
  • #78
    marek_Łódź
    Poziom 36  
    lbugiera napisał:
    język drabinkowo-podobny zamieniany na kod C.
    ...jako opcja. Wersja podstawowa dla przeciętnego użytkownika powinna omijać C. Wygenerowanie kodu wynikowego w C, ASM czy kodzie binarnym jest zbliżonym zadaniem i można porobić takie nakładki, natomiast dla przeciętnego nieprogramisty wędrówka przez C to wycieczka z Grójca do Warszawy przez Londyn

    lbugiera napisał:
    Ponieważ założeniem głównym projektu jest także niezawodność to jakość tego kompilatora może tą niezawodność mocno podważyć. Mówie tutaj o tym, że wygenerowany w C kod, kompilowany na końcu przez gcc bedzie generował błędy przy bardziej wymyślnych konstrukcjach drabinek i bez znajomości C sie nie obejdzie. Także dlatego takie środowisko tłumaczące bloki/drabinki na kod C napewno nie jest łatwe do napisania.
    Nie wiem, czy kiedyś robiłeś coś takiego, ale mogę zagwarantować, że dobrze zestrojony z kompilatorem zestaw makrodefinicji czy funkcji bibliotecznych zapewni niezawodność kodu nieporównywalnie wyższą od napisanego ręcznie w C czy ASM (oczywiście odpowiedzialność za to przejmują twórcy generatora-kompilatora).

    W przypadku sterownika drabinkowego można sobie wyobrazić zaimplementowanie maszyny wirtualnej napisanej w C, powiedzmy częściowo przenaszalnej pomiędzy mikrokontrolerami. Maszyna ta może być zainstalowana na gołym procesorze lub w rozbudowanym środowisku (system wielozadaniowy, sieciowy itp).

    Dalej mamy napisany na PC translator drabinek na kod pośredni z graficznym interfejsem do projektowania. Tym interfejsem może być w najprostszym przypadku np. Eagle z zestawem odpowiednich bibliotek. Taka implementacja jest stosunkowo prosta w realizacji i zapewni wysoką niezawodność uzyskanego wyniku. Po drodze robimy jeszcze asembler kodu pośredniego (GNUSTEP) oraz symulator/debuger maszyny wirtualnej na PC. W następnym etapie można zrealizować specjalizowany projektowy panel graficzny i alternatywne, spasowane ze sterownikami generatory kodu binarnego omijające kod pośredni, w celu zwiększenia efektytwności aplikacji (czas realizacji programu).
  • #79
    duzamasa
    Poziom 14  
    Teodor Otulak napisał:
    A ten kto nie zna C i nie ma gotowego programu do zaladowania, będzie mógł na forum takowy sobie zamówić na drodze licytacji - kto z "wtajemniczonych" taniej mu go napisze.

    Ale tak już jest: na necie są dostępne projekty wielu urządzeń, np. w BTC. Nie trzeba za nie płacić tylko przerysować (jednak koszt takiego urządznia wykonanego domowym sposobem wcale nie jest dużo tańszy od kupna gotowego biorąc pod uwagę wszystkie koszty). Napisać program w C też można samemu lub sobie zamówić np. na Elektrodzie. Zatem to chyba za mało na nowy projekt. Świat idzie w kierunku upraszczania skomplikowanych rzeczy.
    Jednak jedna rzecz mnie cieszy: walory edukacyjne pod kątem atestów CE. Tego jeszcze (chyba) nie było.
  • #80
    tomba
    Poziom 17  
    Witam
    doczytałem że na ATMege 32 firma Relpol wykonała sterownik mini NEED
    parametry :
    - 8 wejść cyfrowych 230V AC;
    - 2 wejścia analogowe 0-250V AC;
    - 4 wyjścia przekaźnikowe (230V AC/10A);
    - zewnętrzna pamięć będąca rozszerzeniem pamięci programu;
    - możliwość programowania LAD i STL za pomocą PC;
    - przełącznik trybu pracy (RUN/STOP);
    - wskaźniki LED stanów wejść/wyjść;
    - potencjometr do zadawania wartości analogowych;
    - zegar czasu rzeczywistego;
    - 8 liczników;
    - 8 timerów;
    - standardowy RS232
    bez wyświetlacza i bez klawiatury

    http://www.relpol.com.pl/need/img/dokumentacja.pdf
    - ceny 310pln netto w wersji 24VDC lub 230VAC
    na uwagę zasługuje obudowa projekt BAZY GNUMASTERA jest podobny zakładając jego lepsze możliwości np (step CNC) będzie koncepcją lepszą
  • #81
    korneliuszo
    Poziom 16  
    Co do programowania dla "nieprogramistów" wybrałbym metodę grafów (przeciągnij i upuść).
    Mając coś takiego można dać komputerowi polecenie żeby zrobił program z bloków. (Sam coś takiego potrzebuję dla kolegi.)
  • #82
    marekpast
    Poziom 11  
    Witam.
    Szczerze odpowiem, nie uważam aby potrzeba była aż takiego uproszczenia programowania. Po Waszych wypowiedziach wyglądać to będzie jakbyśmy mieli kupić sobie zestaw klocków i nawet małe dziecko będzie sobie konfigurować w sposób jaki mu podpowie wyobraźnia. Nie tędy droga. Nawet jeśli miałoby to być wykorzystane w szkole, np na warsztatach to niech młody uczy sie programować, co mu szkodzi nauczyć sie C, lub bardzo prostego Asemblera, a co do wykorzystania w przemyśle to ktoś kto będzie chciał taki sterownik musi, mieć jako takie pojęcie a tym, przecież nie weźmie do ręki programowalnego procesora absolutny laik.
    Pozdrawiam Marek
  • #84
    marekpast
    Poziom 11  
    korneliuszo napisał:
    No tak lecz zawsze jest zadanie bojowe.

    Mogę prosić o uściślenie, na czy ma polegać to zadanie?
    Bo jeśli wg Ciebie to zadanie to utworzenie:
    Cytat:
    programowania dla "nieprogramistów" wybrałbym metodę grafów (przeciągnij i upuść).... żeby zrobił program z bloków

    to zapraszam do grona, wymyśl, napisz przynajmniej szablon a wspólnymi siłami i wzajemnymi podpowiedziami może damy rade to zrobić.
    Pozdrawiam
    Marek
  • #85
    korneliuszo
    Poziom 16  
    No o to mi chodziło.

    Sprecyzowanie:
    1. Pasek po lewej stronie z ikonkami.
    2. Przeciągając ikonki na pole robocze można ustawiać.
    3. Ikonki są blokami warunkowymi i wykonawczymi.
    4. ikonki będzie najprościej zrobić przez obiekt TImage (w Delphi)

    Jak to zrobię to podeślę ze źródłami. Będzie to uniwersalne. (Ja zrobię na BASCOMA(tylko ten język programowania na mikrokontrolery, a chcę się nauczyć C))
  • #86
    elektryk
    Poziom 42  
    Mnie się coś widzi że problem nie wyrośnie poza samą platforme sprzętowa, a czy ktoś wgra do środka binarke wygenerowaną w bascomie, skompilowaną w jakimś C czy wyskrobaną w asemblerze to już jego sprawa. Osobiście bym się skłaniał że takie rozwiązanie należy oprzeć na maszynie wirtualnej, stworzyć prosty byte-kod który zawiera operacje typu and,or, umożliwiść operacje matematyczne oraz skoki warunkowe i bezwarunkowe. Do tego wszystkie porty zamapować na swego rodzaju rejestry, do tego kilka(naście) rejestrów ogólnego zastosowania. Na to nałożyć maszyne wirtualną która ma zdefiniowaną diagnostykę, komunikacje I/O, obsługe przetworników i ew reakcje na sytuacje wyjątkowe (np przekroczenie parametrów). Do tego trzeba dopisać jakiś edytor języka drabinkowego (ew podobnego). Jak ktoś będzie chciał dłubać w bajtkodzie to sobie coś napisze, a jak ktoś potrzebuje na szybko to namaluje sobie w bloczkach.

    To jest moja prywatna opinie napisana na podstawie własnego doświadczenia. Nie zamierzam osobiście naciskać na jej stosowanie, raczej nie będe brać udziału w tym projekcie.
  • #87
    marek_Łódź
    Poziom 36  
    marekpast napisał:
    Po Waszych wypowiedziach wyglądać to będzie jakbyśmy mieli kupić sobie zestaw klocków i nawet małe dziecko będzie sobie konfigurować w sposób jaki mu podpowie wyobraźnia. Nie tędy droga. Nawet jeśli miałoby to być wykorzystane w szkole, np na warsztatach to niech młody uczy sie programować, co mu szkodzi nauczyć sie C, lub bardzo prostego Asemblera, a co do wykorzystania w przemyśle to ktoś kto będzie chciał taki sterownik musi, mieć jako takie pojęcie a tym, przecież nie weźmie do ręki programowalnego procesora absolutny laik. Pozdrawiam Marek

    Słyszałeś może o językach problemowo zorientowanych (nawet byle jakich - takich jak STEP)? A może widziałeś LabView w akcji. Sam sobie odpowiedz na pytanie gdzie jest przewaga tego typu systemów nad programowaniem w C czy w asemblerze.

    Skoro przeciętny użytkownik sterownika ma posiąść umiejętność programowania w C czy asemblerze, to może dać mu również szansę na stworzenie włanych rozwiązań sprzętowych, co w większości przypadków jest prostszą częścią projektu. W tym momencie cały projekt GNUMASTER sprowadza się do jednego zdania: "Róbta co chceta".
  • #88
    korneliuszo
    Poziom 16  
    No maszyna to trochę zbyt dużo.
    Myślałem żeby użyć schematów drabinkowych, przekształcenia ich na kod pośredni (C, BASCOM czy asm), kompilator tego kodu pośredniego na kod maszynowy i wgranie do procesora.
    C chyba będzie najlepsze bo znajdzie się kompilator pod Windows (konsolę) i programator. (Prosty plik bat do zestawu.)
    To będzie dobry zestaw, bo początkujący wezmą drabinki, średniozawansowani C lub Basic, a profesjonaliści assembler (Najmniej przewidywalny, a najwięcej daje możliwości).
  • #89
    marek_Łódź
    Poziom 36  
    korneliuszo napisał:
    No maszyna to trochę zbyt dużo.
    Myślałem żeby użyć schematów drabinkowych, przekształcenia ich na kod pośredni (C, BASCOM czy asm), kompilator tego kodu pośredniego na kod maszynowy i wgranie do procesora.
    C chyba będzie najlepsze bo znajdzie się kompilator pod Windows (konsolę) i programator. (Prosty plik bat do zestawu.)
    To będzie dobry zestaw, bo początkujący wezmą drabinki, średniozawansowani C lub Basic, a profesjonaliści assembler (Najmniej przewidywalny, a najwięcej daje możliwości).

    Druga wersja to interpreter kodu pośredniego (czyli nasza maszyna wirtualna) napisany w C, BASICu czy asemblerze wrzucony na konkretny sprzęt. W takim przypdku nie trzeba korzystać z zewnętrznych kompilatorów przy generowaniu aplikacji. Wadą tego rozwiązania są gorsze parametry czasowe oprogramowania sterownika.
    Ponieważ cała sprawa jest wyłącznie problemem ustawienia środka ciężkości, można pójść na wersję alternatywną, dającą użytkownikowi kilka różnych możliwości z kompilacją do kodu binarnego włącznie.
  • #90
    marekpast
    Poziom 11  
    Witam.
    marek_Łódź napisał:

    Słyszałeś może o językach problemowo zorientowanych (nawet byle jakich - takich jak STEP)? A może widziałeś LabView w akcji. Sam sobie odpowiedz na pytanie gdzie jest przewaga tego typu systemów nad programowaniem w C czy w asemblerze.

    Słyszeć słyszałem, widzieć nie widziałem - i przypuszczam, że przewaga jest chyba jedna, użytkownik nie musi prawie nic umieć.
    marek_Łódź napisał:

    Skoro przeciętny użytkownik sterownika ma posiąść umiejętność programowania w C czy asemblerze, to może dać mu również szansę na stworzenie włanych rozwiązań sprzętowych, co w większości przypadków jest prostszą częścią projektu. W tym momencie cały projekt GNUMASTER sprowadza się do jednego zdania: "Róbta co chceta".

    Dlaczego "Róbta co chceta", proszę nie przesadzać, dla mnie prostszą częścią wykonania programatora to jest właśnie jego oprogramowanie. Wolę poznać opinie wielu otwartych umysłów bo być może moje zdanie o programowaniu jest zbyt bardzo zeschematyzowane. Bliższe mojej obecnej wizji jest zdanie:
    korneliuszo napisał:
    ...To będzie dobry zestaw, bo początkujący wezmą drabinki, średniozawansowani C lub Basic, a profesjonaliści assembler....

    i takie właśnie widziałbym rozwiązanie. Program, który w bardzo prosty sposób da w kilku krokach efekt końcowy dla najbardziej typowych rozwiązań/zastosowań, do tego możliwość dopisania bloków programu samemu, oczywiście kod źródłowy dostępny dla każdego (taka jest idea GNU), jak również szczegółowy opis schematu sterownika/dokumentacja techniczna dająca możliwość zaawansowanym użytkownikom na samodzielne napisanie kodu np. w asm. Co to da? Dla takich użytkowników jak ja, którzy nie trzepią schematami jak z rękawa pozwoli wszechstronnie zastosować gotowy sterownik, który będę miał opisany jak np w dokumentacji mikrokontrolera.
    Początkowo pisałem o tzw. wyższym stopniu umiejętności programowania, bo jednak trzeba pamiętać że np. mamy ograniczoną ilość pamięci mikrokontrolera. Próba budowania bardzo zaawansowanego zastosowania na zwykłych gotowych schematach blokowych zazwyczaj kończy sie przebudowanym i bardzo dużym kodem wynikowym, wcale niekoniecznie poprawnie działającym i czasami nie mieszczącym sie w ramach struktury pamięci mikrokontrolera, nie mówiąc o bardzo często przepełnionym stosie. Może nie najlepszy przykład, ale taki mi teraz wpadł do głowy.
    Pozdrawiam i oczekuję na inne jeszcze lepsze rozwiązania.

    Osobiście chcę wziąć udział w projekcie w części związanej z oprogramowaniem w miarę wolnego czasu i posiadanych umiejętności jako nieprofesjonalista, a właściwie hobbysta, po zaledwie kilku programatorach różnych urządzeń (najczęściej AGD) i entuzjasta rozwiązań (czytaj oprogramowania) GNU.
    Poza tym polecam lekturę początkowych postów:
    Teodor Otulak napisał:

    ...
    5) Udostępnić wszystkim zainteresowanym jak największą ilość gotowych aplikacji
    6) Jako mikrokontroler, proponuję zastosować ATMega128 + WinAVR
    ...
    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
    [/url]