Ez az a topic ahol elfér az ilyen, hiszen szervesen kapcsolódó téma.

Előzmény: celophant, 2010-10-12 18:20:00 [885]

Csak egy gondolat volt... De nem szemetelek ide. Megcsinálom amit találtam, aztán publokálom...

Előzmény: svejk, 2010-10-12 18:18:00 [884]

Ezek annyira agyon vannak már integrálva, hogy szinte csak a soros, manapság USB kimeneti porthoz férsz hozzá, ami már eleve lelassítja a további feldolgozást.

Előzmény: celophant, 2010-10-12 16:32:00 [881]

Az opto kapuk helyére kötném az encodert...

Előzmény: celophant, 2010-10-12 16:32:00 [881]

Nagyon kicsi a felbontása. Tekerheted mint őrült, vagy nem tudsz elég finoman lépkedni vele.

Előzmény: celophant, 2010-10-12 16:32:00 [881]

Sziasztok!

Az egerekben lévő elektronikát, nem lehet felhasználni az encoderekhez? Vagy túl lassú?
Találtam hardveres megoldásokat, de lehet, hogy a PIC-nél maradok... az sem drága 500-800 Ft kb.

Oké!
Azt árulják, és nem én csináltam.

Előzmény: svejk, 2010-10-11 09:33:00 [879]

Aha, értem...
Ilyen PC nélküli mozgásvezérlőt step-dir kimenettel a Klavio KFT is árul.

Előzmény: celophant, 2010-10-11 09:24:00 [878]

Szia Svejk!
Van egy új proci, a (Nuvoton Cortex M0). Sneci vezérlői közé töltöttem fel képet róla. Egy videó is volt, amin kiszúrtad, hogy a kondi fel volt fújódva. Egy motorvezérlő készül… szervó, léptecs vezérlő… ami képes PC nélkül is üzemelni. Egy BF20-ason akarom kipróbálni, hogy ne kelljen kézzel tekergetni… Nem CNC-sítés. De be lehessen állítani, lépéstávolságokat, amit automatikusan megcsinál. Minek a PC, ha gyorsan meg akarsz csinálni valamit. Van egy ötletem a kopott orsó szoftveres kiküszöbölésére is. Ha túl sok akadályba ütközöm a procival kapcsolatban, akkor megcsinálom sima PIC-el, ahhoz van egy csomó segítség. Sok mindenről nem tudom, hogy működik, csak sejtem, ezért más megoldások születhetnek, mint a mérnökök gondolnák . Röviden ennyi lenne.

Előzmény: svejk, 2010-10-10 22:56:00 [877]

Bocsi, mit is tervezel Te most?

Előzmény: celophant, 2010-10-10 22:25:00 [875]

Neki mindene van )
A talin is árulta szerintem...LS7184
A/B incrementből csinál Step/dir-t.

Előzmény: celophant, 2010-10-10 22:07:00 [872]

PIC-hez találtam egy csomó megoldást… ASM kódot is… mondjuk elég furán nézne ki a dolog, ha PIC végezné a számlálást és az ARM a motor vezérlést…

Valószínű, hogy külső számláló lesz a megoldás. Kevés információm van az ARM-el kapcsolatban.

Előzmény: sneci, 2010-10-10 22:14:00 [873]

Ha külső számlálót akarsz használni, akkor ok. De ha a NuMicro számlálóját akarod bevetni, azt meg kell nézni, hogy az órajel mellett a DIR is kihozható-e port egy pinjére.

Előzmény: celophant, 2010-10-10 21:30:00 [864]

Varsának vannak ilyen encoderhez való IC-i?

Előzmény: svejk, 2010-10-10 21:54:00 [869]

Én is az LSxxxx sorozatban találtam megoldást…

Előzmény: svejk, 2010-10-10 21:54:00 [869]

Köszi!
Megnézem. Ha lenne esetleg egy linked…

Előzmény: svejk, 2010-10-10 21:46:00 [868]

Csak úgy találomra: a digitális szűrs elve a 13. oldalon majd minden encoderfeldolgozó ezt az elvet használja.
Persze van Pl. a Varsányi féle LSxxxx IC-k ott csak egyszerű RC tagok vannak, de az is jól bevált.

Előzmény: celophant, 2010-10-10 21:30:00 [864]

Van egy régi-régi bevált hardveres dekódoló még GAL-ra. Annyi hogy külső órajelet igényel.
De a HEDS optikák kapcsán (adatlapok) is sok alapkapcsolást lehet találni.
Mindnek közös jellemzője, hogy Lath-ekből van felépítve, a zavarszűrés.
Valahol egy 1-2 éve már linlkeltem róluk, szerintem ebbe a topicba.

