Azt nem mondanám, hogy nem a topikba vágóak a hozzászólások, de gondolom Balázsék tudják kezelni a felmerülő problémákat, hiszen Ők készítették.
Ellenben ha engem valaki megkérne, hogy ne szóljak többet hozzá egy adott témához, eszembe nem jutna "csakazértis" szúrkálódni.

Előzmény: designr, 2019-05-28 15:50:21 [6823]

Hátha van 10 jóérzésű (vagy 12 dühös..) ember aki rányom a törlés gombra ha nem idevaló írást lát..

Ismét köszönjük az észrevételed, de ahogy már írtam nem állok le veled vitatkozni. Ha gondolod rondíts bele a topikunkba ahogyan máshova is bele szoktál, a te dolgod, én nem foglalkozom többet veled...

Előzmény: Törölt felhasználó, 2019-05-28 14:34:24 [6821]

Bocs, de a hibás program működésre miért ne reagálhatnék?
Azért vagyunk egy műszaki Fórumon, hogy a jogos műszaki észrevételeket az UCCNC-vel kapcsolatban megbeszéljük, és kijavítsátok. Így inkább érdemben válaszoljál, és ne próbálj engem utasítgatni csak azért, mert hibás a programotok, és meglátva a Robsy nevet csak ennyi telik tőled.

Előzmény: CNCdrive, 2019-05-28 11:04:54 [6817]

Én eleve nem értettem a z tengely túl magas beállítása után, hogy miért kell rohanni a stop gombhoz, ha már a z tiltotta a dolgot. Nekem használva vannak a enable pin-ek a drive-okon. Mind egy pint használ. Akár szoftveres, akár hardweres stop érkezik leáll minden. Persze a program se megy tovább.

Előzmény: CNCdrive, 2019-05-28 12:07:23 [6819]

A vészstop gombot a mozgásvezérlő "hardveresen kezeli", vagyis maga a mikrovezérlő mindent megállít, ha a vészstop bemenet aktív és miután ez megtörtént szól a PC oldali szoftvernek, hogy vészstop van. De még ha a PC nem is kapná meg ezt az üzenetet (ami amúgy szintén nem lehetséges, de ebbe nem megyek most bele), a mozgásvezérlő akkor sem generál több mozgást és a koordináta kijelzéshez a koordinátákat is a mozgásvezérlő küldi. Szóval lehetetlen, hogy benyomott vészstop gombbal pörögnek a pozíció DRO-k.

De egyébként a vezérlődobozt is úgy célszerű (kell) kialakítani, hogy a motorok ne legyenek képesek mozdulni, ha vészstop állapot van. Ezt célszerűen egy relével szokták megoldani, ami vészstop esetén "kiesik" és elveszi a motorvezérlőktől a tápellátást. Egyébként előírás (viszonylag új, pár éves) az is hogy 2 db alaphelyzetben zárt kontaktusán kell sorosan átvezetni a vészstop kört.
Na de kicsit elkanyarodtam...csak érdekességképpen írtam le, hátha valakit érdekel.

A lényeg, hogy nem tűnik hihetőnek a dolog az alapján ahogyan működik a rendszer, valószínűleg hibás volt részedről a történések megfigyelése, de ha megmutatod videón, akkor persze elhiszem.

Előzmény: dtb, 2019-05-28 11:53:47 [6818]

Biztos csak egy rossz álom volt.
Majd megpróbálom reprodukálni, de tegnap (bár eszembe volt, hogy előkapom a telefont és videózok,) a 6os vaciúj kétélű marómat jobban féltettem, mint, hogy a videózással foglalkozzak.
Azt már korábban is észrevettem, hogy a VészStop gomb állapota nem mindig mérvadó, vagyis korábban is előfordult már, hogy a szoftveres és hardveres vészstop eltérő állapotban volt, de ezek szerint valami más bibi is van.

Előzmény: CNCdrive, 2019-05-28 11:00:25 [6816]

