Deploying to gh-pages from @ Klipper3d/klipper@434770eaf9 🚀

This commit is contained in:
KevinOConnor
2024-05-06 00:04:31 +00:00
parent 1abfa00e23
commit 43cff61d2d
58 changed files with 567 additions and 482 deletions

View File

@@ -1499,15 +1499,16 @@ z_hop_speed: 5
<h2 id="bl-touch-kimeneti-mod">BL-Touch kimeneti mód<a class="headerlink" href="#bl-touch-kimeneti-mod" title="Permanent link">&para;</a></h2>
<ul>
<li>
<p>A BL-Touch V3.0 támogatja az 5V vagy OPEN-DRAIN kimeneti mód beállítását, a BL-Touch V3.1 szintén támogatja ezt, de ezt a belső EEPROM-jában is el tudja tárolni. Ha az alaplapodnak szüksége van az 5V-os üzemmód fix 5V magas logikai szintjére, akkor a nyomtató konfigurációs fájl [bltouch] szakaszában a 'set_output_mode' paramétert "5V" értékre állíthatod.<strong><em> Csak akkor használd az 5V-os üzemmódot, ha az alaplapnak a bemeneti vonala 5V-os toleráns. Ezért ezeknek a BL-Touch verzióknak az alapértelmezett konfigurációja a OPEN-DRAIN üzemmód. Ezzel potenciálisan károsíthatod az alaplap CPU-ját </em></strong></p>
<p>A BL-Touch V3.0 támogatja az 5V vagy OPEN-DRAIN kimeneti mód beállítását, a BL-Touch V3.1 szintén támogatja ezt, de ezt a belső EEPROM-jában is el tudja tárolni. Ha az alaplapodnak szüksége van az 5V-os üzemmód fix 5V magas logikai szintjére, akkor a nyomtató konfigurációs fájl [bltouch] szakaszában a 'set_output_mode' paramétert "5V" értékre állíthatod.</p>
<p><strong><em> Csak akkor használd az 5V-os üzemmódot, ha az alaplapnak a bemeneti vonala 5V-os toleráns. Ezért ezeknek a BL-Touch verzióknak az alapértelmezett konfigurációja a OPEN-DRAIN üzemmód. Ezzel potenciálisan károsíthatod az alaplap CPU-ját </em></strong></p>
<p>Ezért tehát: Ha egy alaplapnak 5V-os üzemmódra van szüksége ÉS 5V-os toleráns a bemeneti jelvonalon ÉS ha</p>
</li>
</ul>
<ul>
<li>ha neked BL-Touch Smart V3.0 van, akkor a 'set_output_mode-ot: 5V' paramétert kell megadni, hogy minden egyes indításkor biztosítsd ezt a beállítást, mivel a szonda nem tudja megjegyezni a szükséges beállítást.</li>
<li>ha neked BL-Touch Smart V3.1 van, akkor választhatsz a 'set_output_mode: 5V' vagy az üzemmód egyszeri tárolása a 'BLTOUCH_STORE MODE=5V' parancsok közül, kézzel és NEM a 'set_output_mode:' paraméter használatával.</li>
<li>ha van más szondád is: A kimeneti üzemmód (végleges) beállításához néhány szondának van egy bekötése az alaplapon, amelyet el kell vágni, vagy egy jumperrel kell beállítani. Ebben az esetben hagyd ki teljesen a 'set_output_mode' paramétert.
Ha V3.1 szondával rendelkezel, ne automatizáld vagy ismételd a kimeneti üzemmód tárolását, hogy elkerüld a szonda EEPROM-jának elhasználódását. A BLTouch EEPROM körülbelül 100.000 frissítésre alkalmas. A napi 100 tárolás körülbelül 3 évnyi működést jelentene, mielőtt elhasználódna. Így a kimeneti üzemmód tárolását a V3.1-ben a gyártó bonyolult műveletnek tervezte (a gyári alapértelmezett egy biztonságos OPEN DRAIN üzemmód), és nem alkalmas arra, hogy bármilyen szeletelő, makró vagy bármi más által ismételten kiadja, lehetőleg csak akkor használható, amikor először integrálják a szondát egy nyomtató alaplapjára.</li>
</ul>
</li>
</ul>

View File

