ja startuję od tak zwanej prędkości bezpiecznej (taka, przy której w żaden sposób nie darady zgubić kroków) - również do niej zwalniam przy ostrych "zakrętach" - jest to naprawdę bardzo dobre rozwiązanie oszczędzające sporo czasu.

hmmm. Nie zrozumieliśmy się. Ja mam pełnowartościowe rozpędzanie / spowalnianie i również na rogach (i ostrych łukach) muszę zwalniać żeby nie zerwać kroków - brama plazmy też trochę waży, zwłaszcza przy dużych prędkościach jest to ważne. Jednak przy plazmówce trzeba się starać, żeby droga a tym samym czas hamowania był jak najkrótszy - wspominając o tych prędkościach chodziło mi głównie o to, że jadąc po łuku czy też skosie trzeba mież identyczną prędkość wypadkową z jazdy jedną osią (X lub Y). Tak uzyskuję prędkości sporo większe z rozpędzaniem niż bez. Miałem wcześniej realizowane wszystko w programie na PC (możliwe, że do tego wrócę bo jest po prostu łatwiej) ale gdy ładowałem całą ścieżkę (jeśli jest nieskomplikowana) do sterownika to niestety traciłem możliwość ingerencji w rozpędzanie / hamowanie, kontrolę prędkości itp - przy sterowniku do plazmy ustawienia prędkości, hamowania, rozpędzania i wiele innych są w sterowniku a nie w PC. Można wtedy przy odpowiednio dużej pamięci spokojnie pracować bez użycia komputera ale to jeszcze daleka droga...

jarekk pisze:skrajnym przypadkiem jest "skręt' o 90 stopni

dla mnie skrajnym przypadkiem jest skręt o 180st (zawrócenie) a nie 90st bo to jest tylko np zatrzymanie danej osi a nie zmiana jej kierunku.

jarekk pisze:prędkość styczna do ścieżki powinna być stała. Ale powoduje to skokową zmianę prędkości na osiach X,Y,Z

Dokładnie tak jak piszesz.
Jak wspomniałem mój projekt jest "sercem" wypalarki plazmowej gdzie najważniejsza jest idealnie stała prędkość liniowa więc prędkości poszczególnych osi (XY) są tak dobierane, żeby wypadkowa prędkość liniowa była zawsze stała... powiedzmy że mamy kwadrat 10x10cm na którego "objechanie" potrzeba 40s (przy jakiejś prędkości) i pracują na przemian osie X / Y po 10s - to jest proste ale jak już jedziesz np. po przekątnej tego kwadratu to mimo identycznych długości drogi już nie można włączyć dwóch silników na raz z tymi samymi prędkościami co poprzednio ponieważ dłuższą drogę ( razy pierwiastek z dwóch czyli 1,41 ) narzędzie przejechało by również w 10s a musi przejechać w 10s x 1,41 aby prędkość była stała.

Osobnym przypadkiem są zbyt ostre łuki (lub kąty), żeby przejechać je z niezmienną prędkością żeby nie zgubić kroków i żeby "wytłumić" moment bezwładnościowy. Z frezarkami to nie jest problem ale przy cięciu plazmą zmiana prędkości cięcia = znaczne pogorszenie jakości uzyskanej powierzchni. Piszesz o prędkościach skokowych - tak są to prędkości skokowe dla każdego wektora ale są to skoki jedynie prędkości osi branych pojedyńczo pod uwagę - prędkość samego narzędzia jest zawsze taka sama (wypadkowa z obu osi ).
Ile Jarku buforujesz danych (współrzędnych) ?
Żeby płynnie i "inteligentnie" sterować rozpędzaniem/hamowaniem na trasie złożonej z kilku wektorów trzeba mieć taką ilość danych "na przód", żeby można było przeanalizować, kiedy należy zwalniać i czy jest sens przyspieszać. Dlatego przy mocno "zagęszczonych" kształtach (powiedzmy 100 wektorów na 1mm) mój sterownik na razie nie daje rady, żeby rozpędzanie/hamowanie było możliwe na długim odcinku - analizuję na przód jedynie 64 wektory a to nie zawsze jest wystarczające. Ale popracuję, żeby była możliwość regulacji w dowolnych granicach (no może prawie w dowolnych )

