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

it/Code_Overview.html

@@ -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() -&gt; _process_commands() -&gt; cmd_G1()</code>. Infine viene invocata la classe ToolHead per eseguire la richiesta effettiva: <code>cmd_G1() -&gt; 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() -&gt; LookAheadQueue.add_move() -&gt; LookAheadQueue.flush() -&gt; Move.set_junction() -&gt; 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() -&gt; LookAheadQueue.add_move() -&gt; LookAheadQueue.flush() -&gt; Move.set_junction() -&gt; 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() -&gt; 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() -&gt; trapq_append()</code> (in klippy/chelper/trapq.c). The step times are then generated: <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). 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() -&gt; 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() -&gt; 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() -&gt; 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">&para;</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>