Projekt: driver silników korkowych

jarekk pisze:Schemat sterownika - bez bazowego zasilacza ( dającego +5V,+15V i +40V )

Zadam Koledze proste pytanie: co stanie się z układem, kiedy zawiesi się procesor?

Leoo pisze:Zadam Koledze proste pytanie: co stanie się z układem, kiedy zawiesi się procesor?

Jest to układ specjalizowany do obsługi sterowników silników. Po zwieszeniu się procesora i wystąpieniu przeciążenia prądowego ( no bo to jest tu zagrożeniem) układ PWM sprzętowo przełączany jest w tryb awaryjny.

Konfiguracja PWM jest ustalana na początku pracy i specjalnie "zatrzaskiwana" aby przypadkowo jej nie naruszyć. Jako zabezpieczenie sprzętowo konfigurowany jest "overcurrent fault override" który ustala stan pinów PWM we wcześniej skonfigurowany sposób.

Instrukcja PWM'a liczy 130 stron i zawiera tryby pracy o których nie myślałem że ktoś się pokusi o implementację w sprzęcie. Dlatego siedzi tam dsPIC a nie któryś z Cortexów ( wtedy zwieszenie procesora byłoby faktycznie niszczące dla układu).

http://ww1.microchip.com/downloads/en/D ... 70645C.pdf

Cytat:

The following list describes major functions of the fault input pin:
• A fault can override the PWM outputs. The FLTDAT<1:0> bits (IOCONx<5:4>) can have a
value of either &#8216;0&#8217; or &#8216;1&#8217;. If FLTDAT is set to &#8216;0&#8217;, it is processed asynchronously to enable the
immediate shutdown of the associated power transistors in the application circuit. If
FLTDAT is set to &#8216;1&#8217;, it is processed by the dead time logic and then applied to the PWM
outputs.

14.10.1 Class B Fault
Certain devices incorporate a fault that has been implemented with Class B safety features,
which is known as the Class B Fault. This fault operates in a similar manner as other faults, with
the exception that on any type of reset, the PWM module maintains ownership of that pin. Refer
to the &#8220;High-Speed PWM&#8221; chapter in the specific device data sheet for the fault that incorporates
this feature.
At reset, this fault is enabled in Latched mode to guarantee the fail-safe power-up of the
application. The application software must clear this fault before the PWM module can be
enabled. To clear the Fault condition, this fault pin must first be pulled high externally, or the
internal pull-up resistor in the CNPUx register can be enabled. Once the Fault condition is
cleared, the PWM module can be enabled, and if desired, the fault can be disabled.


To wszystko wciąż nie gwarantuje 100% zabezpieczenia, ale powinno pomóc w 99,9% przypadków.

[ Dodano: 2012-10-25, 09:03 ]

piotr_olbrysz pisze:

jarekk pisze:Schemat sterownika

Witam.
Osobiście , na wejściach transoptorów daję diody typu 1N4148 ( ale SMD) połączone równolegle z diodami , aby chronić diody przez przebiciem. Takie diody dają też chińczycy.
Wyjście portu szeregowego nie zawiera drivera typu MAX232 ?.Dałbym na komunikacji izolację galwaniczną na identycznych transoptoarch, np z użyciem układu FTDI po drugiej stronie, lub/i RS485.
Mam nadzieję ze dywagacje akademickie na temat palenia TB nie zniechęcają kolegę do pisania i tworzenia nowej konstrukcji.

Diody dodam - nigdy nie udało mi się upalić transoptora w ten sposób, ale jest to jak najbardziej możliwe i prawdopodobne.

Układ ten jest prototypem - dlatego nie ma jeszcze pełnej obłsugi portu szeregowego. Jeżeli się sprawdzi to powstanie wersja 3 osiowa w której rs232/usb pojawi się napewno, bo algorytm który zamierzam stosować wymaga konfiguracji indukcyjności i oporności silnika ( oprócz samego prądu ). Ze względu na rozrośnięcie się układu pewnie powstanie wspólny zasilacz natomiast osie będą na osobnych płytkach tak jak jest teraz. Komunikacja będzie wtedy na płytce zasilacza - FTDI ( jedno lub wieloportowy), może też galwaniczna izolacja USB ( układ Analog Devices Adum3160 )

jarekk pisze:może też galwaniczna izolacja USB ( układ Analog Devices Adum3160 )

PikoCnc jest zrobione w ten spoób, że po stronie PC jest FTDI, później opto i procesor.
Prędkość transmisji prawie 1Mbit

Mam pytanie z boku. Jakie środowisko programistyczne używa kolega do programowania tego dsPic? bo coraz bardziej zaczyna mi się podobać.

Dorzuciłem notę aplikacyjną, bo zauwazyłem że TI daje w szereg z diodą (driver) mały opornik,

Większość ludzi ( ja również) używamy firmowego środowiska od Microchip'a - Mplab IDE. Zawiera dość surowy debugger i edytor ( używam zewnętrznie Source Insighta) oraz kompilator C ( trzeba dograć, bazowany na GNU ). Kompilator jest bezpłatny w wersji podstawowej, za komercyjną jest dopłata ( dorobili jakąś optymalizację, ale według mnie nie warto za to płacić - nwet bazowa wersja jest OK ).

Niedawno odświeżyli IDE - wyrzucili swojej, jest nowe bazowane na NetBeans. Wygląda lepiej, ale na mój gust jeszcze muszą nad nim dopracować ( chodzi o ergonomię - choc może jest to bardziej efgekt przyzwyczajenia się do poprzedniej wersji).

