UCCNC vezérlő program

[svejk]

Köszi!

[svejk]

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...

[zt2c4wh9]

Szia Svejk,

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.

[svejk]

Köszi a választ!

Itt most esetemben megoldás lett a köztes S érték beszúrás, mert akkor épp ott nincs mozgás.
De a későbbiekben esetleg gondot okozhat.

[svejk]

Hopsz, várjunk csak!!!

Lehet, hogy ezért nincs nekem szinkron mozgásom 3 lineáris és két forgó tengely együttes mozgatásakor?

A végpontokba mindig pontosan áll be de a köztes mozgás eltér az elvárt pályától.

Eddig annak tudtam be, hogy azért van ez, mert a forgó tengelyek is lineáris interpolációval dolgoznak.
De akkor ennek utána kell nézni...

[zt2c4wh9]

Szia Svejk,

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.

[svejk]

Okszi, közben ki is próbáltam nem ez okozza a pályakövetési hibát, hanem majdnem biztos az interpoláció.

Nem kell megijedni normál gépnél nincs ilyen probléma, csak az én speciális esetemben.

[zt2c4wh9]

A köztes pálya is pontos kell legyen.

Ha mondjuk programozol egy

G0 X0 Y0 Z0 A0 B0 C0

utána pedig egy

G0 X1 Y1 Z1 A1 B1 C1

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.

[Béni]

Egy ilyen példabeli vegyes interpolációnál hogyan van értelmezve az előtolás?
Elérhető, hogy a programozott előtolást jól közelítse a valós?

[zt2c4wh9]

Milyen példáról van szó?

[zt2c4wh9]

Egy egyszerű példá mondjuk:

G64
G1 X0 Y0 F100
X10
Y10

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.

[8rruwvg0k]

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?

[Miki2]

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.

[kaqkk007]

És ha én akarok (igen akarok!) egy maró és egy lézer gépet is építeni , sőt plazmavágó is tervben van akkor vegyek két licenszet ??[#love11]

[Miki2]

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.