Nem teljesen értem mit szeretnél, de egy biztos, hogy minden mozgatás alapja a Mach salyát DRO állapota (legyen az kézi , vagy G-kód álltal programozott)! Ha bármilyen módon ezt az értéket megváltoztatod, az kihatással van az egész rendszer koordináta vezérlésére.
eleve beadni 3 encodert, az 2. LPT portot foh igényelni (3×2=6 bemenettel, 3D esetén)!
Szerintem túl akarod komplikálni a dolgot...

Előzmény: KisKZ, 2009-01-30 12:00:00 [2783]

bocsánat hoyg hozzáfűzök még, de azt is el kell dönteni, hogy ez a kis eszköz működjön-e folyamatosan amikor a gép működik, vagy csak esetenként, amikor leakasztja az ember a gép oldaláról akkor kapcsolódjon be.
Tudom nem nagy dolog, de minek fogyasszon bármit is ha nem kell.
Persze az állandó géppel együtt működés az ésszerűbb és talán egyszerűbb is.

Előzmény: KisKZ, 2009-01-30 12:00:00 [2783]

Igen. Csak tájékoztatás. Semmi más!

Előzmény: n/a (inaktív), 2009-01-30 11:49:00 [2782]

Igen...
Most azon gondolkodok, hogy ezt a kézi módot ugyan teljesen elválasztva használja az ember a G-kódtól. Ugye nem programozott mozgatásról van szó, és ugye valahol lesz éppen az orsó akkor amikor elkezdem ezt a módot. Ez lehet valami állandó alaphelyzet is (pl. gépi nullpont) de megeshet, hogy éppen valami művelet után állok valahol és utána akarok valamit kézi vezérléssel csinálni.
Lehet hogy mégis ki kellene olvasni a DRO értékét és azt használni? Már csak azért is, mert pl. ha nullázok a nullapont felvételnél, akkor itt az eszközön is is nullázni kellene. Értelmetlen két helyen is megtenni.
Akkor a kérdés az, hogy hogyan lehet a legkönnyebben kivenni ezeket az értékeket és kitenni egy kis kijelzőre.

Előzmény: n/a (inaktív), 2009-01-30 11:49:00 [2782]

De a G-kódod a Mach DRO-ja alapján hajtódik végre! A kijelzett értékkel mit szeretnél kezdeni? Csak tájékoztatás lenne? Ismétlem, nem tudom, hogy a visszaadott koordinátákkal a mach mit tud kezdeni!

Előzmény: KisKZ, 2009-01-30 11:43:00 [2781]

Látod István!
Ezzel a két hozzászólással többet elmondtál most nekem mint a lentebbi sok comment.
Köszönöm!
Ugyhogy visszatérek a rotary encoderhez és ahhoz, hogy azt hogyan lenne érdemes elkészíteni.
Ha úgy döntök, hogy az elmozdulás értékét nem a MACH-ból olvasom ki, hanem egyszerűen magán a kézi eszközön számlálom és számítom, akkor van-e valami ötleted arra, hogy hogyan lehetne ezt a legegyszerűbben kijelezni magán az eszközön?

Előzmény: n/a (inaktív), 2009-01-30 11:24:00 [2780]

Igen jól érted! A lényeg, hogy javítani csak akkor lehetne ha van tartaléka (méghozzá tetemes, hogy a hiba idejét alacsonyan lehessen tartani) a motorban, de léptecs pont ott kezd el hibázni (megáll) amikor elfogy az ereje (tehát zéró tartalék)!
A lin-encoder szerintem (de csak gyanítom) a mechanikai hibák (pl, kottyanás) kimutatására, esetleg kezelésére való, de sosem használtam, teszteltem ezt a részét a Mach-nak.

Előzmény: KisKZ, 2009-01-30 11:19:00 [2779]