Czy twój sterownik obsługuje interpolację w 3 osiach ?
Mój jest jedynie 2,5D i długo nie będzie 3D po prostu oś Z jest "odosobniona" i ma konfigurowalne 2 prędkości :
prędkość 1: wyjście z materiału i dojazd do powierzchni materiału
prędkość 2: zagłębianie w materiale
oczywiście położenie materiału trzeba wpisać lub odczytać z położenia maszyny np.dojeżdżając ręcznie.

W wypalarce plazmowej nie będzie nic podobnego bo tam przewiduję automatyczną kontrolę wysokości palnika nad blachą na podstawie parametrów elektrycznych łuku plazmowego (THC).

jarekk pisze:Czy u Ciebie zapewniona jest ciągłość prędkości między wektorami ? Czy też dopuszczasz "skoki" ?

Tak - jest zapewniona ciągłość, Chyba to stawiam za jedną z najważniejszych cech sterownika, żeby np na delikatnym łuku nie rozpędzać i nie hamować silników setki razy na odcinku np. 1cm . Do głowy przychodzą pomysły łatwo ale przekazać tą wiedzę sterownikowi (programowi) jest już gorzej ale się da. Muszę jeszcze dopracować i przedstawię rezultaty.
dla pocieszenia (lub wręcz przeciwnie - zależy jak kto na to patrzy) dodam, że to nie jest projekt "tygodniowy" - wystarczy odszukać kiedy zbudowałem wypalarkę plazmową CNC - około rok przed jej budową zaczynałem zbierać informacje na temat CNC, bez dostępu do internetu, bez wiedzy, że istnieje to forum i zacząłem projektować dorywczo sterownik na '51 i rs232 wraz z programem pod windows. Minęły 4 lata a sterownik nadal nie gotowy a już trzecia wersja .

Jak już wspomniałem - mój projekt to jest banał w porównaniu do Twojego Jarku u mnie niema problemu z transmisją pomiędzy prockami bo jest tylko jeden procesor dla wszystkich 3 osi i wszystkiego co w kółko nich (wyjścia/wejścia krańcówek itp.) interpolacji kołowej nie mam ani łuków nie obsługuję - plik HPGL ma już przecież gotowe wektory ("zinterpolowane") więc po co utrudniać sobie życie skoro masz wszystko podane jak na tacy? Jak też wspomniałem okrajam pliki do realnej dla maszyn dokładności 0,01mm co pozwala znacznie zmniejszyć ilość danych potrzebnych do przesłania, z mój "protokół transmisyjny" nijak się ma do jakiegokolwiek standardu i jest bardzo zmienny w czasie w zależności od potrzeb.... transmisja samego przesłania pliku może być dowolna - ja używam 115200 i jest ona wystarczająco szybka i nie mam potrzeby wykorzystywania szybszej choć testowałem do 1M i działa też nieźle ale czasem ramki się nie zgadzają z sumą kontrolną i ramka leci ponownie więc może w sporadycznych przypadkach dojść do jakiś zakłóceń transmisji (zbyt długie kable, zakłócenia elektromagnetyczne i elektryczne itp... ). Wszystko jak już wspomniałem bezproblemowo uciąga atmelek a konkretnie ATMEGA8 i jeszcze sporo zapasu jej zostaje - do projektu z klawiaturą i wyświetlaczem wykorzystuję atmegę 16 ale to ze względu na ilość pinów potrzebnych do obsługi lcd i klawiaturki choć i z tym bym sobie poradził na atmedze8 ale po co ? Chętnie bym powspółpracował jeśli bym miał czas a tak gdzieś czasem (jak dziś na przykad) mam czas w ogóle przejrzeć forum i zauważyć, że ktoś taki jak Ty tworzy konkretny w końcu sterownik żeby komputer (i sytstem operacyjny) się nie zajmował tym do czego nie jest stworzony . Tak, hamowanie i rozpędzanie obsługuje sterownik ale to nie zmienia ilości wektorów (tzn. zmienia minimalnie) i nie wiem z kąd bierzesz potrojenie wektorów ? hmmm. rozpędzać i hamować można nawet w obrębie pojedyńczego wektora - przy najmniej ja tak robię - nie powiem, trochę zabawy jest - zwłaszcza przy rozpędzaniu na "łukach" bo trzeba przeliczyć czy łuk jest wystarczająco łagodny, żeby pracować z ustawioną prędkością czy zbyt ostry i trzeba zwolnić - działa ale jeszcze nie tak, jakbym sobie tego życzył - obliczenia powinny być automatyczne i ukryte, żeby użytkownik nawet nie wiedział, że jest taka funkcja zaimplementowana . Jeszcze pozostaje mi nieruszona korekcja luzów ale ją robiłem już w sterowniku NC (bez PC) dla klienta i jest to nie problem i już będę zadowolony...

