Lézervezérlők működési modelljei

1 · A három működési modell

A felosztás nem önkényes. A három modell mögött három különböző mozgatástechnológia áll — és mindegyik más kommunikációs megoldást igényel a számítógép és a vezérlő között.

               Lézervezérlők

                     │
      ┌──────────────┼──────────────┐
      │              │              │

 G-code stream   Feladat alapú  Lista alapú
  (stream)          (job)        (command list)

      │              │              │

   GRBL            Ruida          JCZ
   grblHAL         Trocen         BJJCZ
   FluidNC                        EZCAD

2 · G-code stream alapú vezérlők

Ide tartozik: GRBL · grblHAL · FluidNC

Működési elv

A számítógép folyamatosan küldi a mozgásparancsokat a vezérlőnek. A vezérlő sorban feldolgozza őket, és a motorokat ennek megfelelően mozgatja. A kommunikáció a munka teljes ideje alatt fennmarad — ha a kapcsolat megszakad, a munka leáll.

G0 X0 Y0
G1 X50 Y0 F3000
G1 X50 Y50
M3 S1000

Adatfolyam

Tipikus felhasználás: Dióda lézerek · CNC marók · Hobbi és félipari gépek

GRBL

A legismertebb nyílt forrású G-code alapú firmware. Eredetileg Arduino platformra készült. Feladata a G-code értelmezése és a STEP/DIR jelek előállítása a motorvezérlők számára. Maximális PWM frekvenciája kb. ~1 kHz — ez alacsony sebességű, alacsony DPI-s munkáknál elegendő.

grblHAL

A GRBL modern továbbfejlesztése hardveres absztrakciós réteggel (HAL). A platform natív timer perifériáit használja — ennek eredménye 5–50 kHz stabil PWM, platformtól függően. Több tengelyt, Ethernet kapcsolatot és számos ipari funkciót támogat.

FluidNC

ESP32 alapú vezérlőrendszer. G-code stream alapú működési modell, WiFi kapcsolattal, webes kezelőfelülettel és SD-kártyás futtatással. Működési szempontból G-code stream alapú vezérlő.

3 · Feladat alapú vezérlők

Ide tartozik: Ruida · Trocen

Működési elv

A számítógép nem folyamatos mozgásparancsokat küld. A teljes munkát előre elkészíti — egy saját bináris formátumban — és feltölti a vezérlő memóriájába. A vezérlő ezután önállóan hajtja végre a feladatot, a számítógép közreműködése nélkül.

Tipikus felhasználás: CO₂ lézerek · Gyártó rendszerek · Sorozatgyártás

Ruida

A legelterjedtebb CO₂ lézervezérlő család. A teljes munkát előre kapja meg és helyben hajtja végre. A vezérlő a futtatás alatt önállóan dolgozik. Hardveres alapja DSP + FPGA architektúra — ez biztosítja az önálló, determinisztikus feladatvégrehajtást és a precíz trajektóriaszámítást.

Megjegyzés: a Ruida saját galvo vezérlő kártyát is gyárt (RDM4024G-PCI sorozat), amely szintén DSP + FPGA alapú, és ipari kamerával kombinálható. Az anyag főként a CO₂ vonal (RDC sorozat) architektúráját tárgyalja.

Trocen

Működési elve nagyon hasonló a Ruida rendszeréhez. Szintén feladat alapú vezérlő — a teljes munka előre feltöltésre kerül a vezérlőbe.

4 · Lista alapú vezérlők

Ide tartozik: JCZ · BJJCZ · EZCAD alapú rendszerek

Működési elv

A fiber lézerek többsége nem mechanikus tengelyeket mozgat. A nyalábot galvanométeres tükrök irányítják — két kis tömegű, nagypontosságú tükör, amelyek elektromágnesesen vezéreltek. A tükrök szögének változtatásával a lézernyaláb rendkívül gyorsan pásztázza a munkafelületet.

Ez a mozgatástechnológia teljesen más vezérlési modellt igényel.

A szoftver előre összeállít egy parancslistát:

SetSpeed      500 mm/s
SetFrequency  20 kHz
SetPower      70%
Jump          X=0,  Y=0
Mark          X=50, Y=0
Mark          X=50, Y=50
Mark          X=0,  Y=50
Mark          X=0,  Y=0

Tipikus felhasználás: Fiber lézerek · UV lézerek · MOPA rendszerek · Nagy sebességű galvo rendszerek

Sebesség:          2 000 mm/s
Felbontás:           100 µm  (0.1 mm lépésköz)
Parancs/másodperc:  20 000 db

5 · Összehasonlítás

6 · Miért nem ugyanaz a három rendszer?

A három működési modell nem véletlenül különböző. Mindegyik egy konkrét fizikai problémára adott mérnöki válasz — és a fizikai kényszer határozza meg a vezérlési architektúrát, nem fordítva.

A mozgatástechnológia mint kiindulópont

Mechanikus tengelyek, kis sebesség — dióda lézerek
A fej X és Y irányban mozog, léptetőmotorok hajtják. A sebesség 100–600 mm/s. Ennél a sebességnél a G-code stream működőképes — a számítógép képes elég gyorsan küldeni a parancsokat, a vezérlő képes elég gyorsan feldolgozni őket.

Mechanikus tengelyek, nagy munkaterület — CO₂ lézerek
Az elv ugyanaz, de a munkaterület és a futási idő nagyságrendekkel nagyobb. Egy 60 perces gravírozási munkánál a folyamatos PC kapcsolat megbízhatatlan. A megoldás: a teljes feladatot előre feltölteni, és a vezérlőre bízni a végrehajtást.

Galvanométeres tükrök, extrém sebesség — fiber lézerek
Itt a mozgatástechnológia alapvetően más. Nem a fej mozog — a lézernyaláb mozog, két kis tömegű tükör szögváltoztatásával. Ez lehetővé teszi az 1 000–10 000 mm/s sebességet. De ennél a sebességnél a G-code stream fizikailag működésképtelen. A megoldás: előre lefordított, optimalizált parancslista, amelyet a vezérlő hardveresen hajt végre.

A logikai lánc

Ez a lánc magyarázza, hogy miért nem cserélhetők fel a rendszerek egymással — és miért nem "jobb" vagy "rosszabb" egyik a másiknál. Mindhárom a saját fizikai keretein belül optimális megoldás.

7 · Gyakori tévhitek

8 · LaserBase megközelítés

9 · A vezérlő valójában mit vezérel?

A lézeres világ egyik leggyakoribb félreértése, hogy a felhasználók "lézervezérlőnek" nevezik a GRBL, Ruida vagy JCZ rendszereket.

Ez részben igaz, de műszaki szempontból pontatlan.

Mi történik valójában?

A felhasználó általában a lézert látja a gép legfontosabb elemének. A vezérlő számára azonban a mozgás a lényeg.

A lézer teljesítményének beállítása önmagában egyszerű feladat. Egy PWM vagy analóg jel előállítása elektronikai szempontból triviális.

A nehéz feladat az, hogy a megfelelő teljesítmény a megfelelő pillanatban, a megfelelő pozícióban jelenjen meg.

Ezért a vezérlők legfontosabb része mindig a mozgásvezérlés.

GRBL esetén

Ruida esetén

JCZ esetén

A JCZ rendszer esetében ez még látványosabban megfigyelhető. A vezérlő elsődleges feladata nem a lézer teljesítményének szabályozása, hanem a galvanométeres tükrök pontos pozicionálása.

A lézer valójában periféria

Elsőre furcsán hangozhat, de vezérléstechnikai szempontból a lézer gyakran perifériának tekinthető. A vezérlő valódi feladata minden esetben a következő négy dolog biztosítása:

• a pozíció meghatározása,
• a mozgáspálya követése,
• a sebesség szabályozása,
• az időzítés biztosítása.

A lézer bekapcsolása ehhez képest egyetlen kimeneti művelet.

10 · Miért nem létezik univerzális lézervezérlő?

Gyakran felmerül a kérdés: ha mindegyik lézer végső soron ugyanazt csinálja — anyagot vág, gravíroz vagy jelöl — akkor miért nem létezik egyetlen univerzális vezérlő, amely minden géptípust egyformán kezel?

A válasz egyszerű: mert a különböző lézerrendszerek nem ugyanazt a fizikai problémát oldják meg.