Kedves Robsy, ahogy már többször megkértelek legyél kedves más topikokban "okosítani" és hagyd meg nekünk a saját topikunkat. A saját topikodat annakidején már tönkretetted ezzel, nem kérjük, hogy a miénkkel is ezt csináld. Köszönjük.

Előzmény: Törölt felhasználó, 2019-05-28 07:31:24 [6814]

Mindkét dolog elképzelhetetlennek tűnik számomra. Ezeket videó nélkül nehezen hiszem el.

Előzmény: dtb, 2019-05-28 07:31:37 [6815]

"A szoftver mégis honnan tudná, hogy a léptető motorod megtorpant?" Mondjuk onnan, hogy azonnal megállítottam a vészstoppal? Írtam! A motorok azonnal megálltak, de a maróprogram futott tovább, mintha mi sem történt volna. A koordináta rendszert ez állította el. A motorok állnak, a milliméterek meg pörögnek az UCCNC ablakában.
2. Ezt is félre érted, az UCCNC saját belső editorát használtam, hogy kijavítsam a hibát. Ott nyomtam save and exit-et. Tehát miután kijavítottam a rossz Z értéket, (save and exit) rájöttem, hogy nem jó a koordináta sem, és emiatt visszatöltöttem a korábbi munkát, a körvonalast, hogy annak a Gkód értékei alapján a kontúrokon visszaállítsam a helyes DRO értékeket. Mikor újra visszatértem a javított nagyoló programkódhoz, ugyanúgy benne volt a hibás érték, vagyis fizikailag nem mentette el a program.

Előzmény: CNCdrive, 2019-05-28 02:19:17 [6812]

A felhasználót megkötő javaslataidhoz képest az igazi megoldás inkább az lenne, hogy helyes interpolátor és step/dir generáló algoritmusra épüljön a vezérlő program, aminek a valós koordináta és a gép felbontásából adódó hibakezelése is korrekt minden esetben.

Előzmény: CNCdrive, 2019-05-28 02:32:42 [6813]

A saját fórumunkon már volt erről szó, de talán már ezen a fórumon is és elég bonyolult dolog ennek az okát elmagyaráznom, amit írsz.
Szóval, hogy mi okozza ezt a problémát az ismert. Attól van ahogyan a teljes kör (G2/G3) definiálva van a g-kódban.
A kezdő koordináta ilyenkor ugyanaz mint a vég koordináta és a G2/G3 g-kód sor csak a végpont koordinátát tartalmazza. A kör kezdőpontja pedig a gép aktuális pozíciója.
A probléma abból adódik, hogy a steps/érték meghatározza a gép felbontását, vagyis ha mondjuk a steps per hossz egység 100, akkor 0.01 hossz egységet fog egy léptető motor lépés okozni. Vagyis, ha a kezdőpont mondjuk 0 és 0.012-re mondja a program, hogy menjen a gép, akkor értelemszerűen oda nem tud menni, hiszen 0.012-t nem adja ki a az 1/steps egész számú többszöröseként, szóval csak 0.01-re tud lépni.
Itt lesz akkor egy 0.002 hosszúságú hiba ahhoz képest, hogy hol áll a gép és hogy hova irányította a g-kód program.
És ebből adódik a probléma, ugyanis a teljes kör (360 fok) könnyen átmehet közel nulla (0 fok) körbe, ha a kezdő és a végpont egymáshoz képest egy picikét is el van tolva a rossz irányba.
A gond pedig akkor adódik, ha a kezdő koordináta és a vég koordináta programozása között van valami, például egy makró hívás, ami miatt a vezérlőnek le kell frissítenie a koordinátákat a valós értékekre és akkor keletkezhet az említett hiba, ami miatt a programozott kör már nem az a kör aminek eredetileg gondolták amikor le lett programozva.

