Szia,

Szerintem nem az SSD okozza a gyorsabb futást, hanem maga a proci teljesítmény, illetve a RAM sebessége esetleg.
Az is lehet, hogy "véres a torka" az oprendszernek azon a gépen ami ezt a lassúságot produkálja. Esetleg valami rezidens program fut rajta, pl. vírusirtó, vagy éppen vírus ami lefoglalja a gépet.
Netán az alaplap öreg és kiszáradtak a kondik, a hűtőpaszta a procin stb.

Az ugyanis nem normális, hogy a macro fordítása több másodpercet vesz igénybe.
Megnéztem ma a kódot mégegyszer ami a macro-kat fordítja és nem igazán van már rajta mit optimalizálni, mert a kód alig áll néhány sorból.
Macro futtatásakor ugyanis csak annyit csinál a progi, hogy beolvassa a macro text file-t és elé és mögé fűz egy kis rövid string-et, hogy a macro egy osztály és egy függvény belsejében legyen és az egész szöveget (stringet) átadja a CodeDOM fordítónak, ami a VisualStudio (.NET) beépített gyári C# fordítója ami a .NEt framework-el települ, a fordító a kódból egy ojektumot majd futtatható állományt készít a memóriában. Ezután egyszerűen meghívom a kódban a függvényt, hogy fusson. Ennyit csinál a progi macro futtató része, minden fordítást a gyári fordító végez.

Kiméricskéltem a fordítást és futtatási időket itthon 3 PC-n is.
A fordítást és futtatást 1000 ciklusban csináltam és visszaosztottam az eredményt 1000-el, hogy pontosabb átlag eredményt kapjak. A fájl beolvasási idejét, a kód fordítási idejét és a futtatási időket mértem. A fájl beolvasási idők mindegyik gépen elhanyagolhatóan alacsonyak 10^-5 sec nagyságrendben voltak, ezért ezeket nem is írom le ide.

A fordítást az M204-es macroval csináltam ami viszonylag sok sorból áll. Kipróbáltam az M3-al is később, ami csak egy sor, de nem láttam nagyságrendi eltérés.

Az eredményeken egyébként szépen látszik, hogy a leglassabb a fordítási művelet, amit a CodeDOM csinál.

A mérési eredményeim:

1.) Egy öreg legalább 10 éves Compaq gép Celeron 1.8GHz CPU, 1Giga RAM-al, HDD-vel, Win 7/32bit telepítve.
- Fordítás: 0.254 sec
- Futtatás: 0.00048 sec

2.) Egy HP E8400 Core2duo, 3GHz, 2giga RAM-al, HDD-vel, Win 7/32bit telepítve.
- Fordítás: 0.138 sec
- Futtatás: 0.00033 sec

3.) Egy ipari pico ITX alaplap 1.86GHz duocore, SSD-vel, Win 7/32bit telepítve.
- Fordítás: 0.171 sec
- Futtatás: 0.00040 sec

4.) A 2. pontban lévő PC-n lefuttatam ugyanezt a tesztet, de a gépre VirtualBox-ba telepített XP-n, amitől lassú eredményeket vártam, hiszen ez így csak virtuális gépen futott, de nem lett túlzottan lassú.
- Fordítás: 0.286 sec
- Futtatás: 0.00055 sec

Mindegyik esetben UC300-5LPT-t csatlakoztattam. A virtualis PC-nél is a virtualbox USB driverek telepítésével.

Ha gomb nyomásra/input trigger-re hívódik meg macro, akkor ezekkel a késési időkkel kell számolni.
Ha viszont program futtatás közben hívódik meg a macro (ciklus start alatt), akkor csak a futtatás idejével kell számolni,
mert a macrokat aszinkron módon indításkor már fordítja a program és amikor odaér valóban a futás az adott macro sorra, akkor csak végrehajt, vagyis csak a futtatás idejével késik,
ami emberi és még CNC mértékben is elég alacsony ahhoz, hogy semmi lassulás érzést ne okozzon, mert a milliszekundum törtrészéről beszélhetünk.