@@ -1812,7 +1812,10 @@ adaptive_margin: 5
</code></pre></div>
<ul>
<li><code>adaptive_margin</code> <em>Alapértelmezett érték: 0</em> Az ágy meghatározott objektumok által használt területe köré hozzáadandó margó (mm-ben). Az alábbi ábra az adaptív ágy hálóterületét mutatja, ha az <code>adaptive_margin</code> értéke 5 mm. Az adaptív hálóterület (zöld színű terület) a használt ágyterület (kék színű terület) és a meghatározott margó összegeként kerül kiszámításra.<img alt="adaptive_bedmesh_margin" src="img/adaptive_bed_mesh_margin.svg" /></li>
<li>
<p><code>adaptive_margin</code> <em>Alapértelmezett érték: 0</em> Az ágy meghatározott objektumok által használt területe köré hozzáadandó margó (mm-ben). Az alábbi ábra az adaptív ágy hálóterületét mutatja, ha az <code>adaptive_margin</code> értéke 5 mm. Az adaptív hálóterület (zöld színű terület) a használt ágyterület (kék színű terület) és a meghatározott margó összegeként kerül kiszámításra.</p>
<p><img alt="adaptive_bedmesh_margin" src="img/adaptive_bed_mesh_margin.svg" /></p>
</li>
</ul>
<p>Az adaptív ágyrácsok természetüknél fogva a nyomtatás alatt álló G-Kód fájlban meghatározott objektumokat használják. Ezért várható, hogy minden egyes G-Kód fájl olyan hálót generál, amely a nyomtatóágy különböző területét vizsgálja. Ezért az adaptív ágyhálót nem szabad újra felhasználni. Az adaptív hálózás használata esetén elvárás, hogy minden egyes nyomtatáshoz új hálót generáljon.</p>
<p>Azt is fontos figyelembe venni, hogy az adaptív ágyhálózást olyan gépeken lehet a legjobban alkalmazni, amelyek általában a teljes ágyat meg tudják tapogatni, és 1 rétegmagasságnál kisebb vagy azzal egyenlő maximális eltérést érnek el. Az olyan mechanikai problémákkal küzdő gépek, amelyeket a teljes ágyháló általában kompenzál, nemkívánatos eredményeket hozhatnak, amikor a nyomtatási mozgásokat a szondázott területen <strong>kívül</strong> próbálják végrehajtani. Ha a teljes ágyháló eltérése nagyobb, mint 1 rétegmagasság, akkor óvatosan kell eljárni, amikor adaptív ágyhálót használunk, és a hálózott területen kívüli nyomtatási mozgásokat kísérelünk meg.</p>

View File

@@ -1481,14 +1481,15 @@ iface can0 can static
</code></pre></div>
<ul>
<li>A "bridge mcu" valójában nem a CAN-buszon van. A híd mcu-nak küldött és onnan érkező üzeneteket a CAN-buszon lévő más adapterek nem látják.</li>
<li>
<p>A "bridge mcu" valójában nem a CAN-buszon van. A híd mcu-nak küldött és onnan érkező üzeneteket a CAN-buszon lévő más adapterek nem látják.</p>
<ul>
<li>A rendelkezésre álló sávszélességet mind a "híd mcu", mind a CAN-buszon lévő összes eszköz számára a CAN-busz frekvenciája korlátozza. Ennek eredményeképpen az "USB és CAN-busz közötti híd üzemmód" használatakor ajánlott 1000000-es CAN-busz frekvenciát használni.Még 1000000-es CAN-busz frekvencia esetén sem biztos, hogy elegendő sávszélesség áll rendelkezésre a <code>SHAPER_CALIBRATE</code> teszt futtatásához, ha mind az XY-léptetők, mind a gyorsulásmérő egyetlen "USB és CAN-busz" interfészen keresztül kommunikálnak.</li>
<li>Az USB-CAN hídlap nem jelenik meg USB soros eszközként, nem jelenik meg az <code>ls /dev/serial/by-id</code> futtatásakor, és nem konfigurálható a Klipper printer.cfg fájljában a <code>serial:</code> paraméterrel. A hídlap "USB CAN adapter"-ként jelenik meg, és a printer.cfg fájlban <a href="#configuring-klipper">CAN node-ként</a> van konfigurálva .</li>
</ul>
<p>A rendelkezésre álló sávszélességet mind a "híd mcu", mind a CAN-buszon lévő összes eszköz számára a CAN-busz frekvenciája korlátozza. Ennek eredményeképpen az "USB és CAN-busz közötti híd üzemmód" használatakor ajánlott 1000000-es CAN-busz frekvenciát használni.</p>
<p>Még 1000000-es CAN-busz frekvencia esetén sem biztos, hogy elegendő sávszélesség áll rendelkezésre a <code>SHAPER_CALIBRATE</code> teszt futtatásához, ha mind az XY-léptetők, mind a gyorsulásmérő egyetlen "USB és CAN-busz" interfészen keresztül kommunikálnak.</p>
</li>
</ul>
<ul>
<li>Az USB-CAN hídlap nem jelenik meg USB soros eszközként, nem jelenik meg az <code>ls /dev/serial/by-id</code> futtatásakor, és nem konfigurálható a Klipper printer.cfg fájljában a <code>serial:</code> paraméterrel. A hídlap "USB CAN adapter"-ként jelenik meg, és a printer.cfg fájlban <a href="#configuring-klipper">CAN node-ként</a> van konfigurálva .</li>
</ul>
<h2 id="tippek-a-hibaelharitashoz">Tippek a hibaelhárításhoz<a class="headerlink" href="#tippek-a-hibaelharitashoz" title="Permanent link">&para;</a></h2>
<p>Lásd a <a href="CANBUS_Troubleshooting.html">CAN-busz hibaelhárítás</a> dokumentumot.</p>