Ezt köszönöm István.
Értelek. Tehát lépésenként nem igazán lehet értelmeztetni a hibát. Ha az pedig nagyobb, várhatóan a hibát okozó egység a megszüntetésére indított javítás alatt, nagyobb terhelés alatt méginkább problémás lesz.
Eleve ha próbálnék kompenzálni valamit akkor az a kompenzáció nagy valószínűség szerint ugyanúgy hibás lehet. Tehát ez csak egy ördögi körré válna.
Jól értem a dolgot?
Bocsánat a lassú felfogásomért!
Azt még mond el nekem, hogy a lineáris kódolót miért jó használni? Mennyivel más a dolog, mintha csak a szoftver saját maga által kiírt pillanatnyi értékeit nézem?

Előzmény: n/a (inaktív), 2009-01-30 11:07:00 [2777]

Ehhez kapcsolódik a Léptetőmotorok topic #1629 környéki beszélgetések! Érdemes megnézned...

Előzmény: KisKZ, 2009-01-30 10:41:00 [2774]

Ok...
A lényeg, hogy ne tekintsd ideális léptetőnek semelyik motort+vezérlést! eleve van szórása a lépéseknek és ez a szórás 1 fordulaton belül is más és más. Ráadásul a motor belépése után néhány mS-ig csillapodó rezgésekkel áll be a pozícióba, ami sebesség, terhelés, hajtásmód függő is! Ha erre raksz egy encodert, akkor nincs az a jó szoftver, ami meg tudja külömböztetni időben a hibát az egyébb jelenségek közül! Ha meg már egyértelmű a hiba (pl egy 5-10 Step eltérés), akkor meg már úgy is fujhatjuk a kompenzációt (az már selejt)! Arról nem is beszélve, hogy ha a léptecs hibázik, az álltalában azt jelenti, hogy blokkol nagy sebességen, ami a határérték túllépése miatt van, és ezt a marhanagy kését hogyan hozatnád be a motrral, ha már az "alap" sebességet sem bírta????

Előzmény: KisKZ, 2009-01-30 10:41:00 [2774]

Bocsánat rossz az előző link.
Ez már jobb:
SikaBlock

Előzmény: KisKZ, 2009-01-30 10:46:00 [2775]

Az általam felhasználni kívánt "fáról" némi információ:
Sikablock
Ez nem az a fa amire Te gondolsz.

Előzmény: Szigma, 2009-01-29 23:14:00 [2769]

Ej István!
Én nem azért erőszakoskodok, hogy mindenképpen azt akarom, hogy úgy működjön valami amit még nem ismerek ahogy én akarom, hanem azért, hogy megértsem a működését.
Nem azért irok ide annyi mindent mert annyira értek hozzá, hanem azért mert nem.

Előzmény: n/a (inaktív), 2009-01-29 18:22:00 [2768]

Bár a leírásaitok alapján már sejtegetek valamit, azért egyszerűsítsünk. Inkább kérdezek, nem találgatok mert ez úgy látszik ellenérzést kelt:
Mire használja a lineáris encodert és annak jelét a MACH?

Előzmény: svejk, 2009-01-29 18:14:00 [2766]

