"kolizje" - chodzilo mi o to ze program w jakis pokraczny sposob zasugeruje userowi, ze nie powinien tego wysinac, frezowac, szliforac w ten sposob bo zlamie frez or pognie maszynke nie wiem czy to jest potrzebne ale wydaje mi sie ze w przyszlosci mozna cosi takiego doklepac

Co do sterownikow to pytam sie dlatego, gdyz mamy kilka, kilkanascie mozliwosci wysylania sygnalu. Program powinien miec mozliwosc obslugi podstawowych sterownikow: step-dir, kazdy kabelek z osobna, no i moduly do obslugi uP sterownikow.

Wydaje mi sie, ze program powinien wiedziec zanim wysle dane do sterownika jak powinna przebiegac droga frezu. Rozumiem to tak, ze odczytujemy, konwertujemy i analizujemy we wlasnych procedurach co urzytkownik mial na mysli. Nastepnie pokazujemy to na ekranie(opcja) i wysylamy do sterownika ktory wybral sobie obslugujacy program. Dzieki tem my zawsze wiemy co ma zrobic maszyna nawet jak nie znamy sterownika. Pisanie pod konkretny sterownik ogranicza mozliwosci rozwoju i adaptacji pod inne sterowniki.

vegelus pisze:"kolizje" - chodzilo mi o to ze p

... - już wiem o co Ci chodziło - dzięki
Kwestia sterowników może być rozwiązana poprzez osobne moduły do każdego kabelka/uP

Zostawiając na razie zagadnienia dotyczące procedur sterujących, trzeba ustalić podstawowe założenia do programu:
1) w jakim języku piszemy? Proponuję język C/C++. Jest to najbardziej elastyczny język programowania (moim zdaniem i nie tylko). EMC linux jest pisany w tym języku, więc można będzie wykorzystać niektóre fragmenty kodu źródłowego.
2) jaki kompilator i jakie narzędzia do pisania kodu. Możemy użyć kompilatora MinGW, wtedy będzie można korzystać z Dev-C++, co bardzo ułatwi organizację pracy.
3) najważniejsza sprawa - interfejs GUI. Najprościej można by sięgnąć po narzędzia takie jak Borland C++ Builder, czy Visual C++, ale niestety są drogie i trzeba się bez nich obejść. Możemy korzystać także z bibliotek darmowych i tutaj na uwagę zasługuje biblioteka FLTK www.fltk.org Sam napisałem kilkanaście programów pod tą biblioteką. Kod wynikowy jest bardzo mały w porównaniu do np. wxwindows. Sama biblioteka nie jest też wymagająca jeżeli chodzi o komputer na jakim będzie używany program cnc. W tym wypadku doskonale będzie pracować na maszynce 400 MHz i windowsie 98.

Załączam szkic interfejsu graficznego wykonany z biblioteką FLTK, skompilowany pod kompilatorem MinGW. Wielkość programu 204 kb (bardzo mało).
Proszę o przemyślenia. Jeżeli zdecydujemy się na tą bibliotekę, to umieszczę w internecie opis konfiguracji biblioteki i kompilatora (Dev C++) tak, żeby każdy z zainteresowanych mógł sobie przygotować "warsztat pracy"
Szkic programu jest na razie bardzo prymitywny i ma na celu pokazanie że można zbudować GUI na bazie biblioteki FLTK. Kod źródłowy aplikacji w załączniku.

Jeszcze jedno mi się przypomniało. W pierwszej wersji zróbmy standardowe sterowania za pomocą portu LPT, a w kolejnej dodamy obsługę za pomocą USB. Co do sterowania USB, to zaprojektuję Moduł przejściowy żeby uzyskać sygnały sterujące elektroniką. Ale to dalszy etap.

Jezeli chodzi o mnie to jezyki programowania wchodzace w rachube: Delphi oraz Pascal, Visual Basic, PHP. Od C(wszelkie masci) trzymam sie narazie z daleka bo co tu duzo ukrywac prosty to on nie jest. Ale jak bedzie trzeba to i w tym napisze.