Ha gondolod akkor szólj és átküldöm neked a tesztelő progit, ami megcsinálja az említett mérést és macro futtatáskor kiírja az idő eredményeket,
abból látszana, hogy hol megy el az a rengeteg idő...

Előzmény: xabi, 2014-11-15 20:51:00 [1587]

UCCNC-t egy nem túl mai darab Core2duo T5550@1,83Ghz laptopon használtam eddig (SSD-vel tök jól fut a windows7 (PassMark CPU eredmény 1050 pont).
A múltkor találtam egy még régebbi laptopot, gondoltam inkább ezt használom a sok kosz miatt. Ebben egy CeleronD335@2,8Ghz XPSp3 (PassMark CPU eredmény 278pont) ez már egy elég gyenge eredmény.

A program elindul és futott is, de irtó lassan reagál mindenre. A gyenge notebook jól kiemeli az UCCNC "lassúságát". A vágási részekkel, G kódokkal nincsen nagy baj, de ahányszor M utasításhoz ér a program elgondolkozik pl. M05 nél kb.: 2sec-el később kapcsolja ki a plazma ívet.

Az alábbi tapintás kódja nálam M2003.txt
És itt egy video :
Video
Miután megnyomom a gombot kb.: 5-7 sec telik el mire elindul a fej )))

Valami nagyon nincs jól megírva - optimalizálva.



if(!exec.GetLED(56)||!exec.GetLED(57)||!exec.GetLED(58)) // If machine was not homed then it is unsafe to move in machine coordinates, stop here...
{
MessageBox.Show("The machine was not yet homed, do homeing before executing a tool change!");
exec.Stop();
return;
}
while(exec.IsMoving()){}

//Z touch with retract for plasma zero height measurement
//Z 0.00 pont felvétel


string actfeed =exec.mainform.AS3.Getlabel(108); //aktuális mozgási sebesség
double Zmin;
double Feedrate = 400;
double retractheight = 3.7;
double mheight = 6;
double Zoriginalpos = exec.GetZpos();
Zmin = Zoriginalpos-30;

int originaldistancemode = exec.actualdistmode; // remember the distance mode
int originalmodalmode = exec.actualmodal; // remember the modal mode
exec.Code("G90"); // Set system to absolute distance mode
while(exec.IsMoving()){}

exec.Code("G31 Z" + Zmin + " F" + Feedrate); // Move to the probe sensor position in XY
while(exec.IsMoving()){}
//exec.Callbutton(102); // zero Z axis

if(!exec.Ismacrostopped()) // If probe action was not interrupted with a stop only then go on...
{
exec.Code("G92 Z-3.7");
//MessageBox.Show("Touch Probe sucessfuly");
// exec.Code("G01 Z" + retractheight); // Move above probe plate
// while(exec.IsMoving()){}
// exec.Callbutton(102); // zero Z axis
exec.Code("G01 Z" + Zoriginalpos); // Move originalpos
while(exec.IsMoving()){}
}
else
{
MessageBox.Show("Touch Probe not sucessfuly");
exec.Stop();
return;
}

exec.Code("G F" + actfeed);
exec.Code("G" + originaldistancemode); // Set system back to the original distance mode
exec.Code("G" + originalmodalmode); // Set system back to the original distance mode

Üdvözlet! Ma a másik gépen itthon gond nélkül elindult minden, a másik ezek szerint oprendszer gyalu.

Előzmény: n/a (inaktív), 2014-11-14 20:37:00 [1581]

Szia Balázs,ment egy levél.

Szia Balázs!
Pár napja Török Tamás jelezte,hogy a jog gombok kicsit késve válaszolnak,én is ugyanazt tapasztaltam,de azzal különbséggel,ha az érintő képernyő jog gombjait használom akkor nincs késés,csak akkor ha a valós billentyűzetet használom.
Nem akarok példálóznia Mach3-al,de ott nem jelentkezik ez a hiba.
Sőt talán azt hiszem mintha a 38-as verziónál jelentkezett volna először.