Figyelmedbe ajánlom még ezt itt a fórumon.
(#74-#75)

Előzmény: n/a (inaktív), 2009-01-30 07:52:00 [2770]

Ha feltelepítetted, akkor ez EC mellett van egy külön program, a CodeWizard. Ezzel lehet a Mach3-hoz a postprocessor-t megcsinálni.
De CNCzone-n is ez volt valakinek a gondja és ezzel a Mach2 postprocesszorral Mach3-hoz is korrekt G-kódot tudsz generálni.

Előzmény: n/a (inaktív), 2009-01-30 07:52:00 [2770]

Sziasztok!
Tudna valaki segíteni nekem? (kezdő vagyok) Van egy EdgeCAM 11.5-progim, de nem tudom használni a MACH3-mal.Kellene hozzá egy Mach3 driver, megköszönném ha valaki küldene, vagy segítene, vagy valami tippet adna hogy is kell ezt csinálni.

"Egyenlőre örülnék, ha 0.01 pontosságot el tudnék érni (nem fogom szerintem). "

Jól gondolod. Favázas géppel még az 1 tizednek is örülhetsz. Legalábbis fém (akár alu) megmunkálás esetén.

Előzmény: KisKZ, 2009-01-29 13:42:00 [2731]

Ehhhh! Feladom! valósítsd meg az "álmodat" és meghajlok előtted...

Előzmény: KisKZ, 2009-01-29 18:02:00 [2762]

Azt a mechanikát amelyik kotyog azt már b@szhatod, azt már hiába kompenzálod.
Szerintem a hosszú fölösleges eszmefuttatások elkerülése végett dobj össze egy bútorlapos mechanikát a hétvégén és sok minden meg fog világosodni, hidd el.

Előzmény: KisKZ, 2009-01-29 18:02:00 [2762]

Pontosan arra való az encoderbemenet amire leírtad.
Vagyis a kézi tekerővel(MPG) mégy mint hagyományos gépnél és ezt az encoderbemenet érzékeli ha van jeladód, ha nincs akkor küzvetlen az MPG jelét számolja a mach DRO-ja.
Közben a G-kód(program) számlálója nem változik
Aztán a program számlálót vagy a DRO számlálót tudod egyikkel a másikat átiratni.

Előzmény: KisKZ, 2009-01-29 17:57:00 [2759]

Egyszerűen a rotary jelet nem engeded rá közvetlenül a vezérlőre, hanem közbeszól az elektronika és mindaddig nem fog a vezérlő enkóder jelet kapni amíg a lineáris meg nem mozdul.

Előzmény: KisKZ, 2009-01-29 18:06:00 [2764]

Csupán az az érdekes, hogy hol avatkozol bele a folyamatba.
Ennek a hibajavításnak nem az elektronikában van értelme, hanem a G-kód értelmezőjében.
(ezt persze Mi nem tudjuk megcsinálni)

Előzmény: Laslie, 2009-01-29 17:59:00 [2760]

Hidd el, nem mindig érdemes megírni egy G-kódot.
Ezt tapasztalatból mondom.

Előzmény: n/a (inaktív), 2009-01-29 18:00:00 [2761]

István!
Nem értem mi a gond....
Én tulajdonképpen még nem foglalkozok azzal, hogy hogyan és milyen módon vezérlek, léptetek....
Ez még nem érdekes.
Az az érdekes, hogy lehet hiba a kivezérelt elmozdulás között és a valós elmozdulás között.
Erre a legjobb példa a kottyanás kompenzációja Csak az ugye állandó hiba állandó kompenzációval.
Még csak ott tartok, hogy mi lesz a hiba. Ez az eltérés a két tengelyelmozdulás között. Ez adódhat akár a mechanikából is, nem csak az elektronikából.
Azon gondolkodok, hogy ezt hogy van egyáltalán értelme korrigálni.

Előzmény: n/a (inaktív), 2009-01-29 17:56:00 [2758]

Mire használnád a valós életben? Az MPG-vel a felszin megérintését szokás végezni, aztán xD-ben zéró! Nem "konkrét érték" beállítására.
Egy léptetőmotoros rendszerben a Start/Stop freki felett létrjövő lépésvesztést azonnal észre veszed, mert meg áll a gép és csak visít! tehát itt megint nincs jelentősége.

Előzmény: KisKZ, 2009-01-29 17:57:00 [2759]

Jaja....léptetőnél nem oldható meg a dolog. KisKz mégis csak kukorica darálót kell csinálnod a léptetőkből.

A lineáris encoder csakis a tengely aktuális poziciójának jelzéséhez használatos az én eszmefuttatásom szerint. A kézi mozgatást egy rotary encoderrel teszi meg az ember. Ez egy másik dolog.
Ekkor van értelme a valós pozíció kijelzésének egy lineáris encoderrel.
Ugye mint ahogy az egyszerű kézi gépen.
Addig tekersz amig a mechanikus márőeszközödön (skálán akármin) a megfelelő méretig nem jutsz.

Egyébként, programfuttatás közben (kompenzéáció nélkül) nincs értelme, hiszen egy dolog az ami kivezérlésre kerül a tengelyre, és (mert ugye lehetnek hibák/lépésvesztés egyéb) más dolog az ahol a tengelyed a tényleges pozícióban van.
A két érték szépen eltolódhat egymástól.

Előzmény: n/a (inaktív), 2009-01-29 17:50:00 [2754]

Könyörgöm! Step/dir rendszerről van szó! Lépek-rezgek-beállok (a hibát honnét mérjem????) és akkor holvan a micro-step/lépések közötti hibák tűrése (vagy kell egy motoronkénti-fordulatonkénti táblázat, ami megmondja mi a max hibaszint ami alatt még nem kell hibát jelezni/korrigálni????)!

Igen , ott ki lett vesézve már a dolog és arra jutottunk, hogy egy közbeiktatott elektronika is meg tudná ezt csinálni, de ahogy Svejk fogalmazott akkoriban ezt nagyon-nagyon át kellene gondolni.

Előzmény: KisKZ, 2009-01-29 17:52:00 [2755]

Miért nincs jelentősége ?
A lineáris tudná a legpontosabb eredményt adni a mechanikád hollétéről. Ez gépi vezérlésnél is igen csak jó lenne. Nem méri bele az orsók holtjátékát.

Előzmény: KisKZ, 2009-01-29 17:48:00 [2753]

Pedig a kettő különbsége lenne az esetleges hiba nem?
"Csupán" ezt a hibát kellene korrigálni a motor vezérlésénél.
Persze ez mindenképpen késéssel lehetne csak megtenni, értelmezni kellene a pillanatnyi G-kódban kapott parancsot és tudni az meddig tart még (előre gondolkodás) és ez alapján tenni meg a kompenzációt az aktuális tengelynél.

(Csak feltételezek, kérdezek. Ti ezt biztos kiveséztétek már)

Előzmény: Laslie, 2009-01-29 17:48:00 [2752]

Ezt nem értem! lineáris encoder? Kézi vezérlésben????

Előzmény: KisKZ, 2009-01-29 17:48:00 [2753]

Viszont így a kézi vezérlésen kívül nincs jelentősége a lineáris encodereknek. Legalábbis én így gondolom.

Előzmény: n/a (inaktív), 2009-01-29 17:46:00 [2751]

KisKZ !
A mach képes a szervo enkóder jelén felül még az ugyanazon tengelyhez tartozó lineáris enkóder jelét is kezelni???? Valszeg nem !
Pár hónapja az enkóder topicban épp erről ment a diszkurzus, hogy igen problémás a két enkódert összehozni. A csak lineáris enkóder meg kevés a dologhoz.

Szerintem nem lehet normálisan deffiniálni, hogy egy detektált 1 tengelyes eltérés esetén hogyan kompenzálja a hibát (ha már detektált, az el van cseszve)! Ezt akár 6D-ben kellene normálisan lekezelni...
Ne feledd el, hogy léptetőmotorokról van szó (ami ugye fix lépés szögeket lép, tehát az feldolgozásnak a tranzienseket és a lépés/encoder felbontás hibákat is türnie kell)!!! Nem egyszerű... szerintem ezért hagyták az egészet...

Előzmény: KisKZ, 2009-01-29 17:39:00 [2749]

Még nekem is át kell gondolnom az új ismeretek fényében, hogy pontosan mit is szeretnék.

Azt a pozíciót ami a MACH-ban van (kiolvasás és megjelenítés) avagy a valós pozíciót (és ezt mellette beküdeni a MACH-ba is).... ???
Meglátjuk.

Előzmény: n/a (inaktív), 2009-01-29 17:26:00 [2747]

:) Az eszköz alapja végülis indifferens.
A lényeg az, hogy mit tudunk kezdeni vele.
Az, hogy átírja az eredeti számlálóállást így talán még kevés nem? a vezérlést is illene módosítania annak megfelelően. kompenzálnia kellene az eltérést valahol. Vagy rosszul gondolkodok újra? Mert egyébként nem sok értelme van az egésznek.

