Serwokrokowiec czyli pluto-step-encoder.

[jarenio]

no to teraz trochę podopytuje
Jak wygląda na dzisiaj opcja podpięcia FPGA do LinuxCNC ??
LinuxCNC przez LPT daje sygnał step/dir na fpga, które steruje silnikami (sprawdza enkoder i podaje pwm), ile wyjść / wejść można na takim połączeniu pociągnąć, czy może da się zmusić LinuxCNC do podawania sygnału przez inne porty (USB,PCI)?
Czyli, chodzi mi o kwestie programową w LinuxCNC... to co siedzi w fpga mnie nie interesuje

Czyli jak sobie Panowie wyobrażają to, co ma powstać na końcu tego wątku

[upanie]

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

[pitsa]

Myślę, że chodzi o coś nowego, co nie będzie miało wyrafinowanych wymagań w realizacji, bo problemy rozwiąże się na etapie projektowania na poziomie układów i oprogramowania.

Na przykład masę problemów jest w odpowiednim zmontowania czujników do patrzenia w dziurki tarczy enkodera i precyzyjne dopasowywanie ich położenie i przesunięcie aby udało się zrobić enkoder do krokowca. Weźmy teraz FPGA plus kamerę liniową zamiast transoptorów szczelinowych i przechodzimy "tylko" w problemy programowe.

[upanie]

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

[pitsa]

Nie, chodzi o otwarcie nowych możliwości - parę postów masz inny przykład:
spięcie krokowca z silnikiem prądu stałego, najlepiej to BLDC.
Przy małych obrotach silnik sterowany PWM miałby znikomy moment i wszystko by robił krokowiec, ale przy dużych dodawał by mocy która w krokowcu drastycznie z obrotami spada.

[upanie]

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

[markcomp77]

fpga bardziej pasuje do architektury zawartej w linucnc
w fpga realizujemy komponenty HAL..., które potem wykorzystujemy w pliku konfiguracji...
fpga przez lpt może dość szybko się komunikować....

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)

[upanie]

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.

[jarenio]

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

to po co LinuxCNC ??

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 właśnie nie do końca, wyobraź sobie 6 osi, na każdej silnik i enkoder + jakieś dodatkowe wejścia wyjścia, to wszytko trzeba na bieżąco sprawdzać, jeden układ nie może czekać na inny... uP było by super, gdyby realizowało zadania na zasadzie: dostałem przerwanie od komputera, sprawdź jak się to ma do zadanej wartości i jak coś to popraw, ale tutaj te operacje nie zdarzają się raz na jakiś czas, tylko układ działa ciągle. BTW, po to stworzono FPGA żeby nie robić tego na tysiącu scalaków i uP, więc czemu z tego nie skorzystać

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.

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

[upanie]

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