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]

"(Béninek ezúton is üzenem, hogy inkább nem köszörülném le a nagy nehezem megszerzett MPG-mről a rovátkákat és számokat)"

De jó memóriád van.
(Vagy nekem rossz ...)
Sajnos, továbbra sem tudok semmi észérvet felhozni a racsnis kézikerekek mellett.
Aki a gyakorlatban naponta használja az eszközt, azt a víz kiveri az ilyen "japános" hülyeségtől, ha már volt a kezében olyan, ami normális. (Heidenhain pl.)
(A JOG mód az meg egyenesen hajmeresztő ...)

Előzmény: svejk, 2014-11-05 11:23:00 [1529]

OK, megfogom nézni ezt is.

Előzmény: svejk, 2014-11-05 11:40:00 [1532]

Az output trigger ablakon valóban csak az első 3 LED kód SET gombja működik, ez a programban egy hiba, illetve kimaradt a kód a többi gomb mögül, most megnéztem, ezt javítom, mert ez a hiba nem az API-van van, hanem a progiban.

Előzmény: lari, 2014-11-05 11:46:00 [1534]

Lezárni nem kell szerintem a topikot, mert akkor nem tudjuk jelezni ha elkészül az átírás. De a hibajelentéseket addig szüneteltessük, mert arra jutottunk, hogy nincsen értelme foltozgatni a kódokat ami amúgy is teljesen át lesz most írva.

Előzmény: svejk, 2014-11-05 11:41:00 [1533]

Az általad lentebb leírt hibákat én is tapasztaltam több alkalommal is.


"- Az Input triggerek beállításai közben kétszer is eljátszotta, hogy a lista felugrott, de nem volt látható, a tálcáról kellett bezárni. (mondjuk ez talán lehet videókártya hiba is) "

Előzmény: svejk, 2014-11-05 11:23:00 [1529]

Ha gondoljátok akár le is zárattatjuk addig a topicot.

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

Igenis, értettem, Svejk a derék katona kér engedélyt meghunyászkodni!

De azért egy OffLine üzzemmód LED-kóddal dobj meg légyszi!

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

A SingleLine hibához még annyit, hogy ellenőriztem a diagnosztika ablakban, csak a PWM-et veszi el.

Előzmény: svejk, 2014-11-05 11:23:00 [1529]

Sziasztok,

Egyeztettem Balázzsal és arra a megállapításra jutottunk, hogy elég sok hibát jeleztetek az 1.0040-es szoftver verzióban, ezért visszatérünk az 1.0039-es API-ra.
Az 1.0040 API-ban az 1.0039-eshez képest csak az MPG módosításai történtek, de úgy látszik ez sok más dolgot elrontott.
Szóval még ma fogok készíteni egy 1.0041-es verziót az 1.0039-es API-jával összecsomagolva az új programkódot.
Így az új szoftver funkciók, mint például a shift + alt + ctrl billentyű trigger kombinációk, az output triggernél a tab oldalak LED kódjai stb.,
ezek az új funkciók mind megmaradnak, továbbra is működni fognak.
Viszont az API az egyel régebbi lesz, így az MPG funkciói ismét rosszak lesznek éppen úgy, ahogy előtte jeleztétek és amiket hibákat az MPG-ben megpróbáltunk egyelőre sikertelenül javítani.

Ezután a kiadás után most pár hétig nem fogunk új kiadást csinálni, illetve nem is kérünk több hibajelentést,
mert Balázs nekiállt átírni az API-ban a kottyanáskompenzációt, amit már említettem, hogy előkészít a menetvágásra/fúrásra is.
Emiatt az MPG, a jog és sok egyéb funkciót alapjaiban kell átírni, így nem is látjuk értelmét a mostani API javításának,
hiszen úgy is hamarosan ezek teljesen át lesznek írva és majd ezután fogunk kérni tőletek újra tesztelést.

Szóval, összefoglalva: Valamikor ma kifogunk adni egy 1.0041-es verziót a régi API-val, de az új szoftver funkciókkal és most néhány hétig,
a következő kiadásig nem kérünk hibajalenetést az API átírása miatt.