A mostani beállításokkal éppen 8kHz. Így jön ki 2mm-es orsót direktbe hajtva 8 mikrolépéssel a 600 mm/perc. Lehetne a duplája is, csak elfeleztem az üzembiztonság kedvért, azok a 3Nm-es motorok, hát nem nevezném túlzásnak őket. Nagyobb, 12 Nm-es motorokban gondolkodva 20 kHz-en jönne össze az 1500 mm/perc. A teszt meg 40 fölé saccolja egy picivel. Furdal is a kíváncsiság, de majd egyszer.. Volt olyan mikrolépés próbálgatás, ahol 24 kHz volt, akkor is működött. Egy hagyományos csúszóvezetékes mechanikánál szerintem nem az LPT órajele lesz a limit.
Én pont ilyen "beszámolókra" voltam kíváncsi, átnéztem Tibor eszterga programjának leírását a honlapján, az sem lehet rossz, de milyen jó lenne ha arról is írna olyan akinek személyes tapasztalatai vannak a használatáról.
KoLa | 7585
2019-04-24 22:22:34
[43842]
Hát! a Gildemeister CT40 az már egy másik dimenzió, és itt már látszik, hogy a Linuxcnc megállja a helyét ipari környezetben is, nincs sok összehasonlítási alapom, de az eredeti vezérlőt lepipálja az biztos, mivel már be van gyakorolva részemről a használata így teljesen kézreáll a használata. Persze itt már külhonból kaptam segítséget, Halász Attila Szabadkáról, mindent megoldott, a Linuxcnc axis felületére kértem a beállításokat. Ezzel mindíg baj volt itt a fórumon, senki nem nagyon értett hozzá pl: kellett volna az esztergára, fordulatonkénti előtolás kiírása, vagy az aktuális kerületi sebesség kiírása. No ezeket megkaptam alapban a Linuxcnc-re, mi kell még? Mostmár boldogulok, állandóan rendelkezésre állnak az adatok, total kontrol van, persze, van beépítve két mesa kártya és egy plc. Számomra újdonság volt hogy, a szervómotorok enkóderei a tápot a szünetmentes tápegységről kapják, így nincs lépésvesztés addig amíg a táp bírja az áramszünetet! A telómról megpróbálok ide képet küldeni a vezérlőről, talán sikerül...
Teljesen egyetértek azzal amit írsz! Már vagy 8éve használom a Linuxcnc-t LPT portról 12Nm-es léptető motorokkal, esztergagépen. A Stepkonf-al kezdtem,( figyelni kell a mértékegységekre! ) azóta már okosodtam annyit hogy szerkeszgetem a configot. Ez a régi, lusta cnc esztergám, egy EU175-ből épült annó!és tök jó! A gyosjárata 1560mm/perc, menetvágáshoz 1000mm/perc sebességig használom, ez azt jelenti hogy a menetemelkedés szorozva a főorsó fordulatszámmal, ne legyen több 1000-nél. A g95 itt tényleg fordulatonkénti előtolást jelent, ha nem forog nem megy, csak kicsit tér el a g33-tól, talán!?, nem kell neki index jel. Az at speed menti a melléváltást, vagy az elfelejtett váltást, a hal file-ban lehet állítani a tolarenciát. Nálam pl. amikor kúpesztergálásnál a kés visszajön 200-as átmérőn és az x tengely beugrik'60-as átmérőre, akkor a szintén lassú föorsóm nem tud időben felpörögni a megadott g96-ra, az at speed ilyenkor jótékonyan vár, a megfelelő fordulatszámra és csak azután indítja el az esztergálást. Előtte a Mach3 ilyenkor morzsolta az anyagot erősen... Szóval én csak támogatni tudom a Linuxcnc beállítását egy hobbicnc esztergagépre, mert alapfokú tudással is jó eredményt lehet elérni.
Csak a képernyő szettben van bekorlátozva max. 9999-re az érték. Menj be képernyő szerkesztő módba (General settings fül/Edit screen gomb) és válaszd ki az encoder felbontás mezőt és írt át a max. értéket nagyobbra. Majd mentsd el a képernyő szerkesztővel. Ezután tudod nagyobbra is állítani az értéket a mezőben.
négy karakternyit lehet beállítani. Ezért ennyi. Az én választásom hogy jelenleg így maradt, mert nem akarok egyméteres menetet vágni vele. Ha pedig majd lesz időm leosztom a meghajtóban aztán szép kerek szám lesz ami belefér
Az enkóder 2500-as a PPR-hez pedig 9999 van beírva. Ebben biztos lehetsz. Nem volt időm szórakozni a szervo meghajtóval mert mihamarabb dolgoznia kellett a gépnek, így mértem, és írtam. De majd megnézem hogy fel van-e valahol szoroz6va benne ha készen van az adag.
Már az első mondatodban van egy kis "füllentés", mert egy 2500-as encodernek nem lehet 9999-es ppr-je. Legfeljebb egy szép ablakba be lehet írni, aminek közben nincs köze a valósághoz.
Nálam az UC 2500-as enkóderrel szalad az az 9999-re van állítva a PPR. Az Index jelet ez sem látja a diagnosztikában rendesen, de a lényeg, hogy amikor kell megtalálja, és kezeli. 600db-nál tartok most az egyik szériában. Ez az első amit UC-vel csinálok. Menetfúró ciklussal és metszővel. Egyszer sem tévedett. Eszembe nem jutna hogy mással próbálkozzak, és nagyon nem bántam meg hogy ezt választottam. Ami nincs benne, azt megvárom. Vagy legfeljebb tüntetünk majd a G96-ért
Törölt felhasználó
2019-04-24 12:38:15
[43829]
Örvendetes, és követendő hozzáállás, hogy a neked fontos fő műszaki, CNC technikai szempontokat is mérlegelve választottál vezérlőt előny/hátrány alapon. Használd egészséggel, megelégedéssel.
Hogy tulajdonképpen melyik vezérlő, szerintem szubjektív a dolog.
Én személyesen a Linuxcnc mellett tettem le a voksom, de nem akarok senkit rábeszélni, csak az elmúlt két év esztergás tapasztalatait írnám le. Az elsődleges szempontom az ár/jogtisztaság kérdése volt, ebben nyilván nyerő. Én egy Dávid esztergán használom, léptetőmotorokkal, LPT porttal. Az LPT port kimeneti órajele léptetőmotorhoz elég, a léptetőmotornak is véges a használható fordulatszám tartománya, jelentős nyomatékvesztés nélkül.
A bement már problémásabb, a port lekérdezéses működése miatt. 100 impulzus/fordulatos encoderrel még üzembiztos 2000-es főorsó fordulat mellett. Én először egy 2000imp/f encodert tettem rá, hát nem ette meg. Arduinoval le lett osztva 100 imp/fordulatra, azzal már jó. Az index bemenet is problémás, meg kell nyújtani az impulzus hosszát 2-3 impulzusnyira, hogy a port észrevegye. Ez azt jeleni, hogy a körbefordulás 2%-án ha jelen van az indexjel, az már üzembiztos. Egy arduino nano megoldja, nincs egy ezres. Nyilván ez jelent egy pici csúszást, de ha forog a gép, ez állandó. Ezek ez LPT port korlátai, de korrigálható, ettől még korrekt meneteket, csigákat lehet vele készíteni.
Na de a szoftverről is pár szót: A stepconf wizard teljesen korrekt dolog, jól be lehet lőni, konfigolni mindent. Amit utólag kell szerkeszteni, hogy g7, g95 legyen induláskor. De azért a pénzért...
A másik, a holtjátékok, ezeket is utólag kell beleszerkeszteni a konfigba, de egy tengelyhez hozzá lehet rendelni elvileg külön fáljban 256 ponton holtjátékot. Egy öreg, kopott vezérorsónál nem hátrány.
A holtjáték korrekció jó dolog, csak tudni kell kimérni és használni is. Mindig a sor elején nézi, van e az adott tengelyen irányváltás, és akkor beletekeri. Tehát ha a marógépen a helixet negyedkörívekre bontottam, akkor még 0,3-as holtjátékkal is kerekre marta a csapágyfészket.
Van benne olyan opció,Spindle at speed. Ez annyit tesz, hogy ha főorsó nem az m3 után megadott fordulatszám( +- x%)-on forog akkor a g0 után megáll és nem eseik neki egy rosszul beállított váltóval, rossz vágósebességgel az anyagnak.
Szintén pozitívum g95-nél, hogy ha az ember ezen a harmatgyenge gépen nagyobb fogást vesz a kelleténél, és megfolytja, akkor az előtolás is szinkronban lassul, majd megáll. Illetve jobban ki lehet határra járatni a forgácsoló teljesítményt nagyoláskor, mint percenkénti előtolásnál.
A szerszámtábla, és szerkesztője is korrektül használható, mostanában egy 3 késes gang-tooling konfiggal megy a legtöbbet.
Szóval összességében amit egy esztergán tudni kell, azt szerintem tudja. Na jó leszúró ciklust nem tud, de nem is kell érte fizetni.
Akkor sem kell kétségbe esni, ha nincs az alaplapon LPT port, a PCI buszos LPT kártyával is remekül működik, az sem volt 3000 forint újonnan.
Valóban, bár nem tudom van-e olyan gyors reflexű gépkezelő (egy átlegember mire megnyom egy gombot az 0.3-0.4 s reakcióidő), aki képes a törést elkerülni.
Mi a bajod a DOS-sal? Egyszer mindenki csinálhatna egy táblázatot magának, ahol összehasonlítva egy WinXX-es rendszerrel világosan látszanak az előnyök-hátrányok a különböző fő CNC alkalmazástechnikai szempontok alapján. De egy olyan világban élünk, ahol a tények, műszaki érvek, az objektív igazság/valóság nem számít, ehelyett "buborékokban" élik az emberek az életüket. Szomorú dolog ez nagyon.
Ez elkerülte a figyelmed: "feltéve, ha ugrásra kész a dolgozó - megszólalását követően elegendő időt biztosít a szerszámgép megállításához, törés nélkül. " Ciklusban is megállítható, ha más nem vészstoppal.
Na, akkor tulajdonképpen, melyik vezérlő program az amelyik biztonságosan, üzembiztosan használható "hobby" vagy félprofi körülmények között esztergán, viszonylag egyszerűen? Vagy ilyen nincs is? És mégis? Tibornak is biztos van jó megoldása, csak jó lenne kilépne a DOS árnyékából. Tudom, csicsavilág.... de már 2019-et írunk. Trabanttal is lehetett közlekedni, de már csak elvétve látni belőle az utakon....
CNCdrive | 442
2019-04-23 17:55:41
[43822]
Nyugodj meg, senki nem sérteget, nem bánt téged senki én be is fejezem itt most veled, nincs se időm se kedvem neked semmit bizonygatni. Foglalkozz szerintem a saját programod működésével és fejlesztésével, ne a miénkkel.
Most is kérlek, hogy ne minősítgessél ilyen sértően, gunyorosan, szubjektív módon!
Legközelebb vagy semmit vagy valami szakmai magyarázatot írjál arra, mi a garancia arra, hogy a G kódban megadott irányváltási pozícióban biztosan egyszerre lesz nulla mindkét tengely sebessége a VALÓSÁGBAN is a szinkron hajtásotok esetében?
Az első sort elhagyhattad volna, mert az csak szubjektív minősítés. Próbálj csak a műszaki tartalomra koncentrálni.
A videót meg már láttam régebben is, és a mostani menetfúró szinkron problémára sajnos nem mutat távolság lekezelési megoldást, mert egészen más történet a levegőbe kirángatni egy kést, és már a végpozíció előtt felfüggeszteni a szinkront ahhoz képest, hogy pontos Z irányváltási pozíciónk legyen végig szinkronban a főorsóval, egészen addig, amíg ki nem jön a szerszám az anyagból.
No, látom Robsy alias T45 megint keresi a fogást...
A főorsó szinkront a mozgásvezérlő folyamatosan tartja, ha a főorsón gyorsulási/lassulási rámpa van akkor aszerint. Ha megtorpan a főorsó, vagy megáll, akkor sincsen gond, akkor is tartja a szinkront.
Bár nem menetfúrás, hanem vágási kód, de az is így működik mint az alábbi videón, ez választ ad a kérdésre:
Csak azt az egy sor G kódot beírnád ide, ami a szinkron menetmetszést csinálja nálad a videón? Nem találtam erre UCCNC példákat (biztos rosszul kerestem) paraméter értelmezésekkel, csak ezért kérném.
"Teljesen egyértelmű, hogy egy step/dir-es hajtást nem lehet 0 idő alatt visszafordítani egy sima dir jelszint váltással (meg elindítani/leállítani sem lehet a step jelek sima be/kikapcsolásával)"
Abszolút nem egyértelmű. Miért ne lehetne csak dir jelet kiadni? Létezik ugyanis üzemszerű irányváltási start-stop frekvencia is még egy nyamvadt sima léptető motoros hajtásra is (adott esteben teljesen fölösleges rámpázgatni, elintézi azt a motor és hajtás páros magától a saját dinamikai határ képességei, vasba öntött adatai alapján). Pozíció szervónál meg ez egy egységugrási teszt, és alapüzemállapot is lehet, hogy az +n fordulatszámból mennyi idő alatt lesz -n, azaz depláne vonatkozik rá a start-stop freki, azért is szervó.
Igen, jól érted. Teljesen egyértelmű, hogy egy step/dir-es hajtást nem lehet 0 idő alatt visszafordítani egy sima dir jelszint váltással (meg elindítani/leállítani sem lehet a step jelek sima be/kikapcsolásával), ezért van a gyorsulási paraméter. A mellékelt képen a főorsó step/dir beállításait láthatod. (Az adatokat ne elemezd, láthatóan nem ez az üzemmód van kiválasztva, valami alapértelmezett adat van benne.)
Igazad van. Én annyira nem értek az elméleti működéshez. Van gyorsulás is definiálva a step/dir-nél is. Ha ezt is figyelembe veszi akkor meg is van a válasz.
Ha jól értem, te akkor mást állítasz, és nem azt, amit gbalazs, aki az előbbi verziómat írta, te meg az utóbbit, ha tényleg az UCCNC rápásan kezeli ilyenkor a step jeleket is. Jó lenne világosabban látni ebben a kérdésben, mi is a valós helyzet.
Azért ez nem egészen így megy. A step/dir-es főorsónak is van beállított gyorsulási paramétere, amit természetesen figyelembe vesz az irányváltáskor, tehát a megadott rámpával fog megállni és elindulni a másik irányba.
Ha csak dir jelet kap ( előbbi verzió ), ez akkor a veszélyes verzió, mert az irányváltási bit kiadása után csak a főorsó hajtás dinamikáján múlik ( a vezérlő program ilyenkor kiszolgáltatott, csak a szinkront tartja ), mi fog történni, mekkora lesz pl. a lassulási út, és a leállási pozíció pontossága, szórása. Ez pedig a te lépcsős munkadarabodnál se mindegy (zsák meneteknél se), ahol ha túl futna a menethossz, az is törést okoz.
Irányváltáskor csak egy irányváltási bitet (dir jel) kap a szervo a vezérléstől, vagy az UCCNC a főorsó programozott fordulatszám rámpája mentén vált irányt ilyenkor?
Èn egyáltalán nem ellek ezekkel a nyomatèkhatárolókkal. Az UCben nagyon jól működik a szinkron. A menetminősèget meg figyelem. Ha kezd töredezett lenni cserèlem a szerszámot.
Ha nem indul meg a beszorult nyomatékhatárolt menetfúró visszafelé, akkor meg a ciklus végén lesz egy hatalmas bumm, (hiába van hosszkiegyenlítő is) amikor GQ-al odább állna a szerszám, de közben benne van még a menetben, a CNC vezérlő meg azt hiszi már kint van. Hidd el csak az a korrekt, ha a mestertengely határol mert akkor a Z is szinkronban marad. Persze ilyenkor meg egy sebesség egységugrás probléma lép fel, amit a szervo vagy tud dinamikában követni, vagy nem, és akkor megint gáz van ...
Na de közben megy a szinkronozott Z előtolás, a menetfúró meg hiába "forog" (bár inkább állni fog határoláskor) haladni is kellene a menetemelkedésnek megfelelően, így szerintem valami törik ilyen esetben. Nyomatékhatároláskor egy hosszkiegyenlítőnek is működésbe kell lépnie.
Szerintem arra gondolt hogy ez egy biztonsági vèdelem a szerszámtörès ellen. Túlhúzod a nyomatèkot ès csak azelött határol mielött baj van. De amúgy a vágásban nem vesz rèszt. Különben határoláskor a szerszám forog a munkadarabbal, tehát akár mèg a vágáshoz is jó lehet.
Ezt a szerszám nyomatékhatárolást nem értem, hiszen határoláskor "szétszakad" a CNC szinkron, és szinte garantált a szerszám törés. Csak akkor van értelme, ha maga az encoderes főhajtásban (mester tengelyben) van elektronikus nyomatékvédelem, mert akkor a Z tengely is követi.
2019-04-24 23:42:24
