UCCNC vezérlő program

[kr97pwss2]

Valamit félreértesz, az enkóder A,B jeléből megállapítható a forgásirány, még akkor is, ha az A és a B jel nem pont 90fokra van egymáshoz képest. A következő ábrán látható, amint megváltozik a kék vonal mentén a forgásirány:
http://www.polgardidesign.hu/download/Web/Enk%f3der.png" border=0>

[kr97pwss2]

Ha csak a fordulatszámot akarod mérni az Index bemeneten, akkor működik, ha viszont szinkron menetvágást vagy fúrást szeretnél, akkor viszont nem!!! A szinkronizált induláshoz fordulatonként 1 index jelre van szükség.

[ANTAL GÁBOR]

 Balázs ! a forgásirány persze hogy megállapítható a metodikát nagyon rég óta
 (kb 1974 ) ismerem ( iránydiszkiminátor ) sőt  hagyományos Ic kel építettem is anno .  Engem az alapkérdés izgat mert ha egy rossz optó elékeléssel nem tudja pontosan megmintázni a főorsó fordulatát akkor hibás lesz a menet emelkedése . Az irányváltás pillanata után fogalmam sincs hogy mi fog történni egy menetfúrás esetén  ( ezért zártam ki a feltett kérdésből ) Valami azt sugallja hogy ott komoly baj van ha hibás az elékelés  

[kr97pwss2]

Félre értettem a kérdésedet. Vegyünk egy példát: Menetvágásnál egy fordulatra 100-as tárcsa 400 főorsó pozíciót határoz meg. 1mm-es menetemelkedésnél 1/400=0.0025mm kell elmozdulnia a szinkronizált tengelynek az enkóder egy élváltásának hatására. Ha az A és B jelek egymáshoz képest pl. 81fokra vannak (10% eltérés), akkor 81/90*0.0025=0,00225mm azaz 0.0025-0.00225=0,00025mm hullámosság lesz az alapjelben. Ez elhanyagolhatónak tekinthető.

[ANTAL GÁBOR]

 Köszönöm . Az az alapgondom hogy nagyon belémivódott a mach menetelésének a szisztémája  ( fordulat mintázása  számolás azután Start )  A ti  szinkron  szisztémátokat  kezdem megérteni .   IsVarga csinált egy hasonlót. ( T45 szisztémáját nem ismerem közelebbről )    A "tenyésztett" eset : 400 lépésre mozdul a Z tengely 1 mm t  ( ez van a motor tuningban ) . 1 es emelkedést vágunk  100 as ( 400 jel ) tárcsával . Ekkor minden élre  1 et kell lépnie a léptetőnek.  Természetesen ez egy valós időben való SZÁMOLÁS  ( oszás )   eredménye . Ha nem 90 fokos az ékelés akkor az élek közötti idő nem egyforma. A léptető  
 ( szisztematikusan ) egyszer hamarabb lép egyszer meg később  miközben a főorsó szépen stabilan fut vagyis   időegység alatt a szögelfordulása konstans . Ilyen esetben ez a hiba tényleg elhanyagolható . Tehát a fordulatszám ismerete nem is szükséges a szinkron menethez  ( az kijelzésre kerül de számunkra indifferens ) Az is lehet hogy a fordulatszám kijelzésénél az indexek közötti idő  van felhasználva adatként

[000000000]

Szia,
 
Valóban az Apply és Save settings-nél még megmaradt a probléma ... most hogy mondod, megnéztem és tényleg .. fogom javítani a következő verzióban már jó lesz.
 
Ezt a probe dolgot nem értem teljesen, hogy miért kéne demo módban külön választani a működését. Miért nem konfigurálod át a polaritását, hogy alapban ne legyen aktív és akkor demo módban is kell működnie.
 
Ezen a home-olós felvetésen pedig gondolkodnom kell még, hogy hogyan lehetne megoldani. Mondjuk szerintem koncentráljunk egyelőre arra, hogy a meglévő tudás, funkciók minden kombinációja teljesen hibátlan legyen, szóval várjuk a további teszteléseket és hibajalentéseket. mert ugyan mi több hétig 2 gépen is teszteltük a progit, de látszik, hogy már annyi féle beállítás kombináció van, hogy kell a segítség, hogy mind le legyen tesztelve.

[000000000]

Ezt a jelzett MPG-vel végállásra futást és override limits-et megfogjuk hamarosan vizsgálni.

[ANTAL GÁBOR]

  Még szemléletesebben is megfogalmazhattam volna. Az A/ B jelből egy quadratúra dekóderrel csinálok  Step / dir jelet  és abból valami aritmetikával  előállítom azt a step jelet amire szükségem van a menetvágásnál . Ha az alap kétfázisú jel nem 90 fokra van egymástól akkor a quadratúra dekóderből származó  stepek között hosszabb rövidebb idők vannak amik az kimenetre is arányosan rákerülnek .  A többi meg már le van írva .  ( A szisztéma  teljesen hasonló a Mach független  kis esztergám motorizált keresztszánjához, ha gyorsabban tekerem az MPG t akkor gyorsabban és szinkronban  megy a szán , csak nálam nincs aritmetika )