GRBL: mozgást streamel

A GRBL alapú rendszerek folyamatos G-code parancsfolyamot várnak. A számítógép és a vezérlő együtt dolgozik: a PC küldi a parancsokat, a vezérlő pedig valós időben feldolgozza és végrehajtja őket.

Ez a modell egyszerű, nyílt és jól működik dióda lézereknél, ahol a fej mechanikus tengelyeken mozog.

Ruida: feladatot futtat

A Ruida és Trocen jellegű CO₂ vezérlők nem folyamatos G-code streamet várnak. A teljes munkát előre megkapják, saját memóriába töltik, majd PC nélkül hajtják végre.

Itt a vezérlő már nem egyszerű parancsfogadó eszköz, hanem önálló feladatvégrehajtó rendszer. Saját kijelzője, memóriája, kezelőpanelje és belső munkafolyamata van.

JCZ: galvo parancslistát hajt végre

A JCZ alapú fiber rendszerek még ettől is eltérnek. Ezek nem mechanikus tengelyeket mozgatnak, hanem galvanométeres tükröket vezérelnek. A vezérlő előre összeállított parancslistát kap, amelyben a mozgás, a tükörpozíció, a lézeridőzítés és a technológiai paraméterek együtt szerepelnek.

Ez nem egyszerűen gyorsabb változata a G-code vezérlésnek. Teljesen más végrehajtási modell, mert a galvanométeres rendszer időzítési igénye nagyságrendekkel szigorúbb.

Miért nem váltható ki mindhárom egy firmware-rel?

Egy univerzális firmware-nek egyszerre kellene:

• G-code streamet fogadnia és valós időben végrehajtania,
• teljes feladatfájlokat tárolnia és önállóan futtatnia,
• galvanométeres parancslistákat hardveres időzítéssel végrehajtania,
• léptetőmotoros és galvo rendszereket is precízen kezelnie,
• különböző lézertípusok eltérő teljesítmény- és időzítési modelljeit támogatnia.

Ez elméletben lehetségesnek tűnhet, de gyakorlatban nem egyetlen vezérlő lenne, hanem három különböző vezérlési architektúra egy dobozba zsúfolva.

A közös pont nem a firmware, hanem a szoftverréteg

A három rendszer között nem a vezérlő szintjén érdemes egységet keresni, hanem a szoftver felsőbb rétegeiben.

Egy jól felépített lézerszoftver képes lehet ugyanazt a felhasználói logikát — anyag, technika, sebesség, teljesítmény, rétegek, raszter vagy vektor műveletek — különböző vezérlési modellekre lefordítani.

De a kimeneti rétegnek mindig alkalmazkodnia kell a vezérlő architektúrájához:

• GRBL esetén G-code generálás és streamelés,
• Ruida esetén feladatfájl generálás és feltöltés,
• JCZ esetén parancslista építés és végrehajtás.

11 · Hogyan fejlődtek ki a mai lézervezérlők?

A mai lézervezérlők nem egyszerre jelentek meg, és nem egymás közvetlen versenytársainak készültek.

Mindegyik egy adott korszak és egy adott műszaki probléma megoldására született.

A CNC örökség

A történet a CNC gépekkel kezdődött. A marógépek, esztergák és más numerikus vezérlésű gépek mozgásának leírására létrejött a G-code nyelv — első szabványosított változata, az RS-274, 1963-ban jelent meg az Electronic Industries Alliance kiadásában. Ez a protokoll közel 60 évvel ezelőtt született, kizárólag mechanikus szerszámgépek vezérlésére.

CNC gépek
    ↓
G-code (RS-274, 1963)
    ↓
Mozgásvezérlés

A G-code célja egyszerű volt:

• mozgasd a szerszámot,
• adott sebességgel,
• adott koordinátára,
• előre meghatározott pályán.

Ez a modell kiválóan működött mechanikus tengelyekkel, ahol a gépfej vagy a munkadarab mozog. Raszteres képfeldolgozásra — ahol pixelenként kell váltani a lézer teljesítményét — nem tervezték.

A dióda lézerek megjelenése

Amikor a hobbi és félipari dióda lézerek elterjedtek, a legegyszerűbb megoldás az volt, hogy a meglévő CNC világot használták fel.

CNC világ
    ↓
GRBL
    ↓
Dióda lézerek

A lézer itt vezérléstechnikai szempontból gyakorlatilag egy új szerszám.

Maróorsó
vagy
Lézer

A vezérlő számára mindkettő egy kimenet. A különbség az, hogy marásnál az orsó forog, lézernél pedig a teljesítmény PWM jellel szabályozható.

A nagy CO₂ rendszerek problémája

A CO₂ gépeknél a munkaterület és a futási idő jelentősen megnőtt. Megjelentek a nagyobb, ipari jellegű gépek:

• 600×400 mm,
• 900×600 mm,
• 1300×900 mm,
• 1600×1000 mm vagy nagyobb munkaterület.

Egy ilyen gépen egy gravírozási vagy vágási munka akár órákig is tarthat. Ha a vezérlő folyamatos PC kapcsolatot igényelne, egyetlen hálózati kimaradás vagy USB-hiba az egész munkát tönkretehetné.

Ez vezetett a feladat alapú vezérléshez:

Rajz
    ↓
Teljes feladat
    ↓
Vezérlő memória
    ↓
Önálló végrehajtás

Így alakultak ki a Ruida és Trocen jellegű vezérlők. A Ruida Technology-t 2008-ban alapították, és a DSP alapú mozgásvezérlés és lézeralkalmazások fejlesztésére specializálódott. Ezek a vezérlők már nem egyszerű parancsfogadó egységek, hanem önálló feladatvégrehajtó rendszerek saját memóriával, kijelzővel és kezelőpanellel.

A galvanométeres rendszerek megjelenése

A fiber és UV galvo rendszerek teljesen új problémát hoztak. Itt többé nem a fej mozog a munkaterület fölött.

A lézernyaláb mozog.

Mechanikus fej
        ↓
Galvo tükör

A galvanométeres tükrök kis tömegű, nagy sebességű optikai elemek. A lézernyaláb pozícióját a tükörszög változtatásával állítják be, nem mechanikus tengelyek mozgatásával.

Ez a sebességet nagyságrendekkel megemeli:

• mechanikus tengelyeknél tipikusan 100–600 mm/s,
• galvo rendszereknél 1 000–10 000 mm/s.

Ennél a sebességnél a G-code stream modell fizikailag és időzítésileg alkalmatlanná válik. Megjelent a lista alapú vezérlés:

Rajz
    ↓
Parancslista
    ↓
Galvo vezérlő
    ↓
Valós idejű végrehajtás

Így alakult ki a JCZ architektúra és az EZCAD köré épülő vezérlési világ.

A fejlődési lánc

Ez a fejlődési ív segít megérteni, hogy a különböző vezérlők nem egymás hibás vagy fejlettebb változatai. Mindegyik a saját technológiai környezetében logikus és indokolt megoldás.

12 · Hol helyezkednek el a lézerszoftverek?

A következő félreértés általában a szoftverek körül alakul ki. Sokan úgy gondolják, hogy egy lézerszoftver maga a vezérlő.

Ez nem pontos. A LightBurn, a LaserGRBL, az RDWorks, az EZCAD vagy bármely más lézerszoftver nem ugyanaz a réteg, mint maga a hardveres vezérlő.

A LightBurn szerepe

A LightBurn jó példa arra, hogy ugyanaz a felhasználói felület mögött több teljesen eltérő kimeneti modell dolgozhat.

             LightBurn

                  │

      ┌───────────┼───────────┐
      │           │           │

   G-code       RDJob      JCZ API

      │           │           │

    GRBL       Ruida       JCZ

A felhasználó ugyanazt a rajzot látja, ugyanazokat a rétegeket, sebesség- és teljesítménymezőket kezeli. A háttérben azonban a szoftver teljesen más kimenetet állít elő attól függően, milyen vezérlő van kiválasztva.

• GRBL esetén G-code stream készül.
• Ruida esetén RDJob jellegű feladatfájl készül.
• JCZ esetén a rendszer lista/API alapú végrehajtási modellhez illeszkedik.

