Hopp, a 2. pont sztornó: megfejtettem.

Előzmény: n/a (inaktív), 2015-03-14 11:06:00 [1976]

Szia!
Sikerült végre géppel is tesztelni. Akartam panelt marni, de a megszokott munkamenet közben két hibába(?) futottam bele. Illetve az első biztos, hogy hiba, a másodiknak gondolom, van oka, de az én szemszögemből nézve hiba.
1. Generáltam szintező file-t, (a file). Elkezdtem mérni a felületet (8 sor, 10 pont soronként), egyszer csak valami furcsa zajt hallottam. A mérés úgy történik, hogy x,y pozícióba megyek, ott leeresztem a mérőt z=1-re, majd G31 Z-1 jön. Elsőre nem tudom, mikor kezdődött, de teljes áramtalanítás után megismételtem a mérést és kb. az 5. sor elején, tehát kb. az 50-dik mérés magasságában elkezdi, és a mérés sorozat végéig minden G31 indításakor ránt egyet az Y tengelyen. Ráadásul oda-vissza egy lépést (tehát a tengely marad a helyén). Felrakom a profil file-t is, hátha az Y tengely pozíciójától és nem a mérések számától függ.
2. A 163-as nyomógomb fenntartott lett JogmodeMPG helyett. Nekem nagyon hiányzik, mert a nyomorult tapipaddal kell bekapcsolni a tekerőt, amit - térbeli elhelyezkedése miatt - mindig kikapcsolok, ha nem kell...

Előzmény: n/a (inaktív), 2015-03-14 11:06:00 [1976]

Szia!
Úgy tűnik, hogy a charge pump problémát lezárhatjuk: ahogy eddig hibázott, az megszűnt. Délután végre eljutok odáig, hogy üzem közben tesztelhessem.
A LED-ért pedig hálás köszönetem!
(Csak lustasági kérdés: nincs véletlenül elfekvőben egy 1366x768-as képernyő minusz a tálca (28 pixel) méretre optimalizált screenset-etek? Akkor nem kéne nekifogni... )

Előzmény: n/a (inaktív), 2015-03-14 11:06:00 [1976]

Sziasztok,

A jelzett hibák javítva lettek:

- MPG-vel ha végállásra lett tekerve valamelyik tengely, akkor reset-ből kivétel után mozdult egy kicsit a tengely.
- Analog kimenetek nem működtek, fizikailag nem ment ki a jel.
- Apply/Save settings gomboknál a charge pump jelet bekapcsolta a progi.
- Csináltam egy Isdemomode LED-et.

UCCNC 1.1005 letöltés

OK, így már értem a lényegét. Csináltam neked egy Isdemomode LED-et....

Előzmény: dezsoe, 2015-03-13 23:49:00 [1970]

Szia Tibor,

Megtaláltuk Demon Hillt.
Mindjárt felrakom ide a javítást.

Előzmény: nagaoka, 2015-03-14 00:08:00 [1971]

Az a probléma, hogy amikor régebben jelezted, akkor se tudtam előidézni ezt a dolgot és most se tudom. A kódot is megnéztem és igazából az ablak egy példányban tud megjelenni, ráadásul modális, szülőnek a fő ablak van megadva, így mondhatni, hogy a kód szerint képtelenség, hogy a tálcán jelenjen meg külön a főablaktól. Nem igazán tudom elképzelni, hogy hogyan tud ez előfordulni.

Előzmény: lari, 2015-03-14 07:56:00 [1972]

Ma ismét megpróbáltam, most tökéletesen működött.
Tegnap számítógép újraindítással nem próbálkoztam, csak a program újraindításával.
Valószínűleg ezért nem volt jó tegnap.
Valami viszont biztosan nem OK a "háttérben", mert a régi verzióknál is volt ez a hiba... Akkor nem "erősködtem", gondoltam az újnál már nem lesz.

Előzmény: lari, 2015-03-13 21:29:00 [1969]