Do tego potrzebny jest debugger - najlepiej ICD3 ( ICD2 jest zauważalnie wolniejszy, choć bardzo tani bo ludzie zaczęli produkować klony). Ja mam RealICE'a - ale tylko dlatego że w jednym z projektów trafiłem na błąd ICD2 który powodował permanentne blokowanie procków które dopiero RealICE był w stanie naprawić. RealICE i ICD3 są tak samo szybkie, ICE ma dodatkowe możliwości które jednak są rzadko potrzebne. Generalnie - procki Microchip'a nie mają tak dobrego debugginngu jak ARMy. Nie mają niezależnej celki debuggowej - prawdopodobnie wszystko odbywa się poprzez "exception" w procku oraz jakiś wbudowany kod.


http://www.microchip.com/pagehandler/en ... ly/mplabx/


PS. Jeżeli kolega ma duzo czasu to mam do oddania uszkodzony ICD3 - prawdopodobnie bufory wyjściowe. Byłoby trochę zabawy w znalezienie ich ( nie widziałem na sieci schematu), ale są szanse że da się reaktywować.

jarekk pisze:PS. Jeżeli kolega ma duzo czasu to mam do oddania uszkodzony ICD3

Nie mam za duzo czasu, ale dziękuję za propozycję.
Parę lat temu wdałem się w Ziloga, ale chyba poszedł z torbami ( jest częścią IXYS). Muszę ciągnąć parę projektów na Zneo i ez8. Od czasu do czasu patrzę co robi microchip, ale ten MpLab jak kolega mówi trochę ciężki. Ale zobaczę jak to obecnie wyglada. Najbardziej podoba mi się środowisko IR, tylko ta cena... i nie wiem czy obecnie robią na microchipa.

jarekk pisze:Jest to układ specjalizowany do obsługi sterowników silników. Po zwieszeniu się procesora i wystąpieniu przeciążenia prądowego ( no bo to jest tu zagrożeniem) układ PWM sprzętowo przełączany jest w tryb awaryjny.

Konfiguracja PWM jest ustalana na początku pracy i specjalnie "zatrzaskiwana" aby przypadkowo jej nie naruszyć. Jako zabezpieczenie sprzętowo konfigurowany jest "overcurrent fault override" który ustala stan pinów PWM we wcześniej skonfigurowany sposób.

Instrukcja PWM'a liczy 130 stron i zawiera tryby pracy o których nie myślałem że ktoś się pokusi o implementację w sprzęcie. Dlatego siedzi tam dsPIC a nie któryś z Cortexów ( wtedy zwieszenie procesora byłoby faktycznie niszczące dla układu).

Zapomniał Kolega dodać, że takie były założenia Producenta... później wyjdzie errata i okaże się, iż nie wszystko działa jak na papierze
Do czego zmierzam: Kolega zmagał się z gatedriverami IR, które wykazywały zdolność do uszkadzania się razem z kluczami, bez wyraźnej przyczyny, bądź były źródłem uszkodzeń. Moja teoria w w/w względzie jest taka: problem powstaje z chwilą wysterowania górnej gałęzi mostka na dłuższy czas (zanik sygnału PWM). Po pewnym czasie, napięcie zasilające bramkę spadnie do poziomu, przy którym wejdzie on w liniowy zakres pracy, po czym odparuje jego struktura, zabierając ze sobą gatedriver. Zaradzić temu można sprzętowo i to dość tanio. Wystarczy zbudować najprostszą pompę ładunkową zasilaną z napięcia, z którego sterujemy bramkami. W trzech słowach: generator np. 20kHz (NE555), dwa kondensatory i cztery diody małej mocy.

Leoo pisze:W trzech słowach: generator np. 20kHz (NE555), dwa kondensatory i cztery diody małej mocy.

Znam ten układ - miałem go na jednym ze swoich prototypów. Dodanie go spowoduje że mi się chyba w Eaglu skończy licencja na potrzebną powierzchnię PCB

http://www.irf.com/technical-info/appnotes/an-978.pdf
http://www.ti.com/lit/an/slva444/slva444.pdf


Jak tak na to wszystko patrzę to czasami mi się wydaje że prościej ( i nawet nie jakoś drożej) jest zamówić transformator z 5 napięciami zasilania i wyp...ć wszelkie wynalazki - włozyć TLP351 czy podobny i śmigać

http://www.tme.eu/pl/Document/037848d50 ... 351(F).pdf

Swoją drogą - ciekawe czy by dało zrobić tak: charge pump + taki TLP - bez niczego innego. Nie widziałem takich projektów, trzeba by policzyć czy tak da radę z wydajnością prądową

Ten TLP wygląda nieźle, chociaż ma długi czas propagacji (700ns).
Można też użyć sterownika HIP4081A - jest bardzo szybki; nawet w datasheecie w zastosowaniach jest "high performance stepper motor drivers".

ursus_arctos pisze:HIP4081A - jest bardzo szybki

Sprytny - ten się już nie wyłączy - "charge pump" dostarcza 30uA podczas "postoju"

Jest dość drogi - na farnellu 30zł - ale na alledrogo można go kupić za 17zł. Obudowa DIP20 albo SOICW20. Wersja DIP jest RoHS, wersia SOIC niestety nie (niestety dla komercyjnej produkcji).