A vezérlő számára ezek nem felcserélhetők. Egy Ruida vezérlő nem fogad GRBL G-code streamet, egy GRBL firmware nem értelmez Ruida job fájlt, egy JCZ galvo vezérlő pedig nem klasszikus mechanikus tengelyekhez írt G-code alapján működik.

A vezérlő és a szoftver két külön réteg

A különbség röviden:

Ezért félrevezető azt mondani, hogy egy szoftver „ugyanúgy kezeli" a különböző vezérlőket. A felhasználó felé lehet egységes a felület, de a kimeneti réteg vezérlőnként teljesen más.

13 · Hol helyezkedik el a LaserBase?

A legtöbb lézerszoftver vezérlőközpontú gondolkodásból indul ki.

A felhasználó kiválasztja:

• a gépet,
• a vezérlőt,
• a kommunikációs módot,
• majd ezek korlátaihoz alkalmazkodik.

Ez érthető megközelítés, mert a legtöbb lézerszoftver elsődleges feladata az, hogy egy adott vezérlővel kommunikáljon.

Technológia-központú megközelítés

A LaserBase szemlélete ettől eltér. Nem a vezérlőből indul ki, hanem a technológiából.

A folyamat nem így kezdődik:

GRBL
    ↓
Mit tud a gép?

Hanem így:

Anyag
    ↓
Technológia
    ↓
Képfeldolgozás
    ↓
Optimális paraméterek
    ↓
Vezérlőspecifikus kimenet

Ebben a modellben a vezérlő nem a rendszer központja, hanem a végrehajtási réteg egyik lehetséges célpontja.

A LaserBase helye az architektúrában

LaserBase
    ↓
Anyagadatbázis
Technológiai tudás
Képfeldolgozás
    ↓
Végrehajtási réteg
    ↓
GRBL
Ruida
JCZ

A LaserBase nem firmware, nem vezérlő és nem egyszerű fájlküldő program. Magasabb absztrakciós rétegként értelmezhető: a felhasználói szándékot és a technológiai tudást fordítja le az adott vezérlő által végrehajtható formára.

Mit jelent ez a gyakorlatban?

A felhasználó ideális esetben nem abból indul ki, hogy milyen parancsot kell küldeni a vezérlőnek.

Hanem abból, hogy mit szeretne elérni:

• 3 mm nyír rétegelt lemezt szeretnék gravírozni.
• Rozsdamentes acélt szeretnék jelölni.
• Fotót szeretnék gravírozni anodizált alumíniumra.
• Akrilt szeretnék vágni CO₂ lézerrel.
• Fekete-fehér raszterképet szeretnék stabilan reprodukálni.

A rendszer feladata ezután az, hogy:

• azonosítsa az anyagot,
• kiválassza a technológiát,
• meghatározza az optimális paramétereket,
• ellenőrizze a hardver fizikai korlátait,
• elkészítse a megfelelő vezérlőspecifikus kimenetet.

Miért fontos ez?

Ha egy szoftver kizárólag vezérlőközpontú, akkor a felhasználónak kell alkalmazkodnia a vezérlő gondolkodásmódjához.

Ha viszont technológia-központú, akkor a szoftver vállalja át a fordítást a felhasználói cél és a vezérlőspecifikus végrehajtás között.

14 · Záró összegzés

A lézervezérlők fejlődése nem véletlenszerű. A különböző architektúrák különböző fizikai problémák megoldására születtek.

• GRBL → G-code stream alapú vezérlés mechanikus tengelyekhez.
• Ruida / Trocen → feladat alapú vezérlés nagyobb, önálló CO₂ rendszerekhez.
• JCZ → lista alapú vezérlés nagy sebességű galvo rendszerekhez.

Ezek nem egymás jobb vagy rosszabb változatai. Eltérő célokra optimalizált rendszerek.

A modern lézerszoftverek feladata nem az, hogy minden vezérlőt ugyanazzal a módszerrel kezeljenek. Ez műszakilag félrevezető lenne. A valódi feladat az, hogy ugyanazt a technológiai tudást különböző vezérlési modellekre tudják lefordítani.

Ez az a szemlélet, amely lehetővé teszi, hogy ugyanaz a tudás dióda, CO₂ és fiber rendszereken is alkalmazható legyen — miközben a háttérben minden vezérlő a saját működési modelljének megfelelő kimenetet kapja.

15 · Vezérlési rétegek és rendszerarchitektúra

A lézeres rendszer nem egyetlen egység — hanem egymásra épülő rétegek lánca. A felhasználó a legfelső réteggel érintkezik, a fizikai végrehajtás a legalsón történik.

A félreértések többsége abból ered, hogy a rétegek összemosódnak — például a szoftvert vezérlőnek, vagy a vezérlőt magának a lézernek tekintik.

CPU · DSP · FPGA — mi mire való?

A modern lézervezérlők hardveres architektúrája nem egységes — különböző feldolgozóegységek különböző feladatokat látnak el:

A GRBL alapú rendszerek CPU-n futnak — ez elegendő mechanikus tengelyvezérléshez alacsony-közepes sebességen. A Ruida DSP+FPGA kombinációja teszi lehetővé az önálló, PC-független feladatvégrehajtást és a precíz pályakövetést. A galvo rendszereknél az FPGA vagy dedikált hardver biztosítja azt a µs alatti időzítési pontosságot, amit a galvo pozicionálás megkövetel.

JCZ vezérlő  →  XY2-100  →  Galvo egység  →  Tükörszög  →  Nyalábpozíció

— Felhasznált források

16 · Fogalomtár

17 · JCZ és EZCAD architektúra szétválasztása

Az egyik leggyakoribb félreértés a fiber lézeres közösségben a „JCZ" és az „EZCAD" fogalmak összekeverése. A kettő valójában teljesen különböző réteget képvisel: az egyik hardver, a másik szoftver — és ez a szétválasztás a rendszer megértésének alapja.

A JCZ hardver kártyacsalád

A BJJCZ (Beijing JCZ Technology Co., Ltd.) a galvo vezérlő kártyák egyik legjelentősebb gyártója. A kártyacsalád fejlődése jól tükrözi a galvo vezérlés evolúcióját — a korai PCI alapú kártyáktól az önálló USB- és Ethernet-alapú rendszerekig:

Az EZCAD szoftvercsalád

Az EZCAD a JCZ hardver kártyákhoz készült PC-oldali szoftver. A két fő verzió különböző kártyagenerációkat céloz meg, és architektúrájuk alapvetően eltér:

A réteghatár és az integrációs lehetőség

A JCZ hardver és az EZCAD szoftver között két lehetséges integrációs pont létezik, amelyek eltérő megbízhatóságot és komplexitást képviselnek:

Az EZCAD3 TCP/IP API-ja a legmegbízhatóbb integrációs útvonal: dokumentált, a gyártó által karbantartott, és lehetővé teszi, hogy külső alkalmazások — köztük a LightBurn 1.4+ galvo módja — közvetlenül vezéreljék az EZCAD3-at. Ennek feltétele az EZCAD3 telepítése és futtatása a gazdaszámítógépen.

A második útvonal a közvetlen USB protokoll — ez közösségi visszafejtésen alapul (EduTech Wiki LMCV4-FIBER-M RE projekt). Ez az EZCAD nélküli, natív vezérlést teszi lehetővé, de jogi és stabilitási szempontból kockázatosabb, és a protokoll változásait követni kell.

18 · DSP / FPGA / CPU szerepkörök részletesen

A vezérlők belső architektúrájának megértése elengedhetetlen ahhoz, hogy tisztán lássuk, miért különbözik a GRBL, a Ruida és a JCZ teljesítménye és képességei. A három alapvető feldolgozóelem — CPU, DSP és FPGA — eltérő feladatokra optimalizált, és különböző vezérlőosztályokban más-más kombinációban jelenik meg.

CPU — általános célú processzor

A hagyományos, általános célú processzor rugalmas és könnyen programozható — de nem optimalizált valós idejű, µs pontosságú I/O feladatokra. Az operációs rendszer ütemezője, az interrupt-kezelés és a cache miss latenciát visz a rendszerbe, ami determinisztikus időzítést igénylő alkalmazásokban problémát jelent.

A CPU alapú rendszerek előnye a rugalmasság, az alacsony ár és a nyílt forrású szoftverkörnyezet — hátrányuk, hogy a léptetési frekvencia és a valós idejű teljesítmény korlátozott. A GRBL a legkiforrottabb CPU alapú firmware, de tervezési korlátai (lineáris ring buffer, 8 bites Arduino eredet) közel két évtizede változatlanok, és a modern platformokon csak részben hasznosíthatók.

