Sziasztok! Mennyire szentségtörés mach3 pluginnel használni az uc400-zat? Belőttem, jön megy, de ahogy rádugom a frekiváltót és elindul a program, pár sor után megáll midnen, a sorokat veszi, de a dro is úgy néz ki, mintha állna és a plugin ablakban sem látszik, hogy kapna jelet.ezen kívül a bemenetek sem látszanak. Egy probe van szerszámhoz és végálláskapcsolók... Szimpi az UCCNC, 100 hogy váltani fogok, csak most dugtam össze a gépet és vágnék keveset....
svejk | 33151
2019-05-28 20:40:58
[6841]
Aha! Köszönöm, hogy foglalkoztál vele.
Először gyanakodtam én is a G42 különálló mivoltára, de mivel nem láttam változást egybe írva sem, így a G40 ig el sem jutottam.
Jól tudom, Te a Heidenhain vezérlőket preferálod, de szerintem neked nem gond egy Fanuc kompatibilis kódot sem megírni. Ha van kedved, energiád írd le légyszi ott hogy nézne ki a programocska.
Én sokszor az NCT90-es vezérlő leírásából puskázok, de szégyen- nem szégyen abban sem igazán értettem meg a kontúrkövetést.
Mentségemre legyen, hogy most nincs semmilyen gépem itthon, tehát csak a DRO-kra és a Toolpath képernyőre tudok hagyatkozni, bár még ott is látok furcsaságokat.
Nem írtam privátban, de egy órát elszórakoztam vele.
Ahogy láttam, csak tesz verziókban van, tehát még nincs működőképesnek elfogadva a G41/G42. - a figyelmeztetés, amit említesz, olyankor is megjelenik, amikor a ráállás helyesen van megoldva. A program futtathatóságát viszont nem befolyásolja. - ha a program végén a G40 után, vagy annak mondatában nincs XY pozicionálás, a kontúrkövetés nem lesz helyesen kikapcsolva. Emiatt a következő futtatás pozicionálása először nem programozott XY koordinátákra megy. (Az sem segít, ha a program elején G40 van. Hasonló hibával találkoztam egy Fanuc 18i-nél.)
A legtöbb vezérlőnél az M30 gyakorlatilag minden beragadt funkciót, transzformációt alaphelyzetbe állít. (Paraméterezhető kivételekkel.) Eszerint az UCCNC esetében nem így van.
Ok igazad van ( tippem is volt rá ,hogy lesz negatív reagálás a részedről ) De egy (nano) malomban a rotortárcsa ami a beszereléstől számítva 1 percen belül elkezd kopni az (őrlőgolyó jótékony hatása miatt ) számomra indifferens . Mindent olyan pontossággal igyekszem elkészíteni ami illeszkedik a felhasználáshoz . Nem hinném hogy a felhasználóim bevetnének egy Mitutoyo mérőgépet
Esetemben egy szempont van : korrektül illeszkedjen a tengelyen .. No azt ha kell korrekciózom...
Aki egy ilyen mérőgéppel rendelkezik, vagy csak akár egy mérés sorozatot ki tud fizetni szerintem már minimum egy országos céggel fogja legyártatni a munkadarabot , szerintem elképzelhetetlen hogy egy ilyen géppel találkozzon egy kisiparilag készített munkadarab .
"Nem küldik vissza a partnereim a termékeket mert képtelenség kimérni a hibát."
Csak óvatosan, én ilyet azért nem írnék, hogy mi a képtelenség. Ugyanis ha véletelnül egy ilyen Mitutoyo mérőgéppel nézik majd meg a munkadarabodat, akkor szembe találkozol majd a valóságos 4 tizedesjegynyi munkadarab méretekkel a CNC vezérlőd kijelzőjén szaladgáló virtuálisokkal szemben.
Kell a probléma felvetés , kell a kritika mert ez ösztönzi Balázsékat a finomításra ( persze ha kritika jelez és nem "döfköd" akkor az hasznos mert inspirál ) Én várok , várok és drukkolok ... Ha kört akarok marózni akkor acad , artcam és igaz törtvonallal de megy .Ha kopik a maróm és nem azt kapom amit szeretnék akkor kompenzáció ( igaz időt-rabló ) De az eredmény korrekt ... Nem küldik vissza a partnereim a termékeket mert képtelenség kimérni a hibát. Drukkolok hogy egyszer áttérhessek az UCCNC szisztémájára ( megítélésem szerint igen közel vagyunk.... )
Soronként futtatom, de pl. a fentinél miért megy a maró a 3. sor után az X-8 Y-3 koordinátán amikor csak a következő, 4. sorban kapcsolom be a korrekciót?
Az is egy stílus, hogy még vitázni se állsz le velem, én erre azért nem lennék büszke a helyedben.
Persze nekem így is jó, a sok "lojális" fórumos haver UCCNC felhasználó is biztos imádja és elfogadja zokszó nélkül a "csodás" magyarázatodat, hogy "ne programozzunk teljes köröket, hanem helyette fél, vagy negyed köröket."
Hajrá emberek, legfeljebb pár kör megmunkálás kimarad, hiába van ott a G kódban, nem érdekes az nektek, a "főnök" megmondta, ne is programozzatok ilyeneket. A fő hogy közben mindenek feletti élmény biztosít nektek a virtuális képernyő szépsége. A valóság, meg a tények ne zavarjon benneteket, ezek századrangú kérdések egyeseknél.
További szép napot kívánok mindenkinek, téma lezárva részemről.
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.
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..
CNCdrive | 449
2019-05-28 15:39:11
[6822]
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...
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.
É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.
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.
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.
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.
"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.
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.
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...
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.
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...
muller93 | 48
2019-05-27 21:08:42
[6810]
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
svejk | 33151
2019-05-27 20:44:21
[6809]
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?
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
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.
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.
CNCdrive | 449
2019-05-19 04:44:06
[6803]
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.
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ó.
dezsoe | 2934
2019-05-04 19:48:10
[6801]
Már foglalkozunk a kérdéssel, mert valóban problémás.
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?
dtb | 1921
2019-05-04 13:00:39
[6799]
Nem válasz, csak az UCCNC-hez kapcsolódó link. Screenset, Notepad style for uccnc macro, VFD plugin, Aspire postprocess for UCCNC.
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.)
2019-05-29 14:38:24
Belőttem, jön megy, de ahogy rádugom a frekiváltót és elindul a program, pár sor után megáll midnen, a sorokat veszi, de a dro is úgy néz ki, mintha állna és a plugin ablakban sem látszik, hogy kapna jelet.ezen kívül a bemenetek sem látszanak. Egy probe van szerszámhoz és végálláskapcsolók...
