Mjerenje vremena isklopa FID sklopke

news: snipped-for-privacy@googlegroups.com... Pozdrav,

isklopa FID sklopke, je li ima neka formula ili?

-----------

Uz to brzina ovisi i o struju, odnosno prirastu diferencijalne struje u vremenu.

Dana nedjelja, 28. svibnja 2017. u 16:01:02 UTC+2, korisnik Petar Bjel?

o sam referat

vrijeme

?.

news: snipped-for-privacy@googlegroups.com...

napisao je:

Ja bih posudio Fluke-a :)

news: snipped-for-privacy@googlegroups.com...

napisao je:

------------

Izvorom napajanja i counterom.

Fidovku na stolu ispitas i bez 230V Ne treba kroz oba voda ici struja, ona vidi samo razliku. znaci dosta je struju gurat u jedan vod.

Struja naravno treba bit istosmjerna, kod izmjenicne ce ionako isklopit za trajanja poluperiode. Dakle treba izmjerit vrijeme koje je potrebno kad ukljucis neku struju, da fidovka izbaci. Vidi sklop:

Laboratorijski izvor napajanja namjestis na 10 -15V, to napaja i logicke sklopove Struju podesis da bude dosta za logicke sklopove u startu, par mA, a manje od praga izbacivanja.

diagram napona je sa strane, i sve je jasno.

oscilator sa inverterom i kvarcom, posto ima viska invertera. Na izlazu logickih vrata pojavit ce se upravo toliko impulsa od 1Mhz koliko je fidovki trebalo da izbaci. I to broji counter, svaki impuls koji izbroji je 1 mikrosekunda, znaci ako izbroji 10 000 impulsa, fidoovka je izbacila za 10 milisekunda. Vrijeme izbacivanja ovisi i o struji.

Counter i function generator u nuzdi moze zamjenit zvucna kartica i softver, naravno tada osim 1MHz pustas 1khz i princip isti. Izvor regulirane struje moze zamjenit obicno DC napajanje i otpornici.

news:ogi11h$enn$ snipped-for-privacy@ls237.t-com.hr...

Promako mi jedan bug.

Naime stiskanjem tastera, ce nestat napona na logickim sklopovima dok fidovka ne izbaci.

napajanje iz konda dok fidovka ne izbaci i ne ukloni kratak spoj, a dioda sprecava praznjenje u drugom pravcu.

I Debounce tipke zbog 'iskrenja' kontakta? Mogao bi dobiti jako cudne rezultate?

Nema iskrenja kod te struje i napona bez reaktivnih komponenata sa +jot, a i da ima, iskrenje ili stvara ili ne stvara kontakt, i to mora biti dio mjerenja, odnosno i iskrenje ako nastane je dio vremena izbacivanja.

/cut

Iskrenje u navodnicima! Jednom davno sam na SHARP-racunalu pisao igricu u strojnom kodu. Najvise sam se namucio oko toga efekta:

Ajd nemoj zaebavat, taj sharp nije ni imao ulazno izlazne jedinice za

i nikakvu interaktinost softvera i tih velicina nije mogla postojat. A da si piso kod, on ne pretpostavlja unapred nikakve efekte, vec postoji samo efekt napisanog kad dodje do izvrsavanja.

Pero, hebala me TIPKOVNICA, tj. strelice! Pisao sam kod za TETRIS, pritisnem gornju, a ono figura se vrti k'o na

jer je jedan pritisak ustvari bio 5-6 'impulsa'....

To moze biti i posljedica toga da se u petlji tipke ocitavaju puno puta u sekundi pa se i 'cisti' pritisak na tipku registrira stalno iznova a rjesenje je zabraniti pozive za izvrsavanje rutina za obradu pritisaka tipki sve dok se tipka cija je akcija jednom izvrsena najprije ne pusti ili treba napraviti simulaciju 'ponavljanja tipke' kod drzanja.

U slucaju Tetrisa treba napraviti ovo drugo jer drzanje tipke mora uzrokovati visestruko pomicanje ili rotaciju s tim da pauza izmedju prvog pritiska i sljedeceg 'ponavljanja tipke' mora biti veca a sve daljnje pauze moraju biti krace - slicno ko kad se stisne pa drzi gumb na PC tastaturi.

Ovdje mozes vidjeti primjer moje rutine koja radi upravo to:

Trazi 'typematic rate'.

legure.

pobrojat mikrosekunde svih 100 prekida-ukapcanja,

bilo kontraproduktivno. Svaka prelazna pojava koja uspori izbacivanje treba biti registrirana, i to sklop moze ucinit.