A megoldások, hogy a kör kezdőpont mozgási kód sora és a kör program sora közvetlenül egymás után következzen, ne legyen köztük macro stb. hívás.
A másik megoldás, hogy ne programozzunk teljes köröket, hanem helyette fél, vagy negyed köröket.
Minden valamire való CAM programban van ilyen opció, éppen emiatt a probléma miatt amit leírtam, hiszen ez a probléma nem csak az UCCNC szoftvert érinti, ez egy általános gond...

Előzmény: muller93, 2019-05-27 21:08:42 [6810]

1.) A szoftver mégis honnan tudná, hogy a léptető motorod megtorpant? Természetesen nem tudja (hacsak te valahogy meg nem mondod neki.), hiszen ez egy nyílt hurkú szabályzó rendszer, ahol a léptetőmotor vezérlők semmilyen információt nem adnak arról, hogy forog-e a motor vagy sem. Sőt már maga a léptetőmotor vezérlő sem tudja, hogy forog-e a motor.
Persze vannak olyan motorvezérlők, amik tudják, hogy forog-e a motor, sőt, azt is tudják, hogy mekkora a pozíció eltérés a kívánt és a valós pozíció között, ezeket szervonak hívják.

2.) Koordináta DRO-k elmentéshez nem kell Save and exit, azokat automatikusan menti a szoftver a bezárásakor.
Egyik kérdés, hogy biztosan beírtad-e a koordinátát, mármint, hogy a folyamat végén kiléptél-e a DRO-ból a kurzorral.
Másik kérdés, hogy hol írtad át (toltad el) a koordinátát?
Ha a G92 temporary offset-ben, akkor az nem mentődik el, hiszen ideiglenes offsetről van szó, ami egy UCCNC futásra érvényes csak és így érthető, hogy visszaállt a következő futtatáskor a rossz koordináta.
Egyébként ezekhez a dolgokhoz, koordináta mentés stb. már nagyjából évek óta nem nyúltunk és nem volt eddig gond vele.

Előzmény: dtb, 2019-05-27 22:22:51 [6811]

Megint beleszaladtam valami hibába, megpróbálom minél részletesebben leírni. Win7, eth400+ legutolsó UCCNC.
Kezdjük azzal, hogy én mindig a kontur körbevágásával kezdem. Ez hiba nélkül megvolt, utána jött a felületi nagyolás. Mivel a marásban volt két sziget, (ahol a rögzítőcsavarok voltak) először kipróbáltam magasabb Z beállításokkal. Kiderült, hogy mikor a sziget kihagyott részére(előbb megcsinálta a jobb oldalt, majd vissza balra) visszatér a maró, túl alacsony a Z magassága, bele fog szaladni a csavarba. Nosza, szerkesztés, Z érték megfelelő helyen módosítás, save and exit, majd újra próba. Viszont a Z értékét elqúrtam, 35mm helyett 3500mm lett (ez egyértelműen az én elírásom) a teszt alatt a Z túlfutott, és letiltott a driver. Mint a félőrült csaptam a vészgombra.
Hiba 1: A léptetők megálltak, de legnagyobb meglepetésemre a marási program vígan ment tovább, pörögtek a DRO-ban a számok, amíg a szoftveres STOP gombbal le nem állítottam.
Megkerestem a kódban a hibás Z értéket, kijavítottam, majd megint save and exit. Megint tesztelni akartam, de ugye a koordináta elmászott rendesen, sebaj, visszatöltöm a kontur vágás kódját, precízen visszaállok a jó koordináta értékekre, nagyoló program újra betölt, indítanám megint a tesztet, a Z-ben megint ott a 3500mm.
Hiba 2: Nem tudom miért, de előző alkalommal nem mentődött a módosítás, holott 100%, hogy save and exit-tel léptem ki belőle. Érdekes módon, mikor teljesen kiléptem a programból, megnéztem a kódot szövegszerkesztővel, kilépéskor mentődött a módosítás.
Csak ne azt írjátok, hogy megint összeszedett valami zavaró jelet a frekiváltótól...

