Realtime Ethernet w EMC2 i CNC

Chodzi mi o wyświetlanie ścieżki na ekranie - widzę fragment ścieżki a pozycji narzędzia nie.
I czy przy mniejszej małej ( dla mnie normalnej) prędkości widzę pozycje narzędzia, wykonaną ścieżkę i ścieżkę do wykonania ?

W tym filmiku na (20m/min) widać wyraźnie narzędzie, a w filmiku (3,6m/min) tych cienkich linii na filmiku prawie nie widać

może pokaże swój filmik a wtedy będzie widać jak mach pokazuje narzędzie - na filmiku jest robiona inna spirala z prędkością 10m/min

Dzieki, o to mi chodziło.

Fajnie by było, aby jeszcze ktoś z mach3+lpt+silniki krokowe i pokazał jak wykonuje się ta spiralka. Trudno też porównać przejazdy przy różnych prędkościach, no ale to nie jest żadne akademickie podejście do problemu abyśmy tu się nad tym rozczulali.

No, ale mniejsza o to.
To z jaką prędkością i jakościa wykonuje się ten gcode, to jest zasługa Mach, Ethernetu, Serw?Czy wszystkiego na raz? Bo, przyznaję , że widać różnice.

Pędkością to się kolego nie sugeruj, gdyby to puścił na maszynce na paskach to by wrzeciono ino smugę zostawiło.

Sellen pisze:Oto i test na Mach3, a nawet dwa . Przyznam się jednak szczerze, że "cfaniaczę" trochę Ponieważ maszynka jest stosunkowo lekka, a ma założone serwa BLDC. Tak dla informacji - enkodery 10000imp/obr, sterowanie bez mnożników / sterowanie Mach3 + CSMIO/IP-S.

test1 (3,6m/min) :
test2 (20m/min) :

"No niebrzydka rzecz" - rzekła księżna Beata do księcia Ferdynanda na pierwszej randce - "ale czy ma jakieś zastosowanie praktyczne" ?

Nie no prędkość zawrotna - bez gadania i bez porównania. Jeżeli to nie problem chętnie bym to samo zobaczył przy prędkości 'roboczej' - znaczy powiedzmy przy F40.
Bo nasza główna obawa co do serw była taka, że nie będą trzymały ścieżki i dokładności przy naszych prędkościach roboczych.

No chyba że ta maszynka z taką prędkością jak widać robi w stali - wtedy nie mam więcej pytań - no bo jakbym rzucił kawałek żelaza i założył freza powiedzmy 8 to taką spiralkę na raz i na głębokość 21mm to na naszych maszynach raczej przy F40 bym robił a nie przy F3600

Sellen pisze: Komputer PC nawet z nakładką RT nigdy nie będzie w stanie wygenerować na porcie LPT sygnałów sterujących z taką częstotliwością i precyzją jak sprzętowy sterownik. Port LPT po prostu nie był projektowany w tym celu poza tym generowanie sygnałów o wysokich częstotliwościach dla każdego CPU jest wielkim obciążeniem. To raczej domena układów logiki programowalnej FPGA, w naszym sterowniku taki właśnie układ odpowiada za generowanie sygnałów STEP.

Wyjaśnienie czyste, proste i przyjemne - przyjmuję bez marudzenia i widzę zalety posiadania oddzielnego układu generującego sygnały dla maszyny.

Sellen pisze: Dla mnie idealnym rozwiązaniem jest [Linux+RT + ethernet + sprzętowy sterownik], w tym kierunku zamierzamy iść w przyszłości,...

No a dlaczego? Skoro generowanie impulsów wyrzucamy na zewnątrz to już bez różnicy czy na początku kabla sieciwego mamy Linuksa RT, Windowsa, czy czytnik kart perforowanych - tu już w gre wchodzą tylko preferencje/przyzwyczajenia, nie?

Sellen pisze: Mam nadzieję, że nieco wyjaśniłem

Bardzo dużo - dzięki wielkie.