Szia Balázs!
Hova tűnt Damon Hill,no meg a PWM 10V-os feszültsége.
A többi rész úgy tűnik,hogy hibátlan egyenlőre.

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.

Előzmény: n/a (inaktív), 2015-03-13 21:06:00 [1961]

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.

Előzmény: n/a (inaktív), 2015-03-13 21:21:00 [1966]

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.

Előzmény: n/a (inaktív), 2015-03-13 21:17:00 [1965]

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

Előzmény: n/a (inaktív), 2015-03-13 21:12:00 [1964]

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.

Előzmény: lari, 2015-03-13 18:08:00 [1953]

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?

Előzmény: lari, 2015-03-13 18:08:00 [1953]

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.

Előzmény: ANTAL GÁBOR, 2015-03-13 17:14:00 [1945]

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 )

Előzmény: ANTAL GÁBOR, 2015-03-13 20:17:00 [1960]

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

Előzmény: lari, 2015-03-13 17:59:00 [1950]

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.

Előzmény: dezsoe, 2015-03-13 12:49:00 [1944]

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

Előzmény: Polgárdi Balázs, 2015-03-13 19:26:00 [1959]

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ő.

Előzmény: ANTAL GÁBOR, 2015-03-13 19:02:00 [1958]

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

Előzmény: Polgárdi Balázs, 2015-03-13 18:50:00 [1956]

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.

Előzmény: ANTAL GÁBOR, 2015-03-13 18:49:00 [1955]

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:

Előzmény: ANTAL GÁBOR, 2015-03-13 18:24:00 [1954]

Még egy kapcsolódó kérdés : van az Index prescaler ( funkciója tiszta , ha van egy 4 réses indextárcsa akkor 4 et kell beírni és így minden negyedeiket dolgozza föl indexnek . ) Gondolatban tágítom a kört. Van egy 100 réses tárcsám ( A/ B jellel ) bekötöm
főorsóencodernek és az A-t külön ( még egyszer ) az indexre . Utána beállítok a prescalerbe 100 as számot Fog működni ? ( az én logikám szerint igen )

