De, természetesen tudja szinkronban mozgatni/forgatni mind a 6-tengelyt.
Az állandó felületi sebességet nem tudja pozicionált forgó tengelyen, ami azt jelenti, hogy meghatározod, hogy a forgótengelyed középvonala mondjuk Z=0-nál van és a Z tengely távolsága határozza meg a forgatón a munka-átmérőt akkor a megmunkálásnál a kör kerületének aktuális hosszához állítja az előtolást, úgy hogy a palástra vetített előtolás megfeleljen a programozottnak.
Mivel nem ismeri az UCCNC ezt a funkciót, ezért kis átmérőn ugyanaz a programozott F kisebb kerületi sebességet okoz, míg nagy átmérőn nagyobb kerületi sebességet. A pozíció szinkronban lesz, illetve a szögsebesség lesz a helyes, nem pedig a felületi sebesség.
Miért adná meg a választ? Mind a kettő távolság mértékegység. Forgó tengelynél a szögsebesség egy más típusú, értelmű mértékegység, mint az egyenes vonalú sebesség mértékegysége.
De mint már kiderült, megkaptad a választ, a forgó tengelyt felejtsed el, "az UCCNC nem ismeri a forgó tengelyeket".
Köszönjük, de nem kell rávilágítani arra ami magától értetődő, hiszen nincsen a szoftverben forgó pozíció tengely kezelés opció és kinematika modul sem. Semmit nem magyaráztam meg azon kívül, hogy a szoftver nem tudja ezt a funkciót, ha neked ez magyarázkodás, akkor sajnálom. Szerintem ne fárasszuk egymást, mert tudom, hogy csak trollkodni és rosszhír keltés céljából jársz ide, szóval innentől kezdve részemről ignorálva leszel, le is tiltalak gyorsan, hogy ne is lássam a sok butaságot amiket írkálsz.
Érdekes azt "szűklátókörünek, és szakmaiatlannak" nevezni, aki rávilágít arra, hogy már egy forgó és egy lineáris tengelykódnál sem igaz az F kód utáni érték a vezérlőprogramotokban.
Nekem így is jó, megszoktam már, ebben a mai világban mindent meg lehet magyarázni, főleg ha szép a körítés a monitoron hozzá. Azt viszont engedd meg nekem, hogy a valós műszaki tényeket elsőrendűnek és fontosnak tartsam az életemben.
Sajnálatos ha valaki ennyire szűk látókörrel rendelkezik. Sokadjára ismét megkérlek, hogy kerüld a topikunkat, ha más célod nincs ahogy eddig se volt sajnos mint a rosszindulatú értelmetlen és szakmaiatlan hozzászólások.
Teljesen igazad van, egy-egy technológiára is érdemes egy CNC programot létrehozni, hiszen így lehet hatékony, sallangmentes. Ráadásul mint már kiderült, G kódokkal macerás műszakilag korrekten lézer képgravírozni dinamikus keretek közt, az az itt pl. teljesen felesleges és hátráltató maga még a G kód is.
"A pozicionált tengelyeket mindig lineárisnak tekinti."
Aha, így már érthető az A, B, C tengelyek beállítási ablakainál a mindent elkenő "unit" univerzális szócska.
Nagy kár, hogy egy program akkora virtualitást megenged magának hatalmas csicsa keretek közt, hogy ami forog, azt is úgy kezeli, mintha egyenesen mozogna.
Az UCCNC nem ismeri a forgó tengelyeket. Ha használtad, nézted a programot akkor láthattad, hogy nincsen benne forgó tengely opció egyelőre. Ahhoz, hogy forgó tengelyt is tudjon kezelni, ahhoz másfajta számítás kell, illetve némileg a gép kinematikáját is ismernie kéne a programnak (a legtöbb esetben). Ezt az UCCNC jelenleg nem tudja, nincsen benne ilyen opció. A pozicionált tengelyeket mindig lineárisnak tekinti.
Viszont Svejk átmeneti pozíció hibát írt és nem sebesség hibát, ezért nem értettem a kérdésedet.
Úgy tudom, hogy mintha a LinuxCNC-ben lehetne kinematikát programozni. Nem vagyok benne 100%-ig biztos, de mintha azt olvastam volna valamikor. Szóval ha ilyenre van szükséged akkor próbáld meg LinuxCNC-vel, talán az tudja kezelni úgy ahogy szeretnéd.
Köszönöm az ötletet, de ahogy leírtam Gábornak is az előző válaszomban én nem látom ezt annyira jó ötletnek, mert sokkal több munkánk lenne vele. Nem véletlen van a Mach3-nak is egy mag programja és külön képernyőszettjei a különböző gépfajtákhoz. Így nekünk jóval egyszerűbb és gyorsabb és problémamentesebb a fejlesztés.
Én teljesen másképp látom ezt a dolgot. Szerintem a program szétszedése részekre csinálna nekünk sokkal több munkát és jelentősen több problémát. Gondolj bele, hogy ha mondjuk 3 helyen különböző dolgokat fejlesztenénk, azzal mennyire lenne átláthatóbb az egész rendszer a fejlesztőknek, szerintem sokkal kevésbé látnánk át egy idő után. Így, hogy egy közös kód mag van így egyszerű átlátni a fejlesztést és szinkronban tartani az API-t és magát a programot.
Az pedig hogy valami elromlik kiszokott derülni még a teszt kiadásoknál, ahogy most is, éppen ezért csinálunk teszt kiadásokat.
A szétválasztást én a különböző képernyőszettekben látom. Például ha nincs szükséged valamire akkor le lehet szedni a képernyőről például a port/pin-jeit és máris nem lehet konfigurálni.
Az igaz, hogy G-kód szinten már más a helyzet, de ha nincs szükséged a G42-re akkor nem kapcsolod be. Az hogy most éppen emiatt elromlott valami az sajnos benne van a pakliban, mert csak az nem hibázik aki nem dolgozik, de ahogy írtam fentebb ezért adjuk ki teszt verzióban ezeket és várunk bizonyos ideig hogy kiderüljenek ha vannak hibák mielőtt kiraknánk az adott verziót hivatalos kiadásba.
Igaz, hogy nem nekem szólt a kérdés, de megpróbálok több mint 3 évtized programozással a hátam mögött válaszolni a felvetésedre (illetve, felvetésetekre, Gáborral együtt). Mivel a szétdarabolt program jelentős része továbbra is ugyanarra a kódbázisra épülne, csak egy-egy részlet kimaradna, ugyanúgy együtt kéne fejleszteni, javítani. Ha kiderül valami probléma, akkor az összes verziót lehetne javítani. Ez semmilyen előnnyel nem járna, viszont cserébe mindent lehetne több példányban csinálni, ami maga az exponenciális szopásfaktor.
Az például, hogy itt a fórumon nem sokan használnak G42-t, egyáltalán nem jelenti azt, hogy mások sem használják. Amióta folyamatosan olvasom a többi UCCNC-s fórumot is, állandóan téma és nagyon várták már. Amelyik funkcióra nincs szükséged, azt nem használod, és meg is van oldva. (Két kocsid van: az egyikben anyósülés, a másikban meg csomagtartó van? )
A menetvágás hibáját Gábor felfedezte, de nehéz volt reprodukálni, így nehéz volt javítani is. Az egy másik kérdés, hogy kiderült, hogy más is küzd vele, ráadásul gyorsabban tudja előhozni a hibát, mint Gábor. De akkor miért nem szól, hogy valami bibi van? (Ezen a fórumon felhasználó.)
A változással (fejlődéssel!) semmi baj nincs, ez a normális. Ha valami nem sikerül, az bizony előfordul, ha dolgozik az ember. Pont erre valók a teszt verziók, hogy ezek kiderüljenek. Azért a hivatalos verziókban nem nagyon szokott hiba maradni, szerintem.
Nincs kőbe vésve, azaz nem kötelező a tengelyek jelölése és viszonya sem. Csak praktikus, mert elterjedt. "Units" pont azért jó, mert általános. Mi baj van a behelyettesítés utáni "mm/min", "deg/min" vagy "foot/min"-el? (A tárgybéli programnak már talán a földön kívül is vannak felhasználói. Rájuk is kell gondolni!)
Én értem a vegyes interpoláció előtolás problémáját és azt is, hogyan oldják fel ezt azok a vezérlőprogramok, amelyek szimultán 4 és több tengelyes interpolálásra képesek. (Inverse time feed.) Az [5169] béli kérdésem gyakorlatilag ugyanaz, mit a tiéd.
Tudtommal a jobbsodrású CNC koordinátarendszerben az X, Y, Z, A, B, C kódok meghatározottan, egymással összefüggően 3 lineáris, és 3 forgó tengelyt jelent. Az "units" túl általános, és a lineáris mozgásra mások az elmozdulás és sebesség mértékegységek, mint a körmozgásra.
De legye itt egy példa:
G90 G0 X0 Y0 A0 B0 G1 F600 X100 Y100 A200 B200
Kérdések: Mit jelent itt a programban és mit a valóságban az F600? Mi ennek ilyenkor a mértékegysége?
Nem gondolom, hogy a konfigurációs ablak szövegei kihatással lennének a működésre. Mivel az A B és C jelölésű tengely lineárisként is használható, valamint a Units és a Units/min félreérthetetlenül értelmezhető minden mértékrendszerben, ebben nem látok valós problémát. A "pályameneti előtolási sebesség" számítása forgó tengely és említésre méltó fogásmélység esetén már ki kell hogy térjen a szerszám minimális és maximális bemerülő részén adódó sebesség eltérésének kezelésére. (A felhasználó választására bízva.) De ez nem vezérlő oldali, hanem programozási feladat.
A vegyes interpoláción a lineáris és forgó tengelyek egy mondatban programozott szinkron mozgását értem. A példát pedig az 5168-ban hozott két programmondatra értettem.
A probléma már ott elkezdődik, amit már egyszer megemlítettem. Neveztesen a forgó és lineáris tengelyek setup ablakai azonosak. Innentől kezdve a pályamenti előtolási sebesség valódisága erősen kérdéses.
Persze de minden egyben van . Pont ez a bajok forrása . Bele sem kell (alapból ) tenni ami nem kell, és akkor amikor fejlesztik (pl a G42 ) akkor nem fog elromolni más ( mert nem is használ G42 t) ) Az előzőleg leírtak szerint minek a plazmához a szinkron menet lehetősége ? ( ami 1.5 évig hibásan működött az egész világon és most talán sikerült kijavítani Balázséknak ( mert végre elhitték hogy igazat állítok )
Amit írok az példa de én rendszeresen konzultálok Dezsoe vel és sokat bosszankodom ( utoljára a config változtatásaim mentése nem sikerült ha túl sokat állítgattam , de a soft újraindítás megoldotta , a korábbi verziónál nem volt ilyen hiba Win 10 es a gépem ) Vagyis egy egy új funkció bevezetése elrontja a régi jól működő dolgokat . Most a G41 ,G42 ( és még sok más az új ) ami nem is kell mindenhová a korábbiak szerint . Én nem vagyok híve : a" merjünk nagyot álmodni szlogennek ". Kis ( és biztos ) lépésekkel előbbre lehet jutni
Akkor tényleg nem értem , ezt most is meg tudod csinálni , hogy csinálsz x + 1 profilt és azt indítod el amelyik kell . Miért szednéd szét 5-6 külön programra ??
Szerintem nem érted hogy mit akart sugallni Miki2 . Minek a szerszámsugár korrekció a lézehez ? és minek a THC kontroll az esztergához ? nem kell a szinkron menet a plazmához stb Pont az a baj hogy elkészül valami és elromlik egy másik jól működő rész ." Van egy régi közmondás : aki sokat markol az keveset fog "
Szerintem is szét kellene szedni és akkor az egyes részek kifogástalanul fognak működni . Az hogy hogyan lesz a licensz díj megállapítva az tisztán közgazdasági számítás. Pl most veszek egyet és lézerezhetek, plazmázhatok esztergálhatok ,marózhatok . Miért nem lehetne ugyanígy a jövőben is ?. Csak azt fogom betölteni ami nekem kell. Balázséknak nem csökken a jövedelmük csak a munkájuk
Ha felrakok két fejet (maró-lézer) egymás után használhatom őket más beállítással , vagy akár a két külön gépet is egy egy szalagkábellel rá lehet kötni egy vezérlőre ..
Ha üzemszerűen akarsz dolgozni, és szeretnéd kerülni a napi többszöri, hosszú ideig tartó szerelést, akkor igen. Ha csak játszani akarsz, meg úgysem építessz egyszerre mindenféle gépet.
Szervusz Balázs! Lehet,eretnekségnek fog számítani amit most leírok. Az UCCNC mint tudjuk, csak licensszel, és egyszerre csak egy gépen működik. Ezért nem sok értelmét látom annak, hogy ez egy minden egyben szoftver legyen. Szerintem Nektek is könnyebb lenne a javítások nyomon követése, és egyes részek javítása esetén kisebb lenne az esélye annak, hogy egy másik, már jól működő rész elromoljon. Szóval mivel egyszerre általában egy gép készül, talán célszerűbb lenne szétszedni a programot. Külön Marás, Plazma, Lézer, Eszterga gépek vezérlésére alkalmas szoftverekre. Persze az adott megmunkálásra jellemző alap beállításokkal. Így lehetne például: Marásnál 6 tengely (Ebből 1 szolga) mm/perc előtolás Esztergánál elég a 3 tengely (X Z C) mm/fordulat előtolás A többiről azért nem írok semmit, mert azokhoz buta vagyok.
Neked az okozza a problémát, hogy van két forgó tengelyed, ami nem lineáris mozgás végez, igy a pályán a sebességnek sem állandónak kellene lennie (folyamatosan változnia kellene). Ez vajon megoldható, hogy minden tengelynek egy adott pillanatban más és más sebesség étéket adjak egy adott függvény szerint?
Ilyenkor X mozog X=10-re majd Y mozog Y=10-re, ha G61 exact stop módban lenne a mozgatás. Ez a végrehajtás viszonylag lassú, mivel a sarokpontra mozgásnál teljesen le kell lessítani az X tengelyt majd az Y tengely elkezdhet felgyorsítani.
Ha G64 constant velocity mode van beállítva, akkor annak érdekében, hogy az előtolást minél jobban tudja tartani a vezérlő, vagyis hogy minél hamarabb végrehajtódjon a teljes pálya mozgatás kerekíteni fog a csatlakozási vagy más néven sarokponton. Egy rádiuszt fog leírni a sarkon. Ez a pálya gyorsabb mint ha teljesen lelassított volna a sarokpontra, hiszen a pálya rövidebb is és nem kell az X tengelynek teljesen lelassítania mielőtt az Y elkezdené a gyorsítást. A kerekítés mértéke maximum annyi lesz amennyit a CV paramétereknél megengedsz a szoftvernek. Annál nagyobb távolságra nem fog eltávolodni a sarokponttól, vagyis annál nagyobb hibát nem fog ejteni a pályán.
Az hogy milyen esetben mennyit tér el a pályáról az attól is függ, hogy milyen a pálya és mennyi a programozott előtolás, mert lehet olyan a pálya, hogy egyáltalán nem kell letérni róla ahhoz, hogy tartani lehessen a programozott előtolást. De minden esetben a pályáról letérés maximum annyi lesz csak amennyit beállítottál a CV paramétereknél. Szóval ezzel a beállítással tulajdonképpen a munkadarab toleranciát határozod meg nagyjából, illetve azt mondod meg a szoftvernek, hogy max. ennyi hibát ejthetsz a pályán annak érdekében hogy tartsd az előtolást és hogy így minél hamarabb végezz a kóddal.
A Mach3/4 pályatervezője ezt például egyáltalán nem tudja. Mach3-nál csak tippelni lehet, hogy mennyivel fog eltérni a pályáról, szóval a toleranciát nem tudod beállítani, csak tippelhetsz.
akkor a tengelyek szinkronban mozognak. A pálya közbenső részein is szinkronban lesznek. Az mindegy, hogy fix értékeket vagy #változókkal programozod.
Persze ha már több mozgás van, akkor a helyzet bonyolultabb. Ha egy mozgás sok kis szakaszból áll, amiknek az irányvektoraik eltérnek, akkor a pályaoptimalizáció miatt nem feltétlen az lesz a pálya amit programoztál, aminek az oka, hogy G64 konstans sebesség módban te engedélyezed a szoftvernek, hogy módosítson a pályán annak érdekében, hogy minél jobban tudja tartani a programozott előtolást. Persze a pályáról a szoftver maximum annyival fog eltérni amennyit te megengedsz neki a CV paraméterekkel a General settings oldalon. G61 exact stop módban viszont a pálya az lesz amit programoztál, mert a pályaoptimalizációt a G61-el kikapcsolod. Remélem érthető amit írtam, próbáltam érthetően leírni, de nem egyszerű, mert egy regény hosszan is lehetne magyarázna ahhoz hogy minden részletre kitérjen az ember.
Mozgásoknál ez nem okoz problémát. Úgy képzeld el, hogy elindul a ciklikus g-kód végrehajtás, ami mondjuk 100 sorból áll és az előretekintés nagyobb, mondjuk 300 sor (ami az alapbeállítás). Ilyenkor a szoftver elkezdi nézni és feldolgozni a sorokat és betölti a mozgás pufferbe a mozgésokat. Ha minden utasítás mozgásszinkron akkor egy pillanat alatt végig is ér a 100 soron, betesz mindent a mozgáspufferbe és utána már csak a kijelzés folyik, vagyis szépen sorban ahogy a végrehajtódnak a mozgások a kijelzőn frissül a mutató, hogy éppen hol tart a végrehajtás, de valójában a szoftver ilyenkor már nem dolgozik a g-kódon, azt már megtette. Természetesen a mozgásoknál hiába néz előre a progi, az nem okoz koordináta problémákat #változóknál, amikor előre néz akkor a # változó számolásokat is előre kiszámolja, sorban halad, így a mozgáskoordináták természetesen nem lesznek hibásak. Ami a probléma az csak annyi, hogy amit lekérdezel # változó értéket az nem annyi mint amennyinek kéne lenni ott ahol épp a mozgás fizikailag tart, mivel a szoftver a számolásban már előrébb tart mint a végrehajtás.
Ha közben van nem mozgásszinkron utasítás, például text macro, olyankor az előrenézés ott megtorpan, a szoftver megvárja a mozgásvezérlőt, hogy kiürítse a puffert, vagyis hogy minden mozgás utasítást végrehajtson ami a pufferben van és ha ez megtörtént akkor folytatja a következő sorok végrehajtását és ismét próbál előre nézni, ami sikerül is, hacsak megint nem jön egy olyan utasítás ami nem mozgáspuffer szinkron, mert akkor megint szinkronizálnia kell, meg kell várni a mozgások végét.
Ha minden #változó értékadás után beraksz egy várakozást, egy nem mozgásszinkron utasítást, akkor az előrenézés gyakorlatilag megszűnik, mivel minden ilyen utasításnál a mozgásvezérlő meg fogja várni, hogy a mozgáspuffer kiürüljön és emiatt a #var lekérdezett értékei szinkronba kerülnek a program végrehajtással.
Ez a megoldás jelenleg sajnos nem működőképes. A probléma az, hogy a # változókat a feldolgozáskor mivel előrenéz a szoftver a kódban, ezért már előre feldolgozza és a lekérdezésben, ill. az analog kimeneten is már azt az értéket látod, amit már előre kiszámol a szoftver. Ha S kódot teszel be, mivel az nem szinkron utasítás a mozgáspufferrel, ezért ilyenkor a szoftver először üríti a mozgáspuffert (végrehajt mindent ami az S előtt volt), vagyis az előrenézés száma 0 lesz mikor végrehajtja az S parancsot, szóval a #var szinkronba kerül a végrehajtott sorral. Viszont ennek a hátránya, hogy a szoftver nem fogja összefűzni a mozgásokat.
A probléma fennáll az UCCNC-ben és a Mach3-ban is. Vannak terveink, hogy az UCCNC-ben megfejlesztjük, hogy szinkronban tudjon maradni a g-kóddal a lekérdezett #var, már egy ideje tervben van, csak még nem jutottunk oda, hogy meg is csináljuk. Mach3-ban viszont nem tudunk ezzel a problémával mit csinálni, mert nem a plugin hanem a szoftver önállóan kezeli a # változókat.
Ez azért szívatós. Mert oké, hogy ki REM-elem, de ha utána megnyitom a képernyőszerkesztőt és nyomok egy mentést, akkor el is tűnik az SSF file-ból az adott sor, hiszen elmentettem úgy, hogy nincs rá szükség. Tehát a próbák alatt mindent menteni ezerrel...
Pedig nem túl bonyolult. AS3.addtab() a te barátod. Itt vannak leírva a felül levő menük lásd Screenset_functions leírásban. Ha pl. el akarod rejteni a configuration menüt, akkor kikeresed az AS3.Addtab("", "Arial", "center",24, 0,436, 7, 165, 18, 88, 6, 1); sort és teszel elé egy //.
Ez a G41/G42 kód fejlesztésekor lett elrontva sajnos, mert ott sok mindent át kellett írni az alap működésben és nem vettük észre, hogy ez elromlott, de hát végülis erre vannak a teszt verziók, hogy az ilyen gondok kiderüljenek mielőtt hivatalosan is kiadnánk. Jelenleg javítás alatt van, a következő verzióra megfixáljuk. Illetve az 1.2047 verzióban ami még a G41/G42 korszak előtti utolsó verzió, abban még jól működik.
Ja és az M1 stop sem működik jól ha M98 szubrutinban van végrehajtva, ez is ugyanúgy romlott el és jelenleg javítás alatt van.
Először azt hitte a paraméterezés miatt nem megy a soronként futtatás. De normál üzemmódban sem lehet az M98-at tartalmazó kódot futtatni soronként. Ez direkt van vagy még fejlesztődik?
2018-02-13 18:41:52
)