DSP — digitális jelfeldolgozó processzor

A DSP (Digital Signal Processor) kifejezetten matematikai műveletek — szorzás, összeadás, szűrés — nagy sebességű végrehajtására optimalizált processzor. Hardveres szorzó-akkumulátor egységgel (MAC unit), dedikált adatbusszal és ciklikus pufferes memóriakezeléssel rendelkezik. Ezek teszik alkalmassá a mozgástrajektóriák és lézerteljesítmény-görbék valós idejű számítására.

A Ruida RDC sorozatú vezérlői Texas Instruments DSP chipeket alkalmaznak — valószínűleg a C2000 valós idejű vezérlőcsaládból. A DSP feladatai a Ruida rendszerben:

• A feladatfájl (.rd formátum) értelmezése és szegmentálása
• A mozgáspálya számítása — gyorsulási és lassulási profilok, körív-közelítés
• A lézerteljesítmény-görbe számítása menet közben, sebességfüggően (Power Scale funkció)
• A kommunikáció kezelése: Ethernet, USB, RS-232 csatornákon
• A kezelőpanel és a kijelző vezérlése

A DSP önmaga — bármennyire gyors is — nem képes µs alatti, determinisztikus I/O generálásra. Ehhez az FPGA szükséges.

FPGA — programozható logikai áramkör

Az FPGA (Field-Programmable Gate Array) nem processzor a hagyományos értelemben — hanem programozható hardver. Az FPGA-n belül logikai kapukat és flip-flopokat kötnek össze, amelyek párhuzamosan és valós időben hajtanak végre hardveres funkciókat, bármilyen szoftveres overhead nélkül.

Az FPGA szerepköre különböző lézervezérlőkben:

A DSP + FPGA kombináció ereje

A Ruida és JCZ rendszerek mindkét egységet alkalmazzák — és ez nem véletlen. A kettő egymást kiegészítő, komplementer feladatokat lát el:

DSP                              FPGA
─────────────────────────────    ─────────────────────────────
Feladatértelmezés                STEP/DIR impulzus generálás
Trajektória számítás             XY2-100 adatfolyam előállítás
Lézerteljesítmény-görbe          PWM moduláció
Kommunikációkezelés              Enkóder feldolgozás
Felhasználói felület             I/O latching
─────────────────────────────    ─────────────────────────────
Rugalmas, programozható          Determinisztikus, hardveres
µs latencia                      ns latencia

A DSP határozza meg, mit kell csinálni. Az FPGA végrehajtja azt pontosan, mikor szükséges — nanoszekundumos pontossággal, a szoftverből soha nem elérhető determinizmussal.

Ez az architektúra teszi lehetővé, hogy a Ruida önállóan, PC nélkül hajtson végre akár egyórás gravírozási munkát stabilan és reprodukálhatóan — és a JCZ vezérlő 100 000 pozíciófrissítést küldjön másodpercenként a galvo egységnek, megszakítás nélkül.

19 · XY2-100 részletes működése

Az XY2-100 protokoll a digitális galvanométer scanner rendszerek szabványos ipari kommunikációs interfésze. Első kidolgozása a Cambridge Technology (ma Novanta) nevéhez fűződik, és azóta az iparági de facto szabvánnyá vált — minden jelentős galvo gyártó (Scanlab, Cambridge, II-VI, Sino-Galvo) implementálja. A korábbi fejezetek röviden érintették a protokollt — ebben a fejezetben a teljes technikai részletezés következik.

Fizikai réteg

Az XY2-100 elektromosan az RS-422 differenciális jel szabványt követi. Ez a fizikai réteg biztosítja a zajtűrést és a hosszabb kábelen is megbízható kommunikációt ipari környezetben:

• Differenciális vonalpár: minden jel +/− párban fut, amely a közös módusú elektromágneses zavarokat szűri
• Órajel (CLK): 2 MHz szimmetrikus négyszögjel — ez határozza meg az adatátviteli sebességet
• Adatvezeték (MOSI / DATA): a vezérlőtől a galvo felé haladó pozícióadat és vezérlőbitok
• Visszacsatolás (MISO / STATUS): a galvo által visszaküldött állapotinformáció (opcionális, implementáció-függő)
• Maximális kábelhossz: tipikusan 5–10 m, az árnyékolástól és a jelminőségtől függően

Keretszerkezet és adatformátum

Az XY2-100 minden kommunikációs keretet 20 bitből épít fel, szinkronban a 2 MHz-es órajellel:

20 bit × (1 / 2 MHz) = 10 µs / keret
→ 1 s / 10 µs = 100 000 pozíciófrissítés másodpercenként

Egyetlen keret bitjeinek felépítése:

A 16 bites pozícióadat 65 536 lépést fed le a teljes szkennelési mezőn belül. Egy tipikus 110 mm × 110 mm-es szkennelési mezőnél ez a lépéssűrűség:

110 mm / 65 536 lépés ≈ 1,68 µm / lépés

Ez a felbontás jóval finomabb, mint a lézer fókuszfoltjának mérete (tipikusan 20–50 µm 1064 nm-en, 163 mm F-Theta lencsével) — tehát az XY2-100 protokoll nem a felbontás szűk keresztmetszete, hanem az optika és a fókuszfolt mérete.

Az XY2-100E kiterjesztés

Egyes prémium galvo rendszerek az XY2-100 kiterjesztett változatát, az XY2-100E protokollt alkalmazzák. Ez 20 bites pozícióadatot biztosít (1 048 576 lépés), ami a felbontást megközelítőleg 16-szorosára növeli az alap protokollhoz képest. Ez különösen fontos nagy munkaterületű, nagy pontosságú alkalmazásokban — például 300 × 300 mm-es munkamezőn, ahol az alap 16 bit már nem elegendő precizitású.

Időzítési modell és következmények

A galvo szervórendszer a beérkező pozícióadatot folyamatosan, valós időben követi — nem vár a „pozíció elérve" visszajelzésre. Ez azt jelenti, hogy a vezérlőnek pontosan kell ütemezni a pozícióadatok küldését, hogy a galvo tükör a kívánt sebességgel és pályán mozogjon.

Lézer szinkronizáció az XY2-100 mellé

Az XY2-100 maga nem tartalmaz lézer vezérlőjelet — a lézert egy külön csatorna vezérli (tipikusan TTL vagy analóg jel a lézer modulátorához). A JCZ vezérlő feladata, hogy a lézer be/ki jelzést nanoszekundumos pontossággal szinkronizálja a pozícióadattal — ezt az FPGA valósítja meg hardveres szinten.

A szinkronizációs késleltetési paraméterek az EZCAD szoftverben állíthatók:

• Laser On Delay: a galvo elindulása és a lézer bekapcsolása közötti idő
• Laser Off Delay: a mozgás végpontján a lézer kikapcsolásának késleltetése
• Polygon Delay: irányváltásoknál alkalmazott extra várakozási idő

Helytelen szinkronizáció esetén a kontúr elejein és végein elmosódás, törés vagy felesleges jelölés jelenik meg. Ezek a paraméterek minden gépen egyedileg kalibrálódnak a szerviz beállítás során.

20 · Galvanométeres rendszerek fizikája

A galvanométeres tükörvezérlő rendszer megértéséhez érdemes visszamenni az alapvető fizikáig. A galvo mozgató nem egy motor a szokásos értelemben — hanem egy pontosan vezérelt elektromágneses aktuátor, amely a tükörszöget a bevitt áram arányában változtatja. Ez az elv teszi lehetővé a rendkívüli sebességet és ismételhetőséget.

Az elektromágneses aktuátor elve

A galvanométer alapelve a Lorentz-erő: egy áramvezető tekercs mágneses térben forgó nyomatékot kap. A galvo esetén:

• A tekercs a rotor tengelyen helyezkedik el — ez hordozza a tükröt
• A permanens mágneses tér a ház részeként rögzített
• A bevitt áram iránya és nagysága határozza meg a szögelfordulást
• Egy visszatérő erő (mechanikus rugó vagy elektromos negatív visszacsatolás) a nullapozícióba húzza vissza