View File

@@ -1447,7 +1447,8 @@
<p>Gyakori dolgok, amiket a bíráló keres:</p>
<ol>
<li>
<p>Hibátlan-e a beadvány, és készen áll-e a széles körű bevezetésre?A benyújtóknak a benyújtás előtt tesztelniük kell a változtatásokat. A bírálók keresik a hibákat, de általában nem tesztelik a beküldött anyagokat. Egy elfogadott beadványt gyakran az elfogadást követő néhány héten belül több ezer nyomtatóhoz juttatunk el. Ezért a beadványok minősége prioritást élvez.</p>
<p>Hibátlan-e a beadvány, és készen áll-e a széles körű bevezetésre?</p>
<p>A benyújtóknak a benyújtás előtt tesztelniük kell a változtatásokat. A bírálók keresik a hibákat, de általában nem tesztelik a beküldött anyagokat. Egy elfogadott beadványt gyakran az elfogadást követő néhány héten belül több ezer nyomtatóhoz juttatunk el. Ezért a beadványok minősége prioritást élvez.</p>
<p>A fő <a href="https://github.com/Klipper3d/klipper">Klipper3d/klipper</a> GitHub tároló nem fogad el kísérleti munkát. A beküldőknek a kísérletezést, hibakeresést és tesztelést a saját tárolójukban kell elvégezniük. A <a href="Contact.html">Klipper Társalgó</a> szerver jó hely arra, hogy felhívjuk a figyelmet az új munkára, és megtaláljuk azokat a felhasználókat, akiket érdekel a valós visszajelzés.</p>
<p>A beadványoknak át kell menniük az összes <a href="Debugging.html">regressziós teszteseten</a>.</p>
<p>A kódban lévő hiba javításakor a benyújtóknak általában véve tisztában kell lenniük a hiba kiváltó okával, és a javításnak ezt a kiváltó okot kell megcéloznia.</p>
@@ -1456,7 +1457,8 @@
<p>A dokumentáció frissítései nem jelenthetik ki, hogy azok "folyamatban lévő munkák".</p>
</li>
<li>
<p>A beadott pályázat "nagy hatású" előnyt jelent-e a valós felhasználók számára, akik valós feladatokat látnak el?A bírálóknak - legalábbis a saját fejükben - nagyjából meg kell határozniuk, hogy "ki a célközönség", hogy "mekkora a célközönség", hogy "milyen előnyökhöz" jutnak, hogy "az előnyöket hogyan mérik", és hogy "milyen eredményeket hoznak ezek a mérési tesztek". A legtöbb esetben ez mind a benyújtó, mind a bíráló számára nyilvánvaló, és a bírálat során nem kerül kifejezett kijelentésre.</p>
<p>A beadott pályázat "nagy hatású" előnyt jelent-e a valós felhasználók számára, akik valós feladatokat látnak el?</p>
<p>A bírálóknak - legalábbis a saját fejükben - nagyjából meg kell határozniuk, hogy "ki a célközönség", hogy "mekkora a célközönség", hogy "milyen előnyökhöz" jutnak, hogy "az előnyöket hogyan mérik", és hogy "milyen eredményeket hoznak ezek a mérési tesztek". A legtöbb esetben ez mind a benyújtó, mind a bíráló számára nyilvánvaló, és a bírálat során nem kerül kifejezett kijelentésre.</p>
<p>A mester Klipper ágba küldött beadványok várhatóan figyelemre méltó célközönséggel rendelkeznek. Általános "ökölszabályként" a beadványoknak legalább 100 valós felhasználóból álló felhasználói bázist kell megcélozniuk.</p>
<p>Ha egy bíráló részleteket kér egy beadvány "hasznáról", kérjük, ne tekintsd ezt kritikának. Az, hogy képesek legyünk megérteni egy változtatás valós előnyeit, a felülvizsgálat természetes része.</p>
<p>Az előnyök megvitatásakor előnyösebb a "tények és mérések" megvitatása. Általában véve a bírálók nem a "valaki hasznosnak találhatja az X opciót", sem pedig a "ez a beadvány olyan funkciót ad hozzá, amelyet az X firmware valósít meg" formájú válaszokat keresik. Ehelyett általában előnyösebb, ha részletesen tárgyalják, hogy a minőségjavulást hogyan mérték, és milyen eredményeket hoztak ezek a mérések - például: "az Acme X1000 nyomtatókon végzett tesztek a ...képen látható javuló sarkokat mutatnak ", vagy például "az X valós tárgy nyomtatási ideje egy Foomatic X900 nyomtatón 4 óráról 3,5 órára csökkent". Magától értetődik, hogy az ilyen típusú tesztelés jelentős időt és erőfeszítést igényel. A Klipper legjelentősebb funkcióinak némelyike hónapokig tartott a megbeszélések, átdolgozások, tesztelések és dokumentációk során, mielőtt beolvadt a master ágba.</p>
@@ -1466,17 +1468,18 @@
<p>Az új modulok, új opciók és új paraméterek nem biztosíthatnak hasonló funkciókat a meglévő modulokhoz - ha a különbségek önkényesek, akkor inkább a meglévő rendszert kell használni, vagy a meglévő kódot kell átalakítani.</p>
</li>
<li>
<p>A beadvány szerzői joga egyértelmű, nem hálapénz és összeegyeztethető?Az új C és Python fájloknak egyértelmű szerzői jogi nyilatkozatot kell tartalmazniuk. Az előnyben részesített formátumot lásd a meglévő fájlokban. A meglévő fájl szerzői jogának deklarálása a fájl kisebb módosításai esetén elhanyagolható.</p>
<p>A beadvány szerzői joga egyértelmű, nem hálapénz és összeegyeztethető?</p>
<p>Az új C és Python fájloknak egyértelmű szerzői jogi nyilatkozatot kell tartalmazniuk. Az előnyben részesített formátumot lásd a meglévő fájlokban. A meglévő fájl szerzői jogának deklarálása a fájl kisebb módosításai esetén elhanyagolható.</p>
<p>A harmadik féltől származó kódnak kompatibilisnek kell lennie a Klipper licenszel (GNU GPLv3). A nagyobb, harmadik féltől származó kódkiegészítéseket a <code>lib/</code> könyvtárba kell helyezni (és a <a href="https://github.com/Klipper3d/klipper/blob/master/lib/README">lib/README</a> könyvtárban leírt formátumot kell követni).</p>
<p>A beküldőknek meg kell adniuk egy <a href="#format-of-commit-messages">Signed-off-by line</a> sort a teljes valódi nevükkel. Ez azt jelzi, hogy a benyújtó egyetért a <a href="developer-certificate-of-origin">fejlesztői származási igazolással</a>.</p>
</li>
<li>
<p>A benyújtás követi a Klipper dokumentációban meghatározott irányelveket?Különösen a kódnak a <Code_Overview.md>, a konfigurációs fájloknak pedig a <Example_Configs.md> című dokumentumban található irányelveket kell követniük.</p>
<p>A benyújtás követi a Klipper dokumentációban meghatározott irányelveket?</p>
<p>Különösen a kódnak a <Code_Overview.md>, a konfigurációs fájloknak pedig a <Example_Configs.md> című dokumentumban található irányelveket kell követniük.</p>
</li>
<li>
<p>A Klipper dokumentáció frissítve van az új változásoknak megfelelően?Legalább a referenciadokumentációt kell frissíteni a kód megfelelő változtatásaival:</p>
</li>
</ol>
<p>A Klipper dokumentáció frissítve van az új változásoknak megfelelően?</p>
<p>Legalább a referenciadokumentációt kell frissíteni a kód megfelelő változtatásaival:</p>
<ul>
<li>Minden parancsot és parancsparamétert a <G-Codes.md> dokumentumban kell dokumentálni.</li>
<li>Minden felhasználó előtt álló modult és azok konfigurációs paramétereit dokumentálni kell a <Config_Reference.md> fájlban.</li>
@@ -1484,10 +1487,13 @@
<li>Minden új "webhooks" és paramétereiket dokumentálni kell <API_Server.md>.</li>
<li>Minden olyan módosítás, amely nem visszafelé kompatibilis módosítást hajt végre egy parancs vagy konfigurációs fájl beállításán, dokumentálni kell a <Config_Changes.md> dokumentumban.</li>
</ul>
</li>
</ol>
<p>Az új dokumentumokat hozzá kell adni az <Overview.md> fájlhoz, és hozzá kell adni a weboldal indexéhez <a href="https://github.com/Klipper3d/klipper/blob/master/docs/_klipper3d/mkdocs.yml">docs/_klipper3d/mkdocs.yml</a>.</p>
<ol>
<li>
<p>A véglegesítések jól megformáltak, véglegesítésként egyetlen témával foglalkoznak, és függetlenek?A kérelmi üzeneteknek a <a href="#format-of-commit-messages">preferált formátumot</a> kell követniük.</p>
<p>A véglegesítések jól megformáltak, véglegesítésként egyetlen témával foglalkoznak, és függetlenek?</p>
<p>A kérelmi üzeneteknek a <a href="#format-of-commit-messages">preferált formátumot</a> kell követniük.</p>
<p>A kérelmeknek nem lehet összeolvadási konfliktusuk. A Klipper master ágához való új hozzáadások mindig egy "rebase" vagy "squash and rebase" segítségével történnek. A benyújtóknak általában nem szükséges a Klipper főadattár minden egyes frissítésénél újra egyesíteniük a beadványukat. Ha azonban összeolvasztási konfliktus van, akkor a benyújtóknak ajánlott a <code>git rebase</code> használata a konfliktus megoldására.</p>
<p>Minden egyes kérelemnek egyetlen magas szintű változtatással kell foglalkoznia. A nagyobb változtatásokat több független kérelemre kell bontani. Minden commit-nak "önállóan kell állnia", hogy az olyan eszközök, mint a <code>git bisect</code> és <code>git revert</code> megbízhatóan működjenek.</p>
<p>A fehér területi változtatásokat nem szabad összekeverni a funkcionális változtatásokkal. Általánosságban elmondható, hogy az indokolatlan szóköz módosításokat nem fogadjuk el, kivéve, ha azok a módosítandó kód megállapított "tulajdonosától" származnak.</p>