Előzmény: celophant, 2010-10-10 21:30:00 [864]

A Mach3 helyből lekezeli csak legyen elég LPT bemeneted.

Előzmény: n/a (inaktív), 2010-10-10 21:35:00 [866]

...MACH alá természetesen...

Egy sima encoder-ből lehet kézikereket készíteni?

Kell még hozzá valami kütyü, vagy elég az encoder?

Szia, Sneci!

Találtam egy pár megoldást hardveres dekódolásra. Két bit-et kell figyelni, ami csak az irányt jelzi CW-CCW. Így nem kell szoftveresen dekódolni… csak a számlálót kell irányítani. Holnap megyek a Lomex-hez, alkatrészekért. Kipróbálom a dolgokat…

Video

Azt hiszem szemlélet beli különbség van köztünk. Nekem egy kétcsatornás relatív digitális pozíció mérőeszköznél nem a Gray kód jut az eszembe elsődlegesen, hanem a sin-cos analóg függvényelmélet digitalizálási szabályai alapján képzett, és eredményül kapott fázis eltolt két jel (quadrature encoding).
A klasszikus Gray kódolást ahogyan ezt már írtam a sokcsatornás (és nem csak 2) abszolút útmérőeszközökhöz sokkal inkább kötném, de ott is csak mint mellékes dolog a biztonságosabb adatátviteli segédleteként, és nem a működési elvük lényegeként. Itt van talán a fő nézőponti különbség köztünk.
De azt hiszem túl is tárgyaltuk ezt a témát, és ami a lényeg, sikerült szakmai síkon tartani a vitát. Persze Téged már ismerve ez nem is volt nehéz.

Előzmény: sneci, 2010-10-10 15:26:00 [862]

De attól még az A és B Gray kódolású, és itt is előnyös az a tulajdonsága, hogy nincsenek hazárd veszélyes kettős átmenetek. Ezt a kódot természetesen nem a Gray tárcsához találták ki, csupán alkalmazzák itt is, mint sok más helyen.
De tényleg felesleges erről vitázni...

Előzmény: Törölt felhasználó, 2010-10-10 11:31:00 [860]

Szia Tibor45!

Itt egy link!
Most nincs sok időm írni… Ezt nézd meg légy szíves.
Később írok…

Bocs, de én meg azt mondom, a Gray kódot azért alkalmazzák, hogy egy nagyobb abszolut (vagy szakaszosan abszolut) szám digitalizálása során elkerüljék azon pontokat, amikor egyidejűleg sok (pl. akár 10 csatornán egy 1024-es felbontás esetén) van jelváltozás. Ezt elsősorban az abszolut útmérőelemek mechanikai valós gyártási hibái miatt teszik, mivel adott felbontás felett nagyon megdrágítaná a legyártást, és nem is lehet, csak valamilyen tűrésmező szélességben bármit is gyártani. Így nem fordulhat elő téves bit kombináció a Gray kódnál, mivel ott csak egy csatornán van jelváltozás egy időpontban.
A jó öreg AB csatornás encoder pedig eleve relatív mérőelem, és nem abaszolut, kettő csatornája van csak, és muszály eltolni ezek miatt a fázist mert egyébként nem lehet irányt megállapítani. Egyirányú méréshez ugyanis egy csatorna is elég lenne.

Soha nem láttam még AB csatornás négyszög kimenetű encoder taglalásakor a Gray kód idekeverését, pedig elég sok szakiradalmat olvastam erről az elmúlt 30 év alatt.

Előzmény: sneci, 2010-10-10 10:54:00 [859]

Szerintem elbeszélünk egymás mellett...
Te egy hibás példát hozol egy 4 bites Gray tárcsáról, mert ha a másik két bitet nézed, akkor rájössz hogy ugyan az a 0-1-3-2 szekvencia ismétlődik. A Gray kód az Gray kód itt is, ott is...
Én úgy látom, a képet (itt és most a felvetett kérdésre) a felesleges elméleti hitvitával zavarnánk össze.

Előzmény: Törölt felhasználó, 2010-10-10 10:36:00 [858]

"..amin 90 fokkal eltolt.."
Na látod ez a lényeg, ez a matematikai modell és logikai kódolás alapja, és nem a Gray kód, hidd el, nem szabad idekeverni.
AB csatornás encoder kimeneti jelei egyirányú forgáskor:
00, 01, 11, 10, (új ciklus), 00, 01, 11, 10, ...
Gray kódolásnál:
00, 01, 11, 10, (új ciklus), 10, 11, 01, 00, ...
Én ezt a két sort NEM látom azonosnak, csak vannak benne azonos részek.
Azaz továbbra is azt mondom, ne zavarjuk össze a képet a Gray kóddal, a kimenetek logikai szintváltozásának törvényszerűségei egyértelműen a 90 fokos fázis eltolásból adódnak. A szakirodalomban ezt a "quadrature encoder" elmélet alapján taglalják.

