Ha a Robertspark-féle M751-el próbálkozol, akkor az D és E paramétert fogad:
M751 { Dxxx, Exxx } (Constant Surface Speed) D - maximum spindle { RPM } E - surface speed {units per minute}
Tehát a D a max. fordulatszám, míg az E az elvárt felületi sebesség mm/perc-ben megadva.
Előzmény: Varga Kettő István, 2018-06-22 08:40:35 [5702]
Varga Kettő István | 13
2018-06-22 08:40:35
[5702]
Szia Dezső!
Reszelgetem G96 S makrót. A cél az volt hogy külön makróból változókkal megadni az értékeket pl.M751 {V180, HS1560}
A V és H változók S a főorsó fordulat parancsjele:
Ha elindul szépen megy de nullás értéknél beragad a reset parancs. Úgy tűnik nem szereti a HS szövegrészt Meg lehet ezt máshogy adni hogy ne vesszenek össze? István
Balázs ! Tehát kúpos menet G76 tal UCCNC vel : Idézet a "kottából " "Menetvágó ciklus végrehajtásához programozzon G76 P... Z... I... J... K... E... L... Q... H..."
Itt hol adom meg a taper értékét ? Mert én azt írtam hogy nullától eltérő kúpszögű ( akár félkupszögű ) menetet szeretnék vágni az UCCNC G76 os makrójával .
Azt ismerem hogy hogyan lehet G33 al vágni kúposat de az nem olyan kényelemes mint a G76 mert ott optimalizálható a forgácskeresztmetszet
Persze van gyógyszer de nem fehér embernek való ( én feketének tarom magam ) G76 megír Mach ( taprerral ) , lefordit G32 sorokra ( kis trükközés G32>G33 emelkedés> k ) és behív UCCNC ben Megjegyzem hogy a MACH 3 G76 os ban a tapert Briaenék eltévesztették . Akit részletesen érdekel az keressen magánban ( egyszerű trigonometrikus dolog de szívtam vagy 20 órát mire ( a darabok kiértékelése után ) rájöttem . Az egész világ szív ha a Mach ban G76 ot programoznak ( taperrel )
G76 menetciklust évek óta ismeri az UCCNC. A szerszámok egymáshoz viszonyított beállíthatósága és a méretek egymás utáni kompenzálhatóságát nem értem, hogy vajon mit jelenthet. Illetve sejtésem van és ha az amire gondolok az megoldható makrókkal, persze azt meg kell valakinek írnia... Csúcssugár kompenzációt nem tud az UCCNC.
Legalább a szerszámok egymáshoz viszonyított beállíthatósága, és a méretek kompenzálhatósága szükséges lenne ahhoz, hogy esztergán érdemi próbálkozásokat lehessen végezni. A csúcssugár kompenzáció már csak hab lenne a tortán. A másik nagyon fontos dolog a G76 menetvágási ciklus lenne. Amint legalább az alap eszterga funkciók működni fognak, el kezdem a tesztelést.
Ezek a közvetlen gyors kimenetek nagyban meg fogják könnyíteni a célgépeket építők munkáját, köszönjük!
CNCdrive | 449
2018-06-20 11:14:59
[5689]
Szerintem érdemes volna közelebbről megvizsgálnod a problémát. Én a helyedben azt ellenőrizném, hogy a probléma jelentkezik-e ha az első sub előtt van egy nullázó G52. Illetve azt, hogy amikor a probléma jelentkezik, akkor a G52 értéke előzetesen mennyi volt. Hogy 0 volt-e.
Az Offsets ablakban G92 Offset van kiírva, de az technikailag azonos a G52-vel, csak máshogy adod meg. Mindenesetre, ha nem nulla, akkor látod, hogy van eltolás. (Próbáld ki és látni fogod.)
Ha használod, akkor érdemes a g-kód elején és végén alaphelyzetbe állítani. Amíg a program fut, addig a legutóbbi érték az aktív (lásd Offsets ablakban), így saját magadat tréfálod meg, ha nem állítod vissza a kód végén és elindítasz valami más kódot.
Ha sokat G52-zöl, akkor ajánlom figyelmedbe a QuickView plugin-t. Letöltés innen.
Mi garantálja, hogy az első subrutinkor a G52 offset 0? Tehát minden progi elejére be kellene írni minden tengelyre? Arra figyelek, hogy így legyen befejezve, ahogy a ciklusok törlésére is figyelni kell. Tehát maximum én tudom magamnak garantálni. Viszont nem egy ismeretlen értékkel tolódik el, hanem a következő sor eltolását alkalmazza, majd az újabb sub hívásakor ismét. Nem a vita kedvéért, tényleg szeretném megérteni.
Na, látom Dezsoe megint gyorsabb volt és leírta ugyanazt mint amit én.
Továbbgondolva ... lehet a probléma félreértésből adódik a G52 kapcsán. A G52 a szoftver futás idején él és törlődik(nullázódik) a szoftver újraindításakor. Nem pedig a g-kód futásideje alatt aktív. Vagyis a g-kód program előretekerésekor, újra futtatásakor a G52 értéke nem törlődik, hanem benne marad a legutóbb programozott érték.
"Ha beírom a G52 X0 Y0-t, akkor ugyan ott marad, hiszen nincs eltolás, nem?"
Na igen, de az első sub hívás előtt nincs odaírva. Mi garantálja, hogy az első subrutinkor a G52 offset 0? Mivel a kódodban van nem nullás G52, ha esetleg megállítod valahol a programot ahol éppen van G52 eltolás és előretekered a kódot és lefuttatod, akkor az első sub futásod az épp aktuális eltolással lesz eltolva, hiszen nem adsz ki G52 X0 Y0-t előtte. Nem lehet hogy ez okozza a problémát?
Az előző futásból aktív maradt a G52. Azt írtad, hogy próba után volt vele gond, így arra tippelek, hogy az első futtatást megállítod, csinálsz, amit kell, utána rewind és újra futtatod, de mivel előzőleg már a G52 kapott értéket, ezért az O00002 első futásakor a legutóbbi G52 marad aktív, oda fúr. (Ha nem, akkor megdőlt az elmélet. )
Sziasztok! A verzió: 1.2047 A link beszúrását vettem.
Nem értem a logikáját, de természetesen kipróbálom. A koordináta eltolás előtt eleve nincs eltolás, szerintem a munkadarab eredeti nullpontján kellene a munkát kezdenie, nem egy eltolt érték szerint. Ha beírom a G52 X0 Y0-t, akkor ugyan ott marad, hiszen nincs eltolás, nem? Itt kellene kezdenie először alprogramot, nem egy egy sorral később beírt eltolás szerint. A főprogram végén viszont ott van a G52 X0 Y0, amivel lenullázom az eltolást, és így másodszor valóban helyesen kezdi.
Ha korábban félre érthető voltam: refpont felvétel stb., behívtam a Gkódot, lefuttattam (hibás), munkadarab csere, lefuttattam újra (helyes).
Megyek, kipróbálom és köszönöm amit írtál, csak nem értem.
Sejtem ám, hogy mi lehet a probléma. (El kellett hozzá olvasni egy párszor...) A kulcs a próbafúrás. A G52 eltolást nem nullázod a g-kód elején, így ha előzőleg próbafúrtál és a G52 már a második sorra mutat, akkor a kód újrafuttatásakor az első két M98 esetében ugyanaz lesz a koordinátarendszer-eltolás. Az első G0 X0 Y0 elé írj be egy G52 X0 Y0 sort.
(Ui.: kód beszúráshoz továbbra is használd a kód beszúrása gombot, mert így olvashatatlan és hosszú. Köszi!)
Van egy kis gondom néhány sorozat fúrással. A fúrások elkészültek, és a hiba mellett is megfelelők, azonban a későbbiekben lehet vele probléma. Több esetben is az történt, hogy a próba fúráskor a főprogram első alprogram hívását nem végezte el a gép, majd a másodikat viszont duplán. Másként fogalmazva a koordináta eltolást az első meghívásnál a második meghívás koordinátájaként hajtotta végre, és így az duplán ment végig. Viszont az éles, második lefuttatáskor rendesen, a terv szerint működött.
Véletlenül 4 ilyen apró munkám volt, és mindegyik így ment végig. Egyik sem okozott kárt, de szeretnék tisztában lenni az okkal. (Nem használtam fúróciklust, mert nem láttam szükségét.) A képen a bal oldali a teszt, az alsó soron kétszer ment végig, majd a jobb oldali deszkán az éles, változatlan G kóddal, ami az alábbi:
Ezt én sem igazán értettem: "szerszámcsere és egyéb fontos funkciók nélkül", csak valamiért nem kérdeztem rá vissza. Pár szóban kifejtenéd, hogy mire gondolsz?
A sebessége miatt UDP, teljesen zárt és titkosított adatátvitellel. (Ha nem jól írtam, akkor a Balázsok majd kijavítanak, de határozottan így emlékszem. )
Nekem ugyan semmi bajom az LPT-porttal, de szívesen megismerném az ethernet alkalmazását a CNC területén. TCP, vagy UDP protokolt használnak, vagy valami más módja is létezik az alkalmazásának? Ha igen, lehet róla tudni, hogy mi az? Köszi.
Plazmavágó támogatás van az UCCNC-ben. Jelenleg az 1.2047 verzió a legfrissebb stabil verzió, ezt javaslom napi használatra. A nagyobb verziószámúak jelenleg még teszt verziók, kipróbálni lehet, és örülünk a visszajelzéseknek, de figyelembe kell venni, hogy azok teszt verziók, lehet bennük hiba.
Plazmavágót használók tapasztalatai alapján mindenképpen ethernetes vezérlőt tudok javasolni, mivel az USB-s vezérlők eléggé zavarérzékenyek plazmás környezetben. Ennek az az oka, hogy az USB-s vezérlőknél a számítógép és a mozgásvezérlő elektromosan nincs elszigetelve egymástól, míg az ethernetes az UTP kábel mindkét végén le van választva.
Az csak a macro-n és persze a folyamaton múlik, hogy mennyi idő kicserélni. Biztos van valami oka, hogy ennyi idő ezen a gépen. Itt valamivel gyorsabb:
Szerszámcsere évek óta benne van az UCCNC-ben. Szinkron menetet is évek óta tudja. Esztergálni is lehet, de nem javasoljuk. mivel eszterga funkciók hiányoznak, amik kényelmessé tennék az esztergálást.
Ezt nem is értem. Ha tudsz szerszámcsere kódot írni, akkor hol akadtál el? Igaz azt nem értem, hogy aki nem használja, az mi a f..t keres a topikban? Ráadásul inkább fikázós, mint kérdő állasponttal.
Persze, sok mindent lehet. De szerszámcsere és egyéb fontos funkciók nélkül az csak mókolás. Én még a marógépre sem merem feltenni. Most Pl. vezérmű tengelyhez hasonló bütykös tengelyeket marok. Mindezt 4 tengelyen, MACH3-al.
2018-06-22 09:25:07
) G76 megír Mach ( taprerral ) , lefordit G32 sorokra ( kis trükközés G32>G33 emelkedés> k ) és behív UCCNC ben 
