Ale dlaczego trzeba rezygnować z ekranu?
Przecież LinuxCNC może zostać jako cały soft z ustawieniami, podglądem postępu prac itp. a interfejs na zewnątrz dostawałby tylko G-cody do wykonania. Nie potrzeba wtedy systemu czasu rzeczywistego a co do postępu pracy to przecież LinuxCNC mógłby ssać z interfejsu bieżącą pozycję. Fakt, że obrazowanie na ekranie nie byłoby w czasie rzeczywistym a z opóźnieniem powiedzmy 50ms ale czy to ma jakiekolwiek znaczenie? Oczywiście to wymaga ingerencji w kod źródłowy EMC2 czy tam LinuxCNC (nie wiem co jak się nazywa) ale zdaje się, że kod jest otwarty i można go zmienić/rozbudować. Tak chyba działa PikoCNC, mam rację?

tuxcnc zgadzam się z tobą, że zaśmiecam(y) wątek prockami. No ale mi nawet nie chodzi o procek a raczej o interfejs. Uparłeś się, że LinuxCNC jest najlepsze na świecie takie jakie jest i już bo za stówkę można kupić płytę z prockiem i LPT więc zewnętrzne interfejsy to bzdura. Otóż moim zdaniem to nie bzdura tylko konieczność bo za kilka albo kilkanaście lat nie kupisz już żadnej płyty z LPT bo będą tylko w muzeum techniki. I co wtedy, koniec z LinuxCNC?
Poza tym zewnętrzny interfejs znosi konieczność posiadania specjalnej dystrybucji z jądrem RT. To chyba jest ogromna zaleta. Wszyscy dookoła twierdzą, że USB nie może być bo nie ma wersji RT. A po kiego grzyba ma być RT? RT to powinno być na tymże interfejsie i już. Poza tym na zewnętrznym interfejsie da się osiągnąć znacznie wyższe prędkości sygnałów i znacznie stabilniejsze. Tak samo mogłoby to chodzić przez ethernet ale tu znowu jakaś mania wersji RT.
Co złego jest w takim podejściu?

Ja mam takie bardzo proste pytanie, czy moglibyście zajrzeć sobie w Google, zamiast uprawiać tu spekulacje i pisać oczywiste bzdury ?

A ja ciągle proszę o nie atakowanie z byle powodu ale to jak grochem...
Otóż jak zajrzysz sobie w google to się zorientujesz, ze jest coś takiego jak pamięć flash zwana konfiguracją/konfiguratorem, którą to programuje się np. JTAG-em. Poza tym oczywistą bzdurą jest, że jak układ jest FPGA to traci swoją konfigurację po zaniku zasilania. Są układy z wewnętrznym flashem np. Spartan 3 AN.

Zapewne jakimś JTAG-iem.
Nie wiem jak w alterach ale pewnie podobnie jak w xilinx-ach. Interfejsy producenta zapewne są drogie ale też na pewno nie brakuje tanich klonów.
Pewnie coś takiego się nada:
http://kamami.pl/index.php?ukey=product&productID=46743

LinuxCNC jest programem uniwersalnym, obsługującym dowolną kinematykę, delta, SCARA, PUMA i co sobie ktoś jest w stanie wymyślić.
Nie wchodzi w rachubę taka opcja, żeby zmieniając konfigurację maszyny, trzeba było kompilować wsad do procesora i go przeprogramowywać.

Skoro nie trzeba zmieniać konfiguracji FPGA to nie rozumiem dlaczego trzeba by zmieniać program uC. No chyba, że jednak FPGA też trzeba zmienić.

to po co LinuxCNC ??

Bo LinuxCNC to trochę więcej niż tylko przekładanie G-codów na Sterowanie silnikami a właśnie to chciałbym zrobić.

no właśnie nie do końca, wyobraź sobie 6 osi, na każdej silnik i enkoder + jakieś dodatkowe wejścia wyjścia

No to sobie wyobraź uC 168MHz ze sprzętowymi licznikami obsługującymi enkodery plus sprzętowe PWM-y jeśli zajdzie taka potrzeba. DO tego DMA szybkie przerwania i całe stado innych wspomagaczy. Jestem przekonany, że jeśli chodzi o sterowanie sześcioma silnikami krokowymi to taki procek zwyczajnie by się nudził PikoCNC ma atmegę!
Oczywiście masz rację o FPGA ale wydaje mi się (może się mylę, tego nie wykluczam), że uC też da sobie z tym radę a umożliwia do tego zrealizowanie innych funkcji, których FPGA nie może. Oczywiście można wziąć FPGA odpowiednio duże i zapodać tam cora jakiegoś procka, np. microblaze no ale nie o to chodzi.