Sziasztok,

van egy problémám az UCCNC-vel, már nem először fordult elő. Ha van egy kiosztásom, több 10 egyforma alakzat, akkor abban a G03 kör interpolációs alakzatokat (de csak a teljes köröket!!! ívet nem) "véletlenszerűen" kihagyja, de csak azokat és nem mindegyiket. Az UCCNC kirajzolja, a G kód ott van, látszólag le is futtatja, de csak az előtte levő M3-at és az utána levő M5-öt hajtja végre és megy a következőhöz. Van, hogy 5-10 alakzatot kihagy, utána pedig ugyanazt az alakzatot máshol kivágja. Nem látok benne összefüggést.

Ha valaki tud rá megoldást kérem segítsen.

Előre is köszönöm.
Balázs

Nézegetem ezt a kontúrkövetést, de bizony csak nem értem én ebben a logikákat.

Itt van ez az alábbi 60x60 -as négyszög, ezt szeretném egy 6 mm -átmérőjű maróval a külső kontúron lekövetni.

- kiválasztom a General settings-ben hogy kerekítve kerülje a sarkokat
- Az 1-es szerszámhelyre beírom, hogy 6 mm-es és
ugye G42 D1-et használok, mivel jobbról kerülöm és az 1-es szerszámmal.

De a kezdő és végpontok megadásával nem igazán vergődök zöld ágra.
Jellemzően kapom a 2-es figyelmeztetést.

Persze tudok olyan kezdő és végpontokat beállítani hogy minden jó legyen, de annyi erővel már majdnem a korrekciós pályát is kiszámolhatom.

Valaki gyakorlott szaki esetleg kiegészítené azzal a pár koordinátával a kódomat és beszúrná a megfelelő helyére a G42 D2-et és a G40-et hogy minden klappoljon?

G17 G40 G49 G50 G69 G80 G90 G98 G99
G0 Z2
M3 S3000
G1 X0 Y0
G1 Z-1 F300 
X60 F1000
Y60
X0 
Y0 
G0 Z2
M5
M30

A license akkor úgy illegálisan másolható/terjeszthető lenne, ha nem kellene hozzá az elektronika.
Például Mach3-al ezt nap mint nap látjuk sajnos...

Előzmény: nyarfa, 2019-05-21 20:31:03 [6807]

Ez kicsit bosszantó így, mert kísérleti időszakban nem nagyon akartam még az elektronikát is rá biggyeszteni a gépre. Reméltem, hogy ha van licenszem akkor az megvéd

Előzmény: CNCdrive, 2019-05-20 16:01:39 [6806]

Igen, mozgásvezérlő nélkül csak limitált g-kód sort generál le a program, a többit levágja.
Ahhoz, hogy a teljes kódot legenerálja csatlakoztatni kell a mozgásvezérlőt és license-elt módban futtatni.

Előzmény: nyarfa, 2019-05-19 22:04:47 [6804]

Szia!

Próbáld meg úgy, hogy csatlakozik a vezérlőhöz. Ha jól emlékszem (ez persze korántsem biztos), akkor demó módban csak 50 sort generál.

Előzmény: nyarfa, 2019-05-19 22:04:47 [6804]

Sziasztok,


A CAM rész működik rendesen, vagy csak nálam nem hajlandó? Miután betöltöttem egy végtelen egyszerű DXF-et és legeneráltam a G-kódot kicsit érdekes alak jött ki belőle. Nem egyszer próbáltam meg, és az eredemény minden esetben eltérő az eredeti rajztól.

  

Ha az X DRO nem mutat mozgást és mégis van mozgás az X tengelyen, akkor zajt szed fel az X tengely step vezetéke vagy maga a léptető vezérlő. Nem a szoftver/mozgásvezérlő hajtja végre a mozgást, hanem a léptetőmotor vezérlő önállósítja magát.

