SVARFORUM.cz - forum o svářečkách a svařování

G a M jsou První písmena příjmení majtelů, přičemž to M je poč. písmeno příjmení majtelky.

To vážně nebo je to nějaký vtip?

To už  musí  být poznat podle hmotnosti  hned,  jak  to  člověk  vezme do  ruky. Zvláště když  mění  starou součástku  za novou...
Spíš mně připadá pravděpodobnější přetiskování výkonových  tranzistorů,  pokud je levnější méně výkonný  ve stejném  pouzdru jako  drahý  a výkonný.
Co  se týká  GME,  tak  to  je poměrně velká  firma 100 - 200 zaměstnanců a roční obrat 200 - 300 milasů.  V roce 2018.  novější  údaje jsou  placené. připadá  mi,  že v roce 2017  a 2018  se zhoršuje.

Pafiku1605, to snad ani ne. Odhalit takovéto zvěrstvo s kondenzátorem v současné době je do první konstrukce kde to nebude chodit. Spíš bych očekával nákup extra levně součástek s zoxidovanýma nožičkama (součástka se má do 6 měsíců od výroby zapájet, jinak není vhodná pro sériovou výrobu). Součástek na který pršelo, vykoupali se ... Prostě něco co nevadí u ruční výroby, nebo se při pájení ručo skryje. Nebo kde se ví, že životnost je pochybná, hodnoty na kraji či těsně mimo toleranci a nejdou lehce změřit.

K tomu kondenzátoru jsem viděl něco podobného s hardiskem od čínana, kde uvnitř byla napájena usb flash. Jak to bylo s kapacitou si lehce každý sám domyslí.

Editoval Charon (21-04-2022 20:16:04)

davidma: posun je řešen pomocí krokového motoru, napájení 48V, 5.6A. Řízení pomocí PIC procesoru (alternativou by byl Atmel), snímání natočení vratidla pomocí 1024krokového dekoderu bez Z signálu, Z signál bude generován magnetem připevněným na vratidle.  Odečet informací budena na dispeji. Ovládání přes klávesnici. Posun od do, stoupání, digitální odečet natočení vratidla ve funkci úhloměru. Řezání pravých i levých závitů.

KMU1 napsal(a):

VašekP: Proto jsem to napsal "do měděné plochy tišťáku". Kde měď není, tam není (když třeba pominu tišťák z teplovodivé keramiky...)
Radim: když dlouhé nohy, tak na ně přidělat chladící křidélka, tepelná vodivost mědi(nožička) a plastové zálivky (tělo součástky) je nesouměřitelná! V zenerce se teplo emituje veprostřed na styku nožiček, na rozdíl od typických odporů, kde je to na povrchu.
"Pafíkův" kondenzátor mám také, jen jako superkondenzátor 10F.

Tak  ty zenerky včetně jejich  přívodů  jsou  určitě dimenzovány tak,  aby se batstlíř  do  ztrátového  výkonu  zaručeného  datasheetem a do  uváděných  teplot s žádným  takovým  přídavným  chladičem  nemusel  pinožit. Bohužel  i  dnes prodávané  zenerky jsou  staré  součástky a tudíž jejich  datasheety nejsou  tak  podrobné  jako  třeba datassheety nových součástek,  jako třeba nových mosfet  tranzistorů.  Například vysoce výkonové  Mosfety s velmi  malým  odporem v propustném  stavu  jsou  běžně dávány do pouzder  D2pack. Například IFR3205S má v tomto  pouzdru uvnitř pouzdra   maximální  výkon  200 watt,  což  zhruba odpovídá  uváděnému  tepelnému  odporu 0.75 stC/watt. Ale zapájen v plošném  spoji  za podmínky "When mounted on 1" square PCB ( FR-4 or G-10 Material )." má  tepelný  odpor 40 stC/watt,  což  odpovídá  maximálnímu  ztrátovému  výkonu necelé  4 watty. Holé pouzdro  bez  zapájení by mělo  mít maximální  ztrátový  výkon odhadem tak 1 - 2 watty. Pokud se ještě na ten  plošný  spoj  kolem  součástky použije přídavný  chladič, kdsei  jsem  tu  možnost  viděl, měl  by se ten  ztrátový  výkon  zlepšit tak  o 1 - 2 watty.