Előzmény: n/a (inaktív), 2014-11-13 19:58:00 [1577]

A minap írtam,hogy készítek egy bemérő képernyőt.
Van egy problám,amiben olyanok tudnak segíteni ,akik gyakran használnak tapintót.
Ha a tapintó eszköz nem a főorsóban van rögzítve,hanem X/Y/Z irányban el van tolva,akkor melyik utasítással érdemes figyelembevenni az eltolást?
G10 ,bagy G52 ,vagy g92 utaításokkal.
Ugyan ez a kérdés,ha a munkadarab nullpontját méri be valaki,akkor melyik utasítással állítja át,hogy a szerszám pozíciójába essen a nullapont?

Köszi, akkor sz+r a laptopom. Mindent beírtam, és semmi. Portok, pipa , minden. Egyébként a Z nél ha nem állítok be portot, akkor is mén. A hotkey-t megtaláltam, de a grab nem jelenik meg, csak a tálcán. A képernyőn nincs. A képernyőre kattintva pedig csak kongat. Ha a tálcán a GRAB-ra kattintok hogy teljes méret, akkor sem jelenik meg, de nem is enged semmit csinálni, csak ctrl alt dellel tudok kilépni. Majd otthon kipróbálom a másik gépemen, most szoliban vagyok. Köszönöm!

Előzmény: n/a (inaktív), 2014-11-14 20:37:00 [1581]

Szerintem 0 van beállítva a port és pin számra az lehet a gond.

Előzmény: fa_kukac, 2014-11-14 20:32:00 [1579]

Szia,

A hotkeys oldalon a Function oszlop mellett minden sorban van egy "SET" feliratú gomb.
Ha azt megnyomod, akkor előjön egy ablak a kódokkal és a funkciók neveivel.
A tengely Jog kódok Jog++ és Jog-- néven vannak a listában, például JogA++ a 153. kód stb.
Ha kiválasztottad a kódot utána a keycode gomb melletti set billentyűvel beállíthatod, hogy melyik billentyű megnyomására hajtsa végre a funkciót.

Ja és ne felejtsd el engedélyezni az A, B, ill. C tengelyt az axis setupban az Axis enable pipálásával és állíts be a step/dir pinekre is nullától különböző értékeket.

Egy printscreen a hotkeys beállításról:

Előzmény: fa_kukac, 2014-11-14 20:22:00 [1578]

status monitoron az Idle elalszik, és a jog, valamint a run kigyullad, mikor a bal oldalon rákattintok az A vagy B gombra, de a DRO nem változik.

Sziasztok! Valahogy nem találom a hotkey beállítást, és az A B C tengelyt nem tudom mozgatni sehogy, pedig szerintem kipipáltam és amit tudtam beállítottam. Help, köszi.

OK, köszi az infókat. A kód betöltésnél valóban, ha edit file notepad becsukás után néha gondolkodik egy kicsit. Még nem jöttem rá miért, de dolgozom a megoldáson.

A jog gombokra elvileg szinte azonnal kell readálnia, a gomb felengedésre is, legalábbis az én gépemen azonnal reagál, ill. a kód, gombfigyelés egy 20msec-os hurokban van, szóval az nagyon gyorsnak kellene hogy legyen.

Előzmény: Török Tamás, 2014-11-13 05:50:00 [1569]

Nem, egyelőre nem ismeri a G18, G19-et, de majd egyszer azt is fogja tudni.

Előzmény: lari, 2014-11-13 16:50:00 [1570]

Még az lehet, hogy a kommunikációs buffer túl rövid, lassú a PC, illetve az USB port. Próbáld meg átállítani a General settings-en a Com.buffer size paramétert. Alapban 50msec, próbáld meg mondjuk 200msec-el, hogy mit csinál.

Előzmény: Török Tamás, 2014-11-13 05:50:00 [1569]

Azért szinusz koszinusz-szal meg tudod csinálni.

Előzmény: lari, 2014-11-13 18:13:00 [1573]

Értem, köszönöm!

Előzmény: svejk, 2014-11-13 17:52:00 [1572]

