czy to jest realne ?

Bartek_BMW pisze:a czy będziesz chciał sie pochwalić schematami i wsadami do procka ????

Nie wiem czy Kolega pracuje zawodowo ale każda godzina pracy ma swoją wartość. Osobiście wiem ile zdrowia kosztuje pisanie programu w pojedynkę i ile czasu można stracić szukając błędów. Łatwo wycenić wartość pracy kolegi jarekk, wystarczy pomnożyć ilość spędzonego czasu przez stawkę godzinową. Na dodatek tworzenie takiego sprzętu nie jest sprawą jednostkową, zawsze jest w perspektywie produkcja na większą skalę z wymiernym zyskiem.

zawód mój elektronik....

lecz praca w reklamie

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

prokopcio pisze: 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

Ja też, choć wtedy to pewnie nie byłoby takie zabawne.

prokopcio pisze: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.

Tak naprawdę to nie jest problemem częstotliwość pracy ( w rozsądnym zakresie), ale ciągłość pracy dla kolejnych wektorów. Można co prawda przyspieszać/zwalniać przy każdym, ale wtedy praca jest powolna. Sztuką jest zapewnić stały strumień danych gdy np. program składa się 300 różnych odcinków w ciągu sekundy.

Aha - lepiej nie używać COM'a - ja mam u siebie FTDI na bezpośrednich driverach omijających porty szeregowe - działają naprawdę szybciej.

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.

Problem z buforowaniem pojawia mi się gdy mam bardzo dużo krótkich odcinków ( tak poniżej 2ms każdy). Wtedy tylko przez chwilę (sekundy) jestem w stanie pociągnąć ten ruch w sposób ciągły - ale mam na to zabezpieczenie przy tworzeniu scieżki ( wtedy wymuszam wolniejszą pracę).


Ostatnio to nawet chciałem napisać plug-in do Macha aby obsługiwał mój sterownik. Niestety wychodzi na to, że Mach może dostarczać scieżkę po kawałku, nie da rady go w prosty sposób zmusić aby przetworzył wszystko a potem tylko podawał aktualną pozycję

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.

Jak kolega obsługuje łuki ? Bo głównie tam można się spodziewać problemów ( u mnie nie ma jeszcze interpolacji kołowej, wszystko na razie liniowo i to głównie generuje dużo wektorów).

Czy kolega obsługuje rozpędzanie/zwalnianie ( u mnie to potraja liczbę wysłanych wektorów) ?

Jaki najkrótszy dopuszczalny czas pracy pojedynczego wektora jest dopuszczalny ( u mnie na razie 3ms, mam nadzieję zoptmalizować kod tak aby było to < 1ms )

Pytam, bo może razem czegoś się nauczymy.


U mnie wąskim gardłem jest link pomiędzy głównym procesorem, a procesorami osi. Mam tam porty szeregowe pracujące z częstotliwością 230400 bitów/sekundę. Muszę to podkręcić, bo czas przesyłania 16 bajtów jest tym co mnie ogranicza w liczbie obsługiwanych wektorów/sekundę.

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 po prostu zlikwidowałem wszelkie możliwe obliczenia w sterowniku - po prostu odgrywa ustaloną sekwencję.

Dlatego jeden wektor generuje mi aż trzy: jeden w którym jest przyspieszanie, drugi dla pracy stało prędkościowej (nie zawsze jest), trzeci dla zwalniania. Wynika to z algorytmu - u mnie parameterami są - ilość impulsów, prędkość i przyspieszenie.
Wciąż pracuję nad tym aby nie musieć zwalniać między wektorami gdy nie trzeba.

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