Előzmény: svejk, 2009-01-29 17:20:00 [2746]

Csak mint érdekesség: a MODBUS technológia nem kötődik szállítóközeghez, így létezik Ethernetes és WiFis átvitele is! Ezzel dróz nélküli és Interneten keresztüli CNC(?) I/O kezelés is megoldható!
Természetesen a MODBUS nem CNC találmány (lakás vezérlésre is kiváló)!

MODBUS-on keresztül megoldható bármilyik Mach3-as DRO értékének kiküldése és akár LCD-n való megjelenítése is, de jelenleg én ilyesmivel nem foglakozok.

Előzmény: KisKZ, 2009-01-29 10:52:00 [2719]

Felejtsétek már el azt az egeret..

A Mach nem tud semmit kezdeni a jellel, csak kijelezni tudja a poziciót mint DRO és átírni vele az eredeti számlálóállást.

Előzmény: KisKZ, 2009-01-29 17:07:00 [2745]

Ez egy kicsit latin nekem...
tehát levehetem a jelet optikai egérről is közvetlenül és levehetem régebbi görgős egérről is?
Természetes, hogy ha megvan ez a választás, az ember a nagyobb felbontást adó optikai egeret választhja.
Ha ténylegesen jól levehető és feldolgozható a jel, akkor már megint csak az a kérdés, hogy hogyan dolgozza fel az ember (erre írtad gondolom, hogy egy PIC-kel megoldható a dolog) és hogyan teszi ki az eredményt egy kis kijelzőre a legegyszerűbben.
A mnásik kérdés még mindig adott:
A lineáris encoder jelével mit csinál a MACH?
Ha hiba van kompenzál a vezérlésen?