Előzmény: dtb, 2019-05-18 09:11:28 [6802]

Egy viszonylag nagy méretű, (kb. 35MB) g-kód betöltése közben apró lépésekkel ugyan, de elindult az X tengelyem plussz irányba. Active low. Legutolsó (ezek szerint béta) verzió.

Már foglalkozunk a kérdéssel, mert valóban problémás.

Előzmény: dtb, 2019-05-04 13:48:45 [6800]

A legutolsó verzióban az "A" axis beállításainál a softlimit értékének televágtam sok 9-cel, (amíg fért, hogy nagy legyen az érték) erre unhandled error-t adott, és elment boldog vadászmezőkre.
Egyébként, ha be van jelölve, hogy az axis rotary, akkor nem lehetne egy checkbox-al függetleníteni a soft limit beállításaitól?

Nem válasz, csak az UCCNC-hez kapcsolódó link.
Screenset, Notepad style for uccnc macro, VFD plugin, Aspire postprocess for UCCNC.

Előzmény: dezsoe, 2019-05-04 12:29:50 [6798]

Ez kinek válasz és mire?

Előzmény: dtb, 2019-05-04 12:16:58 [6797]

Találtam, közzéteszem: Itt találod!

Jé tényleg, valami rémlett is. Köszi!

Előzmény: dezsoe, 2019-05-03 19:57:15 [6795]

Visszaáll egy biztonságos értékre. Nem te vagy az első, aki kérdezi, itt egy megoldás: 'UCCNC vezérlő program' téma, 4472. hozzászólás. (Illetve, mégis te vagy, mert 2017-ben is te kérdezted.)

Előzmény: izbeki, 2019-05-03 19:35:00 [6794]

A Jog Feed-et miért felejti el az UCCNC kikapcsoláskor?

Az Autoleveler-es kérdést passzolom, de a 2.0049 verzióban lehet menteni és betölteni a mérési adatokat. (Ez van nálam, ezt láttam a képernyőn.)

Szerszámmérés attól függ, hogy melyik verziót használod. Ha 1.2108 vagy újabb, akkor ott a probe képernyő, azon belül is a mobile probe üzemmód. Ha nem, akkor megméred a munkadarab nullpontját, nullázol, elviszed valahova a bemérőt (ott rögzíted), majd ott is mérsz egyet. A kapott különbséget felírod. Szerszámcserénél az új szerszámot beméred a rögzített bemérőn, majd a kapott eredményt módosítod a felírttal. (Ugyanezt csinálja a mobile probe üzemmódban a probe képernyő is.)

Előzmény: Zsoltyfm, 2019-04-29 21:25:34 [6792]

Sziasztok!
Olyan kérdésem lenne, hogy miként lehet azt megoldani, ha már egyszer az autoleveler plugin segítségével feltérképeztem a munkadarabom felületi görbületét, akkor azt ne csak arra az aktuálisan betöltött G-kódra tudjam alkalmazni, hanem ha mondjuk más művelet is el kell végezni egy másik szerszámmal ugyanazon a munkadarabon egy másik G-kóddal, akkor ne keljen újra a felületet letapogatni, hanem alkalmazni tudjam a legutóbbit?
Tehát szeretnék szerszámot is cserélni, és szeretném ha módosulna a szerszámhossznak megfelelően a Z-tengely magasságértéke is, de ha már a munkadarabom magasságából lemunkáltam, akkor a munkadarab érintésével nem tudom ismét felvenni a szerszám munkadarabhoz viszonyított nullpontját. Ezekre gondolom van megoldás, csak én nem ismerem.

Előzmény: svejk, 2019-04-28 20:35:53 [6790]

Ja tényleg!
Pedig csináltam már ilyet...
Köszi!

Előzmény: dezsoe, 2019-04-28 20:05:30 [6789]

Simán exec.GetLED()-del. A LED-es doksiban megtalálod a bemenetekhez tartozó LED-eket.