View File

@@ -1484,21 +1484,23 @@
<p>Egy tipikus nyomtatómozgás akkor kezdődik, amikor egy "G1" parancsot küldünk a Klippy gazdagépnek, és akkor fejeződik be, amikor a megfelelő lépésimpulzusok megjelennek a mikrokontrolleren. Ez a szakasz egy tipikus mozgatási parancs kódfolyamatát vázolja fel. A <a href="Kinematics.html">kinematika</a> dokumentum további információkat tartalmaz a mozgások mechanikájáról.</p>
<ul>
<li>A mozgás parancs feldolgozása a gcode.py fájlban kezdődik. A gcode.py célja a G-kód lefordítása belső hívásokká. Egy G1 parancs a klippy/extras/gcode_move.py állományban lévő cmd_G1() parancsot hívja meg. A gcode_move.py kód kezeli az eredetváltozásokat (pl. G92), a relatív és abszolút pozíciók közötti változásokat (pl. G90) és az egységváltozásokat (pl. F6000=100mm/s). A kód útvonala a mozgatáshoz a következő: <code>_process_data() -&gt; _process_commands() -&gt; cmd_G1()</code>. Végül a ToolHead osztályt hívjuk meg a tényleges kérés végrehajtásához: <code>cmd_G1() -&gt; ToolHead.move()</code></li>
<li>A ToolHead osztály (a toolhead.py állományban) kezeli a "look-ahead" funkciót és követi a nyomtatási műveletek időzítését. A fő kódútvonal egy mozdulathoz a következő: <code>ToolHead.move() -&gt; LookAheadQueue.add_move() -&gt; LookAheadQueue.flush() -&gt; Move.set_junction() -&gt; ToolHead._process_moves()</code>.<ul>
<li>
<p>A ToolHead osztály (a toolhead.py állományban) kezeli a "look-ahead" funkciót és követi a nyomtatási műveletek időzítését. A fő kódútvonal egy mozdulathoz a következő: <code>ToolHead.move() -&gt; LookAheadQueue.add_move() -&gt; LookAheadQueue.flush() -&gt; Move.set_junction() -&gt; ToolHead._process_moves()</code>.</p>
<ul>
<li>A ToolHead.move() létrehoz egy Move() objektumot a mozgás paramétereivel (cartesian térben, másodperc és milliméter egységekben).</li>
<li>A kinematikai osztály lehetőséget kap az egyes mozgások ellenőrzésére (<code>ToolHead.move() -&gt; kin.check_move()</code>). A kinematikai osztályok a klippy/kinematics/ könyvtárban találhatók. A check_move() kód hibát adhat ki, ha a mozgás nem érvényes. Ha a check_move() sikeresen befejeződik, akkor az alapul szolgáló kinematikának képesnek kell lennie a mozgás kezelésére.</li>
<li>A LookAheadQueue.add_move() a move objektumot a "look-ahead" várólistára helyezi.</li>
<li>A LookAheadQueue.flush() meghatározza az egyes mozgások kezdő és végsebességét.</li>
<li>A Move.set_junction() a "trapézgenerátort" valósítja meg egy mozgásban. A "trapézgenerátor" minden mozgást három részre bont: egy állandó gyorsulási fázisra, majd egy állandó sebesség fázisra, majd egy állandó lassulási fázisra. Minden mozgás ebben a sorrendben tartalmazza ezt a három fázist, de egyes fázisok időtartama lehet nulla is.</li>
<li>Amikor a ToolHead._process_moves() meghívásra kerül, a mozgással kapcsolatban minden ismert a kezdőhelye, a véghelye, a gyorsulása, a kezdő/körözési/végsebessége és a gyorsulás/körözési/végsebesség alatt megtett távolság. Minden információ a Move() osztályban tárolódik, és cartesian térben, milliméter és másodperc egységekben van megadva.</li>
</ul>
</li>
<li>A Klipper egy <a href="https://en.wikipedia.org/wiki/Root-finding_algorithm">iteratív megoldót</a> használ az egyes léptetők lépésidejének létrehozásához. Hatékonysági okokból a léptető impulzusidőket C kódban generálja. A mozgások először egy "trapézmozgás-várólistára" kerülnek: (a klippy/chelper/trapq.c-ben). A lépésidők ezután generálódnak: <code>ToolHead._process_moves() -&gt; ToolHead._advance_move_time() -&gt; ToolHead._advance_flush_time() -&gt; MCU_Stepper.generate_steps() -&gt; itersolve_generate_steps() -&gt; itersolve_gen_steps_range()</code> (in klippy/chelper/itersolve.c). Az iteratív megoldó célja, hogy lépésidőket találjon egy olyan függvényt adva, amely egy időből kiszámítja a léptető pozícióját. Ez úgy történik, hogy különböző időket ismételten "kitalál", amíg a léptető pozíció képlete vissza nem adja a léptető következő lépésének kívánt pozícióját. Az egyes találgatásokból származó visszajelzéseket a jövőbeli találgatások javítására használja, hogy a folyamat gyorsan konvergáljon a kívánt időhöz. A kinematikus léptető pozíció képletek a klippy/chelper/ könyvtárban találhatók (pl. kin_cart.c, kin_corexy.c, kin_delta.c, kin_extruder.c).</li>
<li>Vedd figyelembe, hogy az extruder saját kinematikai osztályban van kezelve: <code>ToolHead._process_moves() -&gt; PrinterExtruder.move()</code>. Mivel a Move() osztály pontosan megadja a mozgás idejét, és mivel a lépésimpulzusokat meghatározott időzítéssel küldi a mikrokontrollerhez, az extruder osztály által előállított léptetőmozgások szinkronban lesznek a fejmozgással, annak ellenére, hogy a kódot elkülönítve tartjuk.</li>
<li>Miután az iteratív megoldó kiszámítja a lépésidőket, azok egy tömbhöz kerülnek hozzáadásra: <code>itersolve_gen_steps_range() -&gt; stepcompress_append()</code> (in klippy/chelper/stepcompress.c). A tömb (struct stepcompress.queue) minden lépéshez tárolja a mikrokontroller megfelelő óraszámláló idejét. Itt a "mikrokontroller óraszámláló" értéke közvetlenül megfelel a mikrokontroller hardveres számlálójának, a mikrokontroller utolsó bekapcsolásának időpontjához viszonyítva.</li>
<li>A következő fontos lépés a lépések tömörítése: <code>stepcompress_flush() -&gt; compress_bisect_add()</code> (in klippy/chelper/stepcompress.c). Ez a kód generálja és kódolja a mikrokontroller "queue_step" parancsainak sorozatát, amelyek megfelelnek az előző szakaszban felépített léptető lépésidők listájának. Ezek a "queue_step" parancsok ezután sorba kerülnek, prioritást kapnak, és elküldésre kerülnek a mikrokontrollernek (a stepcompress.c:steppersync és a serialqueue.c:serialqueue kódokon keresztül).</li>
<li>A queue_step parancsok feldolgozása a mikrokontrollerben az src/command.c állományban kezdődik, amely elemzi a parancsot és meghívja a <code>command_queue_step()</code> parancsot. A command_queue_step() kód (az src/stepper.c-ben) csak az egyes queue_step parancsok paramétereit csatolja egy-egy stepper sorba. Normál működés esetén a queue_step parancsot legalább 100ms-mal az első lépés időpontja előtt elemzi és beállítja a sorba. Végül a léptető események generálása a <code>stepper_event()</code>-ban történik. Ezt a hardveres időzítő megszakításából hívjuk meg az első lépés tervezett időpontjában. A stepper_event() kód generál egy lépésimpulzust, majd átütemezi magát a következő lépésimpulzus idejére a megadott queue_step paraméterekhez. Az egyes queue_step parancsok paraméterei a következők: "interval", "count" és "add". Magas szinten a stepper_event() a következőket hajtja végre, 'count' times: <code>do_step(); next_wake_time = last_wake_time + interval; interval += add;</code></li>
</ul>
</li>
</ul>
<p>A fentiek soknak tűnhetnek egy mozdulat végrehajtásához. Az egyetlen igazán érdekes rész azonban a ToolHead és a kinematikai osztályokban található. Ez a kódnak azon része, amely meghatározza a mozgásokat és azok időzítését. A feldolgozás többi része többnyire csak kommunikáció és munka.</p>
<h2 id="gazdamodul-hozzaadasa">Gazdamodul hozzáadása<a class="headerlink" href="#gazdamodul-hozzaadasa" title="Permanent link">&para;</a></h2>
<p>A Klippy gazdakódja dinamikus modulbetöltési képességgel rendelkezik. Ha a nyomtató konfigurációs fájljában található egy "[my_module]" nevű konfigurációs szakasz, akkor a szoftver automatikusan megpróbálja betölteni a klippy/extras/my_module.py modult. Ez a modulrendszer a Klipper új funkciók hozzáadásának előnyben részesített módszere.</p>