Előzmény: elektron, 2009-01-29 16:51:00 [2744]

Ki lehet venni a jelet úgy, hogy a belső komparátor kimenetére kell csatlakozni, vagy közvetlenül a fototranzisztor kimenetére, csak van ezekből az egerekből nem egyféle, így érdemes megnézni többet is, szerintem a régebbiekben érdemes vizsgálódni.

Előzmény: KisKZ, 2009-01-29 16:38:00 [2743]

Én most elkavarodtam itt.....
A soros kimenet jeleit??? Ezt most nem értettem.
Ezek az egerek ugye manapság már USB-sek.
Itt jön az, hogy az ilyen perifériák működésével nem vagyok igazándiból tisztában.
Az alapkérdésem:
Egy ilyen egérből ki tudom csalni az elmozdulásra jellemző jeleket anélkül, hogy a számítógéppre kötném?
Tápot (ha az kell a jelhez) persze valahonnan adnék neki.

Előzmény: elektron, 2009-01-29 15:04:00 [2738]

Ez elég jónak néz ki pl. :

Encoder egérből

Előzmény: KisKZ, 2009-01-29 16:21:00 [2739]

Lehet találni leírásokat a neten, pl. 'encoder from mouse' szerintem erre lesz találat, én már találtam régebben ilyesmit, még egyet csináltam, is szétszedtem, hogy a Z irányban méréseket végezzek vele, ott van valahol a polcon a többi dolgok közt.

Előzmény: KisKZ, 2009-01-29 16:21:00 [2739]

Igen! Emlegették már nekem ezeket a szalagokat.... Valaki a multkor már ajánlott is ilyesmit nekem. Csak az elektronika rész ismerete nélkül én nem mertem bevállalni.

Előzmény: svejk, 2009-01-29 14:57:00 [2735]

Látod! Engem pedig a mechanika nem ejt kétségbe.
hogyan kellene egy ilyen egeret bekötnöm? (vezeték szín, és hova?)
Az, hogy mekkora felbontást tudna az emnber elérni vele az most nem is érdekes. Csak az elméleti megoldhatóság.

Előzmény: elektron, 2009-01-29 14:59:00 [2736]

Ha konkrétan van valami leírás, ami alapján látható, mit hogyan kell értelmezni, pl. egy PIC 16F627-tel meg tudok oldani ilyesmit. Megszakításból fogadni a soros kimenet parancsait, aztán értelmezni, utánna pedig kijeleztetni kijelzőn, pl. sokjegyű számjegyes LED-del, vagy akár pixeles kijelzővel.

Előzmény: svejk, 2009-01-29 14:53:00 [2734]

Az előbb hülyeséget írtam, kitöröltettem.

Előzmény: svejk, 2009-01-29 14:53:00 [2734]