Amint látod a G-kód ablakában a G18 és a G21 pirossal jelenik meg, ez azt jelenti, hogy az UCCNC (még) nem ismeri a koordináta elforgatást.

Előzmény: lari, 2014-11-13 17:44:00 [1571]

Az előbb nem egészen jól írtam a kódot, javítom
G18 G90 G21 G49
m3 s2200
g00 z0 x0 y0
f100
g01 z-3
g03 x-57 r400 z-7

m30

Kipróbáltam a mach3-ba, ott szépen kirajzolja a pályát

Z irányú íveket tud értelmezni az UCCNC?

Z irányba szerettem volna egy ívet marni.
KB a következő volt a kód:

G18 G90 G21 G49
m3 s2200
g00 z0 x0 y0
f100
g01 z-3
g03 z-5 r300

m30

Igen a betöltések, vagy amikor módosítok valamit a g kodban és újra betölti.
Az irány nyomógombok, megnyomom és mintha később indúlna és elengedéskor meg nem abban a pillanatban áll meg.

Mind a két prg-ban 100kh van beállítva.
A léptetők 3000 a csúcssebesség amin még hiba nélkül mennek (G0), 1000 fordulaton van a legnagyobb nyomaték itt már nem tudom puszta kézzel visszafogni a gépet, ehez képest 600 fordulatnál következett be lépésvesztés.

Azt meg akartam kérdezni, hogy azon mit értesz, hogy lassan reagál?
Azt, hogy a relief-nél lassan frissítni a 3D nézetet, vagy pedig azt hogy gombnyomásokra lassan reagál? Vagy netán egészen mást?
Kicsit kifejthetnéd, hogy értsük, hogy mire gondolsz.

Előzmény: Török Tamás, 2014-11-12 22:04:00 [1566]

Köszönjük az észrevételt.

A kernel frekvencia beállítás is azonos?
Csak azért kérdem, mert a túl nagy kernel freki egy olyan vezérlőnél aminek lassú az optocsatolója könnyen lépésvesztést okoz.
Az UCCNC-nél az alap a 100kHz, vagyis a leggyorsabb freki van alapból beállítva, ahol 5usec mindössze az impulzus szélesség. Mach3-nál szerintem alacsonyabb az alapbeállítás, de nem 100% biztos, rég nem használtam már a mach3-at.

Amúgy lépést biztosan nem téveszt az UCCNC, a step generátora már régen tökéletes és pontosabb sokkal mint a mach3-é.
Több mint fél éve használjuk az uccnc-t saját gyátásra, napi 6-8 órában 2 gépen, soha sem tévesztett! Ha nálad lépés vesztés van az esetleg amiatt lehet amit fentebb leírtam.

Előzmény: Török Tamás, 2014-11-12 22:04:00 [1566]

Ma nyüstöltem kicsit a vasat , a gépemet 6N-os léptetők hajtják , mint a MACH mint pedig az UCCNC is telepítve van!
A motorbeálítások paraméterei mind a két prg-ben megegyeznek.
Az UCCNC vel öt marást csináltam (relief) és csak 1 alkalommal ment végig lépésvesztés nélkül! (és a machoz képest nagyon lassú reagálású!!!)

A MACH öt marásból ötször ment végig hibátlanúl!

39es verzió fut.

Sziasztok,

Kijavítottam a hibát.

UCCNC 1.0043

Előzmény: csewe, 2014-11-12 08:38:00 [1562]

Hümm. Így lesz csak igazán érdekes:

double a = 10 ;
double b = 2 ;
double c = 1 ;
exec.Code("#1 =" + a + " - [" + b + " - " + c + "]") ;
exec.Code("G1 x#1 F100");
MessageBox.Show("Megállunk...");
exec.Code("G1 y#1 F100");
while(exec.IsMoving()){}
Ha az Y-ost kiveszed, akkor X megy vissza. A legutóbbi mozgást visszacsinálja? Érdekes.

Előzmény: csewe, 2014-11-12 08:38:00 [1562]

Nem kellene ide valami típuskonverzió?
(Double -> String)?

