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

Czesc problemów da się rozwiązać stosująć "pokrętło główne" - u mnie steruje ono taktowaniem i w sposób proporcjonalny kontroluje prędkosci i przyspieszenia. Wszystkie inne sprawy ( PWMy, wyjscia) mogę zmieniać bez ingerencji w działający na maszynie program.

Co do rozpędzania i przyspieszania - zwalniać zupełnie do zera, czy też ( aby oszczędzić czas) zwalniać do jakiegos progu i potem już skokowo ( chodzi o wartosc prędkosci dla pojedynczej osi ) ?

No ja mam trochę inne dylematy - w tej chwili mój sterownik interpoluje 3 osie ( mam też czwartą niezależną). W wypalarce plazmowej głowica ( w stosunku do frezarki) jest "lekka" i nie powinno być problemu z jej rozpędzaniem. Natomiast we frezarce nie można tak po prostu rozpędzić ciężkiej bramy i frezowanie kwadratu 10cmx10cm wymagałoby zatrzymania się na rogach ( odpowiedniego rozpędzania i potem zwalniania).

Ja poszedłem trochę inną drogą - cała sciezka jest analizowana na PC. Przeliczenia prędkosci, decyzje co do zwalniania/przyspieszania są podejmowane na podstawie całej scieżki. Dzięki temu sam sterownik może działać szybko ( graniczna częstotliwosc generatora kroków jest gdzies w okolicy 500kHz - 1MHz ).

Co do buforowania - wszystkie wektory są już we flash'u - potem bufor na 256 wektorów w SRAM'ie z którego wysyłam do sterowników osi ( tam jest bufor na 2 wektory, docelowo 64 ).

Ustalenie stałęj prędkosci stycznej jest fajne, ale silniki krokowe nie wytrzymają tego dla dużych prędkosci - czy rozpędasz silniki krokowe powyżej prędkosci której nie uzyskałbys bez przyspieszenia ? Wlasnie tak dla "skrętu" o 90 stopni ? Czy wtedy po prostu godzisz się na niższą prędkosc czy też używasz dużej wartoci przyspieszenia/hamowania w takim momencie ?

Chodziło mi o coś innego - prędkość styczna do ścieżki powinna być stała. Ale powoduje to skokową zmianę prędkości na osiach X,Y,Z ( skrajnym przypadkiem jest "skręt' o 90 stopni ). Przy aproksymacji liniowej łuków też tak jest ( w mniejszym stopniu). Wtedy trzeba albo zwalniać, albo zezwalać na skokową zmianę prędkości na osiach. Jaką strategię przyjąłeś ?

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" ?

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ę.

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ę

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.

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

Nie udostepniam schematu ani wsadu ( mozna by powiedzieć nawet wsadów, bo pracuje tam kilka procków - procesor główny LPC2378 plus 4 sztuki LPC2103 jako sterowniki osi - wszystkie taktowane 60MHz ).

Ale zawsze chetnie porozmawiam o algorytmach lub przestawię swoja opinie na temat proponowanych rozwiązań ( jako że ma juz pewne dowiadczenie w tym temacie) .

PS. Mówimy tu o 4 warstowowej płytce z procesorami 144 lub 64 nóżki (rozstaw 0.5mm) - do uruchomienia czegos takiego trzeba już miec troche sprzętu i doswiadczenia.

Proponuje koledze troche inne rozwiązanie - wziać PC-ta, wsadzić tam dwie karty LPT, postawic DOS'a z siecią ( mozna znależć gotowe receptury na sieci) i napisać swój własny program. Dla chetnych - można postawić Linuksa Real-Time lub EMC.
Ta droga jest prostsza i szybciej prowadzi do celu.

Generuje sygnały typu step/dir, wiec nie ma dla niego różnicy.
Dla serw mógłby osiągnąć większą częstotliwosc pracy, bo nie byłoby tak sztywnego wymagania dla stabilnosci generowanego sygnału ( szacunkowo 200-500kHz dla krokowców, 500-800kHz dla serw - cały czas jeszcze pracuję nad programem).

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