Aztán még ez ugatott le, hogy idióta vagyok mert analóg tachogenerátorral mértem egy analóg bemenetes szkóppal a REZONANCIÁT a léptetős rendszernél ! Miközben ez meg full digitális bohóckodással kábítja a fórumot. És még Én voltam elhordva mindenféle idiótának !
Persze. A kvantumszámítógép analogra épül, már amelyik próbálkozás már működik. A vacak digitális PC, (mint a tiéd, vagy abakuszt rángatsz?) kőkeményen a 0 - 1 páros alapján dolgozik. Ne próbálkozz a TTL vagy CMOS, vagy akármilyen szintek analóg magyarázkodásán, a lényeg az 1 és a 0.
Még egy kiegészítés. A világ, a matematika alapja analóg dolgokon nyugszik, hiába ülünk naphosszat egy vacak digitális PC előtt.
Az analóg világban a 0.0003 egy igen nagy számként is értelmezhető, hiszen tőle végtelenül sok és kisebb is van. A digitális ennek nyilván csak egy része lehet, de olyan algorimusokat kell alkalmaznunk, ami mindig a lehető legjobban közelíti a valóságot, azaz az analóg világot.
Hol írtam hogy a kijelzés NE a felbontásból megvalósítható valós koordináta legyen? Sehol! Ez jó a programban, a Robsy CNC vezérlőimben is így van.
Viszont a kijelzés és a számolás két külön dolog, szerintem SÚLYOS elvi programhiba egybemosni. Gondold végig micsoda durva G kód-tól való veszélyes (ütközés, szerszámtörés) eltéréseket jelent ez (mint az adott példa mutatja), amint egyre kisebb step/mm a gépfelbontás a setup-ban. Ez most így azt jelenti, egy teljesen jó G kód attól függően válik egyre szarabbá az UCCNC szerint és a te magyarázkodásod szerint, minél hitványabb felbontású a gép felbontása. Ez pedig nyilván nonszensz!
Egy napja próbálom megemészteni, amit írtál. Rajtad kívül bárkiről el tudtam volna képzelni, hogy azt javasolja, hogy a program mással számoljon, mint a tényleges pozíció. Pont az ilyen átverésekre szoktál ugrani. No, mindegy, csodálkozom tovább, de addig is elmondom a saját véleményemet.
1. A program helyesen jár el, amikor a tényleges koordinátát jeleníti meg, illetve ezt is tárolja, mint aktuális koordinátát. Én személy szerint nagyon fel lennék háborodva, ha kiderülne, hogy a tudtom nélkül, valami akárhogyan kiszámolt koordinátával dolgozik, miközben mást ír ki. (Egyszerű példa: soronként hajtom végre a kódot. Megnézem, hogy hol áll a gép, tetszik, nyomom a következő sort. Egyszer csak kiderül, hogy nem is azzal számol, amit látok...)
2. A program szintén helyesen jár el, amikor a G2 kezdőpontjának az aktuális koordinátát veszi. Ez a dolga, a szabvány ezt írja elő, ettől G2 a G2.
3. Szerintem a CamBam (vagy a posztprocesszora) csinál hülyeséget, amikor képes egy 0.0003mm hosszú körívet generálni. Értem én, hogy erre is lehet szükség egy csillagvizsgáló tükrének kialakításához, de nem tudom elképzelni, hogy bármi értelme lenne akár még ipari környezetben is. Még a 0.03 csak elmegy, de az két nullával odébb van...
Hogy hasznosat is írjak: kicsit utánaolvastam gyorsan a CamBam-nak. A posztprocesszornak meg lehet mondani, hogy milyen hosszúságú körív alatt generáljon inkább G1-et (Options - Arc To Lines Tolerance). Gondolom, hogy ha itt értelmes, a tengelyen egy lépéshez tartozó távolságnál nagyobb érték van megadva, akkor rögtön használhatóvá válik a rendszer. Sokszor csak annyi a baj, hogy az eredeti paraméterek ángilus mértékegységhez lettek megadva és emberi (értsd: metrikus) környezetben értelmetlenül kis értéket képviselnek.
Köszönöm a kielégítő kisérletet, tesztet. Érdekes, hogy másik program "rendben" megcsinálja. Bár nem értem dxf-ből hogy sikerült "hibás" gkódot létrehozatnom. Majd másik progiba generálom le. Köszönöm mégegyszer.
Talán az egy megoldás lehetne, hogy az UCCNC ne az adott gép durva hajtás felbontásával számoljon, hanem attól sokkal pontosabban, a kettő közti különbségeket pedig tengelyenként tartsa nyilván egy hiba regiszterben. Hiszen így mint a példa is mutatja egy jó G kód "rosszá válik" a vezérlő program hibás algoritmusa miatt, sőt balesetveszélyes szerszám törés, ütközés következhet be, amikor egy pici ívszakasz helyett betesz egy teljes kört a hibás működése kapcsán.
A helyzet az, hogy minden jó, csak mégsem. A pálya attól rossz, hogy a program jó. Nem, nem ittam semmi töményet. A következő történik:
A 68-as sor (G2 X289.385 Y290.9629 I192.3902 J-64.5029) hatására az X 289.3840, az Y 290.9640 lesz. Bár a kódban más értékek vannak, a kijelzőn a tényleges koordináták jelennek meg, és ezzel is számol a program. A tényleges és a programozott koordináta csak és kizárólag akkor lehet azonos, ha a programozott koordináta osztható a tengelyre előírt lépéssel, azaz egész számú lépést kell végrehajtania az adott koordináta eléréséhez. Mivel ez elég ritka, ezért két lehetőség adódik: vagy kiírod a tényleges koordinátát, ami többé-kevésbé az lesz, amit a g-kód előírt, vagy kiírod a g-kódban kért koordinátát, ami nem felel meg a valóságnak, de nagyon jól mutat. Az UCCNC az első verziót választja: a koordináták megjelenítése a ténylegesen megtett lépések száma alapján történik.
És itt el is érkeztünk a problémához, ugyanis a következő sorban (G2 Y290.9631 I186.8722 J-79.0784) a következő mozgást írja elő a kód: menj egy köríven a jelenlegi (289.3840, 290.9640) pontból (+186.8722, -79.0784) középponttal (289.3840, 290.9631) pontig. (Itt azt kell észrevenni, hogy a parancsban nem volt X, tehát az az éppen aktuális lesz, a középpont pedig relatív: az aktuális X és Y koordinátákhoz kell hozzáadni, de most mindkét dolog lényegtelen.)
Egymás mellé írom, hogy jól látszódjon: (289.3840, 290.9640) ---> (289.3840, 290.9631)! Az X ugyanaz, de az Y végpont KISEBB, mint a kezdőpont! Ezért fog egy teljes kört menni! A G2 előírja, hogy óramutató járása szerinti körívet kell bejárni, és mivel a végpont egy hajszállal a kezdőpont mögött van, ezért teljesen körbe kell mennie. Ha a kezdőpont nem a tényleges koordináta lenne, hanem az átverős, akkor nem lenne semmi gondod, mert egy 0.0003mm hosszú, az említett középponttal rendelkező körívet kéne bejárnia...
Hogy mi a megoldás? Nem tudom. Nem ismerem a CamBam-ot. Ha át lehet állítani a legkisebb szakasz hosszát, akkor jó. Vagy azt, hogy ne köríveket generáljon, hanem csak szakaszokat. Valamelyik (vagy mindkettő) segíthet.
Van egy kis problémám és nem tudom, hogy az uccnc vagy a cambam progi generálja. Gitár test formát marnék teszt célzattal.Az első kör 1 mm-es vágásánál mielött befejezné a teljes testet kimegy a rajzolatból. Az uccnc mutatja a formát, de azon túl megy. Nem is értem miért. Mutatja hol kéne mozogjon és azt is épp hol mozog, de akkor miért nem ott mozog, ahol kéne? Kinek küldjem a Gkódot? Csaba?
Aknai Gábor | 3170
2017-09-15 14:16:48
[4299]
Tudom, az meg is van. Az ilyen apró szösszenetekre, beállítások mikéntjére gondoltam.
Mit értesz UCCNC összefoglaló alatt? A program leírása ott van a program mappájában. Igazából csak a beépített plugin-ok leírása hiányzik. Talán még a makró/plugin fejlesztéshez lehetne írni doksit. Angol nyelven már megtette egy szorgos felhasználó, ha közelít a teljességhez, akkor majd lefordítjuk, ha megengedi.
- Az UC300ETH és UC400ETH hibásan számolta a gyorsulást a B tengelyen, ami furcsa mozgást eredményezett, javítva - Az UC300ETH és UC400ETH lépést vesztett az enkóder megszakítás prioritási hibája miatt, ha a főorsó enkóder engedélyezve volt, javítva
dezsoe | 2934
2017-09-15 12:15:21
[4293]
Szia!
Letöltöttem, de igazából nem láttam benne hasznos információt. Majd megkérdezem a Balázsokat, hogy egyáltalán létezik-e leírás hozzá, és ha nem, akkor gyűjtök információt és megírom, legyen meg ez is. (Csak egy kis türelmet kérek, mert az osztódás még nem megy, de igyekszem... )
Sziasztok! Tudna valaki segíteni, hogy az uccnc program lézer pluginjének leírása hol lelhető fel magyarul?
dezsoe | 2934
2017-09-13 13:35:36
[4286]
Készítettem egy makrót "smart homing" néven. A beépített home-olástól annyiban különbözik, hogy miután egy tengely felvette a home pozíciót, egy megadott koordinátára elmegy. A másik lényeges különbség a SoftLimit kezelésében van. Ha a home kapcsoló a SoftLimit határain kívül esik és a SoftLimit be van kapcsolva, akkor az UCCNC a home pozíció felvétele után megakad a SoftLimit koordinátánál (nem engedi bemenni a tengelyt a határok közé). Ezért a megadott koordináta felvételekor a SoftLimitet ideiglenesen kikapcsolom.
A profil file-ba fel kell venni egy [SmartHome] szekciót, ahol a paraméterek lesznek. G28Move<tengely>=true/false értékkel lehet egy adott tengelyre engedélyezni vagy tiltani a home utáni elmozdulást, G28Goto<tengely>=<gépi koord.> sorral pedig beállíthatjuk, hogy hova menjen. Például (nálam az X és Y home -5mm-en, a Z 50mm-en van):
A makrót meg lehet hívni paraméter nélkül vagy Q paraméterrel. Ha a Q meg van adva, akkor 0-5-ig az X, Y, Z, A, B, C tengelyt fogja home-olni. Ha nincs paramétere, akkor egy képernyő mezőből veszi, hogy mit csináljon.
A képernyőn kívüli területre tettem egy mezőt (hogy ne látszódjon) és látható helyre egy csúszkát, ami ennek a mezőnek az értékét állítja 0 és 6 között. 0-5-ig egyesével home-olja a tengelyeket, ahogy már fentebb leírtam, ha 6 az értéke, akkor a Configuration/General settings/Homing sequence beállításban megadott tengelyeket az ott megadott sorrendben home-olja. A makróban a SmartHomeAxisFld konstans értéke a beviteli mező sorszáma. Az első képen a nyomógomb (ez hívja a makrót) és mellette a csúszka látható, a másodikon az eredmény a státusz ablakban.
1. Igen, mm, ha mm-t használsz. Pontosabban fogalmazva: az UCCNC nem kezeli a mértékegységeket (nincs G20/G21), tehát ha mm-ben van a g-kódod, a tengelybeállításaid, meg minden, akkor a munkaterület is mm lesz.
2. A munkaterület mérete értelem szerűen gépi koordinátában van, így ha odébb teszed a G54..G59 nulla pontját, már ugrik is odébb a munkadarab.
- AltGr-es karaktereket (pl. #) nem lehetett beírni MDI-be, javítva - Színválasztó ablak kezdőpozíciója kívül eshetett a képernyőn, javítva - Új: a CNCRoom UB1-es paneljének támogatása - Új: csúszka új paramétert kapott (acceptclick), mellyel engedélyezhető vagy tiltható, hogy a csúszán bárhova kattintva oda ugorjon. Ha ez tiltva van, akkor csak a csúszka megfogásával lehet állítani - Új: a szerszámpálya-megjelenítőben egy hálós sík jeleníthető meg, ami a gép munkaterületét mutatja - Néhány THC beállítást nem mentett a program kilépéskor egy korábbi, a mentéssel kapcsolatos módosítás miatt, javítva - THC anti-dive a mozgás végén késett egy szinkronizálási időnyit a THC anti-dive funkció kapcsolással itt van róla szó, javítva
Amatőr | 2184
2017-08-31 12:25:36
[4278]
"és mindjárt elküldenek a fejlesztők a... csába" Csak nem! Azért kíváncsi volnék mit szólnak, lehet egyszerűbb mint gondolnánk.
Hát vanni van, de még az asztalon hever úgy hogy igazad van nem tudom hogy müxik, de ha tényleg így van, akkor inkább valami egyszerű szerkesztő nézet kellene ahol kör és négyzet huzigálós módival köré rakható a képnek
csak gondolom akkor jönnek az újabb igények, hogy a keret mentén halványabb legyen a kép így nagyobb képből is lehetne kivágni... ami szintén állíthatóan mekkora távolságról induljon ,stb..
már hogy ne lenne, a g kódhoz hozzáfűzheted a kivágandó terület g kódját, talán leginkább azzal a hasonlattal tudnék élni, hogy az aspire ben ha olyan megmunkálásokat végzel amelyek ugyan azon szerszámmal vannak akkor megmondhatod neki hogy egy fájlba tegye..
nem tudom mivel generálod a kódot, de gondolom a kép is végül egy G-kódként végzi, akkor a programból külön rajzolsz egy keretet és max a teljesítményt átírod benne..
Csak egy kérdés az UCCNC Laser-pluginnel kapcsolatban: én szinte csak ezt használom, kép gravírozáshoz vettem meg. Mennyire volna bonyolult dolog megoldani hogy amikor kész a kép akkor vágja körbe a lézer? Mondjuk mikor végzett megállna megkérdezni az előtolást aztán full teljesítménnyel a már kiszámolt méretek alapján rajzolna egy téglalapot. Azt már csak nagyon óvatosan említem meg hogy az ovális vágás igazi csemege lenne.
dezsoe | 2934
2017-08-21 22:08:25
[4267]
Csak egy gondolat, világmegváltás nélkül. Ha nekem fix bemérőm lenne (akár szerszám cserélő nélkül is), akkor biztos, hogy a méréseket gépi koordinátában végezném, mert onnantól mindegy, hogy melyik munka koordináta rendszert használod éppen. Pláne, hogy egy szerszámcserélős gép elég komolynak tűnik ahhoz, hogy több munkadarab is be legyen rögzítve: innen már csak G54 és társai kellenek, hogy ráállj a következőre. Ha elég pontos a homing és a befogás, akkor akár meg is jegyezheti a mérések eredményét, hogy csak a szerszámtár feltöltésekor kelljen mérni.
Olvasgattam, kérdezősködtem, de nekem valahogy nem tetszenek az iparban elterjedt szerszámbemérési metódusok. (volt amelyiket meg sem értettem )
Egy hobby gépnél nem gond a ciklusidő, ezért én inkább azt az utat választanám, hogy minden egyes szerszámcsere után menjen el és mérje be a szerszámot, egy célszerűen a szerszámtár mellett levő fix bemérőponton, írja be a szerszámkorrekciós tárba az értéket, majd ezzel a korrekcióval dolgozzon. (vagy akár nem is kell táblázatba írni, hiszen mindig mérnék) Így ki lenne küszöbölve a szerszám visszafogási pontatlansága is. (nem kúpos befogók vannak, hanem csak a szerszám hengeres szárát fogja meg a patron)
No de mihez legyen a viszonyítás? Az iparban sokszor a főorsó homloka és az asztal közti távolság az "etalon".
Én eddig talán még mindig csak olyan munkadarabot martam, ahol a Z0 a munkadarab felső síkja, így nekem az lenne a célszerű és érthető, hogy felvenném mondjuk a T1-es szerszámmal a munkadarab síkját, majd a többi szerszámot ehhez a T1-hez korrekciózná a többi szerszám Z mozgását
Ha valakinek van pár perce, próbálja már szemellenzős gondolkodásomat helyes útra terelni!
Készített-e már valaki fix helyzetű szerszámbemérőhöz olyan makrót, ami ténylegesen ki is tölti a TOOLS fülön a Z hosszkorrekciós táblázatot?
A szerszámcserélő M6 minta makro már tartalmazza a G43 H(aktuális szerszám) parancsot, tehát már valaki foglakozott ezzel a résszel is.
svejk | 33131
2017-08-20 21:22:23
[4264]
Okszi, kafa minden, végül is elég volt a megfelelő zárójelezés, nem kellett a .ToString().
Megcsináltam mindent, a kis Z mozgástartomány miatt a szerszámokat is kerülgetni kellett és a bekapcsoláskor is tudja melyik szerszám van bent. Így most nem is kellett beleírni semmit az M99998 és M99999-be. Egy kis ártatlannak tűnő makrot kellett csak pluszba írni. Egyelőre G01-el mozgok, majd ha a gyakorlatban is megy akkor felgyorsítom.
Köszönöm a segítségeket !
Jöhet a szerszámbemérés! (no az még szép falat lesz, mert azt sem tudom, hogy mi a helyes metódus, hogy is van az ipari gépeken)