Előzmény: csewe, 2014-11-12 08:38:00 [1562]

Kipróbáltam ezt,és elég furcsán viselkedik:
double a = 10 ;
double b = 2 ;
double c = 1 ;
exec.Code("#1 =" + a + " - [" + b + " - " + c + "]") ;
exec.Code("G1 x#1 F100");
while(exec.IsMoving()){}

Szépen elmegy kilencig ahogy kell,majd azonnal lemegy nullára,amit viszont nem kéne neki.

"
Két oka van. Az egyik a zárójel: g-kódban () helyett [] kell, a () a megjegyzés. A másik, hogy nem adhatsz kifejezést paraméterként.
"
Bár tudtam ezeket,de mindkettőről megfelejtkeztem.

Előzmény: dezsoe, 2014-11-11 22:45:00 [1559]

Azért, mert string konkatenációt hajtasz végre, amiben a stringbe fűzi a számokat a C# fordító és nem hajtja végre az aritmetikát. Ez szerintem minden más programozási nyelvben így hajtódik végre, legalábbis amiket én ismerek.

A string értéke ez lesz:
G1 x5 - (2 - 1)F100

Ez G-kódban hiba, mert nem egy numerikus érték vagy változó áll az X paramétereként

Próbáld úgy, hogy az aritmetikai művelet eredményét egy double változónak adod és az eredményt fűzd bele a stringbe.

Előzmény: csewe, 2014-11-11 21:20:00 [1558]

Szia!
Két oka van. Az egyik a zárójel: g-kódban () helyett [] kell, a () a megjegyzés. A másik, hogy nem adhatsz kifejezést paraméterként. (Doksi, 4.2: "... műveletek megadása paraméterként nem megengedett.")
Tehát:
d = a + (b - c);
exec.Code("G1 x" + d + " F100");
vagy:
exec.Code("G1 x" + (a + (b - c)) + " F100");
vagy g-kódban:
#4 = #1 + [#2 - #3]
G1 X#1 F100
Amennyire emlékszem, a nem értelmezhető részeket kihagyja. Más tészta, hogy nem pirul el a kódnak ez a része.

Előzmény: csewe, 2014-11-11 21:20:00 [1558]

Ez miért nem hajtódik végre?

double a = 5 ;
double b = 2 ;
double c = 1 ;
exec.Code("G1 x" + a + " - (" + b + " - " + c + ")" + "F100");
while(exec.IsMoving()){}

Nincs hibajelzés semmi.
Mégsem mozdul meg az X tengely.

megint ítam választ.

Előzmény: csewe, 2014-11-10 14:35:00 [1556]

Ideért,és válaszoltam.

Előzmény: n/a (inaktív), 2014-11-10 12:45:00 [1555]

elküldtem mégegyszer...

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

Nem érkezett meg még eddig,esetleg mégegszer elküldhetnéd,biztos ami biztos.

Előzmény: n/a (inaktív), 2014-11-10 12:20:00 [1553]

Szia, ment válasz.

Előzmény: csewe, 2014-11-10 11:47:00 [1552]

Szia balázs,küldtem egy emailt.

Köszi!

Előzmény: n/a (inaktív), 2014-11-09 15:05:00 [1550]

Sziasztok,

A macro .stop hibát amit Csewe jelzett kijavítottam, mert ez nem az API-ban, hanem a programban volt.
Svejknek csináltam az Offline funkcióhoz LED kódot.

A charge pump problémát amit Dezsoe jelzett, ezt most nem javítjuk, mert a hiba valószínűleg az API-ban lesz és az átírás még nem készült el, majd ha az meglesz, akkor megvizsgáljuk a jelzett problémát.

Letöltés:
UCCNC 1.0042

Szia!

Tudom, hogy tesztszünet van, de már korábban, a #1468-ban írtam a charge pump problémáról. Némi további információm van hozzá.

Ha reset-tel leállítod a charge pump-ot, majd nyomsz egy close file-t (mindegy, hogy van-e betöltve valami), akkor is bekapcsolja a charge pump-ot, és nem is kapcsolja ki, csak reset állapot ki és be után. Demo módban is így működik.

