Van lehetőség őj profilhoz másik screenset betőltésére,anélkül,hogy a profil file-ba bele kellene írni?

Gondom van.

UC100-am van, UCCNC 1.0039, a leírtakat az X, Y és Z tengelyen is próbáltam. Ha az Enable a 14-es, 16-os vagy 17-es lábon van, akkor nem működik rendesen. A lábat 0-ból 1-re tudja váltani, ha előzőleg 0 volt, de vissza nem kapcsolja. Független az Active low kapcsolóktól. Más lábon ezt nem tapasztalom (O1, O8, O9-en próbáltam, a többin tengely van). Először az én elektronikámra tippeltem (az egész saját tervek alapján épült, ezért minden lehet...), de miután alaposabb tesztnek vetettem alá a programot, kiderült, hogy UC100 demó módban is így megy, a diagnosztika fülön lehet nézegetni.
(Természetesen az elektronika a 17-esen negálva várja az Enable jelet...)

A Getlabel tökéletesen működik.

Én viszont tényleg olyan drot akartam felraki,amit nem tud a felhastznló módosítan,mert ccsak kijelzésre hastználnám.
Úgy tűnik,hogy lényegében már minden utasításrt értek a screenset-ben.
A makróhoz meg az UCCNC.exe file-ból lesem ki a szükséges utasításokat,bár néha kell kicsit kísérletezni,és ojkor nem találom ami kell.

Előzmény: n/a (inaktív), 2014-11-01 12:13:00 [1454]

Mint friss uc 300 tulajdonos kérdezem, hogy miként lehet egy bemenetre Pl? 1 port 15 pin
több funkciót is hozzárendelni. x++,home,y--. stb.

Igen, a ToDouble a ludas, ahogy mondod, mert egy label-t töltesz fel a képernyőre és egy input mezőt olvasol ki. A kettő fajta objektum nem ugyanaz, így nem is jön létre 20000-es számú input mező. A Getinputlabel üres stringgel ("") tér vissza, ami nem konvetálható double értékké, ezért van a hiba.

Előzmény: csewe, 2014-11-01 12:10:00 [1453]

Egyetlen probléma van csak a kóddal, a screenset-re feltöltés a probléma, nem a double string konverzió.

A Sendlabeltoscreen az egy olyan címkét készít, ami a képernyőn csak olvasható, de nem szerkeszthető, ez a fajta teljesen más, mint az input mező. Ez a fajta mezőt a Getlabel(); függvénnyel tudnád kiolvasni, nem a Getinputlabal();-el, de szerintem neked nem ilyen mező kell, hanem amit a user tud szerkeszteni a képernyőn.

A következő függvényre cseréld ki a Sendlabeltoscreent:

public void Sendinputtoscreen(string labeltext, string labelfont, string textalign, int fontsize, int fontcolor, int posX, int posY, int intextboxwidth, string type, double min, double max, int labelnumber, int parentnumber)

Például:

AS3.Sendinputtoscreen(" ", "Arial", "center", 22, 0, 100, 100 , 80, "fieldnb", 0, 300, 20000, 36);

Előzmény: csewe, 2014-11-01 11:51:00 [1452]

Mikor csak ezt a sot hagytam a makróban,akkor is megékezett a hibaüzenet,tehát tévedtem,és nem a tostring függvény a ludas,hanem a todouble:
double a = Convert.ToDouble(exec.mainform.AS3.Getinputlabel(20000));

Tehát módosul a kérdésem.
Hogyan kérdezzem le és alakítsam számmá a dro-k értékét?

Előzmény: n/a (inaktív), 2014-11-01 10:50:00 [1451]

Alap módon működik,de valódi dro kiolvasánál hibát ad.
A sreenset-ben így helyeztem el a dro-t:
AS3.Sendlabeltoscreen("1230", "Arial", "right", 25, 35535, 110, 520, 20000, 49);//

