Kto chętny do testów kontrolera CNC/USB ? 1,22zł

prokopcio pisze:u mnie również. ale piszę o zagęszczeniu ponieważ przeliczanie u mnie odbywa się w osobnym "wątku" - "w tle" (jeszcze do dopracowania - narazie wyłączone)

Ja wogóle nie mam przeliczania - tu chodzi tylko o proste przerzucenie zmiennych z bufora do zmiennych kontrolujących generowanie impulsów ( ja wszystko przeliczam na PC i wysyłam do flash'a). Potem tylko odgrywam.

to jest główna i najważniejsza różnica pomiędzy naszymi projektami (tak jak Ty robiłem przy pierwszym sterowniku do plazmy na '51) ale szybko zmieniłem założenia co oczywiście baarrdzooo komplikuje właśnie program dla uP. Ale teraz po Twojej ostatniej wypowiedzi to całkowicie mnie zaskoczyłeś, byłem przekonany, że liczysz to w ARM'ie i dlatego stosujesz o wiele wydajniejszy sprzęt. Przy założeniu, że to PC przelicza pewnie podciągnąłbym prędkość do wspomnianych przez Ciebie 400kHz (pytanie po-co ?) - musiałbym dołożyć dużo RAM'u równoległego = większa ilość wyprowadzeń = Atmega16 = większa płytka = Nie zmieści się we wtyczce = Dodatkowa obudowa = dodatkowe koszty "produkcyjne" i projektowe. Ale nic nie neguję ponieważ jedna i druga metoda ma swoje plusy i minusy. Moje inne urządzenia pracują przeważnie bez kompa stąd mój nawyk, żeby to procek przeliczał a nie komputer bo bardzo łatwo wtedy urządzenie rozbudować o wyświetlacz i klawiaturkę żeby wpisać kilka współrzędnych...

Hmm,

Proste przeliczenia stałoprędkościowe - to by poszły.
Ale aby uwzględnić np. maksymalną dopuszczalną dynamikę dla poszczególnych osi ( która może być różna) - to wchodzi trygonometria. To już nawet nie na ARMa.

Ja jestem w stanie zoptymalizować ścieżkę tak, aby zwalnianie pomiędzy wektorami było jak najmniejsze ( jest to proces iteracyjny)

Aha - ja czytam z kosci NANDowej

Ale skąd w takim razie bierze się u Ciebie ograniczenie prędkości wynikające z przełączania wektorów skoro ścieżkę masz przygotowaną na PC to nie powinno być żadnej różnicy przy odtwarzaniu gotowej ścieżki na uP i powinno Ci to baaardzoo szybko chodzić przy Twoim sprzęcie hmmm..... no chyba, że jest/będzie te 400kHz o których piszesz to ok.

jarekk pisze:Proste przeliczenia stałoprędkościowe - to by poszły.

Moja wersja jest prymitywna tylko z prostymi rzeczami. Nie wiem co w Twoim odczuciu oznacza pojęcie "stało-prędkościowe"?

Ja mam problem większy z symulacją na PC żeby odzwierciedliła dokładnie to co wyliczy uP podczas pracy - tzn ścieżka to banał ale starałem się również kolorystycznie i na "dynamicznym" suwaku prędkości (częstotliwości) odzwierciedlić rozpędzanie / hamowanie - problem jest dlatego że troszkę innymi prawami się rządzi program napisany w assemblerze dla mikroprocesora 8 bitowego a innymi na PC w Windowsie i język wysokiego poziomu i ciężko jest napisać tu i tu dokładnie to samo w związku z czym prawdopodobnie drobne rozbieżności mogą się pojawić pomiędzy symulacją a rzeczywistą pracą. Podczas pracy już jest łatwo bo wyświetlane na ekranie jest aktualna pozycja przysyłana przez kontroler.

prokopcio pisze: Moja wersja jest prymitywna tylko z prostymi rzeczami. Nie wiem co w Twoim odczuciu oznacza pojęcie "stało-prędkościowe"?

To rozumiem jak sterowanie, w którym prędkość wektora (styczna) jest stała. Bez rozpędzania i hamowania (choć można by ją zmieniać suwakiem )

Jak konfigurujesz rozpędzanie i hamowanie ?

Ja u siebie podaje maksymalne prędkości na osiach oraz maksymalne przyspieszenie i opóźnienie. Potem przekładam to wektory ruch dla poszczególnych osi. Poza tym obsługuję tez bezpieczne zatrzymanie - ruch nie zatrzymuje się natychmiast, ale zwalnia liniowo ( można taki ruch wznowić)

1. Wypadkowa prędkość liniowa (styczna) oczywiście powinna być stała (u mnie jeszcze nie jest ale z tym nie będzie problemu bo już to miałęm w sterowniku poprzednik więc myślę, że sobie poradzę).
2. Rozpędzanie konfiguruję również przez podanie prędkości maksymalnej (nigdy nie zostanie przekroczona), przyspieszenia, oraz prędkości tzw. bezpiecznej od której zaczyna się rozpędzanie i na której kończy się hamowanie.
3. Każde zatrzymanie poza awaryjnym jest u mnie wykonywane z uwzględnieniem parametrów właśnie z pkt 2.

Bardzo, bardzo gratuluję. Niestety z braku czasu (przygotowuję 2 kolejne prototypy) nie będę mógł na razie wziąć go na testy. Ale w przyszłości - chętnie.

Co do kontrolera: sprawdź, co będzie jak będziesz musiał kontrolować wszystkie wejścia i wyjścia (razem z krańcówkami) i przeliczać wektory -> czy nadal procesor będzie tak samo wydajny?

Poprosił bym o taki kontroler do testów

Jeśli to możliwe oczywiście

Piotr Rakowski pisze:Co do kontrolera: sprawdź, co będzie jak będziesz musiał kontrolować wszystkie wejścia i wyjścia (razem z krańcówkami) i przeliczać wektory -> czy nadal procesor będzie tak samo wydajny?

Troszkę się niejasno wyraziłem - dopiero widzę jak czytam co napisałem. Ja wektrory przeliczam w procesorze na bierząco tzn. wyliczam co wektor sobie dane wg których mam "stepować" i to zajmuje najwięcej czasu co wydłuża właśnie przełączanie wektorów o których napisał Jarek (potrzeba procesorowi w najgorszym wypadku ponad 300 cykli co powoduje ograniczenie prędkości do owych 50kHz) ale to jest opóźnienie tylko pomiędzy niektórymi wektorami a konkretnie pomiędzy dwoma taktami step a reszta może działać do ponad 100kHz dlatego wymyśliłem żeby już podczas taktowania jednego odcinka wyliczać w tle kolejny co pozwoli podnieść częstotliwość przełączania ale kosztem obniżenia o trochę maksymalnej częstotliwości taktowania - to właśnie miałem na myśli pisząc, że mam wyłączaone przeliczanie "w tle" - tylko testowałe, nie dopracowałem ale wiem , że się da a to już wiele - bezpiecznie przyjmując nie powinno być docelowo gorzej niż 70-80kHz już biorąc pod uwagę obsługę krańcówek (to chyba jest najprostsze zadanie) i innych wejść / wyjść co zajmuje bardzo mało czasu. Najtrudniejsze jest precyzyjne taktowanie.

Dziękuję Piotrku za gratulacje i za "nie owijanie w bawełne" - narazie wyślę kotroler np.blue_17 (bo nie mam go na liście) a jak kiedyś będzie Ci się nudzić (w co wątpię) to masz u mnie zaklepany za 1,22zł .

Kurcze .. takie małe gówienko a tyyyleeee z tym roboty ale przyjemnej jak coś wychodzi.

[ Dodano: 2009-10-10, 09:45 ]
ps. jeden klient (czyta to forum po cichu więc pozdrawiam) mnieee męczy jak cholera żebym mu wrzucił do pamięci kilkanaście współrzędnych bo napisałęm, że można - on zawsze robi identyczne detale (nieskomplikowane) na frezarce i nie chce stawiać całego komputera odpalać systemu itd. chce nacisnąć guzik i ma robić .... ach - napisz coś i już nie daje spokoju.......

prokopcio pisze:dlatego wymyśliłem żeby już podczas taktowania jednego odcinka wyliczać w tle kolejny co pozwoli podnieść częstotliwość przełączania ale kosztem obniżenia o trochę maksymalnej częstotliwości taktowania

Przemysłowe sterowania analizują nawet kilkanaście ruchów do przodu w celu ustalenia czy kolejny "wektor" będzie wymagał hamowania i zatrzymania, bądź możliwe będzie utrzymanie założonej prędkości posuwu.
Jeśli chodzi o kontrolę dodatkowych I/O (krańcówki itd.) nie widzę potrzeby sprawdzania ich stanu z częstotliwością pracy rdzenia programu. Wystarczy sprawdzać co 50 czy nawet 100ms. Oczywiście podczas najazdu na krańcówkę bazową trzeba szybciej ale to tylko opcja programu.