A szög és az áram közötti kapcsolat ideálisan lineáris — ezt a zárt hurkú szervórendszer biztosítja a valóságban, kompenzálva a nemlinearitásokat és a mechanikai zavaróerőket.

Tükörméretek és tehetetlenség

A galvo rendszer gyorsasága közvetlenül összefügg a tükör méretével és tömegével. Kisebb tükör = kisebb tehetetlenségi nyomaték = gyorsabb mozgás és rövidebb beállási idő. Ez az összefüggés kulcsfontosságú a rendszertervezésben:

Szervórendszer, sávszélesség és beállási idő

A galvo szervórendszer zárt hurokban működik: a tükörszöget egy pozíciószenzor (kapacitív vagy optikai enkóder) méri, és a szervóerősítő a mért és a kívánt szög különbségének arányában állítja be az áramot. Ez a PID szabályozás tipikusan 1–3 kHz mechanikai sávszélességet ér el — ami azt jelenti, hogy 1–3 kHz-nél gyorsabb változásokat a galvo már nem tud követni.

A „beállási idő" (settling time) a kritikus paraméter: ez az a minimális idő, amely szükséges ahhoz, hogy a galvo a kívánt pozícióba mozogjon és ott az előírt pontossági határon belül stabilizálódjon — mielőtt a jelölés megkezdődik.

A szkennelési mező és az optikai torzítás

A galvo tükörpár (X és Y tengely) két egymásra merőleges szög-szabadságfokot biztosít. A két tükör azonban nem pontosan ugyanazon a ponton helyezkedik el — köztük néhány milliméter tengelytávolság (offset) van. Ez optikai torzítást (ún. párna- vagy hordószerű torzítást) okoz, különösen a munkamező sarkainál és széleinél.

A torzítás mértéke nő:

• nagyobb szkennerszögnél — azaz nagyobb munkaterületnél azonos fókusztávolság mellett,
• kisebb fókusztávolságú F-Theta optikánál,
• a két galvo tükör közötti nagyobb tengelytávolságnál.

Ennek kezelésére szolgálnak a korrekciós táblák — erről részletesen a következő fejezetben olvasható.

Tükörbevonatok és hullámhossz-kompatibilitás

A galvo tükör bevonatát a lézer hullámhosszához kell igazítani — a helytelen bevonat visszaverődési veszteséget, melegedést és bevonat-sérülést okoz nagy teljesítményen:

Nagy teljesítményű rendszerekben (50 W, 100 W fiber) a tükörbevonat minősége és tisztasága kritikus. Egy koszos vagy sérült tükörbevonat lokálisan abszorbeálhatja a lézert, ami termikus károsodáshoz, pontosságveszteséghez és a tükör teljes meghibásodásához vezet. Rendszeres tisztítás és állapotkövetés kötelező.

21 · F-Theta optikák

A galvo rendszer optikai kialakításának egyik legfontosabb és leggyakrabban félreértett eleme az F-Theta objektív. Megértéséhez érdemes szembeállítani egy hagyományos fókuszáló lencsével — és megérteni, miért nem csereszabatos a kettő galvo alkalmazásban.

A hagyományos lencse problémája galvo rendszerben

Egy egyszerű konvergens lencse (plano-konvex, aszferoid) a bejövő párhuzamos nyalábot a fókuszpontba gyűjti — ez a pont a lencse optikai tengelyén, az f fókusztávolságra helyezkedik el. Ha a galvo tükör megtéríti a nyalábot, a lencse ugyan fókuszál, de a fókuszpont egy gömbfelületen mozog, nem sík felületen.

Matematikailag: ha a galvo szöge θ, egy standard lencse esetén a munkafelületre vetített pozíció:

y = f · tan(θ)

Ez nem lineáris nagy szögeknél — a munkamező sarkain a folt „kiesik" a fókuszból, elmosódik, és a névleges pozíciótól eltér. Ez mind a jelölési minőséget, mind a geometriai pontosságot rontja.

Az F-Theta lencse megoldása

Az F-Theta lencse speciálisan tervezett, összetett optikai rendszer, amelynek két egyidejű célja van:

1. Lapos mező fókuszálás (flat-field focusing): a fókuszpont sík felületen marad az egész munkaterületen, nem gömbfelületen
2. Lineáris leképezés: a galvo szögváltozása lineárisan arányos a munkafelületi elmozdulással

y = f · θ    (F-Theta összefüggés)

A „lineáris leképezés" különösen fontos: a JCZ / EZCAD szoftver egyenesen arányos összefüggést feltételez a galvo szög és a munkaterületi koordináta között. Ha ez a feltétel nem teljesül — mert nem megfelelő optikát használnak —, a jelölt alakzatok torzulnak, és a korrekciós tábla sem tudja teljes mértékben kompenzálni a hibát.

F-Theta lencse specifikációk és munkaterületek

Telecentrikus F-Theta lencse

A standard F-Theta lencse esetén a nyaláb a munkaterület szélein kissé ferde szögben érkezik a felületre. Legtöbb alkalmazásban ez elhanyagolható — de bizonyos esetekben (mély gravírozás, oldalsó falak pontos kialakítása, pontossági kritikájú fúrás, párhuzamos nyalábot igénylő folyamatok) szükséges, hogy a nyaláb mindig pontosan merőleges legyen a munkafelületre.

Erre való a telecentrikus F-Theta lencse, ahol kiegészítő optikai elemek biztosítják, hogy a kimenő nyaláb az optikai tengellyel párhuzamos maradjon az egész munkamezőn — függetlenül a galvo szögétől. Ez drágább és optikailag bonyolultabb, de néhány kritikus alkalmazásban nélkülözhetetlen.

Fókuszfolt méretének meghatározása

A fókuszfolt átmérőjét (d) a diffrakcióhatár közelítéssel lehet becsülni:

d_min ≈ (4 · λ · f) / (π · D)

ahol λ a lézer hullámhossza, f az F-Theta lencse fókusztávolsága, D a bejövő nyaláb átmérője. Ebből következik: kisebb folthoz vagy kisebb fókusztávolság, vagy nagyobb nyaláb szükséges — de a kisebb fókusztávolság kisebb munkaterületet jelent. Ez az alaptörvény minden galvo rendszertervező számára kompromisszumot jelent a foltméret és a munkaterület között.

22 · Korrekciós táblák és COR fájlok

Még a legjobb F-Theta optikával és a legpontosabb galvo rendszerrel sem érhető el tökéletes geometriai hűség kalibrálás nélkül. A mechanikai összeszereléstől, az optikai eltérésektől és a galvo nemlinearitástól adódó torzítások korrekciós táblákkal kompenzálhatók.

A torzítás forrásai

• Galvo nemlinearitás: a szervó nem tökéletesen lineáris a teljes szögtartományon
• Tengelyek nem merőlegessége: az X és Y galvo tengely nem pontosan 90°-ra áll egymáshoz képest
• Optikai torzítás: az F-Theta lencse sem tökéletesen ideális matematikai modell
• Szerelési hiba: a galvo tengelye nem pontosan merőleges az optikai tengelyre
• Hőmérséklet-függés: a mechanikai elemek hőmérsékleti tágulása kisebb munkamező-változást okoz

Ezek a hibák együttesen jellemzően néhány tized mm – 1 mm torzítást okoznak a munkamező széleinél, ami precíziós alkalmazásokban elfogadhatatlan.

A COR fájl felépítése

Az EZCAD szoftver által használt korrekciós fájl (.cor kiterjesztés) egy kétdimenziós rácsot tartalmaz korrekciós vektorokkal. A rács tipikusan 65 × 65 vagy 128 × 128 pontból áll, és az egész munkamezőt egyenletesen lefedi.

Minden rácsponthoz egy (Δx, Δy) korrekciós vektor tartozik — ez mondja meg, hogy az adott névleges koordinátát a galvónak mennyivel kell „eltolnia" a tényleges célpozíció eléréséhez. A két rácsponti korrekció között a szoftver bilineáris interpolációval számít korrekciót tetszőleges közbülső pozícióhoz.

Korrekciós korlátok