Előzmény: sneci, 2010-10-10 10:11:00 [857]

Ellenőrizd légy szíves, hogy mit ad ki binárisan az itt használatos optikai inkrementális enkóder. Azt hiszem, hogy a névazonosság zavar meg Téged. Nem a Gray kódtárcsáról beszélünk, ami több soros, hanem az egy soros kódtárcsáról, amin 90 fokkal eltolt 2 db érzékelő van.

Előzmény: Törölt felhasználó, 2010-10-10 10:04:00 [856]

Én meg az állítom, hogy az A-B csatornás encoder amiatt ad ki olyan jeleket, amit az előbb írtam, és nem a Gray kódolása miatt.
Ugyanis ha megnézed ezt az igazi Gray kód, tárcsát, és a hozzátartozó igazságtáblázatot láthatod, hogy csak az AB csatornás encoder 1, 2 helyiértékű csatornája (ha így fogod fel, ami már eleve kérdéses szemlélet) periodicitása felborul, és ne egyezik meg az igazi Gray kódolással.

Előzmény: sneci, 2010-10-10 09:43:00 [854]

Nekem úgy tűnik, nem sok előny származik egy Gary-Bin átalakításból, de lehetséges. A forgásirány felderítéséhez az előző állapot vizsgálata szükséges, az meg mindegy hogy Gray vagy Bin szerint kódolt. De érdemes a gondolattal foglalkozni, hátha találsz egy olyan algoritmust, ami Bin-ben hatékonyabb.

A gond a processzor oldaláról úgy jelentkezik, hogy interrupt rutin végzi a feldolgozást, és ez erősen lekorlátozza a maximális impulzus frekvenciát. Ezért jó az a nyamvadt xmega, mert hardverben benne van a quadrature dekóder.

Előzmény: celophant, 2010-10-10 09:33:00 [853]

Vitatkozom veled, mert itt az optikai inkrementális enkóder volt a téma, és az Gray kódot ad ki (két szomszéd Hamming távolsága 1).
Digitális jelfeldolgozásnál meg ez a kézenfekvő modell, nem a trigonometrikus.

Előzmény: Törölt felhasználó, 2010-10-10 09:21:00 [852]

Köszi, Sneci!
Annak van értelme, ha a Gray-t átalakítom binárisra… mielőtt a proci foglalkozna vele. Egy kis ciklusidőnyerés végett. Még nem gondoltam át teljesen. Tudom, hogy elegánsabb programmal megoldani a dolgokat, de néha, nem kéne terhelni a procit. ARM-el macerás, mert alig van hozzá anyag. Megpróbálom az AVR kódrészletekkel… az elv ugyanaz… átírom hátha jó lesz.

Előzmény: sneci, 2010-10-10 07:46:00 [851]

A Gray kódot nem keverném ide, az más...
Az A, B csatornás inkrementális jelalak lényege a csatornák közötti 90 fokos fázis eltolás, EMIATT nincs egyidejű szintváltozás. A négyszögjelek periódikus váltakozását matematikailag így egy sinus, cosinus függvénypáros X tengely metszésmetszépontjaival is lehet jellemezni, sőt bizonyos encoderek eleve ilyen analóg jelet adnak ki az A-B csatornákon, és nem négyszögjelet.

Előzmény: sneci, 2010-10-10 07:46:00 [851]

Egy kicsit bővíteném az eddig elhangzottakat.
Az enkóder A és B jelét úgy is lehet értelmezni, hogy az egy 2 bites számláló. De nem a szokásos bináris számláló szerint számol, hanem az un. Gray kód szerint. Ennek a kódolásnak az a lényege, hogy két szomszédos állás (állapot) között csak az egyik bit változik, tehát nincs olyan átmenet, ahol egyszerre változna mind a két bit. Ez azért jó, mert nincs határozatlan átmenet két állapot között. Ezt a tulajdonságot hibavédelemre is lehet használni.
Ha előre forog a motor, akkor a számolási sorrend: 0-1-3-2..., míg ha hátra forog, akkor 0-2-3-1. A vezérlő felől megközelítve: Ha pl. 3 után 2-es jön, akkor előre forog, ha 1-es jön, akkor hátra forog a motor.
Az index jel a lehetséges 4 állapot közül mindig ugyan abban az állapotban kel hogy jöjjön, például a 0-ás állapotban. Ezt az enkóder elektronika biztosítja. Ha a vezérlő úgy látja, hogy az index jel nem a 0-ás állapotbon jött, akkor az hiba.
További hibaellenőrzés lehet, hogy a vezérlő bekapcsolás után megjegyzi, hogy hol jött az első index jel. Legyen az enkóderünk 2000 impulzus/fordulat felbontású. Ha működés közben az index nem a 2000 többszörösének megfelelő számláló állásnál jön, akkor az hiba, mert vagy kimaradt néhány impulzus, vagy zavar következtében többet számolt a vezérlő.