View File

@@ -1621,16 +1621,17 @@
<li>Ha már hozzáadtad az <code>[input_shaper]</code> részt a printer.cfg fájlhoz, akkor hajtsd végre a <code>SET_INPUT_SHAPER SHAPER_FREQ_X=0 SHAPER_FREQ_Y=0</code> parancsot. Ha "Unknown command" hibát kapsz, nyugodtan figyelmen kívül hagyhatod ezen a ponton, és folytathatod a méréseket.</li>
<li>Végezd el a parancsot: <code>TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL START=1500 STEP_DELTA=500 STEP_HEIGHT=5</code> Alapvetően a gyorsulás különböző nagy értékeinek beállításával próbáljuk a gyűrődést hangsúlyosabbá tenni. Ez a parancs 1500 mm/sec^2-től kezdve 5 mm-enként növeli a gyorsulást: 1500 mm/sec^2, 2000 mm/sec^2, 2500 mm/sec^2 és így tovább, egészen 7000 mm/sec^2-ig az utolsó sávra.</li>
<li>Nyomtasd ki a szeletelt tesztmodellt a javasolt paraméterekkel.</li>
<li>A nyomtatást korábban is leállíthatod, ha a gyűrődés jól látható, és úgy látod, hogy a gyorsulás túl nagy lesz a nyomtató számára (pl. a nyomtató túlságosan remeg, vagy elkezd lépéseket kihagyni).</li>
<li>
<p>A nyomtatást korábban is leállíthatod, ha a gyűrődés jól látható, és úgy látod, hogy a gyorsulás túl nagy lesz a nyomtató számára (pl. a nyomtató túlságosan remeg, vagy elkezd lépéseket kihagyni).</p>
<ol>
<li>Használd a modell hátulján található X és Y jeleket a tájékozódáshoz. Az X-jelöléssel ellátott oldalról történő méréseket kell használni az X tengely <em>konfigurációhoz</em>, az Y-jelölést pedig az Y tengely konfigurációjához. Mérd meg a távolságot <em>D</em> (mm-ben) több rezgés között az X jelzésű alkatrészen, a bevágások közelében, lehetőleg az első egy-két rezgést kihagyva. Az oszcillációk közötti távolság könnyebb méréséhez először jelöld meg az oszcillációkat, majd mérd meg a jelölések közötti távolságot vonalzóval vagy tolómérővel:|<img alt="Mark ringing" src="img/ringing-mark.jpg" />|<img alt="Measure ringing" src="img/ringing-measure.jpg" />|</li>
<li>Számold meg, hogy a mért távolság <em>N</em> hány rezgésnek <em>D</em> felel meg. Ha nem vagy biztos benne, hogy hogyan számold a rezgéseket, nézd meg a fenti képet, ahol <em>N</em> = 6 rezgés.</li>
<p>Használd a modell hátulján található X és Y jeleket a tájékozódáshoz. Az X-jelöléssel ellátott oldalról történő méréseket kell használni az X tengely <em>konfigurációhoz</em>, az Y-jelölést pedig az Y tengely konfigurációjához. Mérd meg a távolságot <em>D</em> (mm-ben) több rezgés között az X jelzésű alkatrészen, a bevágások közelében, lehetőleg az első egy-két rezgést kihagyva. Az oszcillációk közötti távolság könnyebb méréséhez először jelöld meg az oszcillációkat, majd mérd meg a jelölések közötti távolságot vonalzóval vagy tolómérővel:</p>
<p>|<img alt="Mark ringing" src="img/ringing-mark.jpg" />|<img alt="Measure ringing" src="img/ringing-measure.jpg" />|</p>
</li>
<li>
<p>Számold meg, hogy a mért távolság <em>N</em> hány rezgésnek <em>D</em> felel meg. Ha nem vagy biztos benne, hogy hogyan számold a rezgéseket, nézd meg a fenti képet, ahol <em>N</em> = 6 rezgés.</p>
</li>
<li>Számítsuk ki az X tengely gyűrődési frekvenciáját <em>V</em> &middot; <em>N</em> / <em>D</em> (Hz), ahol <em>V</em> a külső kerületekre vonatkozó sebesség (mm/sec). A fenti példánál 6 rezgést jelöltünk meg, és a tesztet 100 mm/sec sebességgel nyomtattuk, így a frekvencia 100 * 6 / 12,14 ≈ 49,4 Hz.</li>
<li>A (8)-(10) pontokat az Y jel esetében is végezzük el.</li>
</ol>
</li>
</ol>
<p>Vedd figyelembe, hogy a próbanyomaton a gyűrődésnek a fenti képen látható íves bevágások mintáját kell követnie. Ha nem így van, akkor ez a hiba nem igazán gyűrődés, és más eredetű. Vagy mechanikai, vagy extruder probléma. Ezt kell először kijavítani, mielőtt engedélyeznénk és hangolnánk a bemeneti formázókat.</p>
<p>Ha a mérések nem megbízhatóak, mert például a rezgések közötti távolság nem stabil, az azt jelentheti, hogy a nyomtatónak több rezonanciafrekvenciája van ugyanazon a tengelyen. Megpróbálhatjuk helyette a <a href="#a-gyurodesi-frekvenciak-megbizhatatlan-meresei">A gyűrődési frekvenciák megbízhatatlan mérései</a> szakaszban leírt hangolási eljárást követni, és még mindig kaphatunk valami infót a bemeneti alakítási technikáról.</p>
<p>A gyűrődési frekvencia függhet a modell tárgyasztalon belüli helyzetétől és a Z magasságtól, <em>különösen a delta nyomtatóknál</em>; ellenőrizheted, hogy a tesztmodell oldalai mentén és különböző magasságokban különböző pozíciókban látsz-e különbséget a frekvenciákban. Ha ez a helyzet, akkor kiszámíthatod az X és Y tengelyen mért átlagos gyűrődési frekvenciákat.</p>

