Az M17 mikor hajtódik végre? Rögtön az M5 sor után, vagy vár addig míg a step/dir-es spindle fordulata az ott megadott gyorsulási érték mellett 0-ra csökken.
Ma kísérletezgettem az alábbival: (nem titok, hegesztőgép lesz vagy ócskavas) M3 Sxxx paranccsal indul a huzalelőtolás, M5-el ugye leáll. (DG4S Dc servo, step/dir-es meghajtásal) Írtam pár makrót M12-21 névvel egyéb dolgok mint gáz, áram, stb. kapcsolgatásokra. Ezekben a makrokban egyelőre még csak egyszerűen az Exec.Setoutpin/Clroutpin parancsok vannak.
Két kérdésem lenne ezzel kapcsolatban:
Ezek a portkapcsolgatások mintegy függetlenek az UCCNC programtól? Mert a bekapcsolt portokat az E-stop gomb sem állítja vissza alapba. (én naiv azt hittem hogy a program stop is vissza fogja állítani)
A másik meg az M5-el kapcsolatos. A G-kódban hogyan zajlik ez le? Kiadom az M5-öt és a Spindle (esetemben huzalelőtoló) gyorsulástól független rögtön ugrik a következő sorra és végrehajtja, vagy vár a gyorsulás által megszabott ideig a soron következő G-kód végrehajtásával?
Itt nekem nagyon pontos időzítések kellenek, hogy az un. Burnback megfelelő legyen, azaz ne fagyjon bele a huzal vége az olvadékba de ne is égjen vissza az áramátadóba.
Ha textmacro-val kapcsolgatod, akkor néhány 10msec késés lesz, illetve fennáll az a probléma amit már egyszer nemrég kifejtettem, hogy mivel a macro ilyenkor a PC-n fog lefutni, hiszen lehetnek benne olyan utasítások amik az UCCNC más részeit, pl. GUI érintik, illetve mivel text macro, ezért lehet le is kell fordítani ha változott a macro szövege, ezért ilyenkor a szoftver megvárja amíg a mozgásvezérlő végrehajt minden mozgást és utána fut le a macro majd folytatja a következő sorok végrehajtásával, újra elkezdi tölteni a mozgáspuffert.
Az M10/M11-nél ez a probléma nem áll fenn, egyrészt mert nem szöveges macro, másrészt, mert úgy van megcsinálva, hogy a mozgáspufferbe fűzi be a szoftver ezeket az utasításokat a mozgások közé, vagyis nem kell a programnak várnia a mozgásvezérlőre, hogy végezzen a mozgásokkal és emiatt nincsen késés.
Most nem találom a másik fórumon, de volt ilyen kérés, és ha jól emlékszem, akkor talán a következő teszt verzióban már benne is lesz. Az M10-zel ellentétben nem PWM, csak kétállású. Esetleg ha erre jár, akkor Balázs tud további részleteket írni.
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.
2018-02-15 18:19:54
)