U tom tvom kodu je bilo sve u redu sa izvrsavanjem, jel osim jednog klika nastalo pet klikova, i jesu tih 5 klikova registrirani - jesu ! To sto tebi oni ne trebaju, to je tvoj problem, meni trebaju i ne trebam nista cinit da ih sprijecim.

Ne piskaram ja o kontaktu fidovke, nego o onom prekidacu na tvojoj shemi koji 'upravlja' brojilom!

Upravo to je bio problem: Pritisnes tipku, softver to obradi.

pa opet da je 'ponovo' pritisnuta i nova obrada itd.....

Ubacio sam kasnjenje od mislim 100-njak ms za pritisak i otpustanje tipke. Znaci, pritisnuta tipka, cekaj 'deltaT' i ponovo provjeri, i isto za otpustanje....

Prouci onda dobro i vidjet ces da on nema nikakvog utjecaja na propustanje impulsa, pa cak i da ga 100 puta uspijes toliko kratko pritisnut da fidovka ne uspije izbacit. On ce istina dat logicka stanja, ali radi se o and gates, i dok i fidovka ne da svoje logicko stanje, prolaska impulsa kroz kapiju nema.

Po fidovki je brojanje moguce sve dok ne izbaci...

Istitravanje je jedno, za to treba debounce. Ali ovo o cemu ja govorim je problem koji se javlja cak i kad nema istitravanja i koji se desava zato jer covjek tipku ne moze pustiti tako brzo da rutina za skeniranje stanja tipke ne bi ko zna koliko puta uzastopno procitala da je tipka stisnuta i pozvala rutinu koja bi se inace trebala pozvati jednom.

A u Tetrisu se kod drzanja tipke mora pomak ili rotacija desiti jednom pa se nakon pauze od recimo sekunde, u slucaju da se tipka i dalje drzi stisnuta, mora pomak ili rotacija ponavljati brze, recimo dva puta u sekundi - znaci da rutina mora voditi racuna o inicijalnoj pauzi koja mora biti duza i o pauzi koja kontrolira daljnja ponavljanja koja mora biti kraca.

To je jedan od najjednostavnijih nacina software-skog debounce-a koji radi ali ako se ne koristi interrupt onda nepotrebno trosi processorsko vrijeme i pogodan je eventualno za ocitavanje tipki kod kretanja kroz menu gdje takav algoritam nece narusavati responsivnost. U slucaju gdje sistem mora na pritisak reagirati cim brze i u realnom vremenu takav algoritam ne dolazi u obzir jer bi se sa 100 ms pauze nakon svakog skeniranja tipke ocitavale sporije od 10 puta u sekundi a stavljanje pauze unutar programa predstavlja bacanje processorskog vremena pa ako bi hardware bio taman na granici da moze raditi bi se zbog toga moglo desiti da hardware postane 'peslab'.

U mojoj rutini na koju sam dao link mozes vidjeti jedan od nacina kako se stanja tipaka mogu ocitavati puno brze (recimo 50 ili 100 puta u sekundi), bez bacanja processorskog vremena (nema pauze koja bi zaustavljala glavni program a skeniranje tipaka se desava paralelno unutar interrupt rutine koja je kratka i brza) i uz algoritam koji omogucava i ponovna automatska 'okidanje' pritisaka na tipku kod drzanja uz mogucnost podesavanja inicijalne i daljnih pauza.

Postoje i slucajevi kada debounce nije potreban - recimo kada nas ne zanima sta se je desilo nakon pritiska, npr. kada je 'tipka' ustvari signal s gljive za slucaj opasnosti kakve postoje na strojevima. Iako bi se i tu debounce mogao koristiti da se eliminira mogucnost laznog ocitanja koje moze nastati zbog elektromagnetskih smetnji, bolje je takvu mogucnost otkloniti (npr. s ispravnim dimenzioniranjem pull-up otpornika) a ne koristiti debounce jer ce se tako sve sta treba napraviti u slucaju opasnosti (zaustavljanje motora, iskljucivanje nekih relay-a, ...) desiti za jedan interrupt-ciklus brze.

Sta se tice Tetrisa, tu se izmedju dva osvjezavanja stanja na ekranu ima relativno puno vremena ali kod pauze od desetinke sekunde se moze desiti da se tipka koju je netko drzao 0.09 sekundi ne registrira a drzanje tipke od skoro desetinke sekunde se mora ocitati. Istina je da ce se to desiti samo ako covjek tipku stisne bas u trenutku kad program nailazi na ocitavanje tipke iza koje slijedi pauza a to ce se desiti samo u malom broju slucajeva (a isto tako ce se rijetko desiti i da tipka bude stisnuta manje od desetinke sekunde) ali takvu mogucnost treba izbjeci.