Na mindegy én értem, amit mondani akartam, csak most jöttem rá, mire is jó az, a beírásodból. Most már teszek is az elektronikáimra annak is bemenetet, nem baj, ha ott lesz.

Előzmény: svejk, 2010-10-09 23:30:00 [848]

Igen, de ha számolod az indexet akkor is kapsz egy kvázi abszolútot...
Kérdés, ezt mire tudod használni ?

Előzmény: svejk, 2010-10-09 23:28:00 [847]

Valami ilyesmit írtam én is, bár nekem meg a Te írásod zavaros )

Előzmény: elektron, 2010-10-09 23:25:00 [846]

Igen, de az már abszolút encoder...

Előzmény: Laslie, 2010-10-09 23:17:00 [845]

Van annak az I-n is így értelme, mivel ha kicsit a mechanikus kapcsoló pontatlan, egy körön belül odamegy az indexig és akkor garantáltan az encoder felbontásával egyező pontosságú beállást lehet végezni.

Előzmény: svejk, 2010-10-09 22:54:00 [843]

Vagy maga az enkóder számlálja belül a köröket és sorosan küldi ki az eredményt.
Emlékszel a böszme enkóderre, az is csinálja.

Előzmény: svejk, 2010-10-09 22:54:00 [843]

Köszi, szépen!

Előzmény: svejk, 2010-10-09 22:54:00 [843]

Egy körülfordulást érzékel. Kiegészítve a szánon 1 vagy több mechanikus kapcsolóval fel lehet venni a gépi nullpontot, vagy egyéb koordinátát.

Előzmény: celophant, 2010-10-09 22:33:00 [842]

Sziasztok!
Szeretném tőletek megkérdezni, az encoder pontos működésének a menetét.
A és B jel időbeli eltolódásából lehet a forgásirányát meghatározni… Ezt értem. De az I jel mire jó? A teljes körbefordulást jelzi, vagy referencia jel, hogy volt egy AB-BA átmenet.

Nono... Részemről komolyan van az véve. Csak döntés kérdése is, "ilyet v. olyat?"... Nekem speciel ugyanolyan szimpi az is, amit hivatkoztál, mint a DRO350.

Előzmény: n/a (inaktív), 2010-10-06 19:47:00 [837]

Gondolom nem a "kínai" schieblehre (subler) protokollját keresed, hanem valami ipari útmérőről van szó. Ha bármire rátalálsz ebben a témában, légy szíves tudasd velem is...

Előzmény: Szalai György, 2010-10-06 20:22:00 [839]

Köszönöm, holnap átnézem a linkeket.

Előzmény: n/a (inaktív), 2010-10-06 19:47:00 [837]

de van rs232 változat is ha az érdekel utmérö kijelzésse monitora!:)

Előzmény: Szalai György, 2010-10-06 19:38:00 [836]

minap volt ilyenröl szó de nem veték komolyaban a projektet az az amiröl beszélsz te is!
Digital Readout (DRO) For Lathes & Milling Machines

többi infok a :

http://www.benchtest.com/w-dro.html
http://translate.google.com/translate?hl=en&u=http://www.caliper2pc.de/schieblehre/umbau/umbau.html&rurl=translate.google.com
http://www.shumatech.com/support/chinese_scales.htm
http://www.piclist.com/images/boards/guage/index.htm
http://www.compendiumarcana.com/caliper/
http://rchobby.gmxhome.de/elektro/pic/caliper/calip_eng.htm
http://translate.google.com/translate?hl=en&u=http%3A%2F%2Fwww.steamboating.de%2Fcaliper%2Fcal-main.html
http://users.skynet.be/peter.smolders/digital_caliper_schematics.htm
http://homepage.ntlworld.com/bill_todd/scale/scalereader.html
http://www.yadro.de/digital-scale/mounting-modding.html
http://www.yadro.de/digital-scale/protocol.html

Előzmény: Szalai György, 2010-10-06 19:38:00 [836]