Deploying to gh-pages from @ Klipper3d/klipper@434770eaf9 🚀
This commit is contained in:
KevinOConnor
@@ -1499,15 +1499,16 @@ z_hop_speed: 5
|
||||
<h2 id="modalita-di-output-bl-touch">Modalità di output BL-Touch<a class="headerlink" href="#modalita-di-output-bl-touch" title="Permanent link">¶</a></h2>
|
||||
<ul>
|
||||
<li>
|
||||
<p>Un BL-Touch V3.0 supporta l'impostazione di una modalità di uscita 5V o OPEN-DRAIN, un BL-Touch V3.1 supporta anche questo, ma può anche memorizzarlo nella sua EEPROM interna. Se la tua scheda controller ha bisogno del livello logico alto 5V fisso della modalità 5V, puoi impostare il parametro 'set_output_mode' nella sezione [bltouch] del file di configurazione della stampante su "5V".<strong><em> Utilizzare la modalità 5V solo se la linea di ingresso della scheda controller è tollerante a 5V. Ecco perché la configurazione di default di queste versioni BL-Touch è la modalità OPEN-DRAIN. Potresti potenzialmente danneggiare la CPU delle tue schede di controllo </em></strong></p>
|
||||
<p>Un BL-Touch V3.0 supporta l'impostazione di una modalità di uscita 5V o OPEN-DRAIN, un BL-Touch V3.1 supporta anche questo, ma può anche memorizzarlo nella sua EEPROM interna. Se la tua scheda controller ha bisogno del livello logico alto 5V fisso della modalità 5V, puoi impostare il parametro 'set_output_mode' nella sezione [bltouch] del file di configurazione della stampante su "5V".</p>
|
||||
<p><strong><em> Utilizzare la modalità 5V solo se la linea di ingresso della scheda controller è tollerante a 5V. Ecco perché la configurazione di default di queste versioni BL-Touch è la modalità OPEN-DRAIN. Potresti potenzialmente danneggiare la CPU delle tue schede di controllo </em></strong></p>
|
||||
<p>Quindi: se una scheda controller HA BISOGNO della modalità 5V ED è tollerante a 5V sulla sua linea del segnale di ingresso E se</p>
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>si dispone di un BL-Touch Smart V3.0, è necessario utilizzare il parametro 'set_output_mode: 5V' per garantire questa impostazione ad ogni avvio, poiché la sonda non ricorda l'impostazione necessaria.</li>
|
||||
<li>hai un BL-Touch Smart V3.1, puoi scegliere di usare 'set_output_mode: 5V' o memorizzare la modalità una volta usando un comando 'BLTOUCH_STORE MODE=5V' manualmente e NON usando il parametro 'set_output_mode:'.</li>
|
||||
<li>hai qualche altra sonda: alcune sonde hanno una traccia sul circuito stampato da tagliare o un ponticello da impostare per impostare (permanentemente) la modalità di uscita. In tal caso, omettere completamente il parametro 'set_output_mode'.
|
||||
Se hai una V3.1, non automatizzare o ripetere la memorizzazione della modalità di output per evitare di consumare la EEPROM della sonda. La BLTouch EEPROM è valida per circa 100.000 aggiornamenti. 100 memorizzazioni al giorno aggiungerebbero fino a circa 3 anni di attività prima di logorarlo. Pertanto, la memorizzazione della modalità di output in una V3.1 è progettata dal fornitore per essere un'operazione complicata (l'impostazione predefinita di fabbrica è una modalità OPEN DRAIN sicura) e non è adatta per essere emessa ripetutamente da qualsiasi slicer, macro o altro, esso è preferibilmente da utilizzare solo quando si integra per la prima volta la sonda nell'elettronica di una stampante.</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
@@ -1812,7 +1812,10 @@ adaptive_margin: 5
|
||||
</code></pre></div>
|
||||
|
||||
<ul>
|
||||
<li><code>adaptive_margin</code> <em>Default Value: 0</em> Margin (in mm) to add around the area of the bed used by the defined objects. The diagram below shows the adapted bed mesh area with an <code>adaptive_margin</code> of 5mm. The adapted mesh area (area in green) is computed as the used bed area (area in blue) plus the defined margin.<img alt="adaptive_bedmesh_margin" src="img/adaptive_bed_mesh_margin.svg" /></li>
|
||||
<li>
|
||||
<p><code>adaptive_margin</code> <em>Default Value: 0</em> Margin (in mm) to add around the area of the bed used by the defined objects. The diagram below shows the adapted bed mesh area with an <code>adaptive_margin</code> of 5mm. The adapted mesh area (area in green) is computed as the used bed area (area in blue) plus the defined margin.</p>
|
||||
<p><img alt="adaptive_bedmesh_margin" src="img/adaptive_bed_mesh_margin.svg" /></p>
|
||||
</li>
|
||||
</ul>
|
||||
<p>By nature, adaptive bed meshes use the objects defined by the Gcode file being printed. Therefore, it is expected that each Gcode file will generate a mesh that probes a different area of the print bed. Therefore, adapted bed meshes should not be re-used. The expectation is that a new mesh will be generated for each print if adaptive meshing is used.</p>
|
||||
<p>It is also important to consider that adaptive bed meshing is best used on machines that can normally probe the entire bed and achieve a maximum variance less than or equal to 1 layer height. Machines with mechanical issues that a full bed mesh normally compensates for may have undesirable results when attempting print moves <strong>outside</strong> of the probed area. If a full bed mesh has a variance greater than 1 layer height, caution must be taken when using adaptive bed meshes and attempting print moves outside of the meshed area.</p>
|
||||
|
||||
@@ -1481,14 +1481,15 @@ iface can0 can static
|
||||
</code></pre></div>
|
||||
|
||||
<ul>
|
||||
<li>The "bridge mcu" is not actually on the CAN bus. Messages to and from the bridge mcu will not be seen by other adapters that may be on the CAN bus.</li>
|
||||
<li>
|
||||
<p>The "bridge mcu" is not actually on the CAN bus. Messages to and from the bridge mcu will not be seen by other adapters that may be on the CAN bus.</p>
|
||||
<ul>
|
||||
<li>The available bandwidth to both the "bridge mcu" itself and all devices on the CAN bus is effectively limited by the CAN bus frequency. As a result, it is recommended to use a CAN bus frequency of 1000000 when using "USB to CAN bus bridge mode".Even at a CAN bus frequency of 1000000, there may not be sufficient bandwidth to run a <code>SHAPER_CALIBRATE</code> test if both the XY steppers and the accelerometer all communicate via a single "USB to CAN bus" interface.</li>
|
||||
<li>A USB to CAN bridge board will not appear as a USB serial device, it will not show up when running <code>ls /dev/serial/by-id</code>, and it can not be configured in Klipper's printer.cfg file with a <code>serial:</code> parameter. The bridge board appears as a "USB CAN adapter" and it is configured in the printer.cfg as a <a href="#configuring-klipper">CAN node</a>.</li>
|
||||
</ul>
|
||||
<p>The available bandwidth to both the "bridge mcu" itself and all devices on the CAN bus is effectively limited by the CAN bus frequency. As a result, it is recommended to use a CAN bus frequency of 1000000 when using "USB to CAN bus bridge mode".</p>
|
||||
<p>Even at a CAN bus frequency of 1000000, there may not be sufficient bandwidth to run a <code>SHAPER_CALIBRATE</code> test if both the XY steppers and the accelerometer all communicate via a single "USB to CAN bus" interface.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>A USB to CAN bridge board will not appear as a USB serial device, it will not show up when running <code>ls /dev/serial/by-id</code>, and it can not be configured in Klipper's printer.cfg file with a <code>serial:</code> parameter. The bridge board appears as a "USB CAN adapter" and it is configured in the printer.cfg as a <a href="#configuring-klipper">CAN node</a>.</li>
|
||||
</ul>
|
||||
<h2 id="tips-for-troubleshooting">Tips for troubleshooting<a class="headerlink" href="#tips-for-troubleshooting" title="Permanent link">¶</a></h2>
|
||||
<p>See the <a href="CANBUS_Troubleshooting.html">CAN bus troubleshooting</a> document.</p>
|
||||
|
||||
|
||||
@@ -1447,7 +1447,8 @@
|
||||
<p>Cose comuni che un revisore cercherà:</p>
|
||||
<ol>
|
||||
<li>
|
||||
<p>L'invio è privo di difetti ed è pronto per essere diffuso?I realizzatori dei contributi sono tenuti a testare le loro modifiche prima dell'invio. I revisori cercano gli errori, ma in generale non testano gli invii. Un invio accettato viene spesso distribuito a migliaia di stampanti entro poche settimane dall'accettazione. La qualità degli invii è quindi considerata una priorità.</p>
|
||||
<p>L'invio è privo di difetti ed è pronto per essere diffuso?</p>
|
||||
<p>I realizzatori dei contributi sono tenuti a testare le loro modifiche prima dell'invio. I revisori cercano gli errori, ma in generale non testano gli invii. Un invio accettato viene spesso distribuito a migliaia di stampanti entro poche settimane dall'accettazione. La qualità degli invii è quindi considerata una priorità.</p>
|
||||
<p>Il repository GitHub principale <a href="https://github.com/Klipper3d/klipper">Klipper3d/klipper</a> non accetta lavori sperimentali. I realizzatori di contributi devono eseguire la sperimentazione, il debug e il test nei propri repository. Il server <a href="Contact.html">Klipper Discourse</a> è un buon posto per aumentare la consapevolezza del nuovo lavoro e per trovare utenti interessati a fornire feedback nel mondo reale.</p>
|
||||
<p>Gli invii devono superare tutti i <a href="Debugging.html">test di regressione</a>.</p>
|
||||
<p>Quando si corregge un difetto nel codice, i submitters dovrebbero avere una comprensione generale della causa principale di tale difetto e la correzione dovrebbe mirare a tale causa principale.</p>
|
||||
@@ -1456,7 +1457,8 @@
|
||||
<p>Gli aggiornamenti alla documentazione non devono dichiarare che si tratta di un "work in progress".</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>L'invio fornisce un vantaggio "ad alto impatto" per gli utenti del mondo reale che svolgono attività nel mondo reale?I revisori devono identificare, almeno nella loro mente, approssimativamente "chi è il pubblico di destinazione", una scala approssimativa delle "dimensioni di quel pubblico", il "beneficio" che otterranno, come "il beneficio viene misurato" e i "risultati di tali prove di misurazione". Nella maggior parte dei casi questo sarà ovvio sia per il mittente che per il revisore e non è esplicitamente dichiarato durante una revisione.</p>
|
||||
<p>L'invio fornisce un vantaggio "ad alto impatto" per gli utenti del mondo reale che svolgono attività nel mondo reale?</p>
|
||||
<p>I revisori devono identificare, almeno nella loro mente, approssimativamente "chi è il pubblico di destinazione", una scala approssimativa delle "dimensioni di quel pubblico", il "beneficio" che otterranno, come "il beneficio viene misurato" e i "risultati di tali prove di misurazione". Nella maggior parte dei casi questo sarà ovvio sia per il mittente che per il revisore e non è esplicitamente dichiarato durante una revisione.</p>
|
||||
<p>Le proposte al ramo principale di Klipper dovrebbero avere un pubblico di destinazione degno di nota. Come "regola pratica" generale, gli invii dovrebbero avere come target una base di utenti di almeno 100 utenti del mondo reale.</p>
|
||||
<p>Se un revisore chiede dettagli sul "beneficio" di un invio, non considerarlo una critica. Essere in grado di comprendere i vantaggi reali di un cambiamento è una parte naturale di una revisione.</p>
|
||||
<p>Quando si discute dei benefici è preferibile discutere di "fatti e misurazioni". In generale, i revisori non cercano risposte del modulo "qualcuno potrebbe trovare utile l'opzione X", né cercano risposte del modulo "questo invio aggiunge una funzionalità implementata dal firmware X". Invece, è generalmente preferibile discutere i dettagli su come è stato misurato il miglioramento della qualità e quali sono stati i risultati di tali misurazioni, ad esempio "i test sulle stampanti Acme X1000 mostrano angoli migliorati come si vede in figura...", o ad esempio " il tempo di stampa dell'oggetto reale X su una stampante Foomatic X900 è passato da 4 ore a 3,5 ore". Resta inteso che i test di questo tipo possono richiedere molto tempo e sforzi. Alcune delle caratteristiche più importanti di Klipper hanno richiesto mesi di discussioni, rielaborazioni, test e documentazione prima di essere fuse nel ramo principale.</p>
|
||||
@@ -1466,17 +1468,18 @@
|
||||
<p>Nuovi moduli, nuove opzioni e nuovi parametri non dovrebbero fornire funzionalità simili ai moduli esistenti: se le differenze sono arbitrarie, è preferibile utilizzare il sistema esistente o effettuare refactoring del codice esistente.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Il copyright dell'invio è chiaro, non gratuito e compatibile?I nuovi file C e Python dovrebbero avere una dichiarazione di copyright univoca. Vedere i file esistenti per il formato preferito. È sconsigliato dichiarare un copyright su un file esistente quando si apportano modifiche minori a quel file.</p>
|
||||
<p>Il copyright dell'invio è chiaro, non gratuito e compatibile?</p>
|
||||
<p>I nuovi file C e Python dovrebbero avere una dichiarazione di copyright univoca. Vedere i file esistenti per il formato preferito. È sconsigliato dichiarare un copyright su un file esistente quando si apportano modifiche minori a quel file.</p>
|
||||
<p>Il codice prelevato da fonti di terze parti deve essere compatibile con la licenza Klipper (GNU GPLv3). Grandi aggiunte di codice di terze parti dovrebbero essere aggiunte alla directory <code>lib/</code> (e seguire il formato descritto in <a href="https://github.com/Klipper3d/klipper/blob/master/lib/README">lib/README</a>).</p>
|
||||
<p>I mittenti devono fornire una <a href="#format-of-commit-messages">Signed-off-line</a> utilizzando il loro vero nome completo. Indica che il mittente è d'accordo con il <a href="developer-certificate-of-origin">developer certificate of origin</a>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>L'invio segue le linee guida specificate nella documentazione di Klipper?In particolare, il codice deve seguire le linee guida in <Code_Overview.md> e i file di configurazione devono seguire le linee guida in <Example_Configs.md>.</p>
|
||||
<p>L'invio segue le linee guida specificate nella documentazione di Klipper?</p>
|
||||
<p>In particolare, il codice deve seguire le linee guida in <Code_Overview.md> e i file di configurazione devono seguire le linee guida in <Example_Configs.md>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>La documentazione di Klipper è aggiornata per riflettere le nuove modifiche?Come minimo, la documentazione di riferimento deve essere aggiornata con le relative modifiche al codice:</p>
|
||||
</li>
|
||||
</ol>
|
||||
<p>La documentazione di Klipper è aggiornata per riflettere le nuove modifiche?</p>
|
||||
<p>Come minimo, la documentazione di riferimento deve essere aggiornata con le relative modifiche al codice:</p>
|
||||
<ul>
|
||||
<li>Tutti i comandi e i relativi parametri devono essere documentati in <G-Codes.md>.</li>
|
||||
<li>Tutti i moduli rivolti all'utente e i relativi parametri di configurazione devono essere documentati in <Config_Reference.md>.</li>
|
||||
@@ -1484,10 +1487,13 @@
|
||||
<li>Tutti i nuovi "webhook" e i relativi parametri devono essere documentati in <API_Server.md>.</li>
|
||||
<li>Qualsiasi modifica che apporti una modifica non compatibile con le versioni precedenti a un comando o a un'impostazione del file di configurazione deve essere documentata in <Config_Changes.md>.</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ol>
|
||||
<p>I nuovi documenti dovrebbero essere aggiunti a <Overview.md> e all'indice del sito web <a href="https://github.com/Klipper3d/klipper/blob/master/docs/_klipper3d/mkdocs.yml">docs/_klipper3d/mkdocs.yml</a>.</p>
|
||||
<ol>
|
||||
<li>
|
||||
<p>I commit sono ben formati, affrontano un singolo argomento per commit e sono indipendenti?I messaggi di commit devono seguire il <a href="#format-of-commit-messages">formato preferito</a>.</p>
|
||||
<p>I commit sono ben formati, affrontano un singolo argomento per commit e sono indipendenti?</p>
|
||||
<p>I messaggi di commit devono seguire il <a href="#format-of-commit-messages">formato preferito</a>.</p>
|
||||
<p>I commit non devono avere un conflitto in fase di merge. Le nuove aggiunte al ramo principale di Klipper vengono sempre eseguite tramite un "rebase" o "squash and rebase". In genere non è necessario che i propositori uniscano nuovamente il loro invio ad ogni aggiornamento al repository principale di Klipper. Tuttavia, se c'è un conflitto in fase di merge, si consiglia ai mittenti di usare <code>git rebase</code> per risolvere il conflitto.</p>
|
||||
<p>Ogni commit dovrebbe affrontare una singola modifica di alto livello. Le modifiche di grandi dimensioni dovrebbero essere suddivise in più commit indipendenti. Ogni commit dovrebbe "stare in piedi da solo" in modo che strumenti come <code>git bisect</code> e <code>git revert</code> funzionino in modo affidabile.</p>
|
||||
<p>Le modifiche agli spazi bianchi non devono essere mescolate con le modifiche funzionali. In generale, le modifiche agli spazi bianchi gratuite non sono accettate a meno che non provengano dal "proprietario" stabilito del codice da modificare.</p>
|
||||
|
||||
@@ -1484,21 +1484,23 @@
|
||||
<p>Un tipico movimento della stampante inizia quando viene inviato un comando "G1" all'host Klippy e si completa quando vengono prodotti i corrispondenti impulsi di passo sul microcontrollore. Questa sezione delinea il flusso di codice di un tipico comando di spostamento. Il documento <a href="Kinematics.html">cinematica</a> fornisce ulteriori informazioni sulla meccanica dei movimenti.</p>
|
||||
<ul>
|
||||
<li>L'elaborazione di un comando di spostamento inizia in gcode.py. L'obiettivo di gcode.py è tradurre il G-code in chiamate interne. Un comando G1 invocherà cmd_G1() in klippy/extras/gcode_move.py. Il codice gcode_move.py gestisce le modifiche all'origine (ad esempio, G92), le modifiche alle posizioni relative rispetto a quelle assolute (ad esempio, G90) e le modifiche alle unità (ad esempio, F6000=100mm/s). Il percorso del codice per una mossa è: <code>_process_data() -> _process_commands() -> cmd_G1()</code>. Infine viene invocata la classe ToolHead per eseguire la richiesta effettiva: <code>cmd_G1() -> ToolHead.move()</code></li>
|
||||
<li>The ToolHead class (in toolhead.py) handles "look-ahead" and tracks the timing of printing actions. The main codepath for a move is: <code>ToolHead.move() -> LookAheadQueue.add_move() -> LookAheadQueue.flush() -> Move.set_junction() -> ToolHead._process_moves()</code>.<ul>
|
||||
<li>
|
||||
<p>The ToolHead class (in toolhead.py) handles "look-ahead" and tracks the timing of printing actions. The main codepath for a move is: <code>ToolHead.move() -> LookAheadQueue.add_move() -> LookAheadQueue.flush() -> Move.set_junction() -> ToolHead._process_moves()</code>.</p>
|
||||
<ul>
|
||||
<li>ToolHead.move() crea un oggetto Move() con i parametri del movimento (in spazio cartesiano e in unità di secondi e millimetri).</li>
|
||||
<li>Alla classe cinematica viene data l'opportunità di controllare ogni movimento (<code>ToolHead.move() -> kin.check_move()</code>). Le classi cinematiche si trovano nella directory klippy/cinematica/. Il codice check_move() può generare un errore se il movimento non è valida. Se check_move() viene completato correttamente, la cinematica sottostante deve essere in grado di gestire lo spostamento.</li>
|
||||
<li>LookAheadQueue.add_move() places the move object on the "look-ahead" queue.</li>
|
||||
<li>LookAheadQueue.flush() determines the start and end velocities of each move.</li>
|
||||
<li>Move.set_junction() implementa il "generatore di trapezi" per il movimento. Il "generatore trapezoidale" suddivide ogni movimento in tre parti: una fase di accelerazione costante, seguita da una fase di velocità costante, seguita da una fase di decelerazione costante. Ogni mossa contiene queste tre fasi in questo ordine, ma alcune fasi possono avere durata zero.</li>
|
||||
<li>Quando viene chiamato ToolHead._process_moves(), tutto ciò che riguarda lo spostamento è noto: la sua posizione iniziale, la sua posizione finale, la sua accelerazione, la sua velocità di inizio/crociera/finale e la distanza percorsa durante l'accelerazione/crociera/decelerazione. Tutte le informazioni sono memorizzate nella classe Move() e sono nello spazio cartesiano in unità di millimetri e secondi.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Klipper uses an <a href="https://en.wikipedia.org/wiki/Root-finding_algorithm">iterative solver</a> to generate the step times for each stepper. For efficiency reasons, the stepper pulse times are generated in C code. The moves are first placed on a "trapezoid motion queue": <code>ToolHead._process_moves() -> trapq_append()</code> (in klippy/chelper/trapq.c). The step times are then generated: <code>ToolHead._process_moves() -> ToolHead._advance_move_time() -> ToolHead._advance_flush_time() -> MCU_Stepper.generate_steps() -> itersolve_generate_steps() -> itersolve_gen_steps_range()</code> (in klippy/chelper/itersolve.c). The goal of the iterative solver is to find step times given a function that calculates a stepper position from a time. This is done by repeatedly "guessing" various times until the stepper position formula returns the desired position of the next step on the stepper. The feedback produced from each guess is used to improve future guesses so that the process rapidly converges to the desired time. The kinematic stepper position formulas are located in the klippy/chelper/ directory (eg, kin_cart.c, kin_corexy.c, kin_delta.c, kin_extruder.c).</li>
|
||||
<li>Si noti che l'estrusore è gestito nella propria classe cinematica: <code>ToolHead._process_moves() -> PrinterExtruder.move()</code>. Poiché la classe Move() specifica l'esatto tempo di movimento e poiché gli impulsi di passo vengono inviati al microcontrollore con una tempistica specifica, i movimenti passo-passo prodotti dalla classe estrusore saranno sincronizzati con il movimento della testa anche se il codice viene mantenuto separato.</li>
|
||||
<li>Dopo che il risolutore iterativo ha calcolato i tempi di passaggio, questi vengono aggiunti a un array: <code>itersolve_gen_steps_range() -> stepcompress_append()</code> (in klippy/chelper/stepcompress.c). L'array (struct stepcompress.queue) memorizza i corrispondenti tempi del contatore dell'orologio del microcontrollore per ogni passaggio. Qui il valore del "contatore orologio del microcontrollore" corrisponde direttamente al contatore hardware del microcontrollore - è relativo a quando il microcontrollore è stato acceso l'ultima volta.</li>
|
||||
<li>Il prossimo passo importante è comprimere i passaggi: <code>stepcompress_flush() -> compress_bisect_add()</code> (in klippy/chelper/stepcompress.c). Questo codice genera e codifica una serie di comandi "queue_step" del microcontrollore che corrispondono all'elenco dei tempi di stepper compilati nella fase precedente. Questi comandi "queue_step" vengono quindi accodati, assegnati a priorità e inviati al microcontrollore (tramite stepcompress.c:steppersync e serialqueue.c:serialqueue).</li>
|
||||
<li>L'elaborazione dei comandi queue_step sul microcontrollore inizia in src/command.c che analizza il comando e chiama <code>command_queue_step()</code>. Il codice command_queue_step() (in src/stepper.c) aggiunge semplicemente i parametri di ogni comando queue_step a una coda per stepper. In condizioni normali, il comando queue_step viene analizzato e messo in coda almeno 100 ms prima dell'ora del suo primo passaggio. Infine, la generazione degli eventi stepper viene eseguita in <code>stepper_event()</code>. Viene chiamato dall'interruzione del timer hardware all'ora pianificata del primo passaggio. Il codice stepper_event() genera un impulso di passaggio e quindi si riprogramma per essere eseguito al momento dell'impulso di passaggio successivo per i parametri queue_step specificati. I parametri per ogni comando queue_step sono "interval", "count" e "add". Ad alto livello, stepper_event() esegue quanto segue, 'count' volte: <code>do_step(); next_wake_time = last_wake_time + intervallo; intervallo += aggiungi;</code></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Quanto sopra può sembrare un sacco di complessità per eseguire un movimento. Tuttavia, le uniche parti veramente interessanti sono nelle classi ToolHead e cinematica. È questa parte del codice che specifica i movimenti e le loro tempistiche. Le restanti parti dell'elaborazione sono per lo più solo comunicazioni e collegamenti.</p>
|
||||
<h2 id="aggiunta-di-un-modulo-host">Aggiunta di un modulo host<a class="headerlink" href="#aggiunta-di-un-modulo-host" title="Permanent link">¶</a></h2>
|
||||
<p>Il codice host Klippy ha una capacità di caricamento dinamico dei moduli. Se nel file di configurazione della stampante viene trovata una sezione di configurazione denominata "[my_module]", il software tenterà automaticamente di caricare il modulo python klippy/extras/my_module.py . Questo sistema di moduli è il metodo preferito per aggiungere nuove funzionalità a Klipper.</p>
|
||||
|
||||
@@ -1621,16 +1621,17 @@
|
||||
<li>Se hai già aggiunto la sezione <code>[input_shaper]</code> a printer.cfg, esegui il comando <code>SET_INPUT_SHAPER SHAPER_FREQ_X=0 SHAPER_FREQ_Y=0</code>. Se ricevi l'errore "Comando sconosciuto- Unknown command", puoi tranquillamente ignorarlo a questo punto e continuare con le misurazioni.</li>
|
||||
<li>Eseguire il comando: <code>TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL START=1500 STEP_DELTA=500 STEP_HEIGHT=5</code> Fondamentalmente, cerchiamo di rendere più pronunciato il ringing impostando diversi valori elevati per l'accelerazione. Questo comando aumenterà l'accelerazione ogni 5 mm a partire da 1500 mm/sec^2: 1500 mm/sec^2, 2000 mm/sec^2, 2500 mm/sec^2 e così via fino a 7000 mm/sec^2 per l'ultima fascia.</li>
|
||||
<li>Stampa il modello di test sliced con i parametri suggeriti.</li>
|
||||
<li>Puoi interrompere la stampa prima se il ringing è chiaramente visibile e vedi che l'accelerazione diventa troppo alta per la tua stampante (ad es. la stampante trema troppo o inizia a saltare i passaggi).</li>
|
||||
<li>
|
||||
<p>Puoi interrompere la stampa prima se il ringing è chiaramente visibile e vedi che l'accelerazione diventa troppo alta per la tua stampante (ad es. la stampante trema troppo o inizia a saltare i passaggi).</p>
|
||||
<ol>
|
||||
<li>Utilizzare i segni X e Y sul retro del modello come riferimento. Le misurazioni dal lato con il contrassegno X devono essere utilizzate per la <em>configurazione</em> dell'asse X e il contrassegno Y - per la configurazione dell'asse Y. Misurare la distanza <em>D</em> (in mm) tra più oscillazioni sulla parte con il segno X, in prossimità delle tacche, preferibilmente saltando la prima o due oscillazioni. Per misurare più facilmente la distanza tra le oscillazioni, contrassegnare prima le oscillazioni, quindi misurare la distanza tra i segni con un righello o un calibro:|<img alt="Mark ringing" src="img/ringing-mark.jpg" />|<img alt="Measure ringing" src="img/ringing-measure.jpg" />|</li>
|
||||
<li>Contare a quante oscillazioni <em>N</em> corrisponde la distanza misurata <em>D</em>. Se non sei sicuro di come contare le oscillazioni, fai riferimento all'immagine sopra, che mostra <em>N</em> = 6 oscillazioni.</li>
|
||||
<p>Utilizzare i segni X e Y sul retro del modello come riferimento. Le misurazioni dal lato con il contrassegno X devono essere utilizzate per la <em>configurazione</em> dell'asse X e il contrassegno Y - per la configurazione dell'asse Y. Misurare la distanza <em>D</em> (in mm) tra più oscillazioni sulla parte con il segno X, in prossimità delle tacche, preferibilmente saltando la prima o due oscillazioni. Per misurare più facilmente la distanza tra le oscillazioni, contrassegnare prima le oscillazioni, quindi misurare la distanza tra i segni con un righello o un calibro:</p>
|
||||
<p>|<img alt="Mark ringing" src="img/ringing-mark.jpg" />|<img alt="Measure ringing" src="img/ringing-measure.jpg" />|</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Contare a quante oscillazioni <em>N</em> corrisponde la distanza misurata <em>D</em>. Se non sei sicuro di come contare le oscillazioni, fai riferimento all'immagine sopra, che mostra <em>N</em> = 6 oscillazioni.</p>
|
||||
</li>
|
||||
<li>Calcola la frequenza di squillo dell'asse X come <em>V</em> · <em>N</em> / <em>D</em> (Hz), dove <em>V</em> è la velocità per i perimetri esterni (mm/sec). Per l'esempio sopra, abbiamo contrassegnato 6 oscillazioni e il test è stato stampato a una velocità di 100 mm/sec, quindi la frequenza è 100 * 6 / 12,14 ≈ 49,4 Hz.</li>
|
||||
<li>Esegui (8) - (10) anche per il segno Y.</li>
|
||||
</ol>
|
||||
</li>
|
||||
</ol>
|
||||
<p>Si noti che il ringing sulla stampa di prova dovrebbe seguire lo schema delle tacche curve, come nell'immagine sopra. In caso contrario, questo difetto non è in realtà un ringing e ha un'origine diversa: un problema meccanico o dell'estrusore. Dovrebbe essere risolto prima di abilitare e regolare gli shaper di input.</p>
|
||||
<p>Se le misurazioni non sono affidabili perché, ad esempio, la distanza tra le oscillazioni non è stabile, potrebbe significare che la stampante ha più frequenze di risonanza sullo stesso asse. Si può invece provare a seguire il processo di sintonizzazione descritto nella sezione <a href="#unreliable-measurements-of-ringing-frequencies">Misurazioni inaffidabili delle frequenze di ringing</a> e ottenere comunque qualcosa dalla tecnica di input shaping .</p>
|
||||
<p>La frequenza dei ringing può dipendere dalla posizione del modello all'interno della piastra di stampa e dall'altezza Z, <em>soprattutto sulle stampanti delta</em>; puoi controllare se vedi le differenze di frequenza in diverse posizioni lungo i lati del modello di prova e ad altezze diverse. È possibile calcolare le frequenze di squillo medie sugli assi X e Y, se questo è il caso.</p>
|
||||
|
||||
@@ -2012,7 +2012,10 @@
|
||||
<h2 id="exclude_object">exclude_object<a class="headerlink" href="#exclude_object" title="Permanent link">¶</a></h2>
|
||||
<p>Le seguenti informazioni sono disponibili nell'oggetto <a href="Exclude_Object.html">exclude_object</a>:</p>
|
||||
<ul>
|
||||
<li><code>objects</code>: un array di oggetti conosciuti come fornito dal comando <code>EXCLUDE_OBJECT_DEFINE</code>. Queste sono le stesse informazioni fornite dal comando <code>EXCLUDE_OBJECT VERBOSE=1</code>. I campi <code>center</code> e <code>polygon</code> saranno presenti solo se forniti nell'originale <code>EXCLUDE_OBJECT_DEFINE</code>Ecco un esempio JSON:</li>
|
||||
<li>
|
||||
<p><code>objects</code>: un array di oggetti conosciuti come fornito dal comando <code>EXCLUDE_OBJECT_DEFINE</code>. Queste sono le stesse informazioni fornite dal comando <code>EXCLUDE_OBJECT VERBOSE=1</code>. I campi <code>center</code> e <code>polygon</code> saranno presenti solo se forniti nell'originale <code>EXCLUDE_OBJECT_DEFINE</code></p>
|
||||
<p>Ecco un esempio JSON:</p>
|
||||
</li>
|
||||
</ul>
|
||||
<div class="highlight"><pre><span></span><code>[
|
||||
{
|
||||
|
||||
Binary file not shown.
File diff suppressed because one or more lines are too long
106
it/sitemap.xml
106
it/sitemap.xml
@@ -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.
Reference in New Issue
Block a user