És így olvasom ki:
double a = Convert.ToDouble(exec.mainform.AS3.Getinputlabel(20000));//1.23;
string b = Convert.ToString(a);
MessageBox.Show(b);

Őgy tűnik,hogy több paraméterel kellene ellátni a "Convert.ToString" függvényt,de nem találtam elég jó példát rá.

hibaüzenet.

Előzmény: n/a (inaktív), 2014-11-01 10:50:00 [1451]

Szia, menet válasz.
Ide is bemásolom, hátha valaki mást is érdekel.
double szám konvertálása string-é makróban, példa:

double a = 1.23;
string b = Convert.ToString(a);
MessageBox.Show(b);

Előzmény: csewe, 2014-11-01 10:42:00 [1450]

Szia Balázs,ment egy levél kérdéssel.

A "Jöszi" az "Köszi" akart volna lenni.

Előzmény: n/a (inaktív), 2014-10-31 21:08:00 [1448]

Szia,

Jöszi a hibajalentést.
Azt szeretném kérni, hogy most várjátok meg légyszi a következő kiadást. Addig most felesleges MPG további bugokat jelenteni, mert az MPG-ben a hibákat éppen javítjuk és így most mégegyszer át lesz nézve teljesen. Illetve a javításnál mindent újra tesztelünk. Szóval az új kiadás ami a 1.0040-es lesz (hamarosan), majd az után kérnénk szépen újra MPG-vel kapcsolatos hibajelentéseket.

Előzmény: lari, 2014-10-31 20:49:00 [1447]

Ma a következő hibajelenséggel találkoztam.MPG gomb bekapcsolva, Kézikereket forgatva, közben a Cont. gombot megnyomva a tengely bizonyos sebességgel tovább mozog.Reset gomb, vagy a végállás kapcsoló állítja meg.

Helyes, fő a minőség!
Igyekszem mielőbb tesztelhetőt alkotni.

Előzmény: svejk, 2014-10-31 16:31:00 [1444]

Ez viszont tényleg jó hír, legvégsősoron feltuningolok hardveresen egy billentyűzet elektronikát.

Előzmény: n/a (inaktív), 2014-10-31 09:30:00 [1435]

Az a Pokeys, meg a többiek ránézésre is tök gagyik.

Ha Te csinálsz egyet és valami probléma lesz, akkor lesz kihez fordulni segítségért.
És hidd el nem hagynánk, hogy vackot adj ki a kezedből!

Előzmény: dezsoe, 2014-10-31 09:27:00 [1434]

2.) Igen, pontosan erre gondoltam, kapcsolhatóan. Akkor akár a színezés is kikapcsolató lehet, hogy ne zabálja a procit, hiszen elég akkor megnézni, hogy mi a gond, ha nem futtatható a kód.

Előzmény: n/a (inaktív), 2014-10-31 10:28:00 [1441]

Szia,

OK, köszi az infókat.
Kérlek majd ha használod többet a szoftvert és találsz bármi problémát még, vagy ami esetleg nem tetszik, akkor írd le ide vagy nekem e-mailben és akkor elgondolkodunk rajta.

Előzmény: xabi, 2014-10-31 06:24:00 [1433]

2.) Szóval arra gondolsz, hogy ha van hibás kód, akkor jelezze és semmi ne fusson, el se induljon ciklus start-ra? Vagy legalábbis választható legyen egy ilyen opció?

3.) Igen, amit leírtál megoldást, azzal a módszerrel kitudod olvasni a Z mérési eredményt és utána a változó értékét feltudod használni.

Előzmény: dezsoe, 2014-10-31 10:18:00 [1440]

Huh! Köszönöm a gyors választ!