100 réses tárcsa és max 1000 1/min Ez 6.66 kHz . Gondolom a PIC ( leosztott ) órajele vetül a két beérkező jelre tehát ha nem 90 fok akkor ciklikusan mást mér , de ha tettetek átlagolást a softba akkor jó is lehet ( Irtam hogy egy irányban forog az orsó mert irányváltás esetén triviális hogy nem lesz jó ( válasz Larinak is )

Előzmény: Polgárdi Balázs, 2015-03-13 17:52:00 [1948]

Még egy

Ha használni akarom a run from here lehetőséget,
lefagy a program, s az alábbi hibaüzenet sorakozik fel igen nagy számban ...
Initial movement preparation

Menetfúrásnál és szinkron menetvágásnál a főorsó pozíciót ugyanúgy az A,B jelekből figyeli. Ideális esetben ezeknek a jeleknek 90fokos eltolással kellene lennie. Gábornak is javaslom, hogy a lehetőségekhez képest pontosan be kellene állítani.

Előzmény: lari, 2015-03-13 17:53:00 [1949]

Másik.
Ha egy g kódot betöltök- Load file, close file vagy revind file gombokat használom, akkor a motorok rándulnak egyet.
Hogy fizikai elmozdulás történik-e azt nem tudtam még megnézni, de a jelenség tapasztalható volt a régi verziókban is.

Szia Balázs!

Tapasztaltam valamit az UCCNC kapcsán.
Ha MPG-el közelítek valamelyik végálláshoz, majd a végállás aktivizálódik, a hajtás leáll.
Override limits gomb megnyom, majd reset, és a tengely tovább ugrik jó pár mm-t abba az irányba, amelyikbe a végállás van.
Ez azért nem jó, mert ha a végállás nagyon közel van a tengely mechanikai végpontjához, akkor ütközés van és a motorok (búgnak) túlterhelődnek.
Ha kézzel mozgatva (billentyűzetről) gyorsjáratban történik ez a folyamat, akkor a fent leírt negatívum nem jelentkezik.
Lehet ezzel valamit kezdeni?

Előzmény: n/a (inaktív), 2015-03-13 11:53:00 [1943]

Ha jól tudom Az A-B jelek 90 fokos eltolásának akkor van jelentősége, ha rigid tapping módban, tehát merev menetfúrásra akarod használni, itt ugyanis a menetfúrás végén automatikusan főorsó forgásirányváltást kell végrehajtani.
Ha nem jól tudom, akkor valaki kijavít...

Előzmény: ANTAL GÁBOR, 2015-03-13 17:14:00 [1945]

Nem gond, ha nem pont 90fok, (csak akkor ha a max 100kHz-es tartomány közelében van az enkóder kimenő frekvenciája). Hány rés van a tárcsán, és mekkora max fordulattal szeretnéd használni?

Előzmény: ANTAL GÁBOR, 2015-03-13 17:14:00 [1945]

Bocsi, kimaradt az olvasatból a "nem akarok"

Előzmény: ANTAL GÁBOR, 2015-03-13 17:14:00 [1945]

A főorsó átjárhatóság problémáját a nagyok általában úgy oldották meg, hogy a normál tengelyes encoder a főorsó mellé van szerelve egy kis csapágyazott segédtengelyre és egy kis fogazott szíj viszi át a hajtást 1:1-ben.


Az ipari elektronikák nem túl érzékenyek az 50%-ra, 40-60 arány biztos nem lesz gond.
De ha állíthatóra csinálod akkor szkóppal nézve igen pontosan be tudod áéllítani.

Előzmény: ANTAL GÁBOR, 2015-03-13 17:14:00 [1945]

Egy érdekes problémába ütköztem ( és nemcsak Balázsnak szánom a kérdést ) Csinálok egy nagyméretű encodert a TOS- omra. ( a cél a szinkron menetvágás kipróbálása ) Azért nem gyári mert meg akarom őrizni a főorsó átjárhatóságát és nem akarok szíjáttételt A tárcsa az egy lézervágott 1 mm es KO lemez ( már kb egy fél éve kész van ) A kiolvasás : résoptóval az index egy másik osztókörön reflexiós optóval Természetesen a résoptókat fizikailag egymáshoz képest 90 fokkal el akarom ékelni ( az egyik állítható lesz ) A konkrét kérdés : mi lesz akkor ha nem sikerül jól az elékelés és mondjuk 70 fokra lesznek egymástól ? Az A csatorna jele szép 50% os négyszög lesz ,a B csatornáé szintúgy csak a kettő között a fázistolás 70 fok. Egy irányban forog a főorsó. Csak a megérthetőség szempontjából a kapott A jel magas szintje legyen 1 ms . Akkor a 4 élkiértékeléskor a jelek 0.38, 0.62, 0,38, 0,62 ms onként követik egymást Ha az Uc100 as úgy dolgozik hogy egy kapuidő alatt megszámolja az impulzusokat akkor talán nem baj ha azok a példa szerint jönnek de ha a két beérkező jel között eltelt idő a kapuidő és arra vetül a DSPIC belső órája akkor gebasz mert nem fogja tudni kiértékelni ( tudom hogy nem hagyományos számlálás történik a PIC ben de így talán szemléletesebb ) Ha van valami átlagolás a soft ban akkor lehet megmenekültem . Persze igyekezni fogok jól beállítani de a műhelyben elég macerás lenne egy kétsugaras szkóppal . Vagy csináljak egy fáziskomparátort ? Vajon mennyire kötött a 90 fok ??

Szia!

Az indulást demó módban nem látom, de a Load/Close már jó. Viszont továbbra is maradt az Apply és a Save settings, itt még bekapcsol.
A homing így teljesen érthető, praktikus. Akartam már hominggal kapcsolatban kérdezni, hogy problémás-e (vagy egyáltalán rajtam kívül valakit érdekel-e), hogy a tengelyeknél megadható lenne, hogy a home beállítása után hol álljon meg a tengely. Nálam pl. X és Y -5-re állítja a gépi koordinátát és ha rögtön el tudnám zavarni 0-ra, akkor bekapcsolhatnám a softlimitet, nem panaszkodna, hogy kívül vagyok rajta.
Még egy dologba futottam bele. Nálam a probe aktív demó módban. A mostani újítással (ami egyébként nagyon jó, ha rajta van a gép!) nem "probe-ol", ha a jel aktív. Nem lehetne itt elválasztani a demó és éles üzemmódot? (Esetleg az Offline kapcsolóhoz kötni?)
És még valami a demó módhoz. Egy LED-et lehetne neki definiálni, hogy makróból tudjam, hogy demóban vagyok.

Előzmény: n/a (inaktív), 2015-03-13 11:50:00 [1942]

Az MPG beállított sebességhez képesti +4%-os max. sebessége is javítva lett, ez kimaradt a javítási listából, elfelejtettem leírni az előbb.

Előzmény: dezsoe, 2015-03-11 23:52:00 [1926]

A homing speed up és down értelme, hogy a home kapcsolóra fel és lefutás sebességei külön konfigurálhatók. A homeolás így gyorsabbá tehető, mert a home szenzorra felfutás sebessége lehet egy nagy sebesség érték, hogy a gép gyorsan elérje a szenzort. A lefutás pedig lassú, hogy a home pozíció pontos legyen, mivel a szoftver a lefutás pozícióját veszi home-nak, így ha lassan áll le a home szenzorról, akkor pontosabb lehet a bemérés...

Előzmény: dezsoe, 2015-03-11 23:52:00 [1926]

Sziasztok,

A jelzett hibák javítva lettek:

- Charge pump induláskor egy pillanatra bekapcsolt.
- Charge pump a file kezeléskor is bekapcsolt.
- kb. d>1méter feletti köröket nem jelenítette meg a szerszmámpálya.
- A jog mód (cont.,step,MPG módok) ha külső bemeneti triggerre volt téve és a charge pump jellel volt visszakötve,
hgoy folyamatosan frissítse az állapotot (pl. forgókapcsoló egy-egy állása), akkor a ciklikus 12.50kHz-es hívás
akadozó jog problémát eredményezett.
- MPG számábrázolási probléma.

UCCNC 1.1004 letöltése

Ok. Remélem megtaláltam 867 és 869-es, majd kipróbálom.
Más. Ma Feltettem az új 'test' verziót, jól kivágta amit kellett, de a megjelenítésénél valamiért a két körből csak egy látszik..
N0010 (Filename: kislemez.tap)
N0020 (Post processor: UCCNCplasma.scpost)
N0030 (Date: 13/03/2015)
N0040 G21 (Units: Metric)
N0050 G53 G90 G91.1 G40
N0060 F1
N0070 S500
N0080 (Part: kislemez)
N0090 (Operation: Insert code snippet Code: Start)
N0100 #850=1
N0110 #8500=1
N0120 S200
N0130 (Operation: Inside Offset, MERET, T2: Plasma, 4 mm lemez 50A)
N0140 M06 T2 F900.0 (Plasma, 4 mm lemez 50A)
N0150 G00 Z25.0000
N0160 X582.7110 Y630.4882
N0170 Z4.0000
N0180 M03
N0190 G04 P400
N0200 G02 X585.3991 Y630.1049 I1.1524 J-1.5357 F900.0
N0210 X585.3991 Y630.1049 I-137.3991 J-103.1049
N0220 X585.0158 Y627.4168 I-1.5357 J-1.1524
N0230 M05
N0240 G04 P500
N0250 G00 Z25.0000
N0260 X743.8239 Y405.8668
N0270 Z4.0000
N0280 M03
N0290 G04 P400
N0300 G02 X746.5243 Y405.5832 I1.2085 J-1.4920
N0310 X746.5243 Y405.5832 I-36.5243 J-29.5832
N0320 X746.2408 Y402.8828 I-1.4920 J-1.2085
N0330 M05
N0340 G04 P500
N0350 G00 Z25.0000
N0360 M05 M30

A dokumentációban le van írva.

Előzmény: xabi, 2015-03-12 19:25:00 [1938]

Szia, arra rájöttem hogy a label helyett field van, de hogyan tudnám meg hogy a Fset és az Sset field-nek mi a lekérdezési száma ?

exec.mainform.AS3.Getfield(?????);

Illetve rosszul írtam, vagyis félreérthetően, mert nem csak a screensetben szűnt meg a label objektum, hanem globálisan, beleértve a makróból elérést is.

Előzmény: xabi, 2015-03-12 12:02:00 [1935]

Szia,

A "label" típusú objektum a screensetben teljesen meg lett szüntetve.
A régi verziónál volt label és inputlabel, ezeket összevontuk és "field", azaz mezőnek neveztük el. A lekérdezést a Getfield(int), illetve a Getfieldtext(int) függvényekkel lehet. Ezzel az összevonással egyszerűsödtek a dolgok, átláthatóbb lett szerintem.
A /Documentation mappában van leírás a függvényekről, a régi doksit kiegészítettük...

Előzmény: xabi, 2015-03-12 12:02:00 [1935]

exec.mainform.AS3.Getlabel(110);
exec.mainform.AS3.Getlabel(108);

A fenti kiolvasott értékeket az új programban nem találom. Hogyan tudnám lekérdezni ?

Köszönöm Balázs! ugye nem baj ha ilyen kérdésekkel bombázlak , gondolom a válaszok másnak is hasznosak ... A leírásodból az is következik hogy a fizikailag 100 réses encodernél a configurálásnál 400 ppr et kell írni

Előzmény: Polgárdi Balázs, 2015-03-12 09:03:00 [1930]

Még egy fontos dolga van, csak ha már a fut a szoftver akkor engedélyezünk vele minden letiltható dolgot.
Ugyanis az XP-nél alapból az LPT porton bármilyen jelszint kint lehet.

Előzmény: istvan58, 2015-03-12 09:42:00 [1932]

köszi, kezdem érteni....még egy két kérdés de átviszem a topicomba hogy ne itt szemeteljek...ha ráérsz nézzél át oda.

Előzmény: svejk, 2015-03-12 09:33:00 [1931]

Anno a Mach3-nál vezették be, ez gyakorlatilag egy olyan kimenet, amin a szoftver normál működése során 10 kHz körüli négyszögjel jelenik meg.
ha lefagy a szoftver, vagy belső számolási hiba keletkezik ez a jel azonnal megszűnik.

Később már variáltak, pl. az E-stop-pal is össze lehet logikázni, csak akkor van meg ez a jel, ha működik a szoftver és nincs az e-stop lenyomva.

Maga a charge pump elnevezés pedig abból adódott hogy ezt a négyszögjelet egy egyszerű diódás-kondis "töltéspumpával" figyelték és egy tranzisztort vezéreltek vele, mely aztán beavatkozhat a hardveres vészstop körbe.

Előzmény: istvan58, 2015-03-12 00:06:00 [1928]

A főorsó enkóderének jelét 4x üzemmódban figyeli az UC100 vagy UC300. Én 100 réses enkódert javasolok (400ppr). Két kitétel van csak, hogy az enkóder A,B jele 100kHz alatt legyen 50%-os kitöltéssel, és az index impulzus min. szélessége 20usec. Az A,B jel frekvenciája egy 100 réses (400ppr) enkódernél pl. 2000 1/perc-es fordulatszámon 2000/60*400 = 13333.33Hz.

Előzmény: ANTAL GÁBOR, 2015-03-12 08:22:00 [1929]