https://www.gme.cz/data/attachments/dsh.915-075.1.pdf

E-Ryc napsal(a):

treba by se z toho dalo neco vytezit: https://robotika.vosrk.cz/guide/sensors/decode/cs

Jestli jsem to dobře pochopil, tak hodnota pozice je 16bit. Pro polohování to chce určitě vždycky 32bit a přepočty pozice dělat v šířce 64bit.

Ale ta rutina je jinak pěkná a určitě se někde hodí.



Na pohyb po menu pomocí enkoderu s nízkým rozlišením používám modul, který obsahuje výňaték kódu uvedený níže. Součástí modulu jsou pak autorizované funkce ke čtení pozice, stisku, nastavení mezí, apod... Počet vyhodnocovaných hran se volí pomocí makra.

typedef uint8_t encpos_uint_t;


static volatile struct
{
    uint8_t sw;
    uint8_t sw_change;
    encpos_uint_t pos;
    uint8_t pos_change;
    uint8_t track_a;
    uint8_t track_b;
    uint8_t cw;
    uint8_t ccw;
    encpos_uint_t inc;
    encpos_uint_t min;
    encpos_uint_t max;
}encoder, e_old;


void ENCODER_updateTracks()
{
    encoder.cw = 0;
    encoder.ccw = 0;

    encoder.track_a = ENCODER_READ_TRACK_A();
    encoder.track_b = ENCODER_READ_TRACK_B();    

    
    if (encoder.track_a != e_old.track_a)
    {
        if (encoder.track_a)
        {
            if (encoder.track_b)
                encoder.ccw = 1;
            else
                encoder.cw = 1;
        }
#if defined(ENCODER_EDGE_EVAL_2) || defined( ENCODER_EDGE_EVAL_4)
        else
        {
            if (encoder.track_b)
                encoder.cw = 1;
            else
                encoder.ccw = 1;
        }
#endif
    }
#ifdef ENCODER_EDGE_EVAL_4
    else if (encoder.track_b != e_old.track_b)
    {
        if (encoder.track_b)
        {
            if (encoder.track_a)
                encoder.cw = 1;
            else
                encoder.ccw = 1;
        }
        else
        {
            if (encoder.track_a)
                encoder.ccw = 1;
            else
                encoder.cw = 1;
        }
    }
#endif
}



void ENCODER_updatePosition()
{
    ENCODER_updateTracks();

    if (encoder.cw)
    {
        encoder.pos += encoder.inc;
            
        if (encoder.pos > encoder.max) encoder.pos = encoder.min;
    }
    else
        if (encoder.ccw)
        {
            encoder.pos -= encoder.inc;
                
            if (encoder.pos>encoder.max || encoder.pos<encoder.min) encoder.pos = encoder.max;
        }
}



void ENCODER_update()
{
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
    {
        ENCODER_updatePosition();
    
        encoder.sw = ENCODER_READ_SWITCH();
        encoder.sw_change = encoder.sw != e_old.sw;
        encoder.pos_change = encoder.pos != e_old.pos;
    }        
    
    e_old = encoder;
}

Editoval davidma (22-04-2022 10:27:49)

Ano, je to periodicky volane.

U toho mag.enkoderu bych měl obavu z rychlosti a přesnosti pozice. Kromě toho může být i probléme zástavba.

Zpětná vazba o vyšším rozlišení 1024-2048imp je nutná pro dobrou dynamiku polohování...prostě máš té informace "víc", takže můžeš agresivnějc regulovat a nemusíš čekat, až se něco někam dovleče bez překmitu.

