chomikaaa pisze:pic33FJ128MC706

Ja go też używam - do sensora prędkosci obrotowej ( z dwóch czujników indukcyjnych).
Na stronie Microchipa jest kilka not aplikacyjnych z programami ( choć głównie w assemblerze). Kolega może obejrzeć kity Microchipa do procesorów dsPIC i użyć ich jako szablonów do własnych konstrukcji.

[ Dodano: 2008-10-27, 10:41 ]
A do C - Kerningham Ritchie Język ANSI C
Całe pokolenia się na tym uczyły, książka jest przystępna i z zrozumiała.
Powinna być łatwo dostępna
http://www.allegro.pl/search.php?from_f ... interval=7

dspic 30F2010:
http://www.microchip.com/wwwproducts/De ... e=en010329
z opisu

# Motor Control PWM Module Features:
# Complementary or Independent Output modes
# Edge and Center Aligned modes
# Multiple duty cycle generators
# Dedicated time base with 4 modes
# Programmable output polarity
# Dead time control for Complementary mode
# Manual output control
# Trigger for synchronized A/D conversions

# Quadrature Encoder Interface Module Features:
# Phase A, Phase B and Index Pulse input
# 16-bit up/down position counter
# Count direction status
# Position Measurement (x2 and x4) mode
# Programmable digital noise filters on inputs
# Alternate 16-bit Timer/Counter mode
# Interrupt on position counter rollover/underflow

A kompilator - to kompilator C dla dsPICa - nie chce mi się wszystkiego skrobać w assemblerze

chomikaaa pisze:W tej chwili szukam informacji aby wybrac odp procek do tego celu lecz brakuje mi doswiadczenia. Moze doradzisz jakie srodowisko wybrac z jaka rodzina procow chce szybkiej maszyny napewno nie 8bit i 12mhz moze polecisz jakiegos arm, lub cos innego moze warto dsp.

Poszukaj dsPIC ( microchip). Obejrz 30F2010 - najmniejszy który pasuje. Ja biorę 30F6015. Narzędzia tanie. Można zrobić sobie debugger - mam jeszcze jedną płytkę i zestaw części ( oryginalny kosztuje około 600zł, klona zrobisz za 150zł). Kompilator C - jest wersja studencka. ARM też jest dobry, ale trzeba więcej kombinować - dsPIC ma więcej peryferiów specjalizowanych do kontroli silników ( co znakomicie ułatwia sprawę, poza tym sprzętowe zabezpieczenia uratują ci elektronikę w przypadku błędów programowych - w pewnych granicach).

O ile pamiętam to jest do niego kit:

http://www.microchip.com/stellent/idcpl ... t=DM300020

Tu trochę o moim rozwiązaniu:

chomikaaa pisze:- czy to nie mach, turbocnc odpowiada za rampe rozpedzania hamowania?

Gdyby robić coś na kształt NCpod'a, który odgrywa polecenia Mach'a, to by faktycznie tak wystarczyło. Ja robię sterownik który ma działać pod Step2Cnc - tam dostaję wektory ( w postaci współrzędnych) oraz konfigurację osi - resztę muszę policzyć sam ( całą dynamikę).

chomikaaa pisze:- czy moze tworzycie swoje oprogramowanie na wzor macha, czy tylko soft sterownika?

Mój sterownik razem z Step2Cnc będzie tworzył odpowiednik Mach'a ( jeszcze nieco uproszczony, bo Mach to potężne zwierzę). Zresztą przyświecają nam trochę inne cele - ma to być soft dużo łatwiejszy i krywający szczegóły techniczne których w Machu jest dość dużo.

Poza tym robię sterownik serwo ( oddzielny) do swojej frezarki.

chomikaaa pisze:nie rozumiem dlaczego ograniczacie predkosc.

No bo świat nie jest idealny - bramy frezarki nie zatrzymasz w miejscu - przed punktem zatrzymania musisz mieć prędkość taką która nie przełamie momentu trzymającego napędu.

- jaka strukture wykorzystujecie do regulatora pozycji predkosci momentu?

Ja mam kod PID z Emc2 ( GPL ). Nie pamiętam dokładnie, jak uruchomię to się będę tym bawił.

chomikaaa pisze:- enkoder ile impulsow inkrementuje "krok"

- w dotychczasowych eksperymentach ile trwa pelna petla programu sterownika ile to jest us i ile trwa okres jedengo ze stanow enkodera dla predkosci obrotowej max ?

- no i jakie zalozenie przyjeliscie odczyt z lpt liczycie impulsy w czasie czy inna metoda?

nie bardzo wiem do czego dazycie wiec nie wiem co pisac a chetnie dolacze sie do dyskusji w wolnych chwilach.

Regulator PID, częstotliwość pracy 2-10kHz na procesorze sygnałowym dsPIC. Mocy w bród ( 30 lub 40MHz), sprzętowy licznik do enkodera, sprzętowe sterowanie tranzystorami mocy ( procek specjalizowany do kontroli napędów ). Jak uruchomię to opublikuję źródła.

cnc3d pisze:No to do tego dołóżmy jeszcze płynną regulację prędkości potencjometrem, ograniczającą prędkość zadaną i mamy zabawę na całego. Tak naprawdę to problemów jest znacznie więcej, a to co kolega opisał to wierzchołek góry lodowej: uzależnienie skoku prędkości od aktualnej szybkości, zróżnicowane przyspieszenia, na różnych osiach itd.