prościej i taniej kupić układ od kolegów, np PicoCNC....

Racja w 100% gdyby chodziło tylko i wyłącznie o wykorzystanie we własnej maszynce.
Rozchodzi się jednak o sam projekt kontrolera, wyzwania, problemy, nieprzespane noce... To mnie jara

O qrcze ale jestem niesłowny, miałem już nie namawiać na uC

Spokojnie ja już ostatni raz obstanę przy swoim i się zamykam.

w fpga realizujemy komponenty HAL..., które potem wykorzystujemy w pliku konfiguracji...

A w uC się nie da? Na pewno się da.

fpga przez lpt może dość szybko się komunikować....

Jakby olać LPT, przejść na USB i do procka słać G-cody to będzie wielokrotnie szybsze do LPT + FPGA.

w uC owszem również można próbować robić podobnie.. ale trochę gorzej...
w fpga (pld) każde zadanie może być realizowane równolegle (choć w jednym scalaku)

Raczej nie gorzej a inaczej - tak jak wcześniej napisałem.
Równoległe wykonywanie wielu algorytmów jednocześnie to zaleta ale nie konieczność. W obecnych uC są takie częstotliwości zegara, że możemy stwierdzić, że w tym przypadku zadania też bedą wykonywane równolegle zwłaszcza, że dużą część zadań zrobią peryferia mikrokontrolera.

No ale przepraszam za zamieszanie bo wychodzi na to, że próbuję Was odciągnąć od pierwotnej idei. Nie o to mi chodziło. Chciałem tylko zasugerować inne rozwiązanie ale nic na siłę.
Swoją drogą muszę sobie poczytać trochę o LinuxCNC bo zaczyna mnie ciekawić możliwość zrobienia zewnętrznego kontrolera CNC, który to łykałby G-cody po USB a poza tym miał również jakiś tam swój interfejs do prostych operacji.

No i właśnie tutaj taki mikrokontroler byłby idealny. Ma PWMy, liczniki i wszystko czego trzeba. Nie trzeba tego robić w FPGA - chociaż to akurat żaden problem.
Niemniej z mojego punktu widzenia uC to prostsze rozwiązanie mimo, że z FPGA miałem do czynienia. No ale to tylko moje widzenie na ten temat.
Tak czy siak poczułem się zainspirowany i jak mi to szybko nie minie to porwę się na ten temat w wersji c uC
Swoją droga sprzęgnięcie dwóch typów silników to niezła myśl. Napęd hybrydowy

Zaraz, zaraz to w planach jest robienie własnych enkoderów? :O

A ja trochę z innej beczki...
Co żeście się tak uparli na FPGA?
Rozumiem, że jest gotowa konfiguracja matrycy i można ją tylko modyfikować ale to nie jest jakiś problem aby to samo zaimplementować, zapewne trochę inaczej, w uC.
Obecnie są potężne mikrokontrolery z kilkoma PWM-ami i szybkimi licznikami wręcz dedykowane do sterowania takimi silnikami. Kosztują zazwyczaj mniej niż FPGA ale mają mnóstwo innych przydatnych rzeczy jak chociażby USB do podpięcia do PC czy liczniki z "wbudowaną" obsługą enkoderów, przetworniki DAC i ADC. Tylko brać i używać. Łatwiej się to programuje niż FPGA dla znawców procków. Na przykład STM32F405 genialnie da radę. Fakt, że jeden scalak nie pogoni 9 osi tylko jedną albo dwie ale za to daje więcej możliwości. Chociaż jakby ograniczyć się do silników krokowych z enkoderami to pewnie i 9 pociągnie. No i ten scalak to przykład mikrokontrolera ogólnego zastosowania ale są inne, dedykowane do sterowania silników.
Nie wiem jak w przypadku pluto jest zrealizowane sterowanie z linuxcnc ale tu można wsadzić mnóstwo kodu z niezła logiką więc można zrobić sterownik, któremu zapodajemy G-cody nie majtając STEP/DIR-ami.

Ale zaraz zostanę zje....chany