View File

@@ -2012,7 +2012,10 @@
<h2 id="exclude_object">exclude_object<a class="headerlink" href="#exclude_object" title="Permanent link">&para;</a></h2>
<p>A következő információk az <a href="Exclude_Object.html">exclude_object</a> objektumban találhatók:</p>
<ul>
<li><code>objektumok</code>: Az <code>EXCLUDE_OBJECT_DEFINE</code> parancs által megadott ismert objektumok tömbje. Ez ugyanaz az információ, amelyet az <code>EXCLUDE_OBJECT VERBOSE=1</code> parancs szolgáltat. A <code>center</code> és <code>polygon</code> mezők csak akkor lesznek jelen, ha az eredeti <code>EXCLUDE_OBJECT_DEFINE</code> parancsban szerepelnek.Íme egy JSON-minta:</li>
<li>
<p><code>objektumok</code>: Az <code>EXCLUDE_OBJECT_DEFINE</code> parancs által megadott ismert objektumok tömbje. Ez ugyanaz az információ, amelyet az <code>EXCLUDE_OBJECT VERBOSE=1</code> parancs szolgáltat. A <code>center</code> és <code>polygon</code> mezők csak akkor lesznek jelen, ha az eredeti <code>EXCLUDE_OBJECT_DEFINE</code> parancsban szerepelnek.</p>
<p>Íme egy JSON-minta:</p>
</li>
</ul>
<div class="highlight"><pre><span></span><code>[
{

File diff suppressed because one or more lines are too long

View File

@@ -2,267 +2,267 @@
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>None</loc>
<lastmod>2024-05-05</lastmod>
<lastmod>2024-05-06</lastmod>
<changefreq>daily</changefreq>
</url>
</urlset>

Binary file not shown.