• Nem kompenzál fókusztávolság-változást (z-irányú hibát) — ehhez dinamikus fókuszvezérlés (3D galvo rendszer) szükséges
• A korrekció pontossága korlátozott a mérési pontosság által — durva mérés, durva korrekció
• Nagy torzítás esetén a bilineáris interpoláció nem elegendő — sűrűbb rácsméret vagy magasabb rendű interpoláció szükséges
• A kalibrálás egy adott fókusztávolságra (munkamagasságra) érvényes — más magasságon a torzítás eltér
• A hőmérséklet-változással járó mechanikai tágulás kis mértékű driftet okoz a munkamenet során

A COR fájl és a rétegszétválasztás kapcsolata

A COR fájl kezelése teljes egészében szoftver-oldali feladat — a JCZ kártya nem tud a korrkcióról. Az EZCAD alkalmazza a korrekciót a koordinátákra, mielőtt azokat a kártyának elküldi. Ez azt is jelenti, hogy ha egy külső szoftver (LightBurn, LaserBase, vagy saját alkalmazás) közvetlenül a JCZ kártyát vezérli az EZCAD megkerülésével, saját maga kell, hogy implementálja és alkalmazza a korrekciós tábla logikáját — ez a közvetlen JCZ integráció egyik legkomolyabb technikai kihívása.

23 · LightBurn backend architektúra

A LightBurn a lézeres közösség egyik legelterjedtebb szoftvere — és jó illusztrációja annak, hogyan lehet ugyanazt a felhasználói felületet több teljesen különböző vezérlési modell fölé építeni.

A LightBurn rétegmodell

GRBL driver a LightBurnban

A GRBL driver a LightBurnban a legegyszerűbb és legátláthatóbb — a G-code szabvány publikus:

• Vektoros rétegek → G-code mozgásparancsok (G0 pozicionálás, G1 egyenes, G2/G3 körív)
• Képek → soronkénti szkennelés, M3 S{érték} formátumban pixelenként váltva a teljesítményt
• Cluster mód → G1 Y-0.1S0.875:0:0:0.5:0.875 formátum, ahol egyszerre több pixel S-értéke kerül elküldésre
• Valós idejű streaming: a LightBurn maga kezeli a puffer feltöltését, az OK visszajelzések figyelésével ütemezve a küldést

Ruida driver a LightBurnban

A Ruida driver összetettebb — a Ruida .rd formátuma nem publikus, közösségi visszafejtésen alapul:

• A LightBurn bináris job fájlt generál, amelyet Ethernet-en (UDP protokollon) vagy USB-n tölt fel a vezérlőre
• A formátum tartalmazza: rétegparamétereket, mozgásparancsokat, lézerteljesítmény-görbéket, saroklassítási beállításokat
• A LightBurn elvégzi a Ruida-specifikus optimalizációkat: Power Scale sebességfüggő teljesítménykorrekció, Corner Power beállítás

Galvo / JCZ driver — LightBurn 1.4+ verzió

A LightBurn galvo és fiber lézeres támogatása az 1.4-es verzióban jelent meg, és azóta aktívan fejlődik:

• EZCAD3 TCP/IP API-n keresztül kommunikál — ez a legmegbízhatóbb és a gyártó által támogatott útvonal
• Alternatívaként közvetlen LMC4 kártya kommunikáció is lehetséges (LightBurn beépített LMC driver)
• Korrekciós tábla kezelés: a LightBurn saját korrekciót tud alkalmazni, vagy delegálja az EZCAD3-nak
• MOPA paraméterek (impulzusszélesség, frekvencia) galvo réteg paraméterként kezelhetők

Az eszközabsztrakció korlátai

A LightBurn device rétege erős absztrakciót biztosít — de az absztrakció ára az, hogy a vezérlőspecifikus lehetőségek egy részét nem lehet teljes mértékben kihasználni az egységes felhasználói felületen keresztül:

• A Ruida Power Corner beállítása a LightBurnban elérhető, de más vezérlőkön nem értelmezhető
• A JCZ galvo-specifikus paraméterek (jump speed, mark delay, polygon delay) megjelennek a galvo rétegparaméterekben, de GRBL kontextusban nem alkalmazhatók
• A cluster mód G-code opció GRBL-re vonatkozik, Ruida vagy JCZ esetén más mechanizmus érvényesül

Ez az oka annak, hogy a „LightBurn mindent egyformán kezel" állítás igaz felhasználói szinten — de egyes szakmai alkalmazásokban a natív szoftver (EZCAD3, RDWorks) mélyebb hozzáférést biztosít.

24 · LaserBase többvezérlős modell

A LaserBase architektúrájának egyik meghatározó célkitűzése a technológia-elsőbbségű, többvezérlős modell megvalósítása. Ez azt jelenti, hogy a felhasználói szándék — anyag, technika, kívánt eredmény — nem a vezérlő típusához kötött. Ugyanaz a technológiai tudás fordítódik le vezérlőspecifikus kimenetre, attól függően, milyen hardver van csatlakoztatva.

A technológia-elsőbbségű megközelítés részletesen

A hagyományos lézerszoftverekben a felhasználó a gép és a vezérlő köré szervezi a munkáját — a szoftver elsősorban a vezérlővel kommunikál, és a felhasználó ehhez igazítja a paramétereit. A LaserBase modellben a sorrend fordított:

Anyag azonosítása (anyagkönyvtár)
        ↓
Technológia kiválasztása (gravírozás / vágás / jelölés)
        ↓
Képfeldolgozás és optimalizálás
        ↓
Hardver korlátok ellenőrzése (step/mm, PWM, rise/fall time)
        ↓
Vezérlőspecifikus kimenet generálása

Ebben a modellben a „vezérlőspecifikus kimenet generálása" az utolsó lépés — nem az első. A rendszer a felhasználói szándékból indul ki, és az adott vezérlő architektúrájához igazítja a végső kimenetet.

A kimenet-adapter réteg

A LaserBase belső architektúrájában a kimenet-adapter réteg felelős azért, hogy ugyanaz a feldolgozási eredmény különböző vezérlőformátumra kerüljön lefordításra:

GRBL-specifikus LaserBase optimalizációk

A LaserBase jelenlegi GRBL integrációjában számos vezérlőspecifikus optimalizáció érvényesül, amelyek kizárólag a GRBL és a léptetőmotoros rendszerek architektúrájának ismeretén alapulnak:

Step/mm alapú raszterillesztés: A LaserBase a gép step/mm értékéből kiszámolja a fizikailag lehetséges DPI értékeket — azokat a felbontásokat, amelyek egész számú léptetési egységre esnek. Ezekhez igazítja a rasztert, elkerülve a sub-pixel pozicionálási hibát, amely a step/mm és a DPI inkompatibilitásából ered.

f_img frekvencia ellenőrzés: Minden sebesség–DPI kombináció előtt a LaserBase kiszámolja a szükséges képmodulációs frekvenciát (f_img = v × DPI / 1524), és összehasonlítja a firmware és a lézermodul fizikai korlátaival. Ha a kombináció a hardver határán kívül esik, a rendszer figyelmeztet — megelőzve a puffer éhezést és a kép minőségromlást.

Cluster mód kimenet: Raszteres gravírozásnál a LaserBase cluster módú G-code-ot generál — egy parancsban több pixel S-értékét küldi, drasztikusan csökkentve a planner terhelést, ami különösen nagy sebesség és magas DPI esetén kritikus.

Jövőbeli irányok: Ruida és JCZ integráció

A Ruida integráció a közösség által visszafejtett .rd formátumon alapul — a LightBurn bizonyította, hogy ez megvalósítható és stabilan működtethető. A LaserBase célja, hogy a technológiai tudásbázis (anyagadatbázis, paraméteroptimalizálás, képfeldolgozás) CO₂ Ruida rendszereken is hozzáférhető legyen.

A JCZ / BJJCZ integrációhoz az EZCAD3 TCP/IP API a legígéretesebb útvonal. Ez dokumentált, gyártó által támogatott, és lehetővé teszi, hogy a LaserBase ne a JCZ kártyával közvetlen USB-n, hanem az EZCAD3-mal kommunikáljon TCP/IP-n. Ennek feltétele az EZCAD3 futtatása a gazdaszámítógépen — ami tipikusan fiber galvo gépeken adott.

25 · MOPA technológia