oj. nawet nie wiedziałem, że tyle nadruczyłem więc kończę
pzdr.

[ Dodano: 2008-09-02, 23:12 ]
zapomniałem dodać... może niedługo wypuszczę małą seryjkę (kilka sztuk) testowych konwerterków za pół darmo żebyście potestowali bo beta-testerzy są naprawdę potrzebni i niezastąpieni ale tacy, którzy naprawdę chcą się przyczynić do rozwoju projektu a nie narzekać tylko, że nie działa idealnie (a to jest normalne zjawisko układów testowych ).

czasy pojedyńczych wektorów mierzyłem w symulatorze ale nie pamiętam bo to było z rok temu - projekt leży na razie prawie nie tknięty.

ja niestety nie mogę spowalniać pracy bo w sumie to jest "serce" przyszłego sterownika do wypalarki plazmowej a tam niestety jest ważne, żeby prędkość była idealnie stabilna bo inaczej blacha będzie zniszczona (nadpalona tam gdzie palnik spowolni) ale na szczęście przy wypalarce plazmowej wystarczająca jest dokładność na poziomie 0,05mm więc można "okroić" jakość do tego poziomu co będzie całkowicie niezauważalne na końcowym detalu a pozwoli to znacznie zmniejszyć ilość danych pakowanych do sterownika. W sumie to teraz przy niewielkim buforze 64 wektorów i dokładności 0,01mm nie miałem żadnej najmniejszej niespodzianki z transmisją (a w transmisji jest jeszcze więcej danych niż tylko wektory) więc na razie nad tym myślał nie będę bo są jeszcze ważniejsze problemy.

Rozumiem na czym polega problem a akurat 300 odcinków na sekundę przesłać to nie problem - oczywiście też buforuję dane bo inaczej sobie tego nie wyobrażam żeby (jak to bardzo ładnie nazwałeś) liczyć tylko na PC (zwłaszcza z windowsem) . co do ftdi to nie przypadły mi do gustu nawet z producenta dll'kami (ale to ze względu na nieumiejętność posługiwania się nimi bezpośrednio i w pełni "wartościowo") i teraz stosuję implementację niestety programową USBtoCom w osobnej atmedze8 kóra świetnie sobie radzi do prędkości transmisji 1M/s przy pracy half-duplex co jest dla mnie bardzo wystarczającą prędkością do przesłania pliku PLT(+trochę dodatkowych danych) do sterownika.

jarekk pisze:Atmelek to trochę za słabo ( no chyba ze czestotliwosc pracy bedzie niska)
Ja robie sterownik na USB ( choc rownie dobrze moglby byc tam Ethernet), ale caly program najpierw idzie do flash'a bo USB nie ma takiej predkosci ani stabilnosci aby polegac tylko na danych z PCta.

Prototyp chodzil na ARM7 ( LPC2138, 60Mhz ), dało rade wyciagnac generowanie impulsów około 50kHz

Wszystko zależy czego oczekujesz (jakie prędkości sygnałów i jakie rozdzielczości chcesz uzyskać), konwerterek który zbudowałem również w wersji prototypowej (ale tylko 3osie a w sumie to na razie 2,5D) ale właśnie na atmelku (atmega8 przy 12Mhz) i transmisja przez USB/COM bezproblemowo działa do 50kHz z "inteligentnym" rozpędzianiem / hamowaniem na łukach a mieści się we wtyczce DB25 konwertera usb/cnc.

link do filmiku prezentującego kontrolerek:


Niestety projekt nie może się oderwać ponad wersję prototypową jeszcze nie w pełni uzbrojoną ze względu na brak czasu .... W wolnych chwilkach ( ) sklecam również projekcik z klawiaturką i LCD z transmisją rs485, żeby można było mieś komputer daleko od maszyny (inne pomieszczenie) ale dedykowany typowo dla wypalarek plazmowych gdzie lepiej, żeby komp nie stał, ale to osobna bajka.

Oczywiście są to projekty nie dające się porównywać z projektem kolegi Jarka - bo Twój Jarku projekt jest bardzo ambitny - Gratuluję i życzę wielu sukcesów... Chciałbym mieć czas jedynie dla CNC