Előzmény: n/a (inaktív), 2014-11-05 18:32:00 [1540]

Sajnos azt kell hogy mondjam,a képernyőn megnyomott cyclestop nem úgy működik futó makró esetén,mint ahogy leírtad.
DEMÓ MÓDBAN EZ TÖRTÉNIK:
A makró futása valóban megszakad,de a tengelymozgás nem áll le,csak egy pillanatra megtorpan.
Egy ilyen egyszerű makró esetén is tapasztalható ez:

exec.Code("G01 X1000 F100");
while(exec.IsMoving()){}

Csak két cyclestop nyomás állítja le a mozgásokat véglegesen.

Ez igaz a makróból nyomott cyclestopra is:

exec.Code("G01 X1000 F100");
while(exec.IsMoving()){
exec.Wait(2000);
exec.Callbutton(130);
}

Ennél csak akkor áll le a mozgás,ha még a képernyő is nyomok egy cyclestop-ot.

Érdekelne,hogy ez nem domó módban is így van e.

Előzmény: n/a (inaktív), 2014-11-07 23:04:00 [1547]

Szia,

Köszi a tesztelést.
Ahogy írtam néhány napja, most sokminden átalakítás alatt van a programban az alap mozgató magban sokminden át lesz írva, így egyelőre a tesztelést felfüggesztettük, de azért köszönöm a teszteredményeket, hogy megosztottad velünk.

A hibákat amiket jeleztél nem tapasztaltuk, elég érdekes és egyben fura problémáknak hangzanak. Talán a wifis billentyű valahogy "összeveszik" az UC100 vezérlőjével. Ilyen driver szintű összekeveredésre gondolok, hogy esetleg elveszik egymástól az USB hubvezérlő idejét és talán ez okozhat problémát, bár még nem láttam ilyet, ez csak egy elmélet.
Mach3-nál viszont hallottam olyat, hogy például x-box controller ha egy hubra van dugva UC100-al, akkor nem szeretik egymást és fura problémák jönnek elő. De ezt is csak hallottam ügyfelektől, nem volt alkalmam személyesen megfigyelni, kipróbálni.

Talán azt megpróbálhatnád, hogy az említett probléma akkor is előjön-e ha nem használod az említett wifi-s billentyűt meg más USB-s eszközt, csak hogy igazolni lehessen, hogy valamelyik USB-s eszköz okozza-e a problémát vagy esetleg teljesen más. Én legalábbis ezt próbálnám meg először.

Az UCCNC most ahogy írtad mindent időd msec-ben számol, meglehetne csinálni választhatóra, talán érdemes is volna majd...

Ha fut a program, ciklus start aktív, akkor a macro hívás eleve le van tiltva, nem tud végrehajtódni, illetve más dolgok is például a jog, MDI, stb. is.
Szóval emiatt nem kell szerintem aggódnod, mert ezekre eleve gondoltunk és tiltva vannak a program futása alatt az egyéb végrehajtások...

Ha nincs program végrehajtás és a macro-ban van egy cycle-stop azt végre fogja hajtani.
Van az IsMoving függvény ami pont azt vizsgálja, hogy van-e folyamatban és lehet várni a mozgás végére mielőtt egy következő parancsot kiadnál a makróban.

Ha a képernyőn nyomsz egy cycle stop gombot, az ad egy .stopwithdeccel parancsot az UC100-nak, ami megállít minden mozgást lassítással és a macro végrehajtása is megszakad, a következő utasítás ami a macroban van az már nem hajtódik végre ilyenkor, mert a cycle stop gomb nyomásának hatására az interpolátorban ilyenkor beáll egy feltétel, ami nem engedi végrahajtani a következő sorokat a stop gomb megnyomása után, így az összes többi sor ami a cycle stop után hajtódna végre az már nem fog.

Előzmény: xabi, 2014-11-07 20:43:00 [1546]

A héten elég sokat vágtam plazmán UCCNC vel, 039 és 041 verzióval.