No ja właśnie to uruchamiam - mam panel ( po CANie) z przyciskami oraz cyfrowymi i analogowymi potencjometrami.

Ja to robię tak - każda oś ma następujące parametry - prędkość bezpieczną ( poniżej której nie ma gubienia kroków), maksymalne dopuszczalne przyspieszenie i opóźnienie, maksymalną prędkość. Do tego dla każdego wektora dochodzą dodatkowe parametry prędkości i przyspieszenia ( w zależności od tego czy to posów roboczy, czy też "wolny"). Tak naprawdę jest to matematyka na poziomie równań kwadratowych ( potem chcę używać krzywych Beziera) - choć zanim powstał algorytm to tydzień go męczyłem w Excelu zanim liczby się zgadzały.

Cała trajektoria przeliczana jest na PC ( hamowania, przyspieszania, odcinki ze stałymi prędkościami). W tej chwili nie mam jeszcze pełnej optymalizacji, ale i tak działa to zachęcająco - w porównaniu do algorytmu w którym każdy wektor startuje i kończy na zerze.

Co do taktowania - używam stałego taktu algorytmu - na poziomie 50...500kHz ( przeliczenia robione są na konkretną częstotliwość ). Wtedy chcąc płynnie przyspieszyć/zwolnić po prostu przestrajam ten zegar ( główny procek taktuje procesory osi sygnałem zegarowym ). Docelowo również będzie można w ten sposób zatrzymać i uruchomić program bez ryzyka zgubienia kroków ( płynnie zatrzymując takt). Mam w planie również możliwość pracy w tył ( czasami potrzebne dla plazmy ).

korinsj pisze: I teraz sa schody - co jeżeli pierwszy odcinek jest długi a drugi bardzo krótki? Oznacza to że punkt hamowania na pierwszym odcinku musi leżeć wcześniej, tak aby bez problemu wyhamować na końcu drugiego odcinka. No niby OK, ale co jeśli teraz dodamy trzeci odcinek? Teraz nie muszę już tak wcześnie hamować na pierwszym bo po drugim będę miał jeszcze trzeci. Ale ten trzeci być może będzie też bardzo krótki i to na tyle że hamowanie muszę zacząć już na pierwszym.

Tej właśnie optymalizacji mi brakuje. Ale mam pomysł jak ją zrobić - trzeba będzie iteracyjnie podnosić prędkość w węzłach pomiędzy wektorami ( w stosunku do wersji w której we wszystkich węzłach zakończyliśmy na prędkości bezpiecznej).

korinsj pisze:Załączanie przez 33R, wyłączanie przez 1R. Każdy mostek z małym transformatorkiem - jedno pierwotne, cztery wtórne (dla każdego TLP). Pierwotne sterowanie bezpośrednio z flyback-a.

Dziękuję bardzo. Jeszcze pogrzebałem i w końcu kupiłem HCPL316J - aby mieć od razu zabezpieczenie ( będę robił na IGBT).

korinsj pisze:AT91SAM7SE512 + 2 kości A43L2616V. Transmisja z PC poprzez USB, wyjście na 4 osie, oprogramowanie pod Windowsy. Wejścia na krańcówki, klawiaturę, jakieś dodatkowe we/wy. Obliczanie przyśpieszania/hamowania aby utrzymać stałą prędkość liniową.

Jakich prędkości się kolega spodziewa ? Jeden procek to niestety ograniczenie ( miałem taki prototyp, działał do około 80..100kHz). Obecnie mam procka głównego ( LPC2378) plus dodatkowy procek na każdą oś ( do stabilnej generacji step/dir).

I jeszcze jedno pytanie ( pytałem już innego kolegę który też robi sterownik). Stała prędkość liniowa (jako wymaganie) wymusza czasami skokową zmianę prędkości na osiach sterowników. Mój algorytm zakłada że mam znaną prędkość bezpieczną poniżej której nie ma gubienia kroków - jak skok jest za duży to zwalniam do tej prędkości.
Działą to całkiem ok, ale czy jest jakiś lepszy sposób ? Np. zakładać dopuszczalną względną zmianę prędkości ? ( ale ta nie będzie stała w całym zakresie prędkości)

korinsj pisze: 5. Aha i do czego to ma być zastosowane. - Frezarki, tokarki, plotery CNC - mam na dziś kilka rzeczy do uruchomienia. Główny sterownik (ARM+dużo SDRAM) już prawie mam gotowy, soft pod Windowsy też. Teraz robię właśnie "końcówki" dla silników krokowych i DC. Główny sterownik daje "standardowe" impulsy a ja, w zależności od silnika zmieniam tylko końcówkę sterującą.

Widzę robimy podobną rzecz - może kolega opowie co więcej ? ( ja też mam główny sterownik na ARMach, ale chyba w nieco innej konfiguracji).

korinsj pisze: . Jaki dead time, jaki opornik w bramce - moje sprawdzone rozwiązania, na dużych układach przetwarzania energii. Bramki steruję przez "odpowiednio" łączone TLP250, z rozbudowanym układem załączania/wyłączania tranzystora (ograniczenie stromości zboczy przy załączaniu, a szybkie wypompowanie ładunku z kondensatora bramki tranzystora przy wyłączaniu). Do tego dead time-y zaszyte w logice.

Czy kolega traktuje je jako prywatne, czy też byłby skłonny pokazać samą tę końcówkę mocy ? Chcę przerobić UHU na TLP250 i miałem wątpliwosci zarówno co do formowania impulsów jak i zasilania ( chcę dać mały prosty DC/DC na transformatorze )