A MOPA (Master Oscillator Power Amplifier — Mesteroszcillátor Teljesítményerősítő) egy kétlépéses fiber lézeres architektúra, amely alapvetően különbözik a hagyományos Q-kapcsolt (Q-switched) fiber lézertől. A különbség nem pusztán teljesítménybeli — az impulzusparaméterek szabad szabályozhatósága teszi a MOPA-t alkalmassá olyan alkalmazásokra, amelyek Q-kapcsolt forrással nem valósíthatók meg azonos rugalmassággal.

MOPA vs. Q-kapcsolt fiber lézer

A MOPA működési elve

A MOPA architektúra két fő komponensből épül fel:

1. Mesteroszcillátor (seed lézer): alacsony teljesítményű, de pontosan vezérelt lézerimpulzusokat generál. Az impulzusszélesség, a frekvencia és az impulzus időbeli profilja itt kerül meghatározásra — a JCZ vezérlő által küldött elektromos paramétervezérlő jel alapján. A seed lézer tipikusan néhány mW teljesítményű diódalézer vagy félvezető lézer.
2. Teljesítményerősítő (YDFA — Ytterbium Doped Fiber Amplifier): az Yb-dópolt optikai fiber erősítő felerősíti a seed impulzusokat a kívánt kimeneti teljesítményre (pl. 20 W, 50 W, 100 W). Az erősítő nem változtatja meg az impulzus időbeli profilját — csak az energiaszintet emeli.

Ez a kétlépéses architektúra lehetővé teszi, hogy az impulzusparaméterek (szélesség, frekvencia) és a kimeneti teljesítmény egymástól viszonylag független tartományban változzon — szemben a Q-kapcsolt rendszerrel, ahol a kavitás fizikája rögzíti a lehetséges impulzusszélességet.

Impulzusszélesség és anyaghatás

A MOPA legnagyobb előnye az impulzusszélesség-szabályozás, amely az anyag–lézer kölcsönhatás jellegét és mélységét alapvetően meghatározza:

Színes jelölés rozsdamentes acélon — MOPA-specifikus alkalmazás

A MOPA egyik leglátványosabb és legjelentősebb alkalmazása a rozsdamentes acél színes jelölése. A mechanizmus az oxidációs réteg vastagságán alapul: különböző vastagságú Cr₂O₃ / Fe₂O₃ vegyes oxidrétegek különböző hullámhosszakat vernek vissza — ez a vékony réteg interferenciája, ugyanaz a fizika, ami a szappanbuborékok és a vékony olajrétegek irizáló színeit okozza.

A MOPA képes pontosan beállítani az oxidréteg vastagságát az impulzusszélesség és az ismétlési frekvencia kombinálásával. Tipikus paraméter-szín megfeleltetések:

• Arany / sárga szín: specifikus PW + frekvencia + sebesség kombináció
• Kék / ibolya: eltérő PW / magasabb frekvencia
• Zöld, vörös: további paraméterkombinációk

Ez a folyamat rendkívül paraméter-érzékeny — a sebesség, a teljesítmény, a PW és a frekvencia együttesen határozza meg az eredményt, és kis változás is eltérő színt eredményez. Reprodukálható eredményhez anyagkönyvtár, pontosan kalibrált gép és gondos paraméterdokumentáció szükséges. Egy jól felépített MOPA anyagprofil-rendszer (mint a LaserBase anyagkönyvtára) éppen ezt a reprodukálhatóságot teszi lehetővé.

MOPA paraméterek a JCZ / EZCAD rendszerben

A JCZ LMCV4-FIBER-M kártya és az EZCAD szoftver kifejezetten MOPA forrásokat is támogat. A parancslistában a MOPA-specifikus paraméterek külön vezérlőbejegyzésként szerepelnek, amelyeket a kártya az FPGA-n keresztül, nanoszekundumos pontossággal küld a forrás modulátorának:

• Pulse Width (PW): az impulzus időbeli hossza nanoszekundumban — a legkritikusabb MOPA-specifikus paraméter
• Pulse Repetition Frequency (PRF): másodpercenkénti impulzusszám kHz-ben
• First Pulse Suppression: az első impulzus elnyomása — minden jelölési vonal elején a forrás első impulzusa energetikailag eltér a többi impulzustól, ezt kompenzálja
• Power: átlagteljesítmény százalékban a névleges maximumhoz képest

MOPA gyártók és piaci pozícionálás

26 · További szakirodalom

Az alábbi irodalmak mélyebb elméleti és gyakorlati megalapozást nyújtanak a dokumentumban tárgyalt témakörökhöz.

Galvanométeres rendszerek és optika

• Saleh, B.E.A. & Teich, M.C. — Fundamentals of Photonics (Wiley, 3rd ed. 2019) — Az optikai alapok és lézeroptika egyik legtekintélyesebb tankönyve. A galvo rendszerekre és fókuszáló optikákra vonatkozó fejezetek a fizikai alapokat részletesen tárgyalják.
• Marshall, G.F. & Stutz, G.E. (szerk.) — Handbook of Optical and Laser Scanning (CRC Press, 2nd ed. 2004) — Kifejezetten szkennelő rendszerekre fókuszáló kézikönyv, részletes galvo tárgyalással, F-Theta optikával, kalibrációval és ipari alkalmazásokkal.
• Svelto, O. — Principles of Lasers (Springer, 5th ed. 2010) — Lézeralap és forrástechnológia, beleértve a fiber erősítőket és az erősítési elveket.

Mozgásvezérlés és firmware

• grblHAL dokumentáció és wiki — github.com/grblHAL — Részletes technikai dokumentáció a grblHAL firmware architektúrájáról, a HAL interfészről, a cluster mód implementációjáról és a platform-specifikus optimalizációkról.
• GRBL GitHub Wiki — github.com/gnea/grbl/wiki — Az eredeti GRBL firmware teljes dokumentációja: mozgástervező, puffer kezelés, G-code implementáció, konfigurációs paraméterek.

Fiber lézerek és MOPA technológia

• Richardson, D.J. et al. — High power fiber lasers: current status and future perspectives — Journal of the Optical Society of America B, 2010. — Referencia cikk a nagy teljesítményű fiber lézerekről és az erősítő architektúrákról, szabad hozzáférésű.
• Zervas, M.N. & Codemard, C.A. — High Power Fiber Lasers: A Review — IEEE Journal of Selected Topics in Quantum Electronics, 2014. — Átfogó review a MOPA és más fiber lézertechnológiákról, a csúcsteljesítmény-skálázás fizikájáról.

Ipari lézeralkalmazások

• Ready, J.F. & Farson, D.F. (szerk.) — LIA Handbook of Laser Materials Processing (Magnolia Publishing, 2001) — Az ipari lézeralkalmazások átfogó kézikönyve: anyagfeldolgozás, jelölés, vágás, hegesztés fizikája és technológiája.

Protokollok és interfészek

• XY2-100 Interface Specification — A Cambridge Technology által kidolgozott ipari szabvány. A specifikáció PDF-ben nyilvánosan elérhető (ilphotonics.com terjeszti). Tartalmazza a fizikai réteget, a keretszerkezetet és az időzítési diagramokat.
• EduTech Wiki — LMCV4-FIBER-M reverse engineering — edutechwiki.unige.ch — Részletes közösségi visszafejtési dokumentáció a JCZ LMC4 kártya USB protokolljáról. Nem hivatalos, de a legteljesebb nyilvánosan elérhető forrás a zárt protokoll megértéséhez.

Online közösségi erőforrások

• LightBurn Community Forum — forum.lightburnsoftware.com — Aktív közösség, ahol protokollspecifikus kérdések, firmware kompatibilitás és képfeldolgozás témakörökben részletes technikai vitákat folytatnak.
• LaserGRBL GitHub Discussions — github.com/arkypita/LaserGRBL — A raszter protokoll és cluster mód fejlesztési vitái itt dokumentáltak.
• Inventables / LightBurn Forum — Fiber and Galvo szálak — A galvo rendszerek kalibrációjáról, COR fájl kezelésről és MOPA paraméterezésről sok praktikus felhasználói tapasztalat olvasható.

27 · Kibővített forrásjegyzék

28 · Ökoszisztéma alapú rendszerek

A három architektúrális kategória (G-code stream, feladat alapú, lista alapú) mellett létezik egy negyedik dimenzió, amely keresztbe metszi ezeket: a nyíltság versus zárt ökoszisztéma tengelye. Ez nem vezérlési architektúra — hanem a rendszer integrálhatóságát és nyíltságát jellemző dimenzió.