Zastanawialem sie nad wizualizacja i mam takie oto przemyslenia. Jezeli program ma byc wieloplatformowy(?) to warto zastosowac jakis silnik 3d kozystajacy np z openGL. Direct odpada ze wzgledu na os na ktorym chodzi. Czemu grafika 3d. Wyobrazam sobie, ze podajemy wymiary materialu. Rysuje sie bryla i program zaczyna jezdzic frezem wycinajac ksztalt. Program umozliwia obracanie bryly w kazdym kierunku w celu dokladnego ogladniecia efektu pracy. Czy cos takiego moze byc czy zbyt popuscilem wodze fantazji. Taka funkcja miala byc w moim programiku do obslugi frezarki bo w ploterze wystarczylo ze rysowal linie:-)

Co do delphi to moge zasugerowac tylko tyle ze wersja 2 jest darmowa, ja posiadam licencje do 4 standard.
Jest jeszcze taki twor co sie nazywa Lazarus. Jest to taka wersja free Delphi.

romek-s popieram rozwiązania bazyjące na kompilatorze GCC (MinGW)

część programu która musi pracować w czasie rzeczywistym... ze względu na niedostatki systemów operacyjnych (brak obsługi czasu rzeczywistego) - docelowo powinna trafić do kontrolera (np. AVR atmega128).
W uC warunki pracy w reżimie czasu rzeczywistego będą spełnione !
Przeniesienie kody na uC będzie tym prostsze, iż na AVR istnieje mutacja GCC o nazwie AVRGCC (ta sama składnia)

podglądanie projektu EMC (zwłaszcza wersji EMC2) uważam za bardzo korzystne dla naszego projektu... jednak poco dublować projekt opensourcowy który rozwija się tak owocnie
mi osobiście po przeczytaniu dokumetacji EMC2 - o HAL... bardzo się spodobał ...i wydaje się gotowy do zastosować praktycznych

sensowność naszych wysiłków powinna być uzasadniona robieniem czegoś nowego, innego, unikalnego...

EMC2 to projekt o bardzo przemyślanej architekturze (poprawiono wiele niedoróbek EMC)... jest moduł HAL (warstwa obsługi sprzętu) - który pośredniczy pomiędzy właściwym programem a sprzętem - taka architektura ułatwia dołączanie różnych wynalazków <- trzeba jedynie napisać driverek...
HAL zawiera PID (do programowego obsługiwania serw)... programowo obsługuje enkodery... czyli jest w nim wiele ciekawych patentów...

NASZ projekt powinien być czymś innym
warto się skupić nad stworzeniem programu "finezyjnie" sterującego silnikami krokowymi, ale pomyśleć nieśmiało o takiej strukturze aby dało się dokompilować obsługę sterownia serwem...
"finezyne" - warto wstawić parę algorytmów ustalających przesunięci narzędzia... np. algorytm szybki dokładny (bresenhama), algorytm z wygładzania (większy błąd ale ładniejsza powierzchnia)... itp itd

warto - aby program był możliwie zwarty, i bardzo dobrze udokumentowany - tak aby stanowił dobrą podstawę dydaktyczną

programowanie obiektowe - może być - ale trzeba TO dobrze przemyśleć... przedyskutować... udokumentować

warto pisać kod który będzie wykonywał się w miarę szybko - czyli ostrożnie z obiektami !!!... szybkość jest potrzebna - przy trybie mikrokrokowym... warto też myśleć o optymalności kody ze względu na perspektywę przeniesienia na uC...

romek-s pisze:Załączam szkic interfejsu graficznego wykonany z biblioteką FLTK

dzięks - zaraz pooglądam

