Kontrolery wczoraj wysłałem - zapraszam do nowego tematu i dzięki za zgłoszenie się Beta-Testerów

Tu jest/będzie wszystko czego potrzeba:

https://www.cnc.info.pl/topics12/cnconv ... htm#124153

wiem że poprawki nie mają końca a klientów (nie koniecznie kolegów ) takich narwanych po prostu zbywam.

Piotr Rakowski pisze:jak interpolujesz drogę - przeliczasz jak poprzednio (przypominam, że dostałem od Ciebie kiedyś kod), czy może Bresenhamem?

dziwna będzie odpowiedź albo źle zadane pytanie :
odp. Tak jak poprzednio : bresenhamem

Piotr Rakowski pisze:Jak radzisz sobie z g-kodami 3D?

nie radzę sobie i odstawiam to na dość daleki plan - patrz pierwsza strona :

prokopcio pisze:1. obsługiwane pliki : HPGL (testowane Corel, CadStd)
4. obsługa 3osi (na razie 2,5D)

z założenia miał to być program do obsługi wypalarki plazmowej (i będzie) do umieszczenia w większym sterowniku z wyświetlaczem klawiaturką itd... i z założeń wyszedłem takich, że pełna interpolacja 3D nie będzie potrzebna (niedobre założenie) i teraz niełatwo będzie przebudować program.... Ale mimo to planuję w przyszłości mieć interpolację 3D (teraz mogę ją przygotować w PC bez ruszania oprogramowania w uC i wysłać gotowe dane podobnie jak u Was, ale chcę tego uniknąć).

[ Dodano: 2009-10-11, 08:22 ]
acha.... przepraszam ten kod stary co dostałeś to tam jest zrobione całkiem inaczej - droga przeliczana jest w PC i gotowe dane w postaci komand "jedź krok w prawo", "jedź krok w prawo + krok w górę" leciały po RS'ie do uP .... to jeszcze w tamtym zabytkowym sterowniku do plazmy o osiągach bardzo kiepskich choć stabilnie pracującym.

[ Dodano: 2009-10-11, 08:45 ]
a jeszcze jedno spytam Piotrku : Skrytykowałeś kiedyś stosowanie w takich aplikacjach algorytmu Bresenhama ale nie napisałeś dlaczego jest on niedobry.... Czy mógłbyś napisać dlaczego ? Może coś robię źle i nawet nie jestem tego świadomy? Trochę to dawno było:
https://www.cnc.info.pl/topics50/sterow ... bresenhama

[ Dodano: 2009-10-14, 12:03 ]
Ze względu na ograniczoną liczbę kontrolerów testowych byłem zmuszony przeprowadzić selekcję... Jutro wysyłam kontrolery do użytkowników:

1. pswienty
2. markcomp77
3. chaos
4. jarekk
5. webserver
6. maak

Podajcie proszę (PW/E-mail) Adresy do wysyłek.
Liczę na Waszą pomoc w rozwoju projektu.
Osoby spoza listy, które się zgłosiły proszę o wyrozumiałość.

ale

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

hmmm... kurcze rozpędzam się z odpowiedziami - u mnie jest analizowane odcinków do przodu tylu ile jest potrzeba (czasem jeden a jak trzeba to i 100) żeby uzyskać efekt który opisałeś a nie jest to "przemysłowe" sterowanie ale nie chodzi mi teraz o utworzenie z wyprzedzeniem "mapy prędkościowej" a o przełączenie pomiędzy dwoma wektorami o którym pisał Jarek - w ów czas jest potrzebnej jest troszkę więcej mocy obliczeniowej co objawia się opóźnieniem JEDNEGO impulsu step co dla perfekcyjnego sterowania dyskwalifikuje urządzenie jako idealnie stabilne - choć pewnie dla całej maszyny to opóźnienie nie będzie miało najmniejszego znaczenia przy dzisiejszych podziałach kroków ale mimo to mogę to ominąc - narazie sobie daruję bo z tym dużo zabawy....

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

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.

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.

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

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) i jeśli nie jest zbyt gęsto wektorów to "taktowanie nie dogoni przeliczania" - śmiesznie to brzmi ... ale to już Wy przetestujecie ponieważ ja nawet nie mam sterownika+silnik co by to pociągnął bo mój podział kroku /8 i silnik 1,8szt to przy 100kHz by dało 3750obr/min a nawet przy 50kHz nie sprawdzę na amatorskiej frezareczce - tylko teoria, symulacje programu uP i oscyloskop (też nie najlepszy).

[ Dodano: 2009-10-09, 01:34 ]

tym razem z oryginalną muzą krokowców
niestety kiepska jakość filmiku i nie widać linii jakie ołówek rysuje na papierze

Kwarc 16MHz zajętość pamięci procka (Flesh) 37% więc jeszcze mam sporo miejsca na bajery ale pamięć SRAM wykorzystuję w 75% na samo buforowanie wektorów (ale 25% już z powodzeniem wystarcza żeby zachować ciągłość pracy).

Co do prędkościto chodzi minimum do 50kHz to zależy jak już pisałem od zagęszczenia wektorów jeśli jest małe zagęszczenie (np wircenia) to pójdzie i do 100kHz chociaż podczas dokłądania funkcji ta częstotliwość pewnie spadnie do 75kHz. Właśnie podłączyłem sobie do frezareczki i zaczynam działać w końcu muszę wysłąć w następnym tygodniu bo opinię i tak już mam nienajlepszą jeśli chodzi o moje obietnice. Udoskonalenie algorytmu rozpędzania silników naprawdę mnie miło zaskoczyło - nigdy nie udawało mi się na tej amatorskiej maszynce uzyskiwać takich prędkości jak znajdę dziś chwilkę to nakręcę filmik ale nie obiecuję tym razem ...

Całkowicie inne pułapy. Wg mnie nie będziemy (nie jesteśmy) konkurencją. Z drugiej strony nie wiem czemu ta łezka Jarku... przecież to Ty jesteś przede mną co najmniej 3 kroki i nie zamierzam Cię gonić bo to się mija z celem - raczej staram się wchodzić do ludzi z tym, czego niema wcale a podobne kontrolerki już są i to o wiele lepsze więc nie zdążyłem.