Encoder használata

[svejk]

Én csak egy mezei inkrementálist akartam kirajzoltatni, 500 as felbontással 25 mm külső átmérővel, 2mm sávszélességgel. Ha jól vettem ki akkor ebben az estben 2000-et kell beírni az osztások számába.
Szóval a fenti példa nekem jobban sikerült a Corell/AutoCad-el.
 
Az viszont tény hogy egy absolute kódolású tárcsához könnyebb használni a Te programodat, mint valamelyik rajzolóval kisakkozni.
De itt a hobbycnc berkekben nem nagyon van szükség rájuk.

[KBalázs]

Ott lehetett a gond (talán), hogy bent maradt a sávelválasztó pipa, ami eleve 2mm alaphelyzetben, ez a progiban a sávokból "jön le", azaz 2mm sáv minusz 2mm elválasztó az 0mm sáv és 2mm elválasztó rajzolását fogja okozni (tudom, kicsit következetlenül). Viszont ekkora tárcsa-felbontást még 1200dpi nyomtatással is reménytelen kinyomtatni. A mai otthoni nyomtatók raszteres nyomtatók, azaz képpontokbol rakják össze a képet, egy vektorgrafikus CAD progi persze megmutatja a szép tárcsát, de a nyomtatáskor csak átalakítja a nyomtatónak megfelelô képpontokká, így az eredmény minôsége pont ugyanaz lesz. Szerintem. Ha jól számolom akkor ez a tárcsa 1200dpi mellett (átlag lézernyomtató) ~1200 pontbol épül fel X,Y irányban, tehát a kudarc a belsô rádiuszokon borítékolható. Nagyobb átmérôkön azért a helyzet szerencsére javul.

[KBalázs]

Most látom, van némi hiba a progimban, inkább kézzel nagyobbra kell venni a kép méretet (X;Y;>r*2), mert nem minden esetben méretez megfelelôen.

[Szalai György]

Hát azért egy párhuzamos kimenetű abszolút encoder építése szerintem messze nem csak a tárcsarajzolásról szól. Sajnos.
Mert akkor már készítettem volna magamnak tizenhat bitest, még ha 200mm körüli külső átmérőben is. De van még egy nagy problémám. Az érzékelők által adott kód, a fekete fehér átmenetek környékén (váltáskor) soha nem lesz korrekt. Ehhez kell valami külön megoldás és fogalmam nincsen, hogyan oldják ezt meg a gyártók. Ezért döntöttem úgy, hogy ha nem akad a hálómba gyári abszolút encoder, akkor inkrementálisból számoltatom le, egy kétirányú számlálólánccal. Sajnálom, hogy a DRO-t nem lehet ilyesmire átalakítani.

[KBalázs]

Hogy hogy nem lesz korrekt? A Gray-kód lényege, hogy egyszerre csak egyetlen bit változik, tehát a tévedés is egy egységnyi (1 bit), maximum. Prellezés kizárható hiszterézissel. Vagy valami más miatt nem lesz korrekt?

[svejk]

Lehet, nem bonyólódtam bele..
2400 dpi-es lézerlevilágítóval szoktam a tárcsákat csináltatni..
 
Egyébként ha jól emlékszem, 27mm-es átmérőn az 500 vonal még éppen kivitelezhető otthoni lézernyomtatóval.

[svejk]

Egyébként miért akarsz Te az A/B inkrementális tárcsánál két sávot rajzolni?

[Szalai György]