Kezdeném a jó hírrel :
-Ha a program elindul tökéletesen vág, többször vágtam kb.: 3000 soros programmal 1,5 órán keresztül folyamatosan, egyszer sem hibázott. Nem tudom mitől van (elvileg semmi köze a vezérlő programhoz), de mach3-nál előfordult hogy nem gyújtott be a plazma vagy éppen vágás után égve maradt a fej. Ilyen UCCNC-vel nem volt (kb.: 6 óra vágás és 500 lyukasztás alatt) Respect !!!
- nagyon jó a grafikus szerszámpálya követés, tök jól lehet látni mit csinál(t) a gép.

Problémák:
- Ha elindítom az UCCNC-t és rögtön mondjuk betöltök egy 3000 soros programot utána be bolondul a program, nem veszi fel a referencia pontot pl. kifelejti az X tengelyt, nem működik a Hotkey wifis billentyűm utána hirtelen elindul és kiüti a végállás kapcsolót, nem reagál a macro-imra. Stb. Azt szoktam csinálni hogy elindítom az UCCNC-t utána referencia pontara állok felveszem a 0 pontot ha minden ok. akkor betöltöm a programot és cycle start így hibátlan.
- Sokáig kínlódtam a G04 Pxxx utasítással, mert az UCCNC msec-be fogadja az adatokat, a CAM programok általában sec-ben adják át az adatokat. Jó lenne ha be lehetne állítani hogy msec, vagy sec-ben értelmezze a G04-et.
- Nem tudom hogyan oldottátok meg a hotkey billentyűket. Alapvetően két állapot van fut a program vagy nem fut a program. Ha fut a program és megnyomok egy hotkey billentyűt mondjuk amihez egy macro van rendelve akkor mi történik ? Ha a macroban egy Cycle Stop van akkor azt azonnal végre kell hajtsa, de ha mondjuk pl.: egy G31-es tapintás az erős lenne ha azonnal végre hajtódna Hogyan működik?

Ballázs,küldtem egy emailt.

Igen. Épp most indulok némi alkatrészért a prototípushoz. Ha úgy lesz időm, akkor a hétvégén már tudom tesztelni. Modulosra tervezem, 16 (vagy ha csak a felét ülteted be, akkor 8) kapcsolónként egy kis panel sorkapoccsal, így 8-tól 64 gombig lehet variálni. A panelek párhuzamosan kapcsolódnak szalagkábellel.

Előzmény: svejk, 2014-11-07 07:59:00 [1543]

Dezsoe!

Ugye actív L szintes bemenetek lesznek belső felhúzóval, hogy a régi, jól bevált, örök életű HALL-os nyomógombokat is közvetlen lehessen hozzá használni!?

Előzmény: dezsoe, 2014-11-03 12:25:00 [1476]

Tudom,hogy kimazsolázhatnám a screenset file-ből,de megkérdezni egyszerűbb.

Jelenleg hány írható/olvasható DRO-t használtok,és hány csak olvashatót?
Pusztán azért érdekel,hogy ne legyen összeütközés az új képernyőmön felhasznált DRO-kkal.

Sziasztok,

Akkor ahogy ígértem: UCCNC 1.0041

A szoftverbe visszakerült az egyel előző verziójú API,
így az MPG funkciók ismét nem működnek jól,
viszont a többi funkció igen.

A tesztelést ahogy írtam, most egy időre felfüggesztjük,
amint lesz új kiadás a módosításokkal, amiket leírtam, akkor fogok ismét jelentkezni.

Ki mit szokott meg elsőre az az etalon, még ha az a rosszabb is.
Az viszont igaz, hogy a jót meg általában könnyebb megszokni.

A környezetemben sajnos egy Heidenhain vezérlő sincs csak Fanuc, Mitsubishi és egyéb "japános hülyeség", így még ha akarnék sem tudnék átszokni.

Persze ezen a japánosokat sem kezelem, csak messziről nézem...

Előzmény: Béni, 2014-11-05 11:58:00 [1538]