1.) Ez durva...
2.) Ezt úgy gondoltam, hogy ha van a betöltött g-kódban legalább egy olyan mondat vagy bármi, ami hibás (tehát kihagyná), akkor ne lehessen az egészet futtatni.
3.) A számítások rendben vannak, csak az a fránya Z... Viszont a #1431 nagyon hasznos volt, mert kiderült belőle, hogy csak egyszer fordítja a makrókat, így most meg tudom oldani a Z kiolvasását egy M310 makróval, ami egy sor: exec.ivars[9]=exec.GetZpos();, majd használom a #9-et. Csak a sebessége miatt aggódtam, de #1431 megnyugtatott.:)

Előzmény: n/a (inaktív), 2014-10-31 09:55:00 [1439]

Szia,

Kérdésekre a válasz:

1.) A kód szinezését még az elején megcsináltuk, de sajnos a Flashplayer annyi proci időt zabál a szinezésre, hogy nem igazán jó. Utánaolvastam és arra jutottam, hogy nincsen rá egyelőre megoldás. Az, hogy csak pirosra szinezi a nem végrehajtható kódokat, gyakorlatilag ez a művelet zabálja fel a teljes proci idő (amit az UCCNC használ) kb. 30-40%-át ami azért eléggé durván sok. Ha minden szinezve lenne különböző szinekkel, akkor több proci időt eszik maga a szinezés, mint a program egész többi része. Ez szerintem nem működő megoldás így. Talán valamikor az Adobe a Flashpalyerben megoldja majd, hogy a szines sztringek ne zabáljanak ennyit.
2.) Ha hibás egy kód, akkor az nem futtatható, hiszen hibás.
3.) Van ilyen, ismeri a parametrikus programozást az UCCNC, az amit írsz, hogy # változókból vegye az adatokat, azt tudja a program, sőt képleteket is tud számolni, sőt sin, cos, tan, abs, stb. függvényeket is ismeri. Viszont a G31-nél nem teszi el változóba a mérés eredményét, ez még nincs megcsinálva.
Több infó a parametrikus programozásról, a rendelkezésre álló függvényekről stb. a dokumentációban.

Előzmény: dezsoe, 2014-10-31 09:44:00 [1438]

Nagyszerű, az jó lesz!