Előzmény: svejk, 2019-04-28 18:49:02 [6787]

A bementre állított input trigger és simán a makro meghívása nem jó, mert ez a G-kód futása alatt nem működik.

Előzmény: svejk, 2019-04-28 18:49:02 [6787]

Hogy is kell makroban közvetlen kiolvasni egy adott bemenő port/pin értékét?

Csak egy szöveget akarok kiíratni a Message box-ba ha az adott bemenet aktívvá válik.

Előzmény: svejk, 2019-04-27 21:18:42 [6786]

Igen, valahogy úgy...

Még pontosan nem gondoltam át talán a saját Reset gombja is törölhetné ha már Reset a neve.

Most ugye nincs semmilyen külső lehetőség, funkciókód a leokézáshoz?

Előzmény: CNCdrive, 2019-04-27 21:08:37 [6785]

Ezt pontosan hogy érted? Hogy a külső reset gomb megnyomásakor le OK-zódna a modális ablak ha éppen van ilyen felugorva? Vagyis mintha megnyomtad volna a képernyőn az OK gombot?

Előzmény: svejk, 2019-04-27 14:08:42 [6784]

Szerintem praktikus lenn ha pl. a reset gomb kezelése egyben le is okézná ezeket az ablakokat.

Előzmény: svejk, 2019-04-27 13:45:44 [6782]

Nohát!
"- Új: Cycle check home opció, amivel tiltható a ciklus start, ha nem volt referencia felvétel
- Új: Reset deref. homes opció, amivel a referencia felvétel érvényteleníthető reset hatására"


Végre nem kell ilyen makrókat irkálnom...

Lett végül megoldás ezeknek a felugró win-es ablakok eltüntetésére?
Mármint az Enter, egér/touch-on kívül valami külső triggerrel.

Előzmény: Thowra, 2019-02-05 12:22:11 [6445]

Köszi!

Előzmény: dezsoe, 2019-04-22 19:48:32 [6780]

Segítség a frissítéshez: 'UCCNC vezérlő program' téma, 3928. hozzászólás.

Előzmény: gbalazs, 2019-04-22 19:34:40 [6779]

Köszi!

Előzmény: CNCdrive, 2019-04-22 19:33:15 [6778]

Igen, volt ilyen hiba/probléma. Valamikor meg lett oldva, hogy pontosan melyik verzióban arra most nem emlékszem, de a fórumunkon vissza lehet nézni a kiadások logjából.

Teljesen mindegy, hogy hogyan csinálod. Az M30 alap beépített funkció, vagyis program vége visszatekerés.
Ezután hajtódik végre az M30 macro text fájl. Alapból ez a fájl üres, vagyis semmit sem csinál. Ha nálad lett bele írva valami kód, akkor értelemszerűen azt be kell másolnod ha azt szeretnéd, hogy az új verzió végrehajtsa azt.

Előzmény: gbalazs, 2019-04-22 19:14:59 [6777]

Sziasztok! Egy régebbi UCCNC-t használok, és van egy olyan bajom, hogy az M30 után a szervós step/dires főorsót olyan hirtelen állítja le, ami feleslegesen odaver a hajtásnak. Ha jól láttam az újabb verziókban már meg van oldva ez a probléma. Szóval lecserélném a cuccot.

Logikusan az merült fel bennem, hogy a profil fájlomat nyilván kimenetem és használom az újnál. Na de a makró fájlomat is felülírjam a régivel? Abban van az M30 is nem? És akkor ugyanott vagyok. Vagy a profil írjam felül, a macró meg maradjon az új?

Viszonylag új termék és sajnos még nem érkeztünk lefordítani az adatlapot.

Előzmény: ANTAL GÁBOR, 2019-04-18 16:38:32 [6774]

Lemaradt a lényeg : UCR201 távirányító

Előzmény: ANTAL GÁBOR, 2019-04-18 16:38:32 [6774]