Egyes gyártók — például AlgoLaser, xTool és Twotrees — nem csak hardvert szállítanak, hanem saját, integrált szoftver-hardver ökoszisztémát építenek. A kommunikációs modell alapján ezek általában G-code stream vagy feladat alapú rendszerek, de ez el van rejtve a felhasználó elől.

Mit jelent ez a felhasználó szempontjából?

Ezek a rendszerek kényelmesebbek a kezdőknek — a gyártó gondoskodik az optimalizálásról, a szoftver-hardver illesztésről, a kamera alapú pozicionálásról. A hátrány az, hogy a felhasználó nem tudja kicserélni a szoftvert, nem tud mélyen integrálni, és a gyártó jövőbeli döntéseitől függ — például ha egy szoftver verziót megszüntetnek, vagy a cloud szerver leáll.

Architektúrálisan nem új kategória — de a nyíltság szempontjából önálló dimenzió. Ezért az összehasonlítási táblázatban érdemes különbséget tenni az azonos kommunikációs modellen belül nyílt (GRBL) és zárt (xTool P széria) rendszerek között.

29 · Fejlődő platformok — Klipper, FluidNC, MKS DLC32

A lézervezérlés világa nem statikus. Az elmúlt néhány évben több platform is megjelent vagy érett meg, amelyek nem illeszkednek tisztán a hagyományos három kategóriába — vagy keresztbe metszik azokat.

Klipper — Linux host alapú vezérlés

A Klipper firmware egy különleges esetként érdemel figyelmet. Nem illeszkedik tisztán egyik hagyományos kategóriába sem — G-code alapú, de a számítás és a valós idejű végrehajtás szét van választva:

A Klipper lényege, hogy a nehéz számítást a Linux host végzi, a mikrokontroller csak a valós idejű step generálást. Ez lehetővé teszi a nagyon pontos mozgástervezést, a rezonancia kompenzációt (input shaping) és más fejlett funkciókat, amelyek ESP32 alapú rendszeren nem elérhetők.

Olcsó Linux host lehetőség: egy Android TV box (~15–20 EUR, 64 GB tárhely) erősebb mint egy Raspberry Pi 3, és Armbian fut rajta — ez a legolcsóbb megoldás Klipper hostként. Egy normális alaplap (mini ITX, 6–8 GB RAM) lényegesen erősebb platform, de magasabb árral. A TV box az ESP32 szintnél egyértelműen magasabb kategória, de ez a legjobban elérhető olcsó megoldás.

LaserBase által validált Klipper konfiguráció jelenleg nem áll rendelkezésre — figyelemmel kísért, aktívan fejlődő terület.

FluidNC — ESP32 alapú, SD kártyás önálló futtatással

A FluidNC G-code stream alapú firmware, de az önálló futtatás szempontjából közelebb áll a Ruida-típusú rendszerekhez, mint a hagyományos GRBL-hez. Az SD kártya támogatás konfigurálandó a config.yaml fájlban (sdcard és spi szekció, megfelelő GPIO pinekkel) — sikeres konfiguráció után a $SD/Run=/fajl.nc paranccsal futtatható fájl közvetlenül az SD kártyáról, PC nélkül.

A FluidDial és FluidTouch kiegészítők fizikai kezelőfelületet adnak — kézikerék-szerű vezérlést, menürendszert, SD kártya böngészőt. Ezekkel a FluidNC élménye közelít az önálló, Ruida-típusú vezérlőkhöz, miközben a kommunikációs modell G-code alapú marad.

MKS DLC32 — offline gravírozásra tervezett ESP32 lap

Az MKS DLC32 kifejezetten offline gravírozásra fejlesztett ESP32 alapú vezérlőlap — beépített SD kártya olvasóval és opcionális 3.5 hüvelykes érintőképernyővel. Gyárilag GRBL alapú firmware-rel érkezik, de grblHAL-ra is flashelhető.

30 · SD kártya és önálló futtatás — platformszintű összehasonlítás

Az összehasonlító táblázatban (5. fejezet) a "PC szükséges futás közben" sor egyszerűsített képet ad. A valóság platformfüggő — az önálló futtatás képessége nem architektúrális tulajdonság, hanem hardver és firmware kapacitás kérdése.

A kommunikációs architektúra (stream / feladat feltöltés) és az önálló futtatás képessége két különböző dimenzió:

• A grblHAL SD kártyáról G-code fájlt futtat — ez kommunikációs szempontból G-code stream alapú modell, de PC-független végrehajtás.
• A Ruida saját bináris feladatfájlt tölt és futtat — szintén PC-független, de teljesen más formátumban.
• Az önállóság tehát nem architektúrális határ, hanem hardver képesség kérdése.

31 · Szakmai pontosítások és audit megjegyzések

Ez a fejezet az online validálás és közösségi audit során azonosított pontosításokat gyűjti össze — olyan állítások korrigálása, amelyek az anyag korábbi verzióiban pontatlanul vagy egyszerűsítve szerepeltek.

1. FluidNC SD kártya — "natívan támogatja" vs. "konfigurálandó"

Az anyag korábbi verziói azt sugallhatják, hogy a FluidNC alapértelmezetten SD kártyáról fut. A valóság: az SD kártya nem alapértelmezett — a config.yaml fájlban külön kell konfigurálni az sdcard és spi szekciót a megfelelő GPIO pinekkel. FAT-32 formátum kötelező; ExFAT nem támogatott. 64 GB-nál nagyobb kártyák csak FAT-32-re újraformázva működnek.

2. MKS DLC32 — processzor típus és firmware kompatibilitás

Az MKS DLC32 és az MKS DLC32 Max különböző processzorokat tartalmaz (ESP32 vs ESP32-S3). A két változathoz különböző firmware szükséges. Az MKS ESP32 Download Tool nem validálja a chip ID-t — ezért a firmware feltöltés előtt minden esetben ellenőrizni kell a processzor típusát. A rossz firmware feltöltése brickelhet.

3. xTool — modellszintű különbség

Az "xTool zárt ökoszisztéma" állítás nem általánosítható az egész termékcsaládra. Az xTool D1 és D1 Pro G-code alapú, LightBurnnal teljes mértékben kompatibilis. A zárt ökoszisztéma elsősorban az xTool P2/P2S és P3 modellekre vonatkozik, ahol a LightBurn támogatás korlátozott.

4. Klipper lézer támogatás — nem kísérleti, hanem mainline

2023 decemberétől a Klipper fast PWM frissítés bekerült a mainline-ba. A pwm_tool konfigurációval M3/M4/M5 G-code parancsok működnek. A lézer támogatás tehát nem kísérleti — de elsősorban 3D nyomtatásra fejlesztett rendszer, amelybe a lézer támogatás utólag került. Fontos biztonsági megjegyzés: dióda lézerek általában invertáltak, és MCU újraindításkor a lézer rövid ideig teljes teljesítményen maradhat — biztonsági timeout konfigurálása kötelező.

5. Ruida sebesség — 100–1 500 mm/s

Az összehasonlító táblázatban a Ruida sebessége "100–800 mm/s"-ként szerepelt. A valóság: egyes Ruida rendszerek gravírozásnál 1 000–1 500 mm/s tartományban is dolgoznak. A pontosabb szám: tipikus: 100–1 500 mm/s, modelltől és konfigurációtól függően.

6. "A G-code raszterre nem készült" — pontosabb megfogalmazás

Ez az állítás oktatási célra hasznos egyszerűsítés, de műszakilag pontosabb: a G-code eredetileg vektoros szerszámpályák leírására készült (RS-274, 1963). A raszter gravírozás később került ráépítésre — adaptációként, nem eredeti tervezési célként. A cluster mód (LightBurn 1.2.02+) ezt az adaptációt lényegesen hatékonyabbá tette.

7. "A fiber lézer nem működhet G-code-dal" — pontosabb megfogalmazás

Ez az állítás így túl erős. A pontosabb megfogalmazás: a fiber galvo rendszer vezérelhető lenne G-code által leírt pályákkal elméletileg — de a klasszikus G-code stream architektúra nem alkalmas a szükséges időzítési és sebességi követelmények teljesítésére. A korlát nem a G-code nyelvben, hanem a stream kommunikációs modellben és az USB/PC oldali késleltetésben van.