Ja taż jestem za C++. Znacznie łatwiej można napisać skomplikowany algorytm w c++ niż w składni pascala.
Niestety nie mam za dużo wolnego czasu. Mogę tylko wieczorami coś tworzyć.
Ponieważ kierunek projektu zmierza w stronę języka C++, to powinniśmy rozważyć w jaki sposób tworzyć interfejs graficzny.
Do wyboru są biblioteki:
wxwindows - nie polecam ze względu na duży kod wynikowy i powolne działanie na wolniejszych komputerach
FLTK - już o niej pisałem. Dołączyłem przykładowy ekran z kodem źródłowym.
Są jeszcze inne biblioteki np. VCL, GTK+. Pozostawiam temat do przemyślenia.
Mogę wziąść większy udział w zaprojektowaniu kontrolera sprzętowego, pracującego w trybie rzeczywistym.
markcomp77 uważam jednak, że kontroler powinien być na tyle uniwersalny, żeby podłączyć dowolny sterownik silników krokowych. Docelowo nie jestem za umieszczaniem sterownika silników krokowych w kontrolerze. Możemy wyposażyć go w sterowanie STEP/DIR do silników krokowych, oraz interfejs do podłaczenia w przyszłości serwosilników.

Jeszcze jedno. BCB6 jest typu personal. A jak ktoś zechce sobie użyć programu do maszynki, która na niego zarabia, to sytuacja staje się nielegalna!
Użyjmy narzędzi albo w pełni darmowych, albo komercyjnych. W drugim przypadku można zawsze znaleźć kogoś, kto skompiluje program na wersji licencjonowanej i będziemy mieli pełną wersję programu. Temat do przemyślenia.

Nie wiem czy do końca zdajecie sobie sprawę z tego o czym piszecie. Nad Autocadem, czy Solidworksem pracuje ogromny zespół programistów, a wy od razu chcecie robić limuzynę wśród samochodów.
A może najpierw zrobić coś, co jest podobne do Mach3 albo do innego programu sterującego.
No ale może się mylę i koledzy są na tyle dobrymi programistami, że wiedzą o czym piszą.
Po co od razu robić OpenGL. A nie wystarczy na początek zrobić dobry program sterujący, który komunikuje się z mikrokontrolerem, a w którejś kolejnej fazie doprogramować OpenGL, skoro się przy tym upieracie?
Ja jednak uważam, że powinniśmy zrobić na początek prostą wizualizację graficzną ruchu narzędzia, a lepiej dopracować komunikację programu i sterownika mikroprocesorowego.

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)

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.