romek-s, patrzyłem na ten interfejs - nie jest zły - tylko czy da się w oknie zrobić np. panel i w tym panelu wstawić okno OpenGL - tak jak jest w SolidWorks.
Projekt ma być wykonany w środowisku + języku wieloplatformowym
Implikuje to użycie GCC (łoj - tu ja też Panie vegelus będę się męczył ). Co do środowiska - od jakiegoś czasu używam Eclipse (http://www.eclipse.org) do pisania pod ARM'a. Do uruchominia tego jest potrzebna Java - i tutaj moje ogromne zaskoczenie (jestem Anty-Java'owcem) - Eclipse bardzo żwawo chodzi! . Do GCC potrzebny będzie jeszcze CygWin.
Jeżeli zdecydujemy się jaką kolwiek opcję to wszystkie linki/programy umieścimy lokalnie wraz z instrukcją instalacji środowiska.
Kwestia sterowania przez LPT czy USB - tak czy inaczej to będą osobne moduły (dll).
vegelus, podzielam Twoje obawy przed C - ale cóż zrobić
Grafika - tylko OpenGL - odpadają problemy choćby z oglądaniem grafiki.

romek-s pisze: Kod źródłowy aplikacji w załączniku.

odpaliłem cnc.exe pod wine (linuks).. działa

markcomp77, obiektowo - znaczy wolno A co nas to interesuje jeżeli i tak część wykonawcza będzie wraz z buforem będzie na uP ( tutaj zasugeruję delikatnie popatrzenie na ARMy - cena niemal identyczna co AVR Mega128 - oczuywiście zależy na który ARMa model patrzeć - a możliwości większe). Dokumentowanie części programu obiektowej nie niczym strasznie trudnym - zapewniam.

GrzegorzK pisze: tutaj zasugeruję delikatnie popatrzenie na ARMy - cena niemal identyczna co AVR Mega128

a które modele armów?

Jeżeli chodzi o OpenGL to też da się wstawić. Ale nie zapędzajmy się tak daleko. Na początek musi wystarczyć zwykły podgląd graficzny ruchu narzędzia. Chyba że ktoś z nas jest geniuszem programowania i ma na tyle dużo czasu żeby to zrobić Programowanie obiektowe w bibliotece fltk nie spowolni systemu. Kod wynikowy wykonuje się bardzo szybko.
markcomp77 popieram utworzenie wersji sprzętowej do kontroli sterowania maszyną.
Ja widzę to tak: Program (win) wczytuje kod, interpretuje polecenia i wysyła trajektorię ruchu do kontrolera nadrzędnego i niech tamten się martwi żeby wszystko chodziło jak należy.
Dodatkowo program (win) będzie zajmował się wizualizacją na ekranie.

Jeżeli chodzi o kontroler sprzętowy to proponuję użyć uC Atmega128, dużo kodu i składnia programowania taka sama. Co do wymiany danych między programem i kontrolerem nadrzędnym to należałoby użyć szybkiego RS422, lub USB. Ja popieram użycie USB. Scalak do USB kosztuje ok 25zł, więc nie jest to dużo.
Sprzętowo można to zrobić na dwa sposoby:

1) traktujemy USB jako zwykły RS232 i tak też go obsługujemy.
2) obsługujemy USB programowo (bezpośrednio)

Ponieważ zawodowo zajmuję się projektowaniem urządzeń elektronicznych, więc mogę wziąć na siebie zaprojektowanie odpowiedniego kontrolera sprzętowego.
Komunikację zrobimy na porcie USB, który obsłużymy jako port RS232, lub USB.
Interfejs USB będzie wyglądał następująco:
- z komputera kabel USB do konwertera USB-RS232, albo USB-port równoległy 8 bit.
Ponieważ komputer znajduje się blisko maszyny, to scalak zamieniający informację z portu USB na sygnały logiczne, to całość umieścimy w kontrolerze sprzętowym.

Do przemyślenia.
1) protokół komunikacji między programem komputerowym i sterownikiem sprzętowym
Komunikacja musi być zabezpieczona, tzn. należy wprowadzić żądanie potwierdzenia odebrania rozkazu.
2) podział zadań między programem (win) i programem (procesor)