[000000000]

Gábor,
 
Mindaddig nincsen gond, amíg két detektált él közti idő nagyobb marad mint 1/100kHz=10usec.
Más szóval a korlát a 100kHz frekvencia limit és ebbe bele kell számolni, ha mondjuk a jelek az encoderen nem 90 fokkal vannak eltolva, hanem mondjuk 70 fokkal.

[000000000]

Ezt a run from here dolgot nem tudom előidézni, nálam tökéletesen működik a funkció. Az nem lehet, hogy az ablak csak egyszer jelenik meg, csak azt hiszed, hogy többször, mert a szerszámpálya nézetet amíg az ablak fent van addig nem frissítjük és emiatt ha félrehúzod az ablakot, akkor úgy tűnhet, mintha több ablak lenne, de valójában nincsen több, csak egyszer tud megjelenni, mert egy példány készül az ablakból, gyakorlatilag nem is tud több példányban megjelenni, a kód szerint nem lehetséges...
Ha le OK-zod az ablakot akkor egyébként végrehajtja neked a kezdeti mozgást és minden működik utána?

[000000000]

Még annyi, hogy ez az "initial movement preparation" ablak az nem hibaüzenet. Az egy ablak, ahol be tudod állítani a kezdeti mozgást és ez az ablak akkor mindig megjelenik, ha run from here gombot nyomsz. A lényege, hogy a progi kiszámítja, hogy hol kell állnia a tengelyeknek az újonnan kiválasztott G-kód sor végrehajtásakor és felajánlja, hogy oda mozgatja a gépet mielőtt újra indítanád a ciklust. Az ablakot vagy OK-val tudod eltüntetni, ha OK-t nyomsz, akkor végrehajtja a felajánlott mozgást. Ha Cancel-t nyomsz akkor pedig nem hajtja végre és akkor ha megnyomod újra a ciklus startot, akkor rögtön a G-kód programot fogja végrehajtani.

[ANTAL GÁBOR]

 Köszönöm ! Ha visszaolvassátok akkor kiderül hogy abs megértettem . Egy ÉS  kapuval  (lehet hogy diódás lesz ) összekapuzom az A és B jelet azután szkóppal megnézem a jel/ szünet időt és belövöm az optót.   Durva hiba nem lesz , a kicsivel meg nem foglalkozom mert úgy is kiintegrálódik

[lari]

A Run from here ablak egyszer jelenik meg.
Ezt követően, ha nyomok egy ciklus startot, akkor elkezd remegni az ablak, s ezt követően semmit nem tudok már csinálni. Sem az ok, sem pedig a cancel gombra nem reagál.
CTRL-ALT-DEL-el tudom bezármi az UCCNC-t.

[lari]

az "initial movement preparation" nálam nem egy ablakként jelenik meg, legalábbis én nem látom.
Annyit látok lenn a tálcán, hogy az "initial movement preparation" számozottan ismétlődik és sokszorozza magát, de mint az előbb mondtam, ilyenkor már csak a program "kényszerített" bezárása segít.

[dezsoe]

Szia!
A probe beállításán nem szeretnék változtatni, mert akkor az elektronikát kéne módosítanom. Eddig simán tudtam demóban futtatni például az AutoLeveller által generált probe kódot, ami előállította nekem a probe adatokat. (Az adatok tartalma lényegtelen volt számomra, a meglétük a fontos demó módban.) Most, hogy a G31 dudál, hogy a probe már aktív, nem tudom a normál, a gépnek is megfelelő, de demó állpotban levő profilon futtatni. Eddig megvolt az a lehetőségem, hogy ugyanazt a laptopot használom ugyanazzal a profillal, de vagy rá van dugva a gép, vagy nem. Tehát vagy kapcsolgatom a lábat, vagy csinálok külön profilt demóhoz, ami csak a probe polaritásában tér el. (A hardware módosítást alapból kihagyom.) Ha külön profil, akkor meg minden módosítást mindig át kell vezetni: ez maga a hibalehetőségek mennyországa.
Egyébként pont a programom tesztelése miatt gondoltam a demó LED-re is, akkor a G31-ből jövő, minden probe-ra ugyanazt az eredményt adó számot tudom néhány tizeddel 0 környékére randomizálni, mintha a felület lenne girbe-gurba. A probe adatot úgyis makróból tudom # változóba pakolni, akkor meg lehetne a LED alapján valós vagy kitalált adatot tárolni.