Zgadam się całkowicie że frezowanie powietrza, a frezowanie stali to inna bajka Też bym chciał frezować stal z taką prędkością. W takim wypadku jednak większy podziw miałbym chyba dla freza niż do systemu sterowania, hehe.
Takie prędkości mają zastosowanie jedynie w bardzo łatwych w obróbce tworzywach no i przy ruchach przestawczych. W ploterach ruchy przestawcze i ogólnie prędkości to istotna rzecz, często wykonuje się na nich np. wiele detali z dużej płyty. Prędkość to czas - czas to pieniądz.
Generalnie ruchy przestawcze nigdy nie są zbyt szybkie.

No a dlaczego? Skoro generowanie impulsów wyrzucamy na zewnątrz to już bez różnicy czy na początku kabla sieciwego mamy Linuksa RT, Windowsa, czy czytnik kart perforowanych - tu już w gre wchodzą tylko preferencje/przyzwyczajenia, nie?

Fakt - tak jak pisałem i na windowsie i linuxie można zrobić dobre sterowanie o ile zastosujemy do tego zewnętrzną elektronikę. A linuxa po prostu lubię, no i bardzo łatwo przenosić programy pisane pod nim na różne platformy. Ten sam kod kompiluję na PC, ten sam za chwilę na sterowniku z ARM9 - świetna rzecz. Tym bardziej, że zastanawiamy się jeszcze czy do nowych sterowań użyć PC (ITX) czy będziemy robili własny sterownik np. na Cortex-A8 + DSP. Na Cortexie windowsa już nie zapuszczę, linux za to śmiga aż miło.

Sellen pisze:będziemy robili własny sterownik np. na Cortex-A8 + DSP

Jak kiedyś liczyłem, to najtańszy PC z AMD , pamięcią na sticku USB i 1GB Ramu raczej zawsze będzie tańszy od własnego rozwiązania dużym wypasionym procku ( Cortexie / DSP). Do tego tylko obudowa no i EMC2 z VNC

Dlatego ja się skupiam na minimalistycznych rozwiązaniach - mały, tani zewnętrzny układ do PC-ta.

Na początek na pewno też użyjemy PC'ta tak będzie po prostu szybciej. Zaprojektować sterownik o jakim wspominałem to nie łatwa rzecz. Obwód drukowany przynajmniej 6 warstw, duże częstotliwości, więc trzeba liczyć długości i impedancje ścieżek. No i prototyp będzie diabelnie drogi. Docelowo jednak własne kompaktowe rozwiązanie ma swoje zalety.
To jednak cały czas kwestia nad którą trwają spory, więc zobaczymy jak będzie. W każdym razie pisząc soft pod linuxa zawsze można go później szybko przenieść na własną platformę sprzętową. Dobrze mieć takie pole manewru

Sellen pisze: Docelowo jednak własne kompaktowe rozwiązanie ma swoje zalety.

Właśnie jakie - jaką daje przewagę ? No bo jakaś płyta główna typu mikro z rozsądnym zasilaczem wydaje mi się dobrą bazą. Do tego być może własna karta z FPGA/DAC/ADC na PCIexpress lub drugim porcie ethernetowym - tylko jako prosty człon wykonawczy.

[ Dodano: 2011-03-05, 21:01 ]

Sellen pisze:Obwód drukowany przynajmniej 6 warstw, duże częstotliwości, więc trzeba liczyć długości i impedancje ścieżek. No i prototyp będzie diabelnie drogi.

No robię coś takiego - dla energetyki. Dwie kości Arm9 połączone szybkim SPI - na jednym Linuks ( normalny), na drugim hard realtime - algorytmy zabezpieczające w pętli. Tam to ma sens, bo wszystko ma wstać poniżej 1 sekundy - nierealne nawet w Linuksie. Poza tym ma przeżyć 5kV. W CNC nie ma aż tak wyśrubowanych wymagań - jak się da to gotowe komponenty zawsze bedą tańsze.