markcomp77 pisze:

jarekk pisze:dsPIC

.. a nie lepszy PIC32?

Lepszy,ale nie potrzebny ( jakbym potrzebował coś więcej to by właśnie STM32 tam wylądował). Przy takiej maszynie jak L6470 potrzeba mi tylko sprzętowego enkodera , SPI i RS485. Wezmę jakiegoś dsPICa w obudowie przewlekanej, co by innym było łatwiej klonować

Ja chyba spróbuję L6470 - potrzebuję mały sterownik jednoosiowy . Dodam dsPICa, bo będę potrzebował obsługe liniału.

markcomp77 pisze: patrzyłem na cenę tego l6470 - ponad 40zł
http://www.kamami.pl/index.php?categoryID=3008
trochę za dużo

L6474H ( mniej pancerna obudowa, ale chyba podobna technologia) jest za prawie połowę.

Ktoś go testował ? Trzeba by zachodnie fora poczytać

markcomp77 pisze:wspólne napięcie odniesienia... wspólny zega...

Nie wierzę że są dokładnie kalibrowane pod konkretny prąd ( bo w ich podstawowym zastosowaniu nie ma to znaczenia). Zgaduję że przy wspólnym napięciu referencyjnym prądy będą różne o kilka procent.

ursus_arctos pisze: Krzywe są w przestrzeni - zaletą jest oczywiście możliwość dość dokładneo reprezentowania dowolnej geometrii, a nie tylko prostych i łuków kołowych (jak w G-code). Dzięki takiej reprezentacji do maszyny wysyłam mało danych a mogę mieć bardzo skomplikowane kształty.

Jeżeli tylko to - to bardzo wysoka cena za stopień komplikacji , choć bedę pełen podziwu jak się uda coś takiego dopracować.

Ja to mam aproksymowane odcinkami - a przy procku 256Mbit SDRAM. Nawet jak jest dużo danych, to 3-4 sekundy więcej ładowania niewiele znaczy

Co do AllegroMicro - mają wiele ciekawych układów, choć odczucia używających są mieszane. Tu trzeba by jeszcze saklibrować symetryczność prądów ( przy dwóch układach) bo inaczej mikrokrok będzie krzywy.

Poza tym - przy krzywych problemem będzie synchronizacja prazy wszystkich osi, jako że sterować trzeba będzie "rzutem" krzywej na osie. ale może mi się wydaje - nie rozważałem tego na poważnie.

ursus_arctos pisze: część wykonawcza (DACe i mostki H

Któych mostków kolega chce użyć ? Mam kilka w szufladzie, ale większość jest za wolna aby móc sterować nimi PWMem

ursus_arctos pisze:pełna interpolacja krzywych sześciennych beziera (na liczbach zmiennopozycyjnych).

Jaka jest realna korzyść w stosunku do zwykłych "trapezów" ? Czy ktoś kiedyś tak naprawdę sprawdził że to daje np. lepszą powierzchnię ? (czy może jeszcze coś innego)

STM32F4 do potężna maszyna ( ~168MHz max) ale 4 osie na zmiennym przecinku - mi przy 120Mhz 4 osie stały przecinek ( 64 bity, obsługa przyspieszenia),ethernet, wyrabia około 100..120Khz

Mój algorytm przeznaczony jest w zasadzie dla FPGA, choć 100Mhz Arm Cortex daje radę generować sygnały step do około 100kHz ( dla 4 osi).

Źródłem przerwań jest chodzący synchronicznie zegar( 10us) i przeliczający za każdym krokiem każdą oś. Kilka dodawań stałoprzecinkowych liczb 64 bitowych i jest

Poszło by szybciej gdyby napisać w assemblerze, ale na razie 100kHz mi wystarcza. W tej chwili testuję ARMa 120Mhz ( LPC1788 + SDRAM) + sieć ( uIP z UDP ) i też wyciąga 100kHz.

Wiem ze nie jest to idealne, można by robić jak MACH - odcinkami o stałej prędkości - wtedy dało by radę używać do 'stepów' timerów sprzętowych.

Leoo pisze: Jak by nie liczyć wszelkie kalkulacje procesor musi wykonać najpóźniej w połowie okresu, jakieś 5us Jeśli w tym czasie uda się przeliczyć 3 czy nawet 4 osie, to sterowanie praktycznie gotowe

Właśnie że nie

Ja to robię tak - na początku przerwania obsługuję piny z poprzedniego przeliczenia ( mam informację które 'stepy' trzeba wysterować ). Wystawiam te piny i jednocześnie odpalam sprzętowy zegary który tworzy mi impuls 5us na dodatkowym pinie - pin ten , wraz z zewnętrznymi bramkami AND kontroluje mi docelowy sygnał 'step' ( dzięki temu nie potrzebuje dodatkowego przerwania do zmiany stanu stepów z 1 na 0).

Po tym wszystkim mogę już przeliczyć następny krok i odłożyć wynik z zmiennej.

markcomp77 pisze:2) -- przerwanie o stałym czasie... i badanie czy już czas na STEP (dość proste obliczenia dla rampy liniowej)

Ja używam tego sposobu. Tyle że faktycznie - obliczenia może nie są skomplikowane (tylko dodawanie), ale jak podzielić 16MHz na 100kHz kroku to nie ma wiele czasu .

blue_17 pisze:Może kolega pokazać jeszcze jak debbugować pod linuxem dla pełności opisu

Kolega markcomp77 robi debuggowanie na "twardziela". Nie lepiej odpalić Eclipse'a albo Rowley Crossworks ( też jest po linuksa)

http://linuxfreak.pl/elektronika/debugg ... slackware/
http://www.yagarto.de/
http://www.rowley.co.uk/arm/releases.htm ( wymaga licencji - można dostać na 30 dni)