Gray kódú tárcsa esetében korrekt lehet a váltás, igen, ott csak egy átmenet van egyszerre. (Akkor pedig a #699 rajzán hiba van, mert ott azonos időkben is több váltás történik.)
Megint pontatlan volt a fogalmazásom. Natúr bináris kimenetű abszolút encoderre gondoltam.
 
Ha Gray kódú tárcsát rajzolnék, tovább bonyolódna a feladatom Akkor az encoder Gray kódját elektronikusan konvertálnom kéne natúr bináris kódra, hogy a digitális komparátor összehasonlíthassa egy másik számláló felől érkező másik bináris kóddal. Tehát nekem célszerűbb a natúr bináris kimenetű encoder használata.
 
Nem találtam olyan kétirányú számlálót, aminek Gray kódú kimenete van, sem olyan digitális komparátort, amelyik Gray kódokat hasonlít össze, ezért ragaszkodnom mell a bináris kódhoz, vagy nem úszom meg a konverziós tábla használatát. A konverziós tábla szükségessé teszi valamilyen programozott eszköz alkalmazását, pedig a cél számomra fontos része, a programmentes, korrekt, valós idejű működés lenne.

[KBalázs]

Ellenôrzés nélkül nem illik leszólni a másikat. Szerintem.
http://www.web-oldal.hu/beis-compo/scrshj.gif" border=0>
Azonos idôben csak egyetlen bit változik a Gray kódban, és a generált képben is. Hiszen ez a lényege. /Csak egy vonalzó kellett volna./
Az abszolut enkóderek elektronikája alakítja vissza, /már ha ilyen/ bináris kóddá a leolvasott Gray kódot. Amúgy ez nem egy bonyás matamatikai feladat, egyik irányban sem...konverziós tábla 16 bitre?

[Szalai György]

Igazad van! Ellenőrzés nélkül nem illik.
 
Leszólni még ellenőrzés után sem illik. Nem is tettem. Ha úgy hangzott máris komolyan bocsánatot kérek érte.
 
Az első ellenőrzés mindég a szemrevételezés. A hétnullás vonalad felett egy egységgel két egymás melletti sor átmenete pont egybe esik, ezután kezdtem figyelni. De rosszul tettem, hogy nem importáltam mindjárt a Corel-be, és nem néztem végig az origón áthaladó egyenes forgatásával. Most megtettem.
Máshol nincs egybeesés.
 
Grayből binárisba, beégetett konverziós tábla helyett kiszámoló algoritmust írni, akár csak egy irányba, nekem, az én szakmámmal, érdeklődési körömmel és ismereteimmel, ez nemhogy bonyolult matematikai feladat, hanem egyenesen ismeretlen terület. A programozás szintén. És oda lenne a valós idejű működés. Nem véletlenül kerülöm. Már így is kinőttem a sapkámat.

[KBalázs]

És valóban, felfelé nem is néztem, a 0 felett tényleg nagy (3 bit) a változás, ez annyira nyilvánvaló, hogy észre sem vettem [#heureka] , ott a pont! Ezen pl. egy kilencedik, beíró (engedélyezô) jellel lehetne segíteni, tehát ha az a jel megvan, akkor olvassa be a többi 8 bit értékét. (Mármint ebben a példában.) Ez a jel természetesen "szûkebb" kell legyen, mint a többi jel. Vagypedig, eleve nem fordul körbe, hiszen ezért abszolut enkóder, ha átfordul, ki mondja meg épp hol tart?  
A konverzió, kissebb bitszámú tárcsánál, végiggondolva, akár egy paralell eprom is szóba jöhet, címbuszra megy az enkóder, adatbuszon kijön az átszámolt valódi bin.jel. (Ezt most ötlöttem ki, de érdekes lehet, és marha gyors.) Én PIC-be már megírtam az átszámoló algoritmust, igaz 8 bitre, de persze bôvíthetô, és nem titkos. Mint írtam, ilyen szenzorokból (adó+vevô) nekem van egy vödörrel, tehát vállalkozó szellemûeknek szívesen adok (Bp). Mondjuk lineáris enk. esetén méginkább érdekes az abs.enkóder.  
Ezek az érzékelôk 5x5mm méretûek szembôl, ezért írtam progiba egy "bit-eltolás" navû részt, teháthogy hamár maszk van nyomtatva a vevôkhöz, akkor a vevôknek nem kell egy csoportban gyülekezniük, így a sávok is kissebbek lehetnek.

[svejk]

Az abszolute encoderek általában 20-25 bit fordulatot is tárolnak, mégpedig nagyon egyszerűen van bennük többfokozatú fogaskerékáttétel..
 
Ajánlom hogy vizsgálj meg egy pár gyári encodert közelebbről, szedd szét őket.
Úgy is sokat lehet tanulni nem csak elméleti szinten.
Sajnos valószűnű ezen a területen is már nehéz lesz új találmányokat alkotni

[KBalázs]

"Multiturn Absolute Encoder".
Ezek "mechanikusan egymásután kötött", áttételezett, többszörös abszolút enkóderek, ugye? Élôben ilyenhez még nem volt szerencsém. Sajnos. Ezeket leutánozni hobby szinten a lehetetlennel határos.[#wow1] Akkor inkább számláló enkóder, valami szünetmentes táp megoldással. Régebben olvastam, hogy a digi. tolómérôk (a párezer forintos kategória) is sima számláló enkóder elven mûködnek, persze nem optikailag érzékelnek, hanem kapacitívan, preciziós nyákgyártással, és amikor ki vannak kapcsolva, akkor is számolnak, csak nem kötik az orrunkra, ezért is merülnek le pár hónap alatt. Viszont pokoli gyorsasággal olvasnak le.
Ez is egy érdekes enkóder elv lehet.
Keresek róla leírást, és belinkelem.

[KBalázs]

Két említésre méltót találtam kapacitív útmérés, pdf-ek, angolul:
Ami az elvet illeti, ez itt egy szabvány leírása, 1976-ból..
 
http://www.web-oldal.hu/beis-compo/szabvany_capenc76.pdf" TARGET=_fnew>elsô pdf
 
és egy tanulmány  

[KBalázs]

oppsz, melléböktem.
 
http://www.web-oldal.hu/beis-compo/IEEESENSORS.pdf" TARGET=_fnew>második pdf