Lenne viszont néhány kérdésem, észrevételem.
- A kód színezőbe nagy meló lenne belenyúlni? Az a gondom, hogy minden, amit nem hajt végre, az piros, de nem mind hiba. Nem lehetne az Nxx sorszám pl. sárga, a megjegyzések pl. zöld színnel? Akkor messziről látszik, hogy nem hiba, csak irreleváns a futtatás szempontjából.
- Már jóval korábban is kérdezte valaki, de nem rémlik, hogy lett volna állásfoglalás arról, hogy lehetne-e valahol egy pipa, hogy a hibás kód futtatható legyen-e. Én biztos bepipálnám.
- Lehet-e belső változókat olvasásni G-kódból (pl. G31 után #2002 a Mach3-ban)? Ha nincs ilyen funkció, akkor legalább a tengely pozíciókat meg lehetne-e oldani a változókhoz hasonlóan mondjuk #X, #Y stb. módszerrel? (A példában levő G31 utáni Z olvasás kéne nagyon.)

Előzmény: n/a (inaktív), 2014-10-31 09:30:00 [1435]

Pokeysből annakidején vettünk pár teszt példányt, vannak vele problémák. Egyik gond, hogy nagyon zavarérzékeny. A másik, hogy a mikrovezérlő lábait soros ellenállás nélkül kivezették a panelon a sorkapcsokra. Többször előfordult, hogy egyszerű érintéstől az ESD miatt szétment valamelyik bemenet vagy kimenet, mivel nem raktak még egy soros ellenállást sem ami korlátozná az ESD kisüléskor vagy hosszú kábel csatlakozásból adódó induktív túlfeszültségeket. Szóval nagyon érzékeny az áramkör, önmagában nem lehet biztonságosan használni. Amúgy funkcionálisan működött.

Előzmény: dezsoe, 2014-10-31 09:27:00 [1434]

Köszönöm! A #1398 és #1434 egyelőre rövidre zárta a kérdést, de ha mégis szükség lesz rá, akkor még elő lehet venni a feladatot.

Előzmény: ANTAL GÁBOR, 2014-10-28 17:02:00 [1382]

Fogja tudni kezelni a ctrl, alt, shift módosító gombokat , ill. azok bármilyen kombinációit hamarosan. vagyis hogy pontos legyek már megcsináltam, de szoftver kiadás később lesz, mert még teszteljük az új, ill. javított funkciókat.

Előzmény: dezsoe, 2014-10-31 09:27:00 [1434]

Volt egy ötletem, hogy mikrokontrollerrel hamar meg lehet csinálni, de amit javasoltak (PoKeys56U), az mindent tud, amire szükség lehet, kár lenne energiát fektetni bele. Csak az a probléma, hogy az UCCNC egyénileg értelmezi a gombokat, így nem lehet módosító billentyűt nyomni. (Én pl. a file betöltést szerettem volna a máshol megszokott Ctrl+O-ra rátenni, de a Ctrl-re beírt 17-et, az O már nem is érdekelte...)

Előzmény: svejk, 2014-10-29 12:42:00 [1398]

Szia,
- 0038-at használtam.
- A 3sec nempontosan gondoltam, lehet hogy csak 0,5 sec, csak zavaró hogy nem történik semmi kényszert érzek hogy újból megnyomjam-e a gombot vagy ne. A Mach3 rögtön reagált. Lehet hogy csak szoknom kell.
- A cycle start után is gondolkodik pár másodpercet, de utána tényleg hibátlanul és gyorsan fut, ez tetszett.

Még csak 1 napja hsználom, majd jövőhét végére kitapasztalom, ha gondom van írok.

Ja, még azt le akartam írni, hogy a 2800 soros progi nem szabadna, hogy gondot vagy bármilyen lassulást okozzon. Egyrészt mert a 2800 sor az nem sok, én többszázezer soros progikkal is teszteltem. A másik dolog, hogy ha tényleg olyan sok sorból áll a program, hogy az lassulást okozna, akkor automatikusan hozzá állítja a progi a frissi ciklusidejét például a 3D nézetnek, hogy ne legyen lassulás.
De a gyors hurkok, amik a mozgatást stb. végzik azok mindig 50Hz-el futnak, viszont azok nem "esznek" sokat.

Előzmény: xabi, 2014-10-30 20:30:00 [1430]

Szia,

Köszi a tesztelést.
Melyik szoftver verzió van feltelepítve?

Ezt a 3sec késést nem nagyon értem, nincsen valami felesleges várakozás beleírva a makróba. Olyan 300msec körüli késés a makró végrahajtásánál az előfordulhat ha hotkey-re van definiálva, mert a C# fordító valósidőben fordítja be mindig a makrót, csak így lehet azt megoldani, hogy szövegszerkesztővel bármikor át lehessen írni a makrókat és mindig a frissen átírt verziót futassa.
G-kód program futtatáskor ez a késés nem nagyon jelentkezik, mert olyankor a sorokat puffereli a progi és már előre befordítja a makrókat, de csak akkor futtatja, amikor odaért a végrehajtás, ilyenkor a késés nulla körül kell legyen.
A 3sec az nagyon sok, ott szerintem a makróban kell valami hiba legyen ami miatt várakozik.

Az egyetlen dolog amibe mesterségesen beépítettünk késleltetés, az a referenciára futás, ezt kollégám kérésére lassítottuk be, mert neki nem tetszett, ha rögtön ugranak egymás után a tengelyek.

Egyébként volt egy hiba a progiban, azért kérdezem melyik verziót használod, amit le is írtam, hogy a .stop eseménynél benne felejtettem a debuggoláskor használt pár dolgot, ami esetleg okozhat ilyen várakozgatást. A legutolsó verzióban ez már ki lett véve.

Azért is gondolom, hogy talán régi verziód lehet fent, mert a hotkeys definiálásánál nekem nem joggol a legújabb verzió, úgy látom, mintha már le lenne tiltva, bár a kódot még nem néztem át...

Előzmény: xabi, 2014-10-30 20:30:00 [1430]

A mai napra sikerült átírnom a mach3 makróimat UCCNC-re, így áttértem.

A hotkeys billentyűk konfigurálásánál össze vissza mozgott a gép itt is mindenképpen tiltani kellene a hotkeys billentyűket.

Ami tetszett :
- Első próbálkozásra egy 2800 soros (35.000 mm vágási hossz plazmán) programmal vágtam, hiba nélkül végig vágta.
- Sokkal jobb a kezelő felülete, főleg a szerszámpálya ablak.

Ami nem tetszett:
- valahogy lassú a program, vagy nem is a program hanem csak lassan reagál, vannak makróim amikhez hotkeys billentyű van rendelve, megnyomok egy gombot és 3 sec múlva történik csak meg az esemény. Mintha valami késleltetné..? Ha be volt töltve a 2800 soros program akkor még nehezebben reagált.
- Végig vágta a 2800 soros programot, de utána valami történt mert ref. home gombra csak a Z tengely állt referencia pontra. (újból kellett indítanom hogy megjavuljon.)
- Voltak még apró hibák amik nem voltak reprodukálhatóak (ha ki tudom szűrni mi okozta jelzem).

Ez jó egy már félbe hagyott darab folytatásához
Ha a szerszám korrekció is menet közben módosíható akkor ugye eltolás meg hasonló hasznos dolgok beigazitáshoz

Előzmény: robroy007, 2014-10-29 19:57:00 [1428]

Mielőtt ezt a hibát teljesen megszűntetnétek !

A Forest gép aminek közelébe dolgoztam (6x3x2m munkaterület 5 tengely) tudott olyan trükköt, hogy munka közben lehetett a koordináta rendszert mozgatni, vagyis pontosabban egy felületi vagy akármilyen megmunkálás során menet közben lehetett ilyen módon az érintőt felvenni

Előzmény: n/a (inaktív), 2014-10-29 17:08:00 [1424]

Értem.
Akkor sajnos egyelőre a bill. emulátor is felesleges.

Előzmény: n/a (inaktív), 2014-10-29 17:09:00 [1425]

Még egy.

Ha nem a RUN fülön vagyok, vagy átváltok egy másik futó program ablakra, a kézikerék továbbra is működik, esetleg szakadozva. Ilyen esetben szerintem tiltva kellene lennie.

Előzmény: n/a (inaktív), 2014-10-29 17:08:00 [1424]

Ahogy most működik, úgy nem tudja a billentyű kódokat úgy mint shift+, ctrl+ stb.

Előzmény: svejk, 2014-10-29 15:35:00 [1419]

Szia,

Köszi a hibajelzést, hamarosan utánanézünk és kijavítjuk.

Előzmény: lari, 2014-10-29 17:05:00 [1423]

Ismét.

Ha elindítok egy G kódot és az MPG be van kapcsolva, akkor a kód futása közben a kézikerékkel odébb tudom mozgatni bármelyik tengelyt.

Na még egy.

MPG mód X tengely mozog. Átkapcsol Y tengelyre, ami a monitoron kijelzésre is kerül. de továbbra is az x tengely mozog... Nem mindig jön elő a hiba...

Balázs!


Egy újabb megtapasztalás...
MPG bekacsolva, X tengelyt mozgatom.
Eléri a végállást, tengely megáll, ESTOP.
Ez eddig jó.

MPG bekacsolva, X tengelyt mozgatom. (de bármely tengelyre igaz)
Megállok a mozgatással E-stop-ot nyomok, tengelyek tovább mozgathatók.
Tehát ha a tengely mozgása közben nyomok E-stop-ot, akkor leáll a tengelymozgás de egyébként nem.

Próbáltam kilépni az MPG módból, majd megpróbáltam a tengelymozgató nyilakkal mozgatni a tengelyeket a billenytüzetről, de az helyesen működik.

Jól van no!
Egyszerű tévedés lehet, írta Balázs, hogy javítva lesz.

Előzmény: fektiforg, 2014-10-29 15:33:00 [1418]

Nem akarok a türelmeddel játszani, csak tudni kellene, hogy a kezelőpultom fejlesztését milyen irányba vigyem?

"Az előbb próbálgattam és sajnos az UCCNC HOTKEY felületén csak a normál billentyűk kódjait veszi be, hiába írok be neki mondjuk 125-öt (ez a kapcsos zárójel bezárás, AltGr+N billentyű vagy Alt+125) ezt nem észleli az UCCNC."

Előzmény: n/a (inaktív), 2014-10-29 15:27:00 [1416]

Most már semmit sem értek, vagy Én nem vagyok érthető? MPG multinál mi értelme van az JRO nak,
magyarázza meg már valaki !

Igen, valami bibi csúszhatott bele, semmi gond majd megjavul.
Én már így is nagyon becsülöm a hozzánk való türelmeteket!

Előzmény: n/a (inaktív), 2014-10-29 15:27:00 [1416]

Elvileg úgy kéne működnie, hogy a pipa kiszedése teljesen le kéne válassza a JRO-t az MPG-ről, minden állapotban. De akkor ezek szerint ez még nem tökéletes. Ezt majd P.Balázs tudja megcsinálni szerintem, mert az UC hardveresen kapcsolja össze ezeket a dolgokat.

Előzmény: svejk, 2014-10-29 15:23:00 [1414]

Igen lett, ezt mondom én is, hogy hamar megcsináltuk neked a funkciót amit kértél, ki tudod választani ha akarod, aki meg nem akarja az meg nem választja ki.
Van aki ezt máshogy látja és szeretné ha a JRO hatással lenne az MPG-re is.
Te nem szeretnéd és a pipával meg is teheted, hogy így legyen.
Sajnos az nem megy, hogy mindent pont úgy csinálunk ahogy te vagy más ember kéri, mert más meg ugyanazt máshogy szeretné, ilyenkor kompromisszumokat kell kötni, vagy jön a "pipa" mint megoldás.

És az, hogy esetleg nem helyesen működik még az elképzelhető, meg fogjuk vizsgálni hamarosan.

Előzmény: fektiforg, 2014-10-29 15:14:00 [1413]

Valóban, csak MPG Count-nál működik a "pipa" de MPG Multi-nál nem.

Előzmény: fektiforg, 2014-10-29 14:55:00 [1407]

#1190 -ben irtam : "Elég csak annyi, hogy MPG multi üzemmódjára nincs hatással az JRO poti, mert kis % -on mi értelme is van ?
Szerintem így nem is kell pipa !"

Háát, mégis pipa lett!

Előzmény: n/a (inaktív), 2014-10-29 15:05:00 [1409]

Lemaradt a válaszgomb a #1411-t neked címeztem.

Előzmény: n/a (inaktív), 2014-10-29 13:48:00 [1405]

Modjuk fut egy makró,ami csak akkor léphet tovább,ha megnyomnak egy bizonyos gombot,de ez a gomb jelen esetben ez egy userbutton.
Esetleg így nézne ki a dolog:

while(exec.Getdobutton(user button number)){}
messagebox.show("Gomb lenyomva");

Persze meg tudom oldani,úgy,is,hogy a gombomhoz rendelek egy ledet,amit a gombhoz rendelt makróval átváltok,de ez nagyban megbonyolítja a dolgot,mivel két makró nem futhat egyszerre.


Gonodolom,nincs megengedve a makróban,hogy definiáljak egy új szálat,és azt párhuzamosssan futtassam.

OK, köszi az infót, megpróbálok írni a Péternek.

Előzmény: Sz.József, 2014-10-29 13:51:00 [1406]