64bit je nutnost pro přepočty (krok <--> um) přes převodové poměry a stoupání šroubu. Navíc když pracuješ v pevné řádové čárce cca x10000, tak ti 32bit snadno přeteče. Toto je osobní zkušenost z poslední akce (závitořez - krokáč s nastavením kroků 1000imp/rev a převodem 1:3 do pomala).

Použití rovnou 32bit MCU je asi nejlogičtější, ale tady mi asi brání lenost se nějaký nový naučit .

Až to budeš mít v k kupě, tak určitě udělej nějaký video .

Je fakt, že syrové počítání pulzů zvládneš přes periferii čítače, jehož jediné přerušení bude generováno jako "overflow". Což v případě např. 8bit čítače znamená dělení vstupní frekvence /256 a to ti dá dost času na zbytek věcí. V rutině přerušení je pak jenom inkrementování pozice o +256. Výsledná celková pozice je pak načítaná pozice (z přerušení) + aktuální stav čítače.


Na závitořezu (Atmega2560) jsem používal 16bit čítač, jehož obsluha v přerušení byla triviální:

volatile static int32_t g_counter5_valueHigh;

ISR(TIMER5_OVF_vect)
{
    g_counter5_valueHigh += 0x10000;
}

Editoval davidma (22-04-2022 11:21:40)

Nene, signál z enkodéru je veden na vstup MCU, jenž je vnitřně veden na HW periferii - v mém případě čítač 16bit. Uvedené přerušení se vyvolá pouze po přetečení čítače - tzn. při příchodu impulzu (respektive jeho hrany), když je aktuální stav čítače 65535. Je to přechod z hodnoty 65535->0. V přerušení se inkrementuje hodnota pozice o 65536. Takže pokud na můj vstup přivedeš frekvenci ~65kHz, bude se volat obsluha přerušení každou ~1s.

Ten PIC bude mít taky nějaký vnitřní čítač/časovač, ne? Buď 8bit nebo 16bit.

Charon>
Uplne presne tenhle model jsem nepouzival (ten muj mel i kvadraturni vystup), muzu zkusit nekde doma najit, pokud by to nekoho zajimalo. Pro predstavu, magnet byl na vstupni hrideli RC modelu auta (tam co je normalne motor), do rychlosti cca 2m/s to stihalo, vic jsem nezkousel - z motoru byl schvalne extra prevod do pomala, aby to o moc vic nebylo schopne jet ani naplno - proste aby se to dalo dobehnout, kdyz se software zblaznil

Rychlost nevim (a v datasheetu jsem to zbeznym pohledem nenasel), proto jsem psal "na polohovadlo", bezici vreteno by to zrejme nedalo, ale na to to ani neni urcene. Na pohonu sroubu pro "CNC zavitovani" uz bych si to predstavit umel.

Ty citace funguji na vsech jednocipech vicemene stejne.

Chci mít napevno svázané otáčení vřetene s posunem a tím odstranit chybu, pokud se rychlost otáčení zhoupne. Jinak řečeno, když zajede nůž do materiálu, tak se může rychlost zhoupnout a řízení přes frekvenci nezareaguje dost rychle. Vím, že to tak někteří mají udělaný, ale nevidím to jako dost robusní řešení.

Přistupuji k tomu tak, že zadam požadované stoupání na jeden závit  na klávesnici a procesor mi napíše maximální možné otáčky. Ty pak před samotným řezáním závitu zkontroluje a pokud budou vyšší než maximální, tak řezání závitu nezačne a zahlásí chybu. Nřešim zda metrický či jiný závit, to je o tabulkách. Možná udělam v menu možnost přednastavených hodnot pro nejběžnější hodnoty - ale to je už jen kosmetika a hraní si. Jádro bude stejný.

Před řezáním závitu zpočítám kolik pulzu od vřetene generuje jeden krok. Pracuji na setiny pulzu. Tak například pro potřebných 10,3 pulzu na krok pujde 10 pulzu, pak 11 pulzu, pak 10, pak 10 .... Prostě se bude průběžně korigovat odchylka.

Editoval Charon (22-04-2022 13:51:12)