diff --git a/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc b/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc
index 13c05bdf2bf8..73525b949fa0 100644
Binary files a/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc and b/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc differ
diff --git a/fr/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc b/fr/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc
index 13c05bdf2bf8..73525b949fa0 100644
Binary files a/fr/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc and b/fr/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc differ
diff --git a/fr/sitemap.xml b/fr/sitemap.xml
index 43bfc903d2e1..94b20dc6ddd9 100644
--- a/fr/sitemap.xml
+++ b/fr/sitemap.xml
@@ -2,267 +2,267 @@
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
\ No newline at end of file
diff --git a/fr/sitemap.xml.gz b/fr/sitemap.xml.gz
index dd40ed72384d..6e36b7260620 100644
Binary files a/fr/sitemap.xml.gz and b/fr/sitemap.xml.gz differ
diff --git a/hu/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc b/hu/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc
index 13c05bdf2bf8..73525b949fa0 100644
Binary files a/hu/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc and b/hu/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc differ
diff --git a/hu/sitemap.xml b/hu/sitemap.xml
index 43bfc903d2e1..94b20dc6ddd9 100644
--- a/hu/sitemap.xml
+++ b/hu/sitemap.xml
@@ -2,267 +2,267 @@
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
None
- 2024-02-21
+ 2024-02-22
daily
\ No newline at end of file
diff --git a/hu/sitemap.xml.gz b/hu/sitemap.xml.gz
index f62b1f76c1b0..387e4552a1d6 100644
Binary files a/hu/sitemap.xml.gz and b/hu/sitemap.xml.gz differ
diff --git a/it/Overview.html b/it/Overview.html
index 611fa114aa4c..83a3c3160562 100644
--- a/it/Overview.html
+++ b/it/Overview.html
@@ -1374,7 +1374,7 @@
Panoramica
-Benvenuto nella documentazione di Klipper. Se sei nuovo di Klipper, inizia con i documenti features e installation.
+Benvenuto nella documentazione di Klipper. Se sei nuovo di Klipper, inizia con la documentazione su features e istallazione.
- Caratteristiche: un elenco di funzionalità di alto livello in Klipper.
@@ -1394,11 +1394,11 @@ Installazione e configurazioneLivello del piatto: Informazioni sul "livellamento del piatto" in Klipper.
- Compensazione della risonanza: Uno strumento per ridurre le risonanze nelle stampe.
@@ -1420,7 +1420,7 @@
-- Panoramica del codice: Gli sviluppatori dovrebbero leggere prima questo.
+- Panoramica codice: Gli sviluppatori dovrebbero leggere prima questo.
- Cinematica: Dettagli tecnici su come Klipper implementa il movimento.
- Protocollo: Informazioni sul protocollo di messaggistica di basso livello tra host e microcontrollore.
- Server API: Informazioni sulle API di comando e controllo di Klipper.
@@ -1438,9 +1438,9 @@ Documenti specifici del dispositivo
- Raspberry Pi come microcontrollore: Dettagli per controllare i dispositivi collegati ai pin GPIO di un Raspberry Pi.
- Beaglebone: Dettagli per l'esecuzione di Klipper sulla PRU Beaglebone.
- Bootloaders: Informazioni per gli sviluppatori sul flashing del microcontrollore.
-- Bootloader Entry: Requesting the bootloader.
+- Bootloader Entry: Richiedere il bootloader.
- CAN bus: Informazioni sull'uso del CAN bus con Klipper.
- Sensore larghezza filamento TSL1401CL
diff --git a/it/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc b/it/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc
index 13c05bdf2bf8..73525b949fa0 100644
Binary files a/it/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc and b/it/_klipper3d/__pycache__/mkdocs_hooks.cpython-38.pyc differ
diff --git a/it/search/search_index.json b/it/search/search_index.json
index 032c0fd90bf2..8190b8702983 100644
--- a/it/search/search_index.json
+++ b/it/search/search_index.json
@@ -1 +1 @@
-{"config":{"indexing":"full","lang":["it"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"index.html","text":"Klipper \u00e8 un firmware per stampanti 3D. Combina la potenza di un computer con uno o pi\u00f9 microntrollori. Leggi la pagina sulle funzionalit\u00e0 per avere pi\u00f9 informazioni sul perch\u00e9 usare Klipper. Per iniziare ad usare Klipper comincia con la sua installazione . Klipper \u00e8 un software libero. Leggi la documentazione o visualizza il codice Klipper su github . Dipendiamo dal generoso supporto dei nostri sponsor .","title":"Benvenuto"},{"location":"API_Server.html","text":"Server API \u00b6 Questo documento descrive l'Application Programmer Interface (API) di Klipper. Questa interfaccia consente alle applicazioni esterne di interrogare e controllare il software host Klipper. Abilitazione del socket API \u00b6 Per utilizzare il server API, il software host klippy.py deve essere avviato con il parametro -a . Per esempio: ~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer.cfg -a /tmp/klippy_uds -l /tmp/klippy.log Ci\u00f2 fa s\u00ec che il software host crei un socket di dominio Unix. Un client pu\u00f2 quindi aprire una connessione su quel socket e inviare comandi a Klipper. Consulta il progetto Moonraker per uno strumento popolare in grado di inoltrare richieste HTTP all'API Server Unix Domain Socket di Klipper. Formato richiesta \u00b6 I messaggi inviati e ricevuti sul socket sono stringhe codificate JSON terminate da un carattere ASCII 0x03: <0x03><0x03>... Klipper contiene uno strumento scripts/whconsole.py che pu\u00f2 eseguire il framing dei messaggi sopra. Per esempio: ~/klipper/scripts/whconsole.py /tmp/klippy_uds Questo strumento pu\u00f2 leggere una serie di comandi JSON da stdin, inviarli a Klipper e riportare i risultati. Lo strumento prevede che ogni comando JSON si trovi su una singola riga e aggiunger\u00e0 automaticamente il terminatore 0x03 durante la trasmissione di una richiesta. (Il server dell'API Klipper non ha un requisito di newline.) Protocollo API \u00b6 Il protocollo dei comandi utilizzato sul socket di comunicazione \u00e8 ispirato a json-rpc . Una richiesta potrebbe essere simile a: {\"id\": 123, \"method\": \"info\", \"params\": {}} e una risposta potrebbe essere simile a: {\"id\": 123, \"result\": {\"state_message\": \"Printer is ready\", \"klipper_path\": \"/home/pi/klipper\", \"config_file\": \"/home/pi/printer.cfg\", \"software_version\": \"v0.8.0-823-g883b1cb6\", \"hostname\": \"octopi\", \"cpu_info\": \"4 core ARMv7 Processor rev 4 (v7l)\", \"state\": \"ready\", \"python_path\": \"/home/pi/klippy-env/bin/python\", \"log_file\": \"/tmp/klippy.log\"}} Ogni richiesta deve essere un dizionario JSON. (Questo documento usa il termine Python \"dizionario\" per descrivere un \"oggetto JSON\" - una mappatura di coppie chiave/valore contenute in {} .) Il dizionario di richiesta deve contenere un parametro \"method\" che \u00e8 il nome stringa di un \"endpoint\" di Klipper disponibile. Il dizionario della richiesta pu\u00f2 contenere un parametro \"params\" che deve essere di tipo dizionario. I \"parametri\" forniscono ulteriori informazioni sui parametri all'\"endpoint\" di Klipper che gestisce la richiesta. Il suo contenuto \u00e8 specifico dell'\"endpoint\". Il dizionario delle richieste pu\u00f2 contenere un parametro \"id\" che pu\u00f2 essere di qualsiasi tipo JSON. Se \u00e8 presente \"id\", Klipper risponder\u00e0 alla richiesta con un messaggio di risposta contenente tale \"id\". Se \"id\" viene omesso (o impostato su un valore JSON \"null\"), Klipper non fornir\u00e0 alcuna risposta alla richiesta. Un messaggio di risposta \u00e8 un dizionario JSON contenente \"id\" e \"result\". Il \"risultato\" \u00e8 sempre un dizionario: i suoi contenuti sono specifici dell'\"endpoint\" che gestisce la richiesta. Se l'elaborazione di una richiesta genera un errore, il messaggio di risposta conterr\u00e0 un campo \"errore\" anzich\u00e9 un campo \"risultato\". Ad esempio, la richiesta: {\"id\": 123, \"method\": \"gcode/script\", \"params\": {\"script\": \"G1 X200\"}} potrebbe generare una risposta di errore come: {\"id\": 123, \"error\": {\"message\": \"Deve prima posizionare l'asse: 200.000 0.000 0.000 [0.000]\", \"error\": \"WebRequestError\"}} Klipper inizier\u00e0 sempre a elaborare le richieste nell'ordine in cui sono state ricevute. Tuttavia, alcune richieste potrebbero non essere completate immediatamente, il che potrebbe causare l'invio di una risposta associata non conforme rispetto alle risposte di altre richieste. Una richiesta JSON non sospender\u00e0 mai l'elaborazione di future richieste JSON. Sottoscrizioni \u00b6 Alcune richieste di \"endpoint\" di Klipper consentono di \"iscriversi\" a futuri messaggi di aggiornamento asincrono. Per esempio: {\"id\": 123, \"method\": \"gcode/subscribe_output\", \"params\": {\"response_template\":{\"key\": 345}}} inizialmente pu\u00f2 rispondere con: {\"id\": 123, \"result\": {}} e fare in modo che Klipper invii messaggi futuri simili a: {\"params\": {\"response\": \"ok B:22.8 /0.0 T0:22.4 /0.0\"}, \"key\": 345} Una richiesta di sottoscrizione accetta un dizionario \"response_template\" nel campo \"params\" della richiesta. Quel dizionario \"response_template\" viene utilizzato come modello per futuri messaggi asincroni: pu\u00f2 contenere coppie chiave/valore arbitrarie. Quando invier\u00e0 questi futuri messaggi asincroni, Klipper aggiunger\u00e0 un campo \"params\" contenente un dizionario con contenuti specifici per \"endpoint\" al modello di risposta e quindi invier\u00e0 quel modello. Se non viene fornito un campo \"response_template\", il valore predefinito \u00e8 un dizionario vuoto ( {} ). \"endpoint\" disponibili \u00b6 Per convenzione, gli \"endpoint\" di Klipper sono nella forma / . Quando si effettua una richiesta a un \"endpoint\", il nome completo deve essere impostato nel parametro \"method\" del dizionario di richiesta (ad esempio, {\"method\"=\"gcode/restart\"} ). info \u00b6 L'endpoint \"info\" viene utilizzato per ottenere informazioni sul sistema e sulla versione da Klipper. Viene anche utilizzato per fornire a Klipper le informazioni sulla versione del client. Ad esempio: {\"id\": 123, \"method\": \"info\", \"params\": { \"client_info\": { \"version\": \"v1\"}}} Se presente, il parametro \"client_info\" deve essere un dizionario, ma quel dizionario potrebbe avere contenuti arbitrari. I clienti sono incoraggiati a fornire il nome del client e la sua versione del software quando si connettono per la prima volta al server dell'API Klipper. emergency_stop \u00b6 L'endpoint \"emergency_stop\" viene utilizzato per indicare a Klipper di passare allo stato di \"spegnimento\". Si comporta in modo simile al comando G-Code M112 . Ad esempio: {\"id\": 123, \"method\": \"emergency_stop\"} register_remote_method \u00b6 Questo endpoint consente ai client di registrare metodi che possono essere chiamati da klipper. Restituir\u00e0 un oggetto vuoto in caso di successo. Per esempio: {\"id\": 123, \"method\": \"register_remote_method\", \"params\": {\"response_template\": {\"action\": \"run_paneldue_beep\"}, \"remote_method\": \"paneldue_beep\"}} will return: {\"id\": 123, \"result\": {}} Il metodo remoto paneldue_beep ora pu\u00f2 essere chiamato da Klipper. Nota che se il metodo accetta parametri, dovrebbero essere forniti come argomenti di parole chiave. Di seguito \u00e8 riportato un esempio di come pu\u00f2 essere chiamato da una gcode_macro: [gcode_macro PANELDUE_BEEP] gcode: {action_call_remote_method(\"paneldue_beep\", frequency=300, duration=1.0)} Quando viene eseguita la macro gcode PANELDUE_BEEP, Klipper invia qualcosa di simile al seguente tramite il socket: {\"action\": \"run_paneldue_beep\", \"params\": {\"frequency\": 300, \"duration\": 1.0}} oggetti/elenco \u00b6 Questo endpoint interroga l'elenco degli \"oggetti\" della stampante disponibili che \u00e8 possibile interrogare (tramite l'endpoint \"objects/query\"). Ad esempio: {\"id\": 123, \"method\": \"objects/list\"} potrebbe restituire: {\"id\": 123, \"result\": {\"objects\": [\"webhooks\", \"configfile\" , \"heaters\", \"gcode_move\", \"query_endstops\", \"idle_timeout\", \"toolhead\", \"extruder\"]}} oggetti/interrogazione \u00b6 Questo endpoint consente di interrogare informazioni da oggetti. Ad esempio: {\"id\": 123, \"method\": \"objects/query\", \"params\": {\"objects\": {\"toolhead\": [\"position\"], \"webhooks\": null}}} potrebbe restituire: {\"id\": 123, \"result\": {\"status\": {\"webhooks\": {\"state\": \"ready\", \"state_message\": \"Printer is ready\"}, \"toolhead\": { \"position\": [0.0, 0.0, 0.0, 0.0]}}, \"eventtime\": 3051555.377933684}} Il parametro \"objects\" nella richiesta deve essere un dizionario contenente gli oggetti stampante che devono essere interrogati - la chiave contiene il nome dell'oggetto stampante e il valore \u00e8 \"null\" (per interrogare tutti i campi) o un elenco di nomi di campo. Il messaggio di risposta conterr\u00e0 un campo \"status\" contenente un dizionario con le informazioni richieste: la chiave contiene il nome dell'oggetto stampante e il valore \u00e8 un dizionario contenente i suoi campi. Il messaggio di risposta conterr\u00e0 anche un campo \"eventtime\" contenente il timestamp da quando \u00e8 stata eseguita la query. I campi disponibili sono documentati nel documento Status Reference . oggetti/subscribe \u00b6 Questo endpoint consente di eseguire query e quindi iscriversi alle informazioni dagli oggetti stampante. La richiesta e la risposta dell'endpoint sono identiche all'endpoint \"objects/query\". Ad esempio: {\"id\": 123, \"method\": \"objects/subscribe\", \"params\": {\"objects\":{\"toolhead\": [\"position\"], \"webhooks\": [\"state\"] }, \"response_template\":{}}} potrebbe restituire: {\"id\": 123, \"result\": {\"status\": {\"webhooks\": {\"state\": \"ready\"}, \"toolhead\": {\"position\": [0.0, 0.0, 0.0, 0.0]}}, \"eventtime\": 3052153.382083195}} e generare messaggi asincroni successivi come: {\"params\": {\"status\": {\"webhooks\": {\"state\": \"shutdown\"}}, \"eventtime\": 3052165.418815847}} gcode/help \u00b6 Questo endpoint consente di interrogare i comandi G-Code disponibili che hanno una stringa di aiuto definita. Ad esempio: {\"id\": 123, \"method\": \"gcode/help\"} potrebbe restituire: {\"id\": 123, \"result\": {\"RESTORE_GCODE_STATE\": \"Restore a previously saved G-Code state\", \"PID_CALIBRATE\": \"Run PID calibration test\", \"QUERY_ADC\": \"Report the last value of an analog pin\", ...}} gcode/script \u00b6 Questo endpoint consente di eseguire una serie di comandi G-Code. Ad esempio: {\"id\": 123, \"method\": \"gcode/script\", \"params\": {\"script\": \"G90\"}} Se lo script G-Code fornito genera un errore, allora viene generata una risposta di errore. Tuttavia, se il comando G-Code produce un output del terminale, tale output del terminale non viene fornito nella risposta. (Utilizzare l'endpoint \"gcode/subscribe_output\" per ottenere l'output del terminale G-Code.) Se c'\u00e8 un comando G-Code in elaborazione quando viene ricevuta questa richiesta, lo script fornito verr\u00e0 messo in coda. Questo ritardo potrebbe essere significativo (ad esempio, se \u00e8 in esecuzione un comando di attesa del codice G per la temperatura). Il messaggio di risposta JSON viene inviato al completamento dell'elaborazione dello script. gcode/restart \u00b6 Questo endpoint consente di richiedere un riavvio: \u00e8 simile all'esecuzione del comando \"RESTART\" del codice G. Ad esempio: {\"id\": 123, \"method\": \"gcode/restart\"} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso. gcode/firmware_restart \u00b6 Questo \u00e8 simile all'endpoint \"gcode/restart\": implementa il comando G-Code \"FIRMWARE_RESTART\". Ad esempio: {\"id\": 123, \"method\": \"gcode/firmware_restart\"} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso. gcode/subscribe_output \u00b6 Questo endpoint viene utilizzato per iscriversi ai messaggi del terminale G-Code generati da Klipper. Ad esempio: {\"id\": 123, \"method\": \"gcode/subscribe_output\", \"params\": {\"response_template\":{}}} potrebbe in seguito produrre messaggi asincroni come: {\"params\": { \"response\": \"// Klipper state: Shutdown\"}} Questo endpoint ha lo scopo di supportare l'interazione umana tramite un'interfaccia \"finestra di terminale\". L'analisi del contenuto dall'output del terminale G-Code \u00e8 sconsigliata. Usa l'endpoint \"objects/subscribe\" per ottenere aggiornamenti sullo stato di Klipper. motion_report/dump_stepper \u00b6 Questo endpoint viene utilizzato per iscriversi al flusso di comandi queue_step interno di Klipper per uno stepper. L'ottenimento di questi aggiornamenti di movimento di basso livello pu\u00f2 essere utile per scopi diagnostici e di debug. L'utilizzo di questo endpoint pu\u00f2 aumentare il carico di sistema di Klipper. Una richiesta pu\u00f2 essere simile a: {\"id\": 123, \"method\":\"motion_report/dump_stepper\", \"params\": {\"name\": \"stepper_x\", \"response_template\": {}}} e potrebbe restituire: {\"id\": 123, \"result\": {\"header\": [\"interval\", \"count\", \"add\"]}} e potrebbe in seguito produrre messaggi asincroni come: {\"params\": {\" first_clock\": 179601081, \"first_time\": 8.98, \"first_position\": 0, \"last_clock\": 219686097, \"last_time\": 10.984, \"data\": [[179601081, 1, 0], [29573, 2, -8685] , [16230, 4, -1525], [10559, 6, -160], [10000, 976, 0], [10000, 1000, 0], [10000, 1000, 0], [10000, 1000, 0] , [9855, 5, 187], [11632, 4, 1534], [20756, 2, 9442]]}} Il campo \"intestazione\" nella risposta alla query iniziale viene utilizzato per descrivere i campi trovati nelle risposte \"dati\" successive. motion_report/dump_trapq \u00b6 Questo endpoint viene utilizzato per iscriversi alla \"coda di movimento trapezoidale\" interna di Klipper. L'ottenimento di questi aggiornamenti di movimento di basso livello pu\u00f2 essere utile per scopi diagnostici e di debug. L'utilizzo di questo endpoint pu\u00f2 aumentare il carico di sistema di Klipper. Una richiesta pu\u00f2 essere simile a: {\"id\": 123, \"method\": \"motion_report/dump_trapq\", \"params\": {\"name\": \"toolhead\", \"response_template\":{}}} e potrebbe restituire: {\"id\": 1, \"result\": {\"header\": [\"time\", \"duration\", \"start_velocity\", \"acceleration\", \"start_position\", \"direction\"]}} e potrebbero in seguito produrre messaggi asincroni quali: {\"params\": {\"data\": [[4.05, 1.0, 0.0, 0.0, [300.0, 0.0, 0.0], [0.0, 0.0, 0.0]], [5.054, 0.001, 0.0, 3000.0 , [300.0, 0.0, 0.0], [-1.0, 0.0, 0.0]]]}} Il campo \"intestazione\" nella risposta alla query iniziale viene utilizzato per descrivere i campi trovati nelle risposte \"dati\" successive. adxl345/dump_adxl345 \u00b6 Questo endpoint viene utilizzato per la sottoscrizione ai dati dell'accelerometro ADXL345. L'ottenimento di questi aggiornamenti di movimento di basso livello pu\u00f2 essere utile per scopi diagnostici e di debug. L'utilizzo di questo endpoint pu\u00f2 aumentare il carico di sistema di Klipper. Una richiesta pu\u00f2 essere simile a: {\"id\": 123, \"method\":\"adxl345/dump_adxl345\", \"params\": {\"sensor\": \"adxl345\", \"response_template\": {}}} e potrebbe restituire: {\"id\": 123,\"result\":{\"header\":[\"time\",\"x_acceleration\",\"y_acceleration\", \"z_acceleration\"]}} e potrebbe in seguito produrre messaggi asincroni come: {\"params \":{\"overflow\":0,\"data\":[[3292.432935,-535.44309,-1529.8374,9561.4], [3292.433256,-382.45935,-1606.32927,9561.48375]]}} Il campo \"intestazione\" nella risposta alla query iniziale viene utilizzato per descrivere i campi trovati nelle risposte \"dati\" successive. angle/dump_angle \u00b6 Questo endpoint viene utilizzato per iscriversi a dati del sensore angolare . L'ottenimento di questi aggiornamenti di movimento di basso livello pu\u00f2 essere utile per scopi diagnostici e di debug. L'utilizzo di questo endpoint pu\u00f2 aumentare il carico di sistema di Klipper. Una richiesta pu\u00f2 essere simile a: {\"id\": 123, \"method\":\"angle/dump_angle\", \"params\": {\"sensor\": \"my_angle_sensor\", \"response_template\": {}}} e potrebbe restituire: {\"id\": 123,\"result\":{\"header\":[\"time\",\"angle\"]}} e potrebbe in seguito produrre messaggi asincroni come: {\"params\":{\"position_offset\":3.151562 ,\"errori\":0, \"dati\":[[1290.951905,-5063],[1290.952321,-5065]]}} Il campo \"intestazione\" nella risposta alla query iniziale viene utilizzato per descrivere i campi trovati nelle risposte \"dati\" successive. pause_resume/cancel \u00b6 Questo endpoint \u00e8 simile all'esecuzione del comando G-Code \"PRINT_CANCEL\". Ad esempio: {\"id\": 123, \"method\": \"pause_resume/cancel\"} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso. pause_resume/pause \u00b6 Questo endpoint \u00e8 simile all'esecuzione del comando G-Code \"PAUSE\". Ad esempio: {\"id\": 123, \"method\": \"pause_resume/pause\"} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso. pause_resume/resume \u00b6 Questo endpoint \u00e8 simile all'esecuzione del comando G-Code \"RESUME\". Ad esempio: {\"id\": 123, \"method\": \"pause_resume/resume\"} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso. query_endstops/status \u00b6 Questo endpoint eseguir\u00e0 una query sugli endpoint attivi e restituir\u00e0 il loro stato. Ad esempio: {\"id\": 123, \"method\": \"query_endstops/status\"} potrebbe restituire: {\"id\": 123, \"result\": {\"y\": \"open\", \"x\": \"aperto\", \"z\": \"TRIGGERED\"}} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso.","title":"Server API"},{"location":"API_Server.html#server-api","text":"Questo documento descrive l'Application Programmer Interface (API) di Klipper. Questa interfaccia consente alle applicazioni esterne di interrogare e controllare il software host Klipper.","title":"Server API"},{"location":"API_Server.html#abilitazione-del-socket-api","text":"Per utilizzare il server API, il software host klippy.py deve essere avviato con il parametro -a . Per esempio: ~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer.cfg -a /tmp/klippy_uds -l /tmp/klippy.log Ci\u00f2 fa s\u00ec che il software host crei un socket di dominio Unix. Un client pu\u00f2 quindi aprire una connessione su quel socket e inviare comandi a Klipper. Consulta il progetto Moonraker per uno strumento popolare in grado di inoltrare richieste HTTP all'API Server Unix Domain Socket di Klipper.","title":"Abilitazione del socket API"},{"location":"API_Server.html#formato-richiesta","text":"I messaggi inviati e ricevuti sul socket sono stringhe codificate JSON terminate da un carattere ASCII 0x03: <0x03><0x03>... Klipper contiene uno strumento scripts/whconsole.py che pu\u00f2 eseguire il framing dei messaggi sopra. Per esempio: ~/klipper/scripts/whconsole.py /tmp/klippy_uds Questo strumento pu\u00f2 leggere una serie di comandi JSON da stdin, inviarli a Klipper e riportare i risultati. Lo strumento prevede che ogni comando JSON si trovi su una singola riga e aggiunger\u00e0 automaticamente il terminatore 0x03 durante la trasmissione di una richiesta. (Il server dell'API Klipper non ha un requisito di newline.)","title":"Formato richiesta"},{"location":"API_Server.html#protocollo-api","text":"Il protocollo dei comandi utilizzato sul socket di comunicazione \u00e8 ispirato a json-rpc . Una richiesta potrebbe essere simile a: {\"id\": 123, \"method\": \"info\", \"params\": {}} e una risposta potrebbe essere simile a: {\"id\": 123, \"result\": {\"state_message\": \"Printer is ready\", \"klipper_path\": \"/home/pi/klipper\", \"config_file\": \"/home/pi/printer.cfg\", \"software_version\": \"v0.8.0-823-g883b1cb6\", \"hostname\": \"octopi\", \"cpu_info\": \"4 core ARMv7 Processor rev 4 (v7l)\", \"state\": \"ready\", \"python_path\": \"/home/pi/klippy-env/bin/python\", \"log_file\": \"/tmp/klippy.log\"}} Ogni richiesta deve essere un dizionario JSON. (Questo documento usa il termine Python \"dizionario\" per descrivere un \"oggetto JSON\" - una mappatura di coppie chiave/valore contenute in {} .) Il dizionario di richiesta deve contenere un parametro \"method\" che \u00e8 il nome stringa di un \"endpoint\" di Klipper disponibile. Il dizionario della richiesta pu\u00f2 contenere un parametro \"params\" che deve essere di tipo dizionario. I \"parametri\" forniscono ulteriori informazioni sui parametri all'\"endpoint\" di Klipper che gestisce la richiesta. Il suo contenuto \u00e8 specifico dell'\"endpoint\". Il dizionario delle richieste pu\u00f2 contenere un parametro \"id\" che pu\u00f2 essere di qualsiasi tipo JSON. Se \u00e8 presente \"id\", Klipper risponder\u00e0 alla richiesta con un messaggio di risposta contenente tale \"id\". Se \"id\" viene omesso (o impostato su un valore JSON \"null\"), Klipper non fornir\u00e0 alcuna risposta alla richiesta. Un messaggio di risposta \u00e8 un dizionario JSON contenente \"id\" e \"result\". Il \"risultato\" \u00e8 sempre un dizionario: i suoi contenuti sono specifici dell'\"endpoint\" che gestisce la richiesta. Se l'elaborazione di una richiesta genera un errore, il messaggio di risposta conterr\u00e0 un campo \"errore\" anzich\u00e9 un campo \"risultato\". Ad esempio, la richiesta: {\"id\": 123, \"method\": \"gcode/script\", \"params\": {\"script\": \"G1 X200\"}} potrebbe generare una risposta di errore come: {\"id\": 123, \"error\": {\"message\": \"Deve prima posizionare l'asse: 200.000 0.000 0.000 [0.000]\", \"error\": \"WebRequestError\"}} Klipper inizier\u00e0 sempre a elaborare le richieste nell'ordine in cui sono state ricevute. Tuttavia, alcune richieste potrebbero non essere completate immediatamente, il che potrebbe causare l'invio di una risposta associata non conforme rispetto alle risposte di altre richieste. Una richiesta JSON non sospender\u00e0 mai l'elaborazione di future richieste JSON.","title":"Protocollo API"},{"location":"API_Server.html#sottoscrizioni","text":"Alcune richieste di \"endpoint\" di Klipper consentono di \"iscriversi\" a futuri messaggi di aggiornamento asincrono. Per esempio: {\"id\": 123, \"method\": \"gcode/subscribe_output\", \"params\": {\"response_template\":{\"key\": 345}}} inizialmente pu\u00f2 rispondere con: {\"id\": 123, \"result\": {}} e fare in modo che Klipper invii messaggi futuri simili a: {\"params\": {\"response\": \"ok B:22.8 /0.0 T0:22.4 /0.0\"}, \"key\": 345} Una richiesta di sottoscrizione accetta un dizionario \"response_template\" nel campo \"params\" della richiesta. Quel dizionario \"response_template\" viene utilizzato come modello per futuri messaggi asincroni: pu\u00f2 contenere coppie chiave/valore arbitrarie. Quando invier\u00e0 questi futuri messaggi asincroni, Klipper aggiunger\u00e0 un campo \"params\" contenente un dizionario con contenuti specifici per \"endpoint\" al modello di risposta e quindi invier\u00e0 quel modello. Se non viene fornito un campo \"response_template\", il valore predefinito \u00e8 un dizionario vuoto ( {} ).","title":"Sottoscrizioni"},{"location":"API_Server.html#endpoint-disponibili","text":"Per convenzione, gli \"endpoint\" di Klipper sono nella forma / . Quando si effettua una richiesta a un \"endpoint\", il nome completo deve essere impostato nel parametro \"method\" del dizionario di richiesta (ad esempio, {\"method\"=\"gcode/restart\"} ).","title":"\"endpoint\" disponibili"},{"location":"API_Server.html#info","text":"L'endpoint \"info\" viene utilizzato per ottenere informazioni sul sistema e sulla versione da Klipper. Viene anche utilizzato per fornire a Klipper le informazioni sulla versione del client. Ad esempio: {\"id\": 123, \"method\": \"info\", \"params\": { \"client_info\": { \"version\": \"v1\"}}} Se presente, il parametro \"client_info\" deve essere un dizionario, ma quel dizionario potrebbe avere contenuti arbitrari. I clienti sono incoraggiati a fornire il nome del client e la sua versione del software quando si connettono per la prima volta al server dell'API Klipper.","title":"info"},{"location":"API_Server.html#emergency_stop","text":"L'endpoint \"emergency_stop\" viene utilizzato per indicare a Klipper di passare allo stato di \"spegnimento\". Si comporta in modo simile al comando G-Code M112 . Ad esempio: {\"id\": 123, \"method\": \"emergency_stop\"}","title":"emergency_stop"},{"location":"API_Server.html#register_remote_method","text":"Questo endpoint consente ai client di registrare metodi che possono essere chiamati da klipper. Restituir\u00e0 un oggetto vuoto in caso di successo. Per esempio: {\"id\": 123, \"method\": \"register_remote_method\", \"params\": {\"response_template\": {\"action\": \"run_paneldue_beep\"}, \"remote_method\": \"paneldue_beep\"}} will return: {\"id\": 123, \"result\": {}} Il metodo remoto paneldue_beep ora pu\u00f2 essere chiamato da Klipper. Nota che se il metodo accetta parametri, dovrebbero essere forniti come argomenti di parole chiave. Di seguito \u00e8 riportato un esempio di come pu\u00f2 essere chiamato da una gcode_macro: [gcode_macro PANELDUE_BEEP] gcode: {action_call_remote_method(\"paneldue_beep\", frequency=300, duration=1.0)} Quando viene eseguita la macro gcode PANELDUE_BEEP, Klipper invia qualcosa di simile al seguente tramite il socket: {\"action\": \"run_paneldue_beep\", \"params\": {\"frequency\": 300, \"duration\": 1.0}}","title":"register_remote_method"},{"location":"API_Server.html#oggettielenco","text":"Questo endpoint interroga l'elenco degli \"oggetti\" della stampante disponibili che \u00e8 possibile interrogare (tramite l'endpoint \"objects/query\"). Ad esempio: {\"id\": 123, \"method\": \"objects/list\"} potrebbe restituire: {\"id\": 123, \"result\": {\"objects\": [\"webhooks\", \"configfile\" , \"heaters\", \"gcode_move\", \"query_endstops\", \"idle_timeout\", \"toolhead\", \"extruder\"]}}","title":"oggetti/elenco"},{"location":"API_Server.html#oggettiinterrogazione","text":"Questo endpoint consente di interrogare informazioni da oggetti. Ad esempio: {\"id\": 123, \"method\": \"objects/query\", \"params\": {\"objects\": {\"toolhead\": [\"position\"], \"webhooks\": null}}} potrebbe restituire: {\"id\": 123, \"result\": {\"status\": {\"webhooks\": {\"state\": \"ready\", \"state_message\": \"Printer is ready\"}, \"toolhead\": { \"position\": [0.0, 0.0, 0.0, 0.0]}}, \"eventtime\": 3051555.377933684}} Il parametro \"objects\" nella richiesta deve essere un dizionario contenente gli oggetti stampante che devono essere interrogati - la chiave contiene il nome dell'oggetto stampante e il valore \u00e8 \"null\" (per interrogare tutti i campi) o un elenco di nomi di campo. Il messaggio di risposta conterr\u00e0 un campo \"status\" contenente un dizionario con le informazioni richieste: la chiave contiene il nome dell'oggetto stampante e il valore \u00e8 un dizionario contenente i suoi campi. Il messaggio di risposta conterr\u00e0 anche un campo \"eventtime\" contenente il timestamp da quando \u00e8 stata eseguita la query. I campi disponibili sono documentati nel documento Status Reference .","title":"oggetti/interrogazione"},{"location":"API_Server.html#oggettisubscribe","text":"Questo endpoint consente di eseguire query e quindi iscriversi alle informazioni dagli oggetti stampante. La richiesta e la risposta dell'endpoint sono identiche all'endpoint \"objects/query\". Ad esempio: {\"id\": 123, \"method\": \"objects/subscribe\", \"params\": {\"objects\":{\"toolhead\": [\"position\"], \"webhooks\": [\"state\"] }, \"response_template\":{}}} potrebbe restituire: {\"id\": 123, \"result\": {\"status\": {\"webhooks\": {\"state\": \"ready\"}, \"toolhead\": {\"position\": [0.0, 0.0, 0.0, 0.0]}}, \"eventtime\": 3052153.382083195}} e generare messaggi asincroni successivi come: {\"params\": {\"status\": {\"webhooks\": {\"state\": \"shutdown\"}}, \"eventtime\": 3052165.418815847}}","title":"oggetti/subscribe"},{"location":"API_Server.html#gcodehelp","text":"Questo endpoint consente di interrogare i comandi G-Code disponibili che hanno una stringa di aiuto definita. Ad esempio: {\"id\": 123, \"method\": \"gcode/help\"} potrebbe restituire: {\"id\": 123, \"result\": {\"RESTORE_GCODE_STATE\": \"Restore a previously saved G-Code state\", \"PID_CALIBRATE\": \"Run PID calibration test\", \"QUERY_ADC\": \"Report the last value of an analog pin\", ...}}","title":"gcode/help"},{"location":"API_Server.html#gcodescript","text":"Questo endpoint consente di eseguire una serie di comandi G-Code. Ad esempio: {\"id\": 123, \"method\": \"gcode/script\", \"params\": {\"script\": \"G90\"}} Se lo script G-Code fornito genera un errore, allora viene generata una risposta di errore. Tuttavia, se il comando G-Code produce un output del terminale, tale output del terminale non viene fornito nella risposta. (Utilizzare l'endpoint \"gcode/subscribe_output\" per ottenere l'output del terminale G-Code.) Se c'\u00e8 un comando G-Code in elaborazione quando viene ricevuta questa richiesta, lo script fornito verr\u00e0 messo in coda. Questo ritardo potrebbe essere significativo (ad esempio, se \u00e8 in esecuzione un comando di attesa del codice G per la temperatura). Il messaggio di risposta JSON viene inviato al completamento dell'elaborazione dello script.","title":"gcode/script"},{"location":"API_Server.html#gcoderestart","text":"Questo endpoint consente di richiedere un riavvio: \u00e8 simile all'esecuzione del comando \"RESTART\" del codice G. Ad esempio: {\"id\": 123, \"method\": \"gcode/restart\"} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso.","title":"gcode/restart"},{"location":"API_Server.html#gcodefirmware_restart","text":"Questo \u00e8 simile all'endpoint \"gcode/restart\": implementa il comando G-Code \"FIRMWARE_RESTART\". Ad esempio: {\"id\": 123, \"method\": \"gcode/firmware_restart\"} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso.","title":"gcode/firmware_restart"},{"location":"API_Server.html#gcodesubscribe_output","text":"Questo endpoint viene utilizzato per iscriversi ai messaggi del terminale G-Code generati da Klipper. Ad esempio: {\"id\": 123, \"method\": \"gcode/subscribe_output\", \"params\": {\"response_template\":{}}} potrebbe in seguito produrre messaggi asincroni come: {\"params\": { \"response\": \"// Klipper state: Shutdown\"}} Questo endpoint ha lo scopo di supportare l'interazione umana tramite un'interfaccia \"finestra di terminale\". L'analisi del contenuto dall'output del terminale G-Code \u00e8 sconsigliata. Usa l'endpoint \"objects/subscribe\" per ottenere aggiornamenti sullo stato di Klipper.","title":"gcode/subscribe_output"},{"location":"API_Server.html#motion_reportdump_stepper","text":"Questo endpoint viene utilizzato per iscriversi al flusso di comandi queue_step interno di Klipper per uno stepper. L'ottenimento di questi aggiornamenti di movimento di basso livello pu\u00f2 essere utile per scopi diagnostici e di debug. L'utilizzo di questo endpoint pu\u00f2 aumentare il carico di sistema di Klipper. Una richiesta pu\u00f2 essere simile a: {\"id\": 123, \"method\":\"motion_report/dump_stepper\", \"params\": {\"name\": \"stepper_x\", \"response_template\": {}}} e potrebbe restituire: {\"id\": 123, \"result\": {\"header\": [\"interval\", \"count\", \"add\"]}} e potrebbe in seguito produrre messaggi asincroni come: {\"params\": {\" first_clock\": 179601081, \"first_time\": 8.98, \"first_position\": 0, \"last_clock\": 219686097, \"last_time\": 10.984, \"data\": [[179601081, 1, 0], [29573, 2, -8685] , [16230, 4, -1525], [10559, 6, -160], [10000, 976, 0], [10000, 1000, 0], [10000, 1000, 0], [10000, 1000, 0] , [9855, 5, 187], [11632, 4, 1534], [20756, 2, 9442]]}} Il campo \"intestazione\" nella risposta alla query iniziale viene utilizzato per descrivere i campi trovati nelle risposte \"dati\" successive.","title":"motion_report/dump_stepper"},{"location":"API_Server.html#motion_reportdump_trapq","text":"Questo endpoint viene utilizzato per iscriversi alla \"coda di movimento trapezoidale\" interna di Klipper. L'ottenimento di questi aggiornamenti di movimento di basso livello pu\u00f2 essere utile per scopi diagnostici e di debug. L'utilizzo di questo endpoint pu\u00f2 aumentare il carico di sistema di Klipper. Una richiesta pu\u00f2 essere simile a: {\"id\": 123, \"method\": \"motion_report/dump_trapq\", \"params\": {\"name\": \"toolhead\", \"response_template\":{}}} e potrebbe restituire: {\"id\": 1, \"result\": {\"header\": [\"time\", \"duration\", \"start_velocity\", \"acceleration\", \"start_position\", \"direction\"]}} e potrebbero in seguito produrre messaggi asincroni quali: {\"params\": {\"data\": [[4.05, 1.0, 0.0, 0.0, [300.0, 0.0, 0.0], [0.0, 0.0, 0.0]], [5.054, 0.001, 0.0, 3000.0 , [300.0, 0.0, 0.0], [-1.0, 0.0, 0.0]]]}} Il campo \"intestazione\" nella risposta alla query iniziale viene utilizzato per descrivere i campi trovati nelle risposte \"dati\" successive.","title":"motion_report/dump_trapq"},{"location":"API_Server.html#adxl345dump_adxl345","text":"Questo endpoint viene utilizzato per la sottoscrizione ai dati dell'accelerometro ADXL345. L'ottenimento di questi aggiornamenti di movimento di basso livello pu\u00f2 essere utile per scopi diagnostici e di debug. L'utilizzo di questo endpoint pu\u00f2 aumentare il carico di sistema di Klipper. Una richiesta pu\u00f2 essere simile a: {\"id\": 123, \"method\":\"adxl345/dump_adxl345\", \"params\": {\"sensor\": \"adxl345\", \"response_template\": {}}} e potrebbe restituire: {\"id\": 123,\"result\":{\"header\":[\"time\",\"x_acceleration\",\"y_acceleration\", \"z_acceleration\"]}} e potrebbe in seguito produrre messaggi asincroni come: {\"params \":{\"overflow\":0,\"data\":[[3292.432935,-535.44309,-1529.8374,9561.4], [3292.433256,-382.45935,-1606.32927,9561.48375]]}} Il campo \"intestazione\" nella risposta alla query iniziale viene utilizzato per descrivere i campi trovati nelle risposte \"dati\" successive.","title":"adxl345/dump_adxl345"},{"location":"API_Server.html#angledump_angle","text":"Questo endpoint viene utilizzato per iscriversi a dati del sensore angolare . L'ottenimento di questi aggiornamenti di movimento di basso livello pu\u00f2 essere utile per scopi diagnostici e di debug. L'utilizzo di questo endpoint pu\u00f2 aumentare il carico di sistema di Klipper. Una richiesta pu\u00f2 essere simile a: {\"id\": 123, \"method\":\"angle/dump_angle\", \"params\": {\"sensor\": \"my_angle_sensor\", \"response_template\": {}}} e potrebbe restituire: {\"id\": 123,\"result\":{\"header\":[\"time\",\"angle\"]}} e potrebbe in seguito produrre messaggi asincroni come: {\"params\":{\"position_offset\":3.151562 ,\"errori\":0, \"dati\":[[1290.951905,-5063],[1290.952321,-5065]]}} Il campo \"intestazione\" nella risposta alla query iniziale viene utilizzato per descrivere i campi trovati nelle risposte \"dati\" successive.","title":"angle/dump_angle"},{"location":"API_Server.html#pause_resumecancel","text":"Questo endpoint \u00e8 simile all'esecuzione del comando G-Code \"PRINT_CANCEL\". Ad esempio: {\"id\": 123, \"method\": \"pause_resume/cancel\"} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso.","title":"pause_resume/cancel"},{"location":"API_Server.html#pause_resumepause","text":"Questo endpoint \u00e8 simile all'esecuzione del comando G-Code \"PAUSE\". Ad esempio: {\"id\": 123, \"method\": \"pause_resume/pause\"} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso.","title":"pause_resume/pause"},{"location":"API_Server.html#pause_resumeresume","text":"Questo endpoint \u00e8 simile all'esecuzione del comando G-Code \"RESUME\". Ad esempio: {\"id\": 123, \"method\": \"pause_resume/resume\"} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso.","title":"pause_resume/resume"},{"location":"API_Server.html#query_endstopsstatus","text":"Questo endpoint eseguir\u00e0 una query sugli endpoint attivi e restituir\u00e0 il loro stato. Ad esempio: {\"id\": 123, \"method\": \"query_endstops/status\"} potrebbe restituire: {\"id\": 123, \"result\": {\"y\": \"open\", \"x\": \"aperto\", \"z\": \"TRIGGERED\"}} Come con l'endpoint \"gcode/script\", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso.","title":"query_endstops/status"},{"location":"Axis_Twist_Compensation.html","text":"Compensazione torsione assi \u00b6 Questo documento descrive il modulo [axis_twist_compensation]. Some printers may have a small twist in their X rail which can skew the results of a probe attached to the X carriage. This is common in printers with designs like the Prusa MK3, Sovol SV06 etc and is further described under probe location bias . It may result in probe operations such as Bed Mesh , Screws Tilt Adjust , Z Tilt Adjust etc returning inaccurate representations of the bed. Questo modulo utilizza misurazioni manuali da parte dell'utente per correggere i risultati della sonda. Tieni presente che se l'asse \u00e8 notevolmente distorto, ti consigliamo vivamente di utilizzare mezzi meccanici per ripararlo prima di applicare le correzioni del software. Warning : This module is not compatible with dockable probes yet and will try to probe the bed without attaching the probe if you use it. Overview of compensation usage \u00b6 Tip: Make sure the probe X and Y offsets are correctly set as they greatly influence calibration. After setting up the [axis_twist_compensation] module, perform AXIS_TWIST_COMPENSATION_CALIBRATE The calibration wizard will prompt you to measure the probe Z offset at a few points along the bed The calibration defaults to 3 points but you can use the option SAMPLE_COUNT= to use a different number. Adjust your Z offset Perform automatic/probe-based bed tramming operations, such as Screws Tilt Adjust , Z Tilt Adjust etc Home all axis, then perform a Bed Mesh if required Perform a test print, followed by any fine-tuning as desired Tip: Bed temperature and nozzle temperature and size do not seem to have an influence to the calibration process. [axis_twist_compensation] setup and commands \u00b6 Configuration options for [axis_twist_compensation] can be found in the Configuration Reference . Commands for [axis_twist_compensation] can be found in the G-Codes Reference","title":"Compensazione torsione assi"},{"location":"Axis_Twist_Compensation.html#compensazione-torsione-assi","text":"Questo documento descrive il modulo [axis_twist_compensation]. Some printers may have a small twist in their X rail which can skew the results of a probe attached to the X carriage. This is common in printers with designs like the Prusa MK3, Sovol SV06 etc and is further described under probe location bias . It may result in probe operations such as Bed Mesh , Screws Tilt Adjust , Z Tilt Adjust etc returning inaccurate representations of the bed. Questo modulo utilizza misurazioni manuali da parte dell'utente per correggere i risultati della sonda. Tieni presente che se l'asse \u00e8 notevolmente distorto, ti consigliamo vivamente di utilizzare mezzi meccanici per ripararlo prima di applicare le correzioni del software. Warning : This module is not compatible with dockable probes yet and will try to probe the bed without attaching the probe if you use it.","title":"Compensazione torsione assi"},{"location":"Axis_Twist_Compensation.html#overview-of-compensation-usage","text":"Tip: Make sure the probe X and Y offsets are correctly set as they greatly influence calibration. After setting up the [axis_twist_compensation] module, perform AXIS_TWIST_COMPENSATION_CALIBRATE The calibration wizard will prompt you to measure the probe Z offset at a few points along the bed The calibration defaults to 3 points but you can use the option SAMPLE_COUNT= to use a different number. Adjust your Z offset Perform automatic/probe-based bed tramming operations, such as Screws Tilt Adjust , Z Tilt Adjust etc Home all axis, then perform a Bed Mesh if required Perform a test print, followed by any fine-tuning as desired Tip: Bed temperature and nozzle temperature and size do not seem to have an influence to the calibration process.","title":"Overview of compensation usage"},{"location":"Axis_Twist_Compensation.html#axis_twist_compensation-setup-and-commands","text":"Configuration options for [axis_twist_compensation] can be found in the Configuration Reference . Commands for [axis_twist_compensation] can be found in the G-Codes Reference","title":"[axis_twist_compensation] setup and commands"},{"location":"BLTouch.html","text":"BL-Touch \u00b6 Collegare BL-Touch \u00b6 Attenzione warning prima di cominciare : Evita di toccare la punta del BL-Touch a mani nude, \u00e8 molto sensibili al sebo delle dita. Se sei costretto usa dei guanti ed evita di spingerla o piegarla. Collega il connettore \"servo\" BL-Touch a un control_pin secondo la documentazione BL-Touch o la documentazione MCU. Usando il cablaggio originale, il filo giallo del triplo \u00e8 il control_pin e il filo bianco della coppia \u00e8 il sensor_pin . \u00c8 necessario configurare questi pin in base al cablaggio. La maggior parte dei dispositivi BL-Touch richiede un pullup sul pin del sensore (prefissare il nome del pin con \"^\"). Per esempio: [bltouch] sensor_pin: ^P1.24 control_pin: P1.26 Se il BL-Touch verr\u00e0 utilizzato per l'home dell'asse Z, impostare endstop_pin: probe:z_virtual_endstop e rimuovere position_endstop nella sezione di configurazione [stepper_z] , quindi aggiungere una sezione di configurazione [safe_z_home] per aumentare il asse z, posiziona gli assi xy, spostati al centro del letto e posizionati sull'asse z. Per esempio: [safe_z_home] home_xy_position: 100, 100 # Cambiare le coordinate per il centro del tuo piatto speed: 50 z_hop: 10 # Move up 10mm z_hop_speed: 5 \u00c8 importante che il movimento z_hop in safe_z_home sia sufficientemente alto in mode che la sonda non colpisca nulla anche se il pin della sonda si trova nel suo stato pi\u00f9 basso. Test iniziali \u00b6 Prima di proseguire, verificare che il BL-Touch sia montato all'altezza corretta, il perno dovrebbe trovarsi a circa 2 mm sopra il nozzle quando \u00e8 retratto Quando si accende la stampante, la sonda BL-Touch dovrebbe eseguire un autotest e spostare il pin su e gi\u00f9 un paio di volte. Una volta completato l'autotest, il perno deve essere retratto e il LED rosso sulla sonda deve essere acceso. In caso di errori, ad esempio la sonda lampeggia in rosso o il pin \u00e8 in basso anzich\u00e9 in alto, spegnere la stampante e controllare il cablaggio e la configurazione. Se quanto sopra sembra buono, \u00e8 il momento di verificare che il pin di controllo funzioni correttamente. Per prima cosa esegui BLTOUCH_DEBUG COMMAND=pin_down nel terminale della tua stampante. Verificare che il pin si abbassi e che il LED rosso sulla sonda si spenga. In caso contrario, controllare nuovamente il cablaggio e la configurazione. Quindi emettere un BLTOUCH_DEBUG COMMAND=pin_up , verificare che il pin si muova verso l'alto e che la luce rossa si accenda di nuovo. Se lampeggia allora c'\u00e8 qualche problema. Il passaggio successivo \u00e8 confermare che il pin del sensore funzioni correttamente. Esegui BLTOUCH_DEBUG COMMAND=pin_down , verifica che il pin si sposti verso il basso, esegui BLTOUCH_DEBUG COMMAND=touch_mode , esegui QUERY_PROBE e verifica che il comando riporti \"probe: open\". Quindi, spingendo leggermente verso l'alto il perno con l'unghia del dito, eseguire nuovamente QUERY_PROBE . Verificare che il comando riporti \"probe: TRIGGERED\". Se una delle query non riporta il messaggio corretto, di solito indica un cablaggio o una configurazione errati (sebbene alcuni clones potrebbero richiedere una gestione speciale). Al completamento di questo test, eseguire BLTOUCH_DEBUG COMMAND=pin_up e verificare che il pin si muova verso l'alto. Dopo aver completato i test del pin di controllo BL-Touch e del pin del sensore, \u00e8 ora il momento di testare il rilevamento, ma con una svolta. Invece di lasciare che il perno della sonda tocchi il piano di stampa, lascia che tocchi l'unghia del dito. Posizionare la testina lontano dal letto, emettere un G28 (o PROBE se non si utilizza probe:z_virtual_endstop), attendere che la testina inizi a muoversi verso il basso e interrompere il movimento toccando molto delicatamente il perno con l'unghia. Potrebbe essere necessario farlo due volte, poich\u00e9 la configurazione di homing predefinita esegue due sonde. Preparati a spegnere la stampante se non si ferma quando tocchi il perno. Se ha avuto successo, esegui un altro G28 (o PROBE ) ma questa volta lascia che tocchi il letto come dovrebbe. BL-Touch andato male \u00b6 Una volta che il BL-Touch \u00e8 in uno stato incoerente, inizia a lampeggiare in rosso. Puoi forzarlo a lasciare quello stato emettendo: BLTOUCH_DEBUG COMMAND=reset Ci\u00f2 pu\u00f2 accadere se la sua calibrazione viene interrotta dal blocco dell'estrazione della sonda. Tuttavia, anche il BL-Touch potrebbe non essere pi\u00f9 in grado di calibrarsi. Ci\u00f2 accade se la vite sulla sua sommit\u00e0 \u00e8 nella posizione sbagliata o se il nucleo magnetico all'interno del perno della sonda si \u00e8 spostato. Se si \u00e8 alzato in modo che si attacchi alla vite, potrebbe non essere pi\u00f9 in grado di abbassare il perno. Con questo comportamento \u00e8 necessario aprire la vite e utilizzare una penna a sfera per spingerla delicatamente in posizione. Reinserire il perno nel BL-Touch in modo che cada nella posizione estratta. Riposizionare con cura la vite senza testa in posizione. \u00c8 necessario trovare la posizione giusta in modo che sia in grado di abbassare e alzare il perno e la luce rossa si accende e si spegne. Usa i comandi reset , pin_up e pin_down per raggiungere questo obiettivo. BL-Touch \"cloni\" \u00b6 Molti dispositivi \"clone\" BL-Touch funzionano correttamente con Klipper utilizzando la configurazione predefinita. Tuttavia, alcuni dispositivi \"clone\" potrebbero non supportare il comando QUERY_PROBE e alcuni dispositivi \"clone\" potrebbero richiedere la configurazione di pin_up_reports_not_triggered o pin_up_touch_mode_reports_triggered . Importante! Non configurare pin_up_reports_not_triggered o pin_up_touch_mode_reports_triggered su False senza prima seguire queste indicazioni. Non configurare nessuno di questi su False su un BL-Touch originale. Un'impostazione errata di questi valori su False pu\u00f2 aumentare il tempo di ispezione e pu\u00f2 aumentare il rischio di danneggiare la stampante. Alcuni dispositivi \"clone\" non supportano touch_mode e di conseguenza il comando QUERY_PROBE non funziona. Nonostante ci\u00f2, potrebbe essere ancora possibile eseguire il rilevamento e l'homing con questi dispositivi. Su questi dispositivi il comando QUERY_PROBE durante i initial tests non avr\u00e0 esito positivo, tuttavia il successivo test G28 (o PROBE ) riesce. Potrebbe essere possibile utilizzare questi dispositivi \"clone\" con Klipper se non si utilizza il comando QUERY_PROBE e se non si abilita la funzione probe_with_touch_mode . Alcuni dispositivi \"clone\" non sono in grado di eseguire il test di verifica del sensore interno di Klipper. Su questi dispositivi, i tentativi di home o probe possono far s\u00ec che Klipper riporti un errore \"BLTouch non \u00e8 riuscito a verificare lo stato del sensore\". In tal caso, eseguire manualmente i passaggi per verificare che il pin del sensore funzioni come descritto nella initial tests section . Se i comandi QUERY_PROBE in quel test producono sempre i risultati attesi e si verificano ancora gli errori \"BLTouch non \u00e8 riuscito a verificare lo stato del sensore\", potrebbe essere necessario impostare pin_up_touch_mode_reports_triggered su False nel file di configurazione di Klipper. Un raro numero di vecchi dispositivi \"clone\" non \u00e8 in grado di segnalare quando hanno sollevato con successo la sonda. Su questi dispositivi Klipper segnaler\u00e0 un errore \"BLTouch non \u00e8 riuscito a sollevare la sonda\" dopo ogni tentativo di home o probe. Si pu\u00f2 testare questi dispositivi: spostare la testa lontano dal letto, eseguire BLTOUCH_DEBUG COMMAND=pin_down , verificare che il pin si sia spostato verso il basso, eseguire QUERY_PROBE , verificare che il comando riporti \"probe: open\", eseguire BLTOUCH_DEBUG COMMAND= pin_up , verifica che il pin sia stato spostato in alto ed esegui QUERY_PROBE . Se il pin rimane attivo, il dispositivo non entra in uno stato di errore e la prima query riporta \"probe: open\" mentre la seconda query riporta \"probe: TRIGGERED\", quindi indica che pin_up_reports_not_triggered dovrebbe essere impostato su False in Klipper file di configurazione. BL-Touch v3 \u00b6 Alcuni dispositivi BL-Touch v3.0 e BL-Touch 3.1 potrebbero richiedere la configurazione di probe_with_touch_mode nel file di configurazione della stampante. Se il BL-Touch v3.0 ha il cavo del segnale collegato a un pin endstop (con un condensatore di filtraggio del rumore), il BL-Touch v3.0 potrebbe non essere in grado di inviare un segnale in modo coerente durante l'homing e il probe. Se i comandi QUERY_PROBE nella initial tests section producono sempre i risultati attesi, ma il toolhead non si ferma sempre durante i comandi G28/PROBE, allora \u00e8 indicativo di questo problema. Una soluzione alternativa consiste nell'impostare probe_with_touch_mode: True nel file di configurazione. Il BL-Touch v3.1 potrebbe entrare erroneamente in uno stato di errore dopo un tentativo di probe riuscito. I sintomi sono una luce lampeggiante occasionale sul BL-Touch v3.1 che dura per un paio di secondi dopo che \u00e8 entrato in contatto con successo con il letto. Klipper dovrebbe cancellare questo errore automaticamente ed \u00e8 generalmente innocuo. Tuttavia, \u00e8 possibile impostare probe_with_touch_mode nel file di configurazione per evitare questo problema. Importante! Alcuni dispositivi \"clone\" e BL-Touch v2.0 (e precedenti) potrebbero avere una precisione ridotta quando probe_with_touch_mode \u00e8 impostato su True. L'impostazione su True aumenta anche il tempo necessario per distribuire la sonda. Se si configura questo valore su un dispositivo BL-Touch \"clone\" o precedente, assicurarsi di testare l'accuratezza della sonda prima e dopo aver impostato questo valore (utilizzare il comando PROBE_ACCURACY per eseguire il test). Multi-sondaggio senza riporre \u00b6 Per impostazione predefinita, Klipper rilascia la sonda all'inizio di ogni tentativo di sonda e poi riporr\u00e0 la sonda in seguito. Questo dispiegamento e stivaggio ripetitivo della sonda pu\u00f2 aumentare il tempo totale delle sequenze di calibrazione che coinvolgono molte misurazioni della sonda. Klipper consente di lasciare la sonda dispiegata tra test consecutivi, il che pu\u00f2 ridurre il tempo totale di rilevamento. Questa modalit\u00e0 \u00e8 abilitata configurando stow_on_each_sample su False nel file di configurazione. Importante! L'impostazione di stow_on_each_sample su False pu\u00f2 portare Klipper a fare movimenti orizzontali della testa utensile mentre la sonda \u00e8 estesa. Assicurarsi di verificare che tutte le operazioni con la probe abbiano un gioco Z sufficiente prima di impostare questo valore su False. Se lo spazio libero \u00e8 insufficiente, uno spostamento orizzontale pu\u00f2 causare l'intrappolamento del perno in un'ostruzione e causare danni alla stampante. Importante! Si consiglia di utilizzare probe_with_touch_mode configurato su True quando si utilizza stow_on_each_sample configurato su False. Alcuni dispositivi \"clone\" potrebbero non rilevare un successivo contatto con il piatto se probe_with_touch_mode non \u00e8 impostato. Su tutti i dispositivi, l'utilizzo della combinazione di queste due impostazioni semplifica la segnalazione del dispositivo, che pu\u00f2 migliorare la stabilit\u00e0 generale. Si noti, tuttavia, che alcuni dispositivi \"clone\" e BL-Touch v2.0 (e precedenti) potrebbero avere una precisione ridotta quando probe_with_touch_mode \u00e8 impostato su True. Su questi dispositivi \u00e8 una buona idea testare l'accuratezza della sonda prima e dopo aver impostato probe_with_touch_mode (usare il comando di test PROBE_ACCURACY ). Calibrazione degli offset BL-Touch \u00b6 Seguire le istruzioni nella guida Probe Calibrate per impostare i parametri di configurazione x_offset, y_offset e z_offset. \u00c8 una buona idea verificare che l'offset Z sia vicino a 1 mm. In caso contrario, probabilmente vorrai spostare la sonda su o gi\u00f9 per risolvere il problema. Si desidera che si attivi ben prima che l'ugello colpisca il piatto, in modo che un possibile filamento bloccato o un piatto deformato non influisca sull'azione della sonda. Ma allo stesso tempo, si desidera che la posizione retratta sia il pi\u00f9 possibile al di sopra dell'ugello per evitare che tocchi le parti stampate. Se viene effettuata una regolazione della posizione della sonda, eseguire nuovamente i passaggi di calibrazione della sonda. Modalit\u00e0 di output BL-Touch \u00b6 Un BL-Touch V3.0 supporta l'impostazione di una modalit\u00e0 di uscita 5V o OPEN-DRAIN, un BL-Touch V3.1 supporta anche questo, ma pu\u00f2 anche memorizzarlo nella sua EEPROM interna. Se la tua scheda controller ha bisogno del livello logico alto 5V fisso della modalit\u00e0 5V, puoi impostare il parametro 'set_output_mode' nella sezione [bltouch] del file di configurazione della stampante su \"5V\". Utilizzare la modalit\u00e0 5V solo se la linea di ingresso della scheda controller \u00e8 tollerante a 5V. Ecco perch\u00e9 la configurazione di default di queste versioni BL-Touch \u00e8 la modalit\u00e0 OPEN-DRAIN. Potresti potenzialmente danneggiare la CPU delle tue schede di controllo Quindi: se una scheda controller HA BISOGNO della modalit\u00e0 5V ED \u00e8 tollerante a 5V sulla sua linea del segnale di ingresso E se si dispone di un BL-Touch Smart V3.0, \u00e8 necessario utilizzare il parametro 'set_output_mode: 5V' per garantire questa impostazione ad ogni avvio, poich\u00e9 la sonda non ricorda l'impostazione necessaria. hai un BL-Touch Smart V3.1, puoi scegliere di usare 'set_output_mode: 5V' o memorizzare la modalit\u00e0 una volta usando un comando 'BLTOUCH_STORE MODE=5V' manualmente e NON usando il parametro 'set_output_mode:'. hai qualche altra sonda: alcune sonde hanno una traccia sul circuito stampato da tagliare o un ponticello da impostare per impostare (permanentemente) la modalit\u00e0 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\u00e0 di output per evitare di consumare la EEPROM della sonda. La BLTouch EEPROM \u00e8 valida per circa 100.000 aggiornamenti. 100 memorizzazioni al giorno aggiungerebbero fino a circa 3 anni di attivit\u00e0 prima di logorarlo. Pertanto, la memorizzazione della modalit\u00e0 di output in una V3.1 \u00e8 progettata dal fornitore per essere un'operazione complicata (l'impostazione predefinita di fabbrica \u00e8 una modalit\u00e0 OPEN DRAIN sicura) e non \u00e8 adatta per essere emessa ripetutamente da qualsiasi slicer, macro o altro, esso \u00e8 preferibilmente da utilizzare solo quando si integra per la prima volta la sonda nell'elettronica di una stampante.","title":"BL-Touch"},{"location":"BLTouch.html#bl-touch","text":"","title":"BL-Touch"},{"location":"BLTouch.html#collegare-bl-touch","text":"Attenzione warning prima di cominciare : Evita di toccare la punta del BL-Touch a mani nude, \u00e8 molto sensibili al sebo delle dita. Se sei costretto usa dei guanti ed evita di spingerla o piegarla. Collega il connettore \"servo\" BL-Touch a un control_pin secondo la documentazione BL-Touch o la documentazione MCU. Usando il cablaggio originale, il filo giallo del triplo \u00e8 il control_pin e il filo bianco della coppia \u00e8 il sensor_pin . \u00c8 necessario configurare questi pin in base al cablaggio. La maggior parte dei dispositivi BL-Touch richiede un pullup sul pin del sensore (prefissare il nome del pin con \"^\"). Per esempio: [bltouch] sensor_pin: ^P1.24 control_pin: P1.26 Se il BL-Touch verr\u00e0 utilizzato per l'home dell'asse Z, impostare endstop_pin: probe:z_virtual_endstop e rimuovere position_endstop nella sezione di configurazione [stepper_z] , quindi aggiungere una sezione di configurazione [safe_z_home] per aumentare il asse z, posiziona gli assi xy, spostati al centro del letto e posizionati sull'asse z. Per esempio: [safe_z_home] home_xy_position: 100, 100 # Cambiare le coordinate per il centro del tuo piatto speed: 50 z_hop: 10 # Move up 10mm z_hop_speed: 5 \u00c8 importante che il movimento z_hop in safe_z_home sia sufficientemente alto in mode che la sonda non colpisca nulla anche se il pin della sonda si trova nel suo stato pi\u00f9 basso.","title":"Collegare BL-Touch"},{"location":"BLTouch.html#test-iniziali","text":"Prima di proseguire, verificare che il BL-Touch sia montato all'altezza corretta, il perno dovrebbe trovarsi a circa 2 mm sopra il nozzle quando \u00e8 retratto Quando si accende la stampante, la sonda BL-Touch dovrebbe eseguire un autotest e spostare il pin su e gi\u00f9 un paio di volte. Una volta completato l'autotest, il perno deve essere retratto e il LED rosso sulla sonda deve essere acceso. In caso di errori, ad esempio la sonda lampeggia in rosso o il pin \u00e8 in basso anzich\u00e9 in alto, spegnere la stampante e controllare il cablaggio e la configurazione. Se quanto sopra sembra buono, \u00e8 il momento di verificare che il pin di controllo funzioni correttamente. Per prima cosa esegui BLTOUCH_DEBUG COMMAND=pin_down nel terminale della tua stampante. Verificare che il pin si abbassi e che il LED rosso sulla sonda si spenga. In caso contrario, controllare nuovamente il cablaggio e la configurazione. Quindi emettere un BLTOUCH_DEBUG COMMAND=pin_up , verificare che il pin si muova verso l'alto e che la luce rossa si accenda di nuovo. Se lampeggia allora c'\u00e8 qualche problema. Il passaggio successivo \u00e8 confermare che il pin del sensore funzioni correttamente. Esegui BLTOUCH_DEBUG COMMAND=pin_down , verifica che il pin si sposti verso il basso, esegui BLTOUCH_DEBUG COMMAND=touch_mode , esegui QUERY_PROBE e verifica che il comando riporti \"probe: open\". Quindi, spingendo leggermente verso l'alto il perno con l'unghia del dito, eseguire nuovamente QUERY_PROBE . Verificare che il comando riporti \"probe: TRIGGERED\". Se una delle query non riporta il messaggio corretto, di solito indica un cablaggio o una configurazione errati (sebbene alcuni clones potrebbero richiedere una gestione speciale). Al completamento di questo test, eseguire BLTOUCH_DEBUG COMMAND=pin_up e verificare che il pin si muova verso l'alto. Dopo aver completato i test del pin di controllo BL-Touch e del pin del sensore, \u00e8 ora il momento di testare il rilevamento, ma con una svolta. Invece di lasciare che il perno della sonda tocchi il piano di stampa, lascia che tocchi l'unghia del dito. Posizionare la testina lontano dal letto, emettere un G28 (o PROBE se non si utilizza probe:z_virtual_endstop), attendere che la testina inizi a muoversi verso il basso e interrompere il movimento toccando molto delicatamente il perno con l'unghia. Potrebbe essere necessario farlo due volte, poich\u00e9 la configurazione di homing predefinita esegue due sonde. Preparati a spegnere la stampante se non si ferma quando tocchi il perno. Se ha avuto successo, esegui un altro G28 (o PROBE ) ma questa volta lascia che tocchi il letto come dovrebbe.","title":"Test iniziali"},{"location":"BLTouch.html#bl-touch-andato-male","text":"Una volta che il BL-Touch \u00e8 in uno stato incoerente, inizia a lampeggiare in rosso. Puoi forzarlo a lasciare quello stato emettendo: BLTOUCH_DEBUG COMMAND=reset Ci\u00f2 pu\u00f2 accadere se la sua calibrazione viene interrotta dal blocco dell'estrazione della sonda. Tuttavia, anche il BL-Touch potrebbe non essere pi\u00f9 in grado di calibrarsi. Ci\u00f2 accade se la vite sulla sua sommit\u00e0 \u00e8 nella posizione sbagliata o se il nucleo magnetico all'interno del perno della sonda si \u00e8 spostato. Se si \u00e8 alzato in modo che si attacchi alla vite, potrebbe non essere pi\u00f9 in grado di abbassare il perno. Con questo comportamento \u00e8 necessario aprire la vite e utilizzare una penna a sfera per spingerla delicatamente in posizione. Reinserire il perno nel BL-Touch in modo che cada nella posizione estratta. Riposizionare con cura la vite senza testa in posizione. \u00c8 necessario trovare la posizione giusta in modo che sia in grado di abbassare e alzare il perno e la luce rossa si accende e si spegne. Usa i comandi reset , pin_up e pin_down per raggiungere questo obiettivo.","title":"BL-Touch andato male"},{"location":"BLTouch.html#bl-touch-cloni","text":"Molti dispositivi \"clone\" BL-Touch funzionano correttamente con Klipper utilizzando la configurazione predefinita. Tuttavia, alcuni dispositivi \"clone\" potrebbero non supportare il comando QUERY_PROBE e alcuni dispositivi \"clone\" potrebbero richiedere la configurazione di pin_up_reports_not_triggered o pin_up_touch_mode_reports_triggered . Importante! Non configurare pin_up_reports_not_triggered o pin_up_touch_mode_reports_triggered su False senza prima seguire queste indicazioni. Non configurare nessuno di questi su False su un BL-Touch originale. Un'impostazione errata di questi valori su False pu\u00f2 aumentare il tempo di ispezione e pu\u00f2 aumentare il rischio di danneggiare la stampante. Alcuni dispositivi \"clone\" non supportano touch_mode e di conseguenza il comando QUERY_PROBE non funziona. Nonostante ci\u00f2, potrebbe essere ancora possibile eseguire il rilevamento e l'homing con questi dispositivi. Su questi dispositivi il comando QUERY_PROBE durante i initial tests non avr\u00e0 esito positivo, tuttavia il successivo test G28 (o PROBE ) riesce. Potrebbe essere possibile utilizzare questi dispositivi \"clone\" con Klipper se non si utilizza il comando QUERY_PROBE e se non si abilita la funzione probe_with_touch_mode . Alcuni dispositivi \"clone\" non sono in grado di eseguire il test di verifica del sensore interno di Klipper. Su questi dispositivi, i tentativi di home o probe possono far s\u00ec che Klipper riporti un errore \"BLTouch non \u00e8 riuscito a verificare lo stato del sensore\". In tal caso, eseguire manualmente i passaggi per verificare che il pin del sensore funzioni come descritto nella initial tests section . Se i comandi QUERY_PROBE in quel test producono sempre i risultati attesi e si verificano ancora gli errori \"BLTouch non \u00e8 riuscito a verificare lo stato del sensore\", potrebbe essere necessario impostare pin_up_touch_mode_reports_triggered su False nel file di configurazione di Klipper. Un raro numero di vecchi dispositivi \"clone\" non \u00e8 in grado di segnalare quando hanno sollevato con successo la sonda. Su questi dispositivi Klipper segnaler\u00e0 un errore \"BLTouch non \u00e8 riuscito a sollevare la sonda\" dopo ogni tentativo di home o probe. Si pu\u00f2 testare questi dispositivi: spostare la testa lontano dal letto, eseguire BLTOUCH_DEBUG COMMAND=pin_down , verificare che il pin si sia spostato verso il basso, eseguire QUERY_PROBE , verificare che il comando riporti \"probe: open\", eseguire BLTOUCH_DEBUG COMMAND= pin_up , verifica che il pin sia stato spostato in alto ed esegui QUERY_PROBE . Se il pin rimane attivo, il dispositivo non entra in uno stato di errore e la prima query riporta \"probe: open\" mentre la seconda query riporta \"probe: TRIGGERED\", quindi indica che pin_up_reports_not_triggered dovrebbe essere impostato su False in Klipper file di configurazione.","title":"BL-Touch \"cloni\""},{"location":"BLTouch.html#bl-touch-v3","text":"Alcuni dispositivi BL-Touch v3.0 e BL-Touch 3.1 potrebbero richiedere la configurazione di probe_with_touch_mode nel file di configurazione della stampante. Se il BL-Touch v3.0 ha il cavo del segnale collegato a un pin endstop (con un condensatore di filtraggio del rumore), il BL-Touch v3.0 potrebbe non essere in grado di inviare un segnale in modo coerente durante l'homing e il probe. Se i comandi QUERY_PROBE nella initial tests section producono sempre i risultati attesi, ma il toolhead non si ferma sempre durante i comandi G28/PROBE, allora \u00e8 indicativo di questo problema. Una soluzione alternativa consiste nell'impostare probe_with_touch_mode: True nel file di configurazione. Il BL-Touch v3.1 potrebbe entrare erroneamente in uno stato di errore dopo un tentativo di probe riuscito. I sintomi sono una luce lampeggiante occasionale sul BL-Touch v3.1 che dura per un paio di secondi dopo che \u00e8 entrato in contatto con successo con il letto. Klipper dovrebbe cancellare questo errore automaticamente ed \u00e8 generalmente innocuo. Tuttavia, \u00e8 possibile impostare probe_with_touch_mode nel file di configurazione per evitare questo problema. Importante! Alcuni dispositivi \"clone\" e BL-Touch v2.0 (e precedenti) potrebbero avere una precisione ridotta quando probe_with_touch_mode \u00e8 impostato su True. L'impostazione su True aumenta anche il tempo necessario per distribuire la sonda. Se si configura questo valore su un dispositivo BL-Touch \"clone\" o precedente, assicurarsi di testare l'accuratezza della sonda prima e dopo aver impostato questo valore (utilizzare il comando PROBE_ACCURACY per eseguire il test).","title":"BL-Touch v3"},{"location":"BLTouch.html#multi-sondaggio-senza-riporre","text":"Per impostazione predefinita, Klipper rilascia la sonda all'inizio di ogni tentativo di sonda e poi riporr\u00e0 la sonda in seguito. Questo dispiegamento e stivaggio ripetitivo della sonda pu\u00f2 aumentare il tempo totale delle sequenze di calibrazione che coinvolgono molte misurazioni della sonda. Klipper consente di lasciare la sonda dispiegata tra test consecutivi, il che pu\u00f2 ridurre il tempo totale di rilevamento. Questa modalit\u00e0 \u00e8 abilitata configurando stow_on_each_sample su False nel file di configurazione. Importante! L'impostazione di stow_on_each_sample su False pu\u00f2 portare Klipper a fare movimenti orizzontali della testa utensile mentre la sonda \u00e8 estesa. Assicurarsi di verificare che tutte le operazioni con la probe abbiano un gioco Z sufficiente prima di impostare questo valore su False. Se lo spazio libero \u00e8 insufficiente, uno spostamento orizzontale pu\u00f2 causare l'intrappolamento del perno in un'ostruzione e causare danni alla stampante. Importante! Si consiglia di utilizzare probe_with_touch_mode configurato su True quando si utilizza stow_on_each_sample configurato su False. Alcuni dispositivi \"clone\" potrebbero non rilevare un successivo contatto con il piatto se probe_with_touch_mode non \u00e8 impostato. Su tutti i dispositivi, l'utilizzo della combinazione di queste due impostazioni semplifica la segnalazione del dispositivo, che pu\u00f2 migliorare la stabilit\u00e0 generale. Si noti, tuttavia, che alcuni dispositivi \"clone\" e BL-Touch v2.0 (e precedenti) potrebbero avere una precisione ridotta quando probe_with_touch_mode \u00e8 impostato su True. Su questi dispositivi \u00e8 una buona idea testare l'accuratezza della sonda prima e dopo aver impostato probe_with_touch_mode (usare il comando di test PROBE_ACCURACY ).","title":"Multi-sondaggio senza riporre"},{"location":"BLTouch.html#calibrazione-degli-offset-bl-touch","text":"Seguire le istruzioni nella guida Probe Calibrate per impostare i parametri di configurazione x_offset, y_offset e z_offset. \u00c8 una buona idea verificare che l'offset Z sia vicino a 1 mm. In caso contrario, probabilmente vorrai spostare la sonda su o gi\u00f9 per risolvere il problema. Si desidera che si attivi ben prima che l'ugello colpisca il piatto, in modo che un possibile filamento bloccato o un piatto deformato non influisca sull'azione della sonda. Ma allo stesso tempo, si desidera che la posizione retratta sia il pi\u00f9 possibile al di sopra dell'ugello per evitare che tocchi le parti stampate. Se viene effettuata una regolazione della posizione della sonda, eseguire nuovamente i passaggi di calibrazione della sonda.","title":"Calibrazione degli offset BL-Touch"},{"location":"BLTouch.html#modalita-di-output-bl-touch","text":"Un BL-Touch V3.0 supporta l'impostazione di una modalit\u00e0 di uscita 5V o OPEN-DRAIN, un BL-Touch V3.1 supporta anche questo, ma pu\u00f2 anche memorizzarlo nella sua EEPROM interna. Se la tua scheda controller ha bisogno del livello logico alto 5V fisso della modalit\u00e0 5V, puoi impostare il parametro 'set_output_mode' nella sezione [bltouch] del file di configurazione della stampante su \"5V\". Utilizzare la modalit\u00e0 5V solo se la linea di ingresso della scheda controller \u00e8 tollerante a 5V. Ecco perch\u00e9 la configurazione di default di queste versioni BL-Touch \u00e8 la modalit\u00e0 OPEN-DRAIN. Potresti potenzialmente danneggiare la CPU delle tue schede di controllo Quindi: se una scheda controller HA BISOGNO della modalit\u00e0 5V ED \u00e8 tollerante a 5V sulla sua linea del segnale di ingresso E se si dispone di un BL-Touch Smart V3.0, \u00e8 necessario utilizzare il parametro 'set_output_mode: 5V' per garantire questa impostazione ad ogni avvio, poich\u00e9 la sonda non ricorda l'impostazione necessaria. hai un BL-Touch Smart V3.1, puoi scegliere di usare 'set_output_mode: 5V' o memorizzare la modalit\u00e0 una volta usando un comando 'BLTOUCH_STORE MODE=5V' manualmente e NON usando il parametro 'set_output_mode:'. hai qualche altra sonda: alcune sonde hanno una traccia sul circuito stampato da tagliare o un ponticello da impostare per impostare (permanentemente) la modalit\u00e0 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\u00e0 di output per evitare di consumare la EEPROM della sonda. La BLTouch EEPROM \u00e8 valida per circa 100.000 aggiornamenti. 100 memorizzazioni al giorno aggiungerebbero fino a circa 3 anni di attivit\u00e0 prima di logorarlo. Pertanto, la memorizzazione della modalit\u00e0 di output in una V3.1 \u00e8 progettata dal fornitore per essere un'operazione complicata (l'impostazione predefinita di fabbrica \u00e8 una modalit\u00e0 OPEN DRAIN sicura) e non \u00e8 adatta per essere emessa ripetutamente da qualsiasi slicer, macro o altro, esso \u00e8 preferibilmente da utilizzare solo quando si integra per la prima volta la sonda nell'elettronica di una stampante.","title":"Modalit\u00e0 di output BL-Touch"},{"location":"Beaglebone.html","text":"Beaglebone \u00b6 Questo documento descrive il processo di esecuzione di Klipper su una PRU Beaglebone. Creazione di un'immagine del sistema operativo \u00b6 Inizia installando l'immagine Debian 9.9 2019-08-03 4GB SD IoT . \u00c8 possibile eseguire l'immagine da una scheda micro-SD o dall'eMMC integrato. Se si utilizza l'eMMC, installarlo ora nell'eMMC seguendo le istruzioni dal collegamento sopra. Quindi loggati ssh nella macchina Beaglebone ( ssh debian@beaglebone -- la password \u00e8 temppwd ) e installa Klipper eseguendo i seguenti comandi: git clone https://github.com/Klipper3d/klipper ./klipper/scripts/install-beaglebone.sh Installare Octoprint \u00b6 Si pu\u00f2 quindi installare Octoprint: git clone https://github.com/foosel/OctoPrint.git cd OctoPrint/ virtualenv venv ./venv/bin/python setup.py install E configura OctoPrint per l'avvio all'avvio: sudo cp ~/OctoPrint/scripts/octoprint.init /etc/init.d/octoprint sudo chmod +x /etc/init.d/octoprint sudo cp ~/OctoPrint/scripts/octoprint.default /etc/default/octoprint sudo update-rc.d octoprint defaults \u00c8 necessario modificare il file di configurazione /etc/default/octoprint di OctoPrint. Si deve cambiare l'utente OCTOPRINT_USER in debian , cambiare NICELEVEL in 0 , togliere il commento alle impostazioni di BASEDIR , CONFIGFILE e DAEMON e cambiare i riferimenti della home da /home/pi/ a /home/debian/ : sudo nano /etc/default/octoprint Quindi avvia il servizio Octoprint: sudo systemctl start octoprint Assicurati che il server web OctoPrint sia accessibile - dovrebbe trovarsi su: http://beaglebone:5000/ Creazione del codice del microcontrollore \u00b6 Per compilare il codice del microcontrollore Klipper, inizia configurandolo per il \"Beaglebone PRU\": cd ~/klipper/ make menuconfig Per compilare e installare il nuovo codice del microcontrollore, eseguire: sudo service klipper stop make flash sudo service klipper start \u00c8 inoltre necessario compilare e installare il codice del microcontrollore per un processo host Linux. Configuralo per un \"processo Linux\": make menuconfig Quindi installa anche questo codice del microcontrollore: sudo service klipper stop make flash sudo service klipper start Configurazione rimanente \u00b6 Completare l'installazione configurando Klipper e Octoprint seguendo le istruzioni nel documento principale Installation . Stampa sul Beaglebone \u00b6 Sfortunatamente, il processore Beaglebone a volte pu\u00f2 avere difficolt\u00e0 a far funzionare bene OctoPrint. \u00c8 noto che i blocchi di stampa si verificano su stampe complesse (la stampante potrebbe muoversi pi\u00f9 velocemente di quanto OctoPrint possa inviare comandi di movimento). In questo caso, considera l'utilizzo della funzione \"virtual_sdcard\" (consulta Config Reference per i dettagli) per stampare direttamente da Klipper.","title":"Beaglebone"},{"location":"Beaglebone.html#beaglebone","text":"Questo documento descrive il processo di esecuzione di Klipper su una PRU Beaglebone.","title":"Beaglebone"},{"location":"Beaglebone.html#creazione-di-unimmagine-del-sistema-operativo","text":"Inizia installando l'immagine Debian 9.9 2019-08-03 4GB SD IoT . \u00c8 possibile eseguire l'immagine da una scheda micro-SD o dall'eMMC integrato. Se si utilizza l'eMMC, installarlo ora nell'eMMC seguendo le istruzioni dal collegamento sopra. Quindi loggati ssh nella macchina Beaglebone ( ssh debian@beaglebone -- la password \u00e8 temppwd ) e installa Klipper eseguendo i seguenti comandi: git clone https://github.com/Klipper3d/klipper ./klipper/scripts/install-beaglebone.sh","title":"Creazione di un'immagine del sistema operativo"},{"location":"Beaglebone.html#installare-octoprint","text":"Si pu\u00f2 quindi installare Octoprint: git clone https://github.com/foosel/OctoPrint.git cd OctoPrint/ virtualenv venv ./venv/bin/python setup.py install E configura OctoPrint per l'avvio all'avvio: sudo cp ~/OctoPrint/scripts/octoprint.init /etc/init.d/octoprint sudo chmod +x /etc/init.d/octoprint sudo cp ~/OctoPrint/scripts/octoprint.default /etc/default/octoprint sudo update-rc.d octoprint defaults \u00c8 necessario modificare il file di configurazione /etc/default/octoprint di OctoPrint. Si deve cambiare l'utente OCTOPRINT_USER in debian , cambiare NICELEVEL in 0 , togliere il commento alle impostazioni di BASEDIR , CONFIGFILE e DAEMON e cambiare i riferimenti della home da /home/pi/ a /home/debian/ : sudo nano /etc/default/octoprint Quindi avvia il servizio Octoprint: sudo systemctl start octoprint Assicurati che il server web OctoPrint sia accessibile - dovrebbe trovarsi su: http://beaglebone:5000/","title":"Installare Octoprint"},{"location":"Beaglebone.html#creazione-del-codice-del-microcontrollore","text":"Per compilare il codice del microcontrollore Klipper, inizia configurandolo per il \"Beaglebone PRU\": cd ~/klipper/ make menuconfig Per compilare e installare il nuovo codice del microcontrollore, eseguire: sudo service klipper stop make flash sudo service klipper start \u00c8 inoltre necessario compilare e installare il codice del microcontrollore per un processo host Linux. Configuralo per un \"processo Linux\": make menuconfig Quindi installa anche questo codice del microcontrollore: sudo service klipper stop make flash sudo service klipper start","title":"Creazione del codice del microcontrollore"},{"location":"Beaglebone.html#configurazione-rimanente","text":"Completare l'installazione configurando Klipper e Octoprint seguendo le istruzioni nel documento principale Installation .","title":"Configurazione rimanente"},{"location":"Beaglebone.html#stampa-sul-beaglebone","text":"Sfortunatamente, il processore Beaglebone a volte pu\u00f2 avere difficolt\u00e0 a far funzionare bene OctoPrint. \u00c8 noto che i blocchi di stampa si verificano su stampe complesse (la stampante potrebbe muoversi pi\u00f9 velocemente di quanto OctoPrint possa inviare comandi di movimento). In questo caso, considera l'utilizzo della funzione \"virtual_sdcard\" (consulta Config Reference per i dettagli) per stampare direttamente da Klipper.","title":"Stampa sul Beaglebone"},{"location":"Bed_Level.html","text":"Livellamento del piatto \u00b6 La livellatura del piatto \u00e8 fondamentale per ottenere stampe di alta qualit\u00e0. Se un piatto non \u00e8 adeguatamente \"livellato\" pu\u00f2 portare a una scarsa adesione sul piatto, a una \"deformazione\" e a problemi minori durante la stampa. Questo documento serve come guida per eseguire il livellamento del piatto in Klipper. \u00c8 importante comprendere l'obiettivo del livellamento del piatto. Se alla stampante viene comandata una posizione X0 Y0 Z10 durante una stampa, l'obiettivo \u00e8 che l'ugello della stampante si trovi esattamente a 10 mm dal piatto della stampante. Inoltre, se poi la stampante dovesse essere comandata in una posizione di X50 Z10 , l'obiettivo \u00e8 che l'ugello mantenga una distanza esatta di 10 mm dal piatto durante l'intero movimento orizzontale. Per ottenere stampe di buona qualit\u00e0, la stampante deve essere calibrata in modo che le distanze Z siano precise entro circa 25 micron (0,025 mm). Questa \u00e8 una piccola distanza, significativamente pi\u00f9 piccola della larghezza di un tipico capello umano. Questa scala non pu\u00f2 essere misurata \"a occhio\". Gli effetti sottili (come l'espansione del calore) influiscono sulle misurazioni a questa scala. Il segreto per ottenere un'elevata precisione \u00e8 utilizzare un processo ripetibile e un metodo di livellamento che sfrutti l'elevata precisione del sistema di movimento della stampante. Scegliere il meccanismo di calibrazione appropriato \u00b6 Diversi tipi di stampanti utilizzano metodi diversi per eseguire il livellamento del piatto. Tutti alla fine dipendono dal \"test cartaceo\" (descritto di seguito). Tuttavia, il processo effettivo per un particolare tipo di stampante \u00e8 descritto in altri documenti. Prima di eseguire uno di questi strumenti di calibrazione, assicurarsi di eseguire i controlli descritti nel documento check di configurazione . \u00c8 necessario verificare il movimento di base della stampante prima di eseguire il livellamento del piatto. Per le stampanti con una \"sonda Z automatica\", assicurarsi di calibrare la sonda seguendo le istruzioni nel documento Probe Calibrate . Per le stampanti delta, vedere il documento Delta Calibrate . Per le stampanti con viti di fissaggio e fermi Z tradizionali, vedere il documento Manual Level . Durante la calibrazione potrebbe essere necessario impostare la Z position_min della stampante su un numero negativo (ad esempio, position_min = -2 ). La stampante applica i controlli dei confini anche durante le routine di calibrazione. L'impostazione di un numero negativo consente alla stampante di spostarsi al di sotto della posizione nominale del piatto, il che pu\u00f2 aiutare quando si tenta di determinare la posizione effettiva del piatto. Il \"test con la carta\" \u00b6 Il meccanismo primario di calibrazione del piatto primario \u00e8 il \"test della carta\". Si tratta di posizionare un normale pezzo di \"carta per fotocopiatrice\" tra il piatto della stampante e l'ugello, quindi comandare l'ugello a diverse altezze Z finch\u00e9 non si avverte una piccola quantit\u00e0 di attrito quando si spinge la carta avanti e indietro. \u00c8 importante comprendere il \"test della carta\" anche se si dispone di una \"sonda Z automatica\". La sonda stessa deve spesso essere calibrata per ottenere buoni risultati. La calibrazione della sonda viene eseguita utilizzando questo \"test della carta\". Per eseguire il test della carta, taglia un piccolo pezzo di carta rettangolare usando un paio di forbici (es. 5x3 cm). La carta ha generalmente uno spessore di circa 100 micron (0,100 mm). (Lo spessore esatto della carta non \u00e8 cruciale.) Il primo passaggio del test della carta consiste nell'ispezione dell'ugello e del piatto della stampante. Assicurati che non ci sia plastica (o altri detriti) sull'ugello o sul letto. Ispeziona l'ugello e il piatto per assicurarti che non sia presente plastica! Se si stampa sempre su un determinato nastro o superficie di stampa, \u00e8 possibile eseguire il test della carta con quel nastro/superficie in posizione. Tuttavia, tieni presente che il nastro stesso ha uno spessore e nastri diversi (o qualsiasi altra superficie di stampa) influiranno sulle misurazioni Z. Assicurati di eseguire nuovamente il test della carta per misurare ogni tipo di superficie in uso. Se c'\u00e8 della plastica sull'ugello, riscalda l'estrusore e usa una pinzetta di metallo per rimuovere quella plastica. Attendere che l'estrusore si raffreddi completamente a temperatura ambiente prima di continuare con il test della carta. Mentre l'ugello si sta raffreddando, usa le pinzette di metallo per rimuovere la plastica che potrebbe fuoriuscire. Esegui sempre il test della carta quando sia l'ugello che il letto sono a temperatura ambiente! Quando l'ugello \u00e8 riscaldato, la sua posizione (rispetto al piatto) cambia a causa dell'espansione termica. Questa espansione termica \u00e8 in genere di circa 100 micron, che ha all'incirca lo stesso spessore di un tipico pezzo di carta per stampante. L'esatta quantit\u00e0 di espansione termica non \u00e8 cruciale, cos\u00ec come lo spessore esatto della carta non \u00e8 cruciale. Inizia con il presupposto che i due siano uguali (vedi sotto per un metodo per determinare la differenza tra le due distanze). Pu\u00f2 sembrare strano calibrare la distanza a temperatura ambiente quando l'obiettivo \u00e8 avere una distanza costante quando riscaldata. Tuttavia, se si calibra quando l'ugello \u00e8 riscaldato, tende a rilasciare piccole quantit\u00e0 di plastica fusa alla carta, il che cambia la quantit\u00e0 di attrito sentito. Ci\u00f2 rende pi\u00f9 difficile ottenere una buona calibrazione. La calibrazione mentre il letto/ugello \u00e8 caldo aumenta notevolmente anche il rischio di ustione. La quantit\u00e0 di espansione termica \u00e8 stabile, quindi \u00e8 facilmente contabilizzabile pi\u00f9 avanti nel processo di calibrazione. Utilizza uno strumento automatizzato per determinare l'altezza Z precisa! Klipper ha diversi script di supporto disponibili (ad esempio, MANUAL_PROBE, Z_ENDSTOP_CALIBRATE, PROBE_CALIBRATE, DELTA_CALIBRATE). Consulta i documenti descritti sopra per sceglierne uno. Eseguire il comando appropriato nella finestra del terminale di OctoPrint. Lo script richieder\u00e0 l'interazione dell'utente nell'output del terminale OctoPrint. Sembrer\u00e0 qualcosa come: Recv: // Starting manual Z probe. Use TESTZ to adjust position. Recv: // Finish with ACCEPT or ABORT command. Recv: // Z position: ?????? --> 5.000 <-- ?????? L'altezza attuale dell'ugello (come la intende attualmente la stampante) \u00e8 mostrata tra \"--> <--\". Il numero a destra \u00e8 l'altezza dell'ultimo tentativo di sonda appena maggiore dell'altezza attuale e a sinistra \u00e8 l'ultimo tentativo di sonda inferiore all'altezza attuale (o ?????? se non \u00e8 stato effettuato alcun tentativo). Metti la carta tra l'ugello e il letto. Pu\u00f2 essere utile piegare un angolo della carta in modo che sia pi\u00f9 facile da afferrare. (Cerca di non spingere il piatto quando muovi la carta avanti e indietro.) Utilizzare il comando TESTZ per richiedere all'ugello di avvicinarsi alla carta. Per esempio: TESTZ Z=-.1 Il comando TESTZ sposter\u00e0 l'ugello di una distanza relativa dalla posizione corrente dell'ugello. (Quindi, Z=-.1 richiede che l'ugello si avvicini al piatto di 0,1 mm.) Dopo che l'ugello ha smesso di muoversi, spingere la carta avanti e indietro per controllare se l'ugello \u00e8 in contatto con la carta e per sentire la quantit\u00e0 di attrito. Continua a emettere comandi TESTZ finch\u00e9 non si avverte una piccola quantit\u00e0 di attrito durante il test con la carta. Se si trova troppo attrito, \u00e8 possibile utilizzare un valore Z positivo per spostare l'ugello verso l'alto. \u00c8 anche possibile utilizzare TESTZ Z=+ o TESTZ Z=- per \"sezionare in due\" l'ultima posizione, ovvero per spostarsi in una posizione a met\u00e0 strada tra due posizioni. Ad esempio, se si riceve il seguente prompt da un comando TESTZ: Recv: // Z position: 0.130 --> 0.230 <-- 0.280 Quindi un TESTZ Z=- sposterebbe l'ugello in una posizione Z di 0,180 (a met\u00e0 strada tra 0,130 e 0,230). \u00c8 possibile utilizzare questa funzione per ridurre rapidamente a un attrito costante. \u00c8 anche possibile usare Z=++ e Z=-- per tornare direttamente a una misurazione passata - per esempio, dopo il prompt sopra un comando TESTZ Z=-- sposterebbe l'ugello su una Z posizione di 0,130. Dopo aver trovato una piccola quantit\u00e0 di attrito, eseguire il comando ACCETTA: ACCEPT Questo accetter\u00e0 l'altezza Z data e proceder\u00e0 con lo strumento di calibrazione fornito. L'esatta quantit\u00e0 di attrito percepito non \u00e8 cruciale, cos\u00ec come la quantit\u00e0 di espansione termica e l'esatta larghezza della carta non sono cruciali. Cerca solo di ottenere la stessa quantit\u00e0 di attrito ogni volta che esegui il test. Se qualcosa va storto durante il test, \u00e8 possibile utilizzare il comando ABORT per uscire dallo strumento di calibrazione. Determinare l'espansione termica \u00b6 Dopo aver eseguito con successo il livellamento del piatto, si pu\u00f2 continuare a calcolare un valore pi\u00f9 preciso per l'impatto combinato di \"espansione termica\", \"spessore della carta\" e \"quantit\u00e0 di attrito sentito durante il test della carta\". Questo tipo di calcolo generalmente non \u00e8 necessario poich\u00e9 la maggior parte degli utenti ritiene che il semplice \"test cartaceo\" fornisca buoni risultati. Il modo pi\u00f9 semplice per eseguire questo calcolo \u00e8 stampare un oggetto di prova con pareti dritte su tutti i lati. Il cubo vuoto che si trova in docs/prints/square.stl pu\u00f2 essere usato per questo. Quando si fa lo slicing l'oggetto, assicurarsi che lo slicer utilizzi la stessa altezza del livello e la stessa larghezza di estrusione per il primo livello che utilizza per tutti i livelli successivi. Utilizzare un'altezza dello strato grossolana (l'altezza dello strato dovrebbe essere circa il 75% del diametro dell'ugello) e non utilizzare un bordo o una raft. Stampa l'oggetto di prova, attendi che si raffreddi e rimuovilo dal piatto. Ispeziona lo strato pi\u00f9 basso dell'oggetto. (Pu\u00f2 anche essere utile far scorrere un dito o un'unghia lungo il bordo inferiore.) Se si scopre che lo strato inferiore si gonfia leggermente lungo tutti i lati dell'oggetto, significa che l'ugello era leggermente pi\u00f9 vicino al piatto di quanto dovrebbe essere. Si pu\u00f2 emettere un comando SET_GCODE_OFFSET Z=+.010 per aumentare l'altezza. Nelle stampe successive \u00e8 possibile controllare questo comportamento e apportare ulteriori modifiche secondo necessit\u00e0. Le regolazioni di questo tipo sono in genere in 10 micron (0,010 mm). Se il livello inferiore appare costantemente pi\u00f9 stretto dei livelli successivi, \u00e8 possibile utilizzare il comando SET_GCODE_OFFSET per effettuare una regolazione Z negativa. Se non si \u00e8 sicuri, \u00e8 possibile diminuire la regolazione Z finch\u00e9 lo strato inferiore delle stampe non mostra un piccolo rigonfiamento, quindi arretrare finch\u00e9 non scompare. Il modo pi\u00f9 semplice per applicare la regolazione Z desiderata \u00e8 creare una macro di G-code START_PRINT, fare in modo che lo slicer chiami quella macro all'inizio di ogni stampa e aggiungere un comando SET_GCODE_OFFSET a quella macro. Per ulteriori dettagli, vedere il documento slicers .","title":"Livellamento del piatto"},{"location":"Bed_Level.html#livellamento-del-piatto","text":"La livellatura del piatto \u00e8 fondamentale per ottenere stampe di alta qualit\u00e0. Se un piatto non \u00e8 adeguatamente \"livellato\" pu\u00f2 portare a una scarsa adesione sul piatto, a una \"deformazione\" e a problemi minori durante la stampa. Questo documento serve come guida per eseguire il livellamento del piatto in Klipper. \u00c8 importante comprendere l'obiettivo del livellamento del piatto. Se alla stampante viene comandata una posizione X0 Y0 Z10 durante una stampa, l'obiettivo \u00e8 che l'ugello della stampante si trovi esattamente a 10 mm dal piatto della stampante. Inoltre, se poi la stampante dovesse essere comandata in una posizione di X50 Z10 , l'obiettivo \u00e8 che l'ugello mantenga una distanza esatta di 10 mm dal piatto durante l'intero movimento orizzontale. Per ottenere stampe di buona qualit\u00e0, la stampante deve essere calibrata in modo che le distanze Z siano precise entro circa 25 micron (0,025 mm). Questa \u00e8 una piccola distanza, significativamente pi\u00f9 piccola della larghezza di un tipico capello umano. Questa scala non pu\u00f2 essere misurata \"a occhio\". Gli effetti sottili (come l'espansione del calore) influiscono sulle misurazioni a questa scala. Il segreto per ottenere un'elevata precisione \u00e8 utilizzare un processo ripetibile e un metodo di livellamento che sfrutti l'elevata precisione del sistema di movimento della stampante.","title":"Livellamento del piatto"},{"location":"Bed_Level.html#scegliere-il-meccanismo-di-calibrazione-appropriato","text":"Diversi tipi di stampanti utilizzano metodi diversi per eseguire il livellamento del piatto. Tutti alla fine dipendono dal \"test cartaceo\" (descritto di seguito). Tuttavia, il processo effettivo per un particolare tipo di stampante \u00e8 descritto in altri documenti. Prima di eseguire uno di questi strumenti di calibrazione, assicurarsi di eseguire i controlli descritti nel documento check di configurazione . \u00c8 necessario verificare il movimento di base della stampante prima di eseguire il livellamento del piatto. Per le stampanti con una \"sonda Z automatica\", assicurarsi di calibrare la sonda seguendo le istruzioni nel documento Probe Calibrate . Per le stampanti delta, vedere il documento Delta Calibrate . Per le stampanti con viti di fissaggio e fermi Z tradizionali, vedere il documento Manual Level . Durante la calibrazione potrebbe essere necessario impostare la Z position_min della stampante su un numero negativo (ad esempio, position_min = -2 ). La stampante applica i controlli dei confini anche durante le routine di calibrazione. L'impostazione di un numero negativo consente alla stampante di spostarsi al di sotto della posizione nominale del piatto, il che pu\u00f2 aiutare quando si tenta di determinare la posizione effettiva del piatto.","title":"Scegliere il meccanismo di calibrazione appropriato"},{"location":"Bed_Level.html#il-test-con-la-carta","text":"Il meccanismo primario di calibrazione del piatto primario \u00e8 il \"test della carta\". Si tratta di posizionare un normale pezzo di \"carta per fotocopiatrice\" tra il piatto della stampante e l'ugello, quindi comandare l'ugello a diverse altezze Z finch\u00e9 non si avverte una piccola quantit\u00e0 di attrito quando si spinge la carta avanti e indietro. \u00c8 importante comprendere il \"test della carta\" anche se si dispone di una \"sonda Z automatica\". La sonda stessa deve spesso essere calibrata per ottenere buoni risultati. La calibrazione della sonda viene eseguita utilizzando questo \"test della carta\". Per eseguire il test della carta, taglia un piccolo pezzo di carta rettangolare usando un paio di forbici (es. 5x3 cm). La carta ha generalmente uno spessore di circa 100 micron (0,100 mm). (Lo spessore esatto della carta non \u00e8 cruciale.) Il primo passaggio del test della carta consiste nell'ispezione dell'ugello e del piatto della stampante. Assicurati che non ci sia plastica (o altri detriti) sull'ugello o sul letto. Ispeziona l'ugello e il piatto per assicurarti che non sia presente plastica! Se si stampa sempre su un determinato nastro o superficie di stampa, \u00e8 possibile eseguire il test della carta con quel nastro/superficie in posizione. Tuttavia, tieni presente che il nastro stesso ha uno spessore e nastri diversi (o qualsiasi altra superficie di stampa) influiranno sulle misurazioni Z. Assicurati di eseguire nuovamente il test della carta per misurare ogni tipo di superficie in uso. Se c'\u00e8 della plastica sull'ugello, riscalda l'estrusore e usa una pinzetta di metallo per rimuovere quella plastica. Attendere che l'estrusore si raffreddi completamente a temperatura ambiente prima di continuare con il test della carta. Mentre l'ugello si sta raffreddando, usa le pinzette di metallo per rimuovere la plastica che potrebbe fuoriuscire. Esegui sempre il test della carta quando sia l'ugello che il letto sono a temperatura ambiente! Quando l'ugello \u00e8 riscaldato, la sua posizione (rispetto al piatto) cambia a causa dell'espansione termica. Questa espansione termica \u00e8 in genere di circa 100 micron, che ha all'incirca lo stesso spessore di un tipico pezzo di carta per stampante. L'esatta quantit\u00e0 di espansione termica non \u00e8 cruciale, cos\u00ec come lo spessore esatto della carta non \u00e8 cruciale. Inizia con il presupposto che i due siano uguali (vedi sotto per un metodo per determinare la differenza tra le due distanze). Pu\u00f2 sembrare strano calibrare la distanza a temperatura ambiente quando l'obiettivo \u00e8 avere una distanza costante quando riscaldata. Tuttavia, se si calibra quando l'ugello \u00e8 riscaldato, tende a rilasciare piccole quantit\u00e0 di plastica fusa alla carta, il che cambia la quantit\u00e0 di attrito sentito. Ci\u00f2 rende pi\u00f9 difficile ottenere una buona calibrazione. La calibrazione mentre il letto/ugello \u00e8 caldo aumenta notevolmente anche il rischio di ustione. La quantit\u00e0 di espansione termica \u00e8 stabile, quindi \u00e8 facilmente contabilizzabile pi\u00f9 avanti nel processo di calibrazione. Utilizza uno strumento automatizzato per determinare l'altezza Z precisa! Klipper ha diversi script di supporto disponibili (ad esempio, MANUAL_PROBE, Z_ENDSTOP_CALIBRATE, PROBE_CALIBRATE, DELTA_CALIBRATE). Consulta i documenti descritti sopra per sceglierne uno. Eseguire il comando appropriato nella finestra del terminale di OctoPrint. Lo script richieder\u00e0 l'interazione dell'utente nell'output del terminale OctoPrint. Sembrer\u00e0 qualcosa come: Recv: // Starting manual Z probe. Use TESTZ to adjust position. Recv: // Finish with ACCEPT or ABORT command. Recv: // Z position: ?????? --> 5.000 <-- ?????? L'altezza attuale dell'ugello (come la intende attualmente la stampante) \u00e8 mostrata tra \"--> <--\". Il numero a destra \u00e8 l'altezza dell'ultimo tentativo di sonda appena maggiore dell'altezza attuale e a sinistra \u00e8 l'ultimo tentativo di sonda inferiore all'altezza attuale (o ?????? se non \u00e8 stato effettuato alcun tentativo). Metti la carta tra l'ugello e il letto. Pu\u00f2 essere utile piegare un angolo della carta in modo che sia pi\u00f9 facile da afferrare. (Cerca di non spingere il piatto quando muovi la carta avanti e indietro.) Utilizzare il comando TESTZ per richiedere all'ugello di avvicinarsi alla carta. Per esempio: TESTZ Z=-.1 Il comando TESTZ sposter\u00e0 l'ugello di una distanza relativa dalla posizione corrente dell'ugello. (Quindi, Z=-.1 richiede che l'ugello si avvicini al piatto di 0,1 mm.) Dopo che l'ugello ha smesso di muoversi, spingere la carta avanti e indietro per controllare se l'ugello \u00e8 in contatto con la carta e per sentire la quantit\u00e0 di attrito. Continua a emettere comandi TESTZ finch\u00e9 non si avverte una piccola quantit\u00e0 di attrito durante il test con la carta. Se si trova troppo attrito, \u00e8 possibile utilizzare un valore Z positivo per spostare l'ugello verso l'alto. \u00c8 anche possibile utilizzare TESTZ Z=+ o TESTZ Z=- per \"sezionare in due\" l'ultima posizione, ovvero per spostarsi in una posizione a met\u00e0 strada tra due posizioni. Ad esempio, se si riceve il seguente prompt da un comando TESTZ: Recv: // Z position: 0.130 --> 0.230 <-- 0.280 Quindi un TESTZ Z=- sposterebbe l'ugello in una posizione Z di 0,180 (a met\u00e0 strada tra 0,130 e 0,230). \u00c8 possibile utilizzare questa funzione per ridurre rapidamente a un attrito costante. \u00c8 anche possibile usare Z=++ e Z=-- per tornare direttamente a una misurazione passata - per esempio, dopo il prompt sopra un comando TESTZ Z=-- sposterebbe l'ugello su una Z posizione di 0,130. Dopo aver trovato una piccola quantit\u00e0 di attrito, eseguire il comando ACCETTA: ACCEPT Questo accetter\u00e0 l'altezza Z data e proceder\u00e0 con lo strumento di calibrazione fornito. L'esatta quantit\u00e0 di attrito percepito non \u00e8 cruciale, cos\u00ec come la quantit\u00e0 di espansione termica e l'esatta larghezza della carta non sono cruciali. Cerca solo di ottenere la stessa quantit\u00e0 di attrito ogni volta che esegui il test. Se qualcosa va storto durante il test, \u00e8 possibile utilizzare il comando ABORT per uscire dallo strumento di calibrazione.","title":"Il \"test con la carta\""},{"location":"Bed_Level.html#determinare-lespansione-termica","text":"Dopo aver eseguito con successo il livellamento del piatto, si pu\u00f2 continuare a calcolare un valore pi\u00f9 preciso per l'impatto combinato di \"espansione termica\", \"spessore della carta\" e \"quantit\u00e0 di attrito sentito durante il test della carta\". Questo tipo di calcolo generalmente non \u00e8 necessario poich\u00e9 la maggior parte degli utenti ritiene che il semplice \"test cartaceo\" fornisca buoni risultati. Il modo pi\u00f9 semplice per eseguire questo calcolo \u00e8 stampare un oggetto di prova con pareti dritte su tutti i lati. Il cubo vuoto che si trova in docs/prints/square.stl pu\u00f2 essere usato per questo. Quando si fa lo slicing l'oggetto, assicurarsi che lo slicer utilizzi la stessa altezza del livello e la stessa larghezza di estrusione per il primo livello che utilizza per tutti i livelli successivi. Utilizzare un'altezza dello strato grossolana (l'altezza dello strato dovrebbe essere circa il 75% del diametro dell'ugello) e non utilizzare un bordo o una raft. Stampa l'oggetto di prova, attendi che si raffreddi e rimuovilo dal piatto. Ispeziona lo strato pi\u00f9 basso dell'oggetto. (Pu\u00f2 anche essere utile far scorrere un dito o un'unghia lungo il bordo inferiore.) Se si scopre che lo strato inferiore si gonfia leggermente lungo tutti i lati dell'oggetto, significa che l'ugello era leggermente pi\u00f9 vicino al piatto di quanto dovrebbe essere. Si pu\u00f2 emettere un comando SET_GCODE_OFFSET Z=+.010 per aumentare l'altezza. Nelle stampe successive \u00e8 possibile controllare questo comportamento e apportare ulteriori modifiche secondo necessit\u00e0. Le regolazioni di questo tipo sono in genere in 10 micron (0,010 mm). Se il livello inferiore appare costantemente pi\u00f9 stretto dei livelli successivi, \u00e8 possibile utilizzare il comando SET_GCODE_OFFSET per effettuare una regolazione Z negativa. Se non si \u00e8 sicuri, \u00e8 possibile diminuire la regolazione Z finch\u00e9 lo strato inferiore delle stampe non mostra un piccolo rigonfiamento, quindi arretrare finch\u00e9 non scompare. Il modo pi\u00f9 semplice per applicare la regolazione Z desiderata \u00e8 creare una macro di G-code START_PRINT, fare in modo che lo slicer chiami quella macro all'inizio di ogni stampa e aggiungere un comando SET_GCODE_OFFSET a quella macro. Per ulteriori dettagli, vedere il documento slicers .","title":"Determinare l'espansione termica"},{"location":"Bed_Mesh.html","text":"Matrice del Piatto \u00b6 Il modulo Bed Mesh pu\u00f2 essere utilizzato per compensare le irregolarit\u00e0 della superficie del piatto per ottenere un primo strato migliore sull'intero piatto. Va notato che la correzione basata sul software non otterr\u00e0 risultati perfetti, potr\u00e0 solo approssimare la forma del piatto. Inoltre, Bed Mesh non pu\u00f2 compensare problemi meccanici ed elettrici. Se un asse \u00e8 inclinato o una sonda non \u00e8 precisa, il modulo bed_mesh non ricever\u00e0 risultati accurati dal processo di tastatura. Prima della calibrazione della mesh dovrai assicurarti che l'offset Z della tua sonda sia calibrato. Se si utilizza un fine corsa per l'homing Z, anche questo dovr\u00e0 essere calibrato. Per ulteriori informazioni, vedere Probe Calibrate e Z_ENDSTOP_CALIBRATE in Manual Level . Configurazione base \u00b6 Piatti rettangolari \u00b6 Questo esempio presuppone una stampante con un piatto rettangolare di 250 mm x 220 mm e una sonda con un offset x di 24 mm e un offset y di 5 mm. [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 probe_count: 5, 3 speed: 120 Valore predefinito: 50 La velocit\u00e0 con cui la testa di stampa si sposta tra i punti. horizontal_move_z: 5 Valore predefinito: 5 La coordinata Z a cui si solleva la sonda prima di spostarsi tra i punti. mesh_min: 35, 6 Richiesto La prima coordinata rilevata, pi\u00f9 vicina all'origine. Questa coordinata \u00e8 relativa alla posizione della sonda. mesh_max: 240, 198 Obbligatorio La coordinata pi\u00f9 lontana rilevata dall'origine. Questo non \u00e8 necessariamente l'ultimo punto esplorato, poich\u00e9 il processo di ispezione avviene a zig-zag. Come con mesh_min , questa coordinata \u00e8 relativa alla posizione della sonda. probe_count: 5, 3 Valore predefinito: 3, 3 Il numero di punti da sondare su ciascun asse, specificato come valori interi X, Y. In questo esempio verranno tastati 5 punti lungo l'asse X, con 3 punti lungo l'asse Y, per un totale di 15 punti tastati. Nota che se desideri una griglia quadrata, ad esempio 3x3, questo potrebbe essere specificato come un singolo valore intero che viene utilizzato per entrambi gli assi, ad esempio probe_count: 3 . Si noti che una mesh richiede un probe_count minimo di 3 lungo ciascun asse. L'illustrazione seguente mostra come le opzioni mesh_min , mesh_max e probe_count vengono utilizzate per generare punti sonda. Le frecce indicano la direzione della procedura di probing, a partire da mesh_min . Per riferimento, quando la sonda \u00e8 a mesh_min , l'ugello sar\u00e0 a (11, 1), e quando la sonda \u00e8 a mesh_max , l'ugello sar\u00e0 a (206, 193). Piatti rotondi \u00b6 Questo esempio presuppone una stampante dotata di un raggio del piatto rotondo di 100 mm. Utilizzeremo gli stessi offset della sonda dell'esempio rettangolare, 24 mm su X e 5 mm su Y. [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_radius: 75 mesh_origin: 0, 0 round_probe_count: 5 mesh_radius: 75 Obbligatorio Il raggio della mesh sondata in mm, relativo a mesh_origin . Si noti che gli offset della sonda limitano la dimensione del raggio della mesh. In questo esempio, un raggio maggiore di 76 sposterebbe lo strumento oltre il range della stampante. mesh_origin: 0, 0 Valore predefinito: 0, 0 Il punto centrale della mesh. Questa coordinata \u00e8 relativa alla posizione della sonda. Sebbene il valore predefinito sia 0, 0, pu\u00f2 essere utile regolare l'origine nel tentativo di sondare una porzione pi\u00f9 ampia del letto. Vedi l'illustrazione qui sotto. round_probe_count: 5 Valore predefinito: 5 Questo \u00e8 un valore intero che definisce il numero massimo di punti sondati lungo gli assi X e Y. Per \"massimo\" si intende il numero di punti tastati lungo l'origine della mesh. Questo valore deve essere un numero dispari, in quanto \u00e8 necessario che venga sondato il centro della mesh. L'illustrazione seguente mostra come vengono generati i punti rilevati. Come puoi vedere, impostando mesh_origin su (-10, 0) ci consente di specificare un raggio di mesh maggiore di 85. Configurazione avanzata \u00b6 Di seguito vengono spiegate in dettaglio le opzioni di configurazione pi\u00f9 avanzate. Ciascun esempio si baser\u00e0 sulla configurazione base del piatto rettangolare mostrata sopra. Ciascuna delle opzioni avanzate si applica allo stesso modo ai piatti rotondi. Interpolazione mesh \u00b6 Sebbene sia possibile campionare direttamente la matrice rilevata utilizzando una semplice interpolazione bilineare per determinare i valori Z tra i punti rilevati, \u00e8 spesso utile interpolare punti aggiuntivi utilizzando algoritmi di interpolazione pi\u00f9 avanzati per aumentare la densit\u00e0 della mesh. Questi algoritmi aggiungono curvatura alla mesh, tentando di simulare le propriet\u00e0 del materiale del letto. Bed Mesh offre interpolazione lagrange e bicubica per raggiungere questo obiettivo. [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 probe_count: 5, 3 mesh_pps: 2, 3 algorithm: bicubic bicubic_tension: 0.2 mesh_pps: 2, 3 Valore predefinito: 2, 2 L'opzione mesh_pps \u00e8 un'abbreviazione per Mesh Points Per Segment. Questa opzione specifica quanti punti interpolare per ciascun segmento lungo gli assi X e Y. Considera un \"segmento\" come lo spazio tra ogni punto sondato. Come probe_count , mesh_pps \u00e8 specificato come una coppia di interi X, Y e pu\u00f2 anche essere specificato un singolo intero che viene applicato a entrambi gli assi. In questo esempio ci sono 4 segmenti lungo l'asse X e 2 segmenti lungo l'asse Y. Questo restituisce 8 punti interpolati lungo X, 6 punti interpolati lungo Y, che si traduce in una mesh 13x8. Si noti che se mesh_pps \u00e8 impostato su 0, l'interpolazione della mesh \u00e8 disabilitata e la matrice sondata verr\u00e0 campionata direttamente. algoritmo: lagrange Valore predefinito: lagrange L'algoritmo utilizzato per interpolare la mesh. Pu\u00f2 essere \"lagrange\" o \"bicubico\". L'interpolazione Lagrange \u00e8 limitata a 6 punti sondati poich\u00e9 tende a verificarsi l'oscillazione con un numero maggiore di campioni. L'interpolazione bicubica richiede un minimo di 4 punti sondati lungo ciascun asse, se vengono specificati meno di 4 punti, viene forzato il campionamento lagrange. Se mesh_pps \u00e8 impostato su 0, questo valore viene ignorato poich\u00e9 non viene eseguita alcuna interpolazione della mesh. bicubic_tension: 0.2 Valore predefinito: 0.2 Se l'opzione algorithm \u00e8 impostata su bicubic \u00e8 possibile specificare il valore della tensione. Maggiore \u00e8 la tensione, maggiore \u00e8 la pendenza interpolata. Prestare attenzione durante la regolazione, poich\u00e9 valori pi\u00f9 elevati creano anche una maggiore sovraelongazione, che risulter\u00e0 in valori interpolati superiori o inferiori rispetto ai punti rilevati. L'illustrazione seguente mostra come vengono utilizzate le opzioni precedenti per generare una mesh interpolata. Divisione dei movimenti \u00b6 Bed Mesh funziona intercettando i comandi di spostamento di gcode e applicando una trasformazione alla loro coordinata Z. I movimenti lunghi devono essere suddivisi in movimenti pi\u00f9 piccoli per seguire correttamente la forma del piatto. Le opzioni seguenti controllano il comportamento di divisione. [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 probe_count: 5, 3 move_check_distance: 5 split_delta_z: .025 move_check_distance: 5 Valore predefinito: 5 La distanza minima per verificare la modifica desiderata in Z prima di eseguire una divisione. In questo esempio, un movimento pi\u00f9 lungo di 5 mm verr\u00e0 eseguito dall'algoritmo. Ogni 5 mm si verificher\u00e0 una ricerca Z della mesh, confrontandola con il valore Z del movimento precedente. Se il delta raggiunge la soglia impostata da split_delta_z , il movimento sar\u00e0 diviso e l'attraversamento continuer\u00e0. Questo processo si ripete fino al raggiungimento della fine del movimento, dove verr\u00e0 applicato un aggiustamento finale. I movimenti pi\u00f9 brevi di move_check_distance hanno la correzione Z corretta applicata direttamente alla mossa senza attraversamento o divisione. split_delta_z: .025 Valore predefinito: .025 Come accennato in precedenza, questa \u00e8 la deviazione minima richiesta per attivare una divisione del movimento. In questo esempio, qualsiasi valore Z con una deviazione +/- 0,025 mm attiver\u00e0 una divisione. Generalmente i valori predefiniti per queste opzioni sono sufficienti, infatti il valore predefinito di 5 mm per move_check_distance potrebbe essere eccessivo. Tuttavia un utente esperto potrebbe voler sperimentare queste opzioni nel tentativo di ottenere il primo livello ottimale. Dissolvenza Mesh \u00b6 Quando la \"dissolvenza\" \u00e8 abilitata, la regolazione Z viene gradualmente eliminata su una distanza definita dalla configurazione. Ci\u00f2 si ottiene applicando piccole regolazioni all'altezza dello strato, aumentando o diminuendo a seconda della forma del letto. Quando la dissolvenza \u00e8 completata, la regolazione Z non viene pi\u00f9 applicata, consentendo alla parte superiore della stampa di essere piatta anzich\u00e9 rispecchiare la forma del letto. La dissolvenza pu\u00f2 anche avere alcuni tratti indesiderati, se dissolve troppo rapidamente pu\u00f2 causare artefatti visibili sulla stampa. Inoltre, se il tuo letto \u00e8 notevolmente deformato, la dissolvenza pu\u00f2 ridurre o allungare l'altezza Z della stampa. In quanto tale, la dissolvenza \u00e8 disabilitata per impostazione predefinita. [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 probe_count: 5, 3 fade_start: 1 fade_end: 10 fade_target: 0 fade_start: 1 Valore predefinito: 1 L'altezza Z in cui iniziare la regolazione graduale. \u00c8 una buona idea avere alcuni layer prima di iniziare il processo di dissolvenza. fade_end: 10 Valore predefinito: 0 L'altezza Z in cui deve essere completata la dissolvenza. Se questo valore \u00e8 inferiore a fade_start , la dissolvenza \u00e8 disabilitata. Questo valore pu\u00f2 essere regolato a seconda di quanto \u00e8 deformata la superficie di stampa. Una superficie notevolmente deformata dovrebbe dissolvere su una distanza maggiore. Una superficie quasi piatta potrebbe essere in grado di ridurre questo valore per eliminarlo gradualmente pi\u00f9 rapidamente. 10mm \u00e8 un valore ragionevole per cominciare se si utilizza il valore predefinito di 1 per fade_start . fade_target: 0 Valore predefinito: il valore Z medio della mesh Il fade_target pu\u00f2 essere considerato come un offset Z aggiuntivo applicato all'intero piatto una volta completata la dissolvenza. In generale vorremmo che questo valore fosse 0, tuttavia ci sono circostanze in cui non dovrebbe esserlo. Ad esempio, supponiamo che la posizione di homing sul piatto sia un valore anomalo, ovvero 0,2 mm inferiore all'altezza media rilevata del piatto. Se fade_target \u00e8 0, la dissolvenza ridurr\u00e0 la stampa in media di 0,2 mm sul piano. Impostando fade_target su .2, l'area home si espander\u00e0 di 0,2 mm, tuttavia, il resto del piatto verr\u00e0 dimensionato accuratamente. Generalmente \u00e8 una buona idea lasciare \"fade_target\" fuori dalla configurazione in modo da utilizzare l'altezza media della mesh, tuttavia potrebbe essere preferibile regolare manualmente il target di dissolvenza se si desidera stampare su una porzione specifica del piano. Configuring the zero reference position \u00b6 Many probes are susceptible to \"drift\", ie: inaccuracies in probing introduced by heat or interference. This can make calculating the probe's z-offset challenging, particularly at different bed temperatures. As such, some printers use an endstop for homing the Z axis and a probe for calibrating the mesh. In this configuration it is possible offset the mesh so that the (X, Y) reference position applies zero adjustment. The reference postion should be the location on the bed where a Z_ENDSTOP_CALIBRATE paper test is performed. The bed_mesh module provides the zero_reference_position option for specifying this coordinate: [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 zero_reference_position: 125, 110 probe_count: 5, 3 zero_reference_position: Default Value: None (disabled) The zero_reference_position expects an (X, Y) coordinate matching that of the reference position described above. If the coordinate lies within the mesh then the mesh will be offset so the reference position applies zero adjustment. If the coordinate lies outside of the mesh then the coordinate will be probed after calibration, with the resulting z-value used as the z-offset. Note that this coordinate must NOT be in a location specified as a faulty_region if a probe is necessary. The deprecated relative_reference_index \u00b6 Existing configurations using the relative_reference_index option must be updated to use the zero_reference_position . The response to the BED_MESH_OUTPUT PGP=1 gcode command will include the (X, Y) coordinate associated with the index; this position may be used as the value for the zero_reference_position . The output will look similar to the following: // bed_mesh: generated points // Index | Tool Adjusted | Probe // 0 | (1.0, 1.0) | (24.0, 6.0) // 1 | (36.7, 1.0) | (59.7, 6.0) // 2 | (72.3, 1.0) | (95.3, 6.0) // 3 | (108.0, 1.0) | (131.0, 6.0) ... (additional generated points) // bed_mesh: relative_reference_index 24 is (131.5, 108.0) Note: The above output is also printed in klippy.log during initialization. Using the example above we see that the relative_reference_index is printed along with its coordinate. Thus the zero_reference_position is 131.5, 108 . Regioni difettose \u00b6 \u00c8 possibile che alcune aree di un piatto riportino risultati imprecisi durante il sondaggio a causa di un \"guasto\" in punti specifici. Il miglior esempio di ci\u00f2 sono i piatti con serie di magneti integrati utilizzati per trattenere le lamiere di acciaio rimovibili. Il campo magnetico su e intorno a questi magneti pu\u00f2 causare l'attivazione di una sonda induttiva a una distanza maggiore o minore di quanto sarebbe altrimenti, risultando in una mesh che non rappresenta accuratamente la superficie in queste posizioni. Nota: questo non deve essere confuso con la distorsione della posizione della sonda, che produce risultati imprecisi sull'intero letto. Le opzioni faulty_region possono essere configurate per compensare questo effetto. Se un punto generato si trova all'interno di una regione difettosa, la mesh del letto tenter\u00e0 di sondare fino a 4 punti ai confini di questa regione. Questi valori sondati verranno mediati e inseriti nella mesh come valore Z alla coordinata generata (X, Y). [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 probe_count: 5, 3 faulty_region_1_min: 130.0, 0.0 faulty_region_1_max: 145.0, 40.0 faulty_region_2_min: 225.0, 0.0 faulty_region_2_max: 250.0, 25.0 faulty_region_3_min: 165.0, 95.0 faulty_region_3_max: 205.0, 110.0 faulty_region_4_min: 30.0, 170.0 faulty_region_4_max: 45.0, 210.0 faulty_region_{1...99}_min faulty_region_{1..99}_max Valore predefinito: Nessuno (disabilitato) Le regioni difettose sono definite in modo simile a quello della mesh stessa, dove minimo e massimo (X , Y) delle coordinate devono essere specificate per ciascuna regione. Una regione difettosa pu\u00f2 estendersi al di fuori di una mesh, tuttavia i punti alternativi generati saranno sempre all'interno del confine della mesh. Non possono sovrapporsi due regioni. L'immagine seguente illustra come vengono generati i punti di sostituzione quando un punto generato si trova all'interno di una regione difettosa. Le regioni mostrate corrispondono a quelle nella configurazione di esempio sopra. I punti di sostituzione e le relative coordinate sono identificati in verde. GCodes della mesh del piatto \u00b6 Calibrazione \u00b6 BED_MESH_CALIBRATE PROFILE= METHOD=[manuale | automatico] [=] [=] Profilo predefinito: default Metodo predefinito: automatico se viene rilevata una sonda, altrimenti manuale Avvia la procedura di sondaggio per la calibrazione della mesh del piatto. La mesh verr\u00e0 salvata in un profilo specificato dal parametro PROFILE , o default se non specificato. Se viene selezionato METHOD=manual , si verificher\u00e0 il rilevamento manuale. Quando si passa dal probing automatico a quello manuale, i punti mesh generati verranno regolati automaticamente. \u00c8 possibile specificare parametri mesh per modificare l'area sondata. Sono disponibili i seguenti parametri: Piatti rettangolari (cartesiani): MESH_MIN MESH_MAX PROBE_COUNT Piatti rotondi (delta): MESH_RADIUS MESH_ORIGIN ROUND_PROBE_COUNT Tutti i piatti: ALGORITHM Vedere la documentazione di configurazione sopra per i dettagli su come ogni parametro si applica alla mesh. Profili \u00b6 BED_MESH_PROFILE SAVE= LOAD= REMOVE= Dopo aver eseguito un BED_MESH_CALIBRATE, \u00e8 possibile salvare lo stato della mesh corrente in un profilo denominato. Ci\u00f2 consente di caricare una mesh senza risondare il piatto. Dopo che un profilo \u00e8 stato salvato usando BED_MESH_PROFILE SAVE= \u00e8 possibile eseguire il gcode SAVE_CONFIG per scrivere il profilo su printer.cfg. I profili possono essere caricati eseguendo BED_MESH_PROFILE LOAD= . Va notato che ogni volta che si verifica un BED_MESH_CALIBRATE, lo stato corrente viene automaticamente salvato nel profilo predefinito . Il profilo predefinito pu\u00f2 essere rimosso come segue: BED_MESH_PROFILE REMOVE=default Qualsiasi altro profilo salvato pu\u00f2 essere rimosso allo stesso modo, sostituendo default con il nome del profilo che desideri rimuovere. Caricamento del profilo predefinito \u00b6 Le versioni precedenti di bed_mesh caricavano sempre il profilo denominato default all'avvio se era presente. Questo comportamento \u00e8 stato rimosso per consentire all'utente di determinare quando viene caricato un profilo. Se un utente desidera caricare il profilo predefinito , si consiglia di aggiungere BED_MESH_PROFILE LOAD=default alla macro START_PRINT o alla configurazione \"Start G-Code\" del proprio slicer, a seconda di quale sia applicabile. In alternativa, il vecchio comportamento di caricamento di un profilo all'avvio pu\u00f2 essere ripristinato con un [delayed_gcode] : [delayed_gcode bed_mesh_init] initial_duration : .01 gcode : BED_MESH_PROFILE LOAD = default Output \u00b6 BED_MESH_OUTPUT PGP=[0 | 1] Invia lo stato della mesh corrente al terminale. Si noti che viene emessa la mesh stessa Il parametro PGP \u00e8 un'abbreviazione per \"Print Generated Points\". Se \u00e8 impostato PGP=1 , i punti sondati generati verranno inviati al terminale: // bed_mesh: generated points // Index | Tool Adjusted | Probe // 0 | (11.0, 1.0) | (35.0, 6.0) // 1 | (62.2, 1.0) | (86.2, 6.0) // 2 | (113.5, 1.0) | (137.5, 6.0) // 3 | (164.8, 1.0) | (188.8, 6.0) // 4 | (216.0, 1.0) | (240.0, 6.0) // 5 | (216.0, 97.0) | (240.0, 102.0) // 6 | (164.8, 97.0) | (188.8, 102.0) // 7 | (113.5, 97.0) | (137.5, 102.0) // 8 | (62.2, 97.0) | (86.2, 102.0) // 9 | (11.0, 97.0) | (35.0, 102.0) // 10 | (11.0, 193.0) | (35.0, 198.0) // 11 | (62.2, 193.0) | (86.2, 198.0) // 12 | (113.5, 193.0) | (137.5, 198.0) // 13 | (164.8, 193.0) | (188.8, 198.0) // 14 | (216.0, 193.0) | (240.0, 198.0) I punti \"Tool Adjusted\" si riferiscono alla posizione dell'ugello per ciascun punto e i punti \"Probe\" si riferiscono alla posizione della sonda. Si noti che quando il probing \u00e8 manuale i punti \"sonda\" si riferiscono sia alla posizione dell'utensile che dell'ugello. Cancella stato mesh \u00b6 BED_MESH_CLEAR Questo gcode pu\u00f2 essere utilizzato per cancellare lo stato della mesh interna. Applicare gli offset X/Y \u00b6 BED_MESH_OFFSET [X=] [Y=] Ci\u00f2 \u00e8 utile per le stampanti con pi\u00f9 estrusori indipendenti, poich\u00e9 \u00e8 necessario un offset per produrre la corretta regolazione Z dopo un cambio utensile. Gli offset devono essere specificati rispetto all'estrusore primario. Vale a dire, \u00e8 necessario specificare un offset X positivo se l'estrusore secondario \u00e8 montato a destra dell'estrusore primario e un offset Y positivo se l'estrusore secondario \u00e8 montato \"dietro\" l'estrusore primario.","title":"Matrice del Piatto"},{"location":"Bed_Mesh.html#matrice-del-piatto","text":"Il modulo Bed Mesh pu\u00f2 essere utilizzato per compensare le irregolarit\u00e0 della superficie del piatto per ottenere un primo strato migliore sull'intero piatto. Va notato che la correzione basata sul software non otterr\u00e0 risultati perfetti, potr\u00e0 solo approssimare la forma del piatto. Inoltre, Bed Mesh non pu\u00f2 compensare problemi meccanici ed elettrici. Se un asse \u00e8 inclinato o una sonda non \u00e8 precisa, il modulo bed_mesh non ricever\u00e0 risultati accurati dal processo di tastatura. Prima della calibrazione della mesh dovrai assicurarti che l'offset Z della tua sonda sia calibrato. Se si utilizza un fine corsa per l'homing Z, anche questo dovr\u00e0 essere calibrato. Per ulteriori informazioni, vedere Probe Calibrate e Z_ENDSTOP_CALIBRATE in Manual Level .","title":"Matrice del Piatto"},{"location":"Bed_Mesh.html#configurazione-base","text":"","title":"Configurazione base"},{"location":"Bed_Mesh.html#piatti-rettangolari","text":"Questo esempio presuppone una stampante con un piatto rettangolare di 250 mm x 220 mm e una sonda con un offset x di 24 mm e un offset y di 5 mm. [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 probe_count: 5, 3 speed: 120 Valore predefinito: 50 La velocit\u00e0 con cui la testa di stampa si sposta tra i punti. horizontal_move_z: 5 Valore predefinito: 5 La coordinata Z a cui si solleva la sonda prima di spostarsi tra i punti. mesh_min: 35, 6 Richiesto La prima coordinata rilevata, pi\u00f9 vicina all'origine. Questa coordinata \u00e8 relativa alla posizione della sonda. mesh_max: 240, 198 Obbligatorio La coordinata pi\u00f9 lontana rilevata dall'origine. Questo non \u00e8 necessariamente l'ultimo punto esplorato, poich\u00e9 il processo di ispezione avviene a zig-zag. Come con mesh_min , questa coordinata \u00e8 relativa alla posizione della sonda. probe_count: 5, 3 Valore predefinito: 3, 3 Il numero di punti da sondare su ciascun asse, specificato come valori interi X, Y. In questo esempio verranno tastati 5 punti lungo l'asse X, con 3 punti lungo l'asse Y, per un totale di 15 punti tastati. Nota che se desideri una griglia quadrata, ad esempio 3x3, questo potrebbe essere specificato come un singolo valore intero che viene utilizzato per entrambi gli assi, ad esempio probe_count: 3 . Si noti che una mesh richiede un probe_count minimo di 3 lungo ciascun asse. L'illustrazione seguente mostra come le opzioni mesh_min , mesh_max e probe_count vengono utilizzate per generare punti sonda. Le frecce indicano la direzione della procedura di probing, a partire da mesh_min . Per riferimento, quando la sonda \u00e8 a mesh_min , l'ugello sar\u00e0 a (11, 1), e quando la sonda \u00e8 a mesh_max , l'ugello sar\u00e0 a (206, 193).","title":"Piatti rettangolari"},{"location":"Bed_Mesh.html#piatti-rotondi","text":"Questo esempio presuppone una stampante dotata di un raggio del piatto rotondo di 100 mm. Utilizzeremo gli stessi offset della sonda dell'esempio rettangolare, 24 mm su X e 5 mm su Y. [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_radius: 75 mesh_origin: 0, 0 round_probe_count: 5 mesh_radius: 75 Obbligatorio Il raggio della mesh sondata in mm, relativo a mesh_origin . Si noti che gli offset della sonda limitano la dimensione del raggio della mesh. In questo esempio, un raggio maggiore di 76 sposterebbe lo strumento oltre il range della stampante. mesh_origin: 0, 0 Valore predefinito: 0, 0 Il punto centrale della mesh. Questa coordinata \u00e8 relativa alla posizione della sonda. Sebbene il valore predefinito sia 0, 0, pu\u00f2 essere utile regolare l'origine nel tentativo di sondare una porzione pi\u00f9 ampia del letto. Vedi l'illustrazione qui sotto. round_probe_count: 5 Valore predefinito: 5 Questo \u00e8 un valore intero che definisce il numero massimo di punti sondati lungo gli assi X e Y. Per \"massimo\" si intende il numero di punti tastati lungo l'origine della mesh. Questo valore deve essere un numero dispari, in quanto \u00e8 necessario che venga sondato il centro della mesh. L'illustrazione seguente mostra come vengono generati i punti rilevati. Come puoi vedere, impostando mesh_origin su (-10, 0) ci consente di specificare un raggio di mesh maggiore di 85.","title":"Piatti rotondi"},{"location":"Bed_Mesh.html#configurazione-avanzata","text":"Di seguito vengono spiegate in dettaglio le opzioni di configurazione pi\u00f9 avanzate. Ciascun esempio si baser\u00e0 sulla configurazione base del piatto rettangolare mostrata sopra. Ciascuna delle opzioni avanzate si applica allo stesso modo ai piatti rotondi.","title":"Configurazione avanzata"},{"location":"Bed_Mesh.html#interpolazione-mesh","text":"Sebbene sia possibile campionare direttamente la matrice rilevata utilizzando una semplice interpolazione bilineare per determinare i valori Z tra i punti rilevati, \u00e8 spesso utile interpolare punti aggiuntivi utilizzando algoritmi di interpolazione pi\u00f9 avanzati per aumentare la densit\u00e0 della mesh. Questi algoritmi aggiungono curvatura alla mesh, tentando di simulare le propriet\u00e0 del materiale del letto. Bed Mesh offre interpolazione lagrange e bicubica per raggiungere questo obiettivo. [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 probe_count: 5, 3 mesh_pps: 2, 3 algorithm: bicubic bicubic_tension: 0.2 mesh_pps: 2, 3 Valore predefinito: 2, 2 L'opzione mesh_pps \u00e8 un'abbreviazione per Mesh Points Per Segment. Questa opzione specifica quanti punti interpolare per ciascun segmento lungo gli assi X e Y. Considera un \"segmento\" come lo spazio tra ogni punto sondato. Come probe_count , mesh_pps \u00e8 specificato come una coppia di interi X, Y e pu\u00f2 anche essere specificato un singolo intero che viene applicato a entrambi gli assi. In questo esempio ci sono 4 segmenti lungo l'asse X e 2 segmenti lungo l'asse Y. Questo restituisce 8 punti interpolati lungo X, 6 punti interpolati lungo Y, che si traduce in una mesh 13x8. Si noti che se mesh_pps \u00e8 impostato su 0, l'interpolazione della mesh \u00e8 disabilitata e la matrice sondata verr\u00e0 campionata direttamente. algoritmo: lagrange Valore predefinito: lagrange L'algoritmo utilizzato per interpolare la mesh. Pu\u00f2 essere \"lagrange\" o \"bicubico\". L'interpolazione Lagrange \u00e8 limitata a 6 punti sondati poich\u00e9 tende a verificarsi l'oscillazione con un numero maggiore di campioni. L'interpolazione bicubica richiede un minimo di 4 punti sondati lungo ciascun asse, se vengono specificati meno di 4 punti, viene forzato il campionamento lagrange. Se mesh_pps \u00e8 impostato su 0, questo valore viene ignorato poich\u00e9 non viene eseguita alcuna interpolazione della mesh. bicubic_tension: 0.2 Valore predefinito: 0.2 Se l'opzione algorithm \u00e8 impostata su bicubic \u00e8 possibile specificare il valore della tensione. Maggiore \u00e8 la tensione, maggiore \u00e8 la pendenza interpolata. Prestare attenzione durante la regolazione, poich\u00e9 valori pi\u00f9 elevati creano anche una maggiore sovraelongazione, che risulter\u00e0 in valori interpolati superiori o inferiori rispetto ai punti rilevati. L'illustrazione seguente mostra come vengono utilizzate le opzioni precedenti per generare una mesh interpolata.","title":"Interpolazione mesh"},{"location":"Bed_Mesh.html#divisione-dei-movimenti","text":"Bed Mesh funziona intercettando i comandi di spostamento di gcode e applicando una trasformazione alla loro coordinata Z. I movimenti lunghi devono essere suddivisi in movimenti pi\u00f9 piccoli per seguire correttamente la forma del piatto. Le opzioni seguenti controllano il comportamento di divisione. [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 probe_count: 5, 3 move_check_distance: 5 split_delta_z: .025 move_check_distance: 5 Valore predefinito: 5 La distanza minima per verificare la modifica desiderata in Z prima di eseguire una divisione. In questo esempio, un movimento pi\u00f9 lungo di 5 mm verr\u00e0 eseguito dall'algoritmo. Ogni 5 mm si verificher\u00e0 una ricerca Z della mesh, confrontandola con il valore Z del movimento precedente. Se il delta raggiunge la soglia impostata da split_delta_z , il movimento sar\u00e0 diviso e l'attraversamento continuer\u00e0. Questo processo si ripete fino al raggiungimento della fine del movimento, dove verr\u00e0 applicato un aggiustamento finale. I movimenti pi\u00f9 brevi di move_check_distance hanno la correzione Z corretta applicata direttamente alla mossa senza attraversamento o divisione. split_delta_z: .025 Valore predefinito: .025 Come accennato in precedenza, questa \u00e8 la deviazione minima richiesta per attivare una divisione del movimento. In questo esempio, qualsiasi valore Z con una deviazione +/- 0,025 mm attiver\u00e0 una divisione. Generalmente i valori predefiniti per queste opzioni sono sufficienti, infatti il valore predefinito di 5 mm per move_check_distance potrebbe essere eccessivo. Tuttavia un utente esperto potrebbe voler sperimentare queste opzioni nel tentativo di ottenere il primo livello ottimale.","title":"Divisione dei movimenti"},{"location":"Bed_Mesh.html#dissolvenza-mesh","text":"Quando la \"dissolvenza\" \u00e8 abilitata, la regolazione Z viene gradualmente eliminata su una distanza definita dalla configurazione. Ci\u00f2 si ottiene applicando piccole regolazioni all'altezza dello strato, aumentando o diminuendo a seconda della forma del letto. Quando la dissolvenza \u00e8 completata, la regolazione Z non viene pi\u00f9 applicata, consentendo alla parte superiore della stampa di essere piatta anzich\u00e9 rispecchiare la forma del letto. La dissolvenza pu\u00f2 anche avere alcuni tratti indesiderati, se dissolve troppo rapidamente pu\u00f2 causare artefatti visibili sulla stampa. Inoltre, se il tuo letto \u00e8 notevolmente deformato, la dissolvenza pu\u00f2 ridurre o allungare l'altezza Z della stampa. In quanto tale, la dissolvenza \u00e8 disabilitata per impostazione predefinita. [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 probe_count: 5, 3 fade_start: 1 fade_end: 10 fade_target: 0 fade_start: 1 Valore predefinito: 1 L'altezza Z in cui iniziare la regolazione graduale. \u00c8 una buona idea avere alcuni layer prima di iniziare il processo di dissolvenza. fade_end: 10 Valore predefinito: 0 L'altezza Z in cui deve essere completata la dissolvenza. Se questo valore \u00e8 inferiore a fade_start , la dissolvenza \u00e8 disabilitata. Questo valore pu\u00f2 essere regolato a seconda di quanto \u00e8 deformata la superficie di stampa. Una superficie notevolmente deformata dovrebbe dissolvere su una distanza maggiore. Una superficie quasi piatta potrebbe essere in grado di ridurre questo valore per eliminarlo gradualmente pi\u00f9 rapidamente. 10mm \u00e8 un valore ragionevole per cominciare se si utilizza il valore predefinito di 1 per fade_start . fade_target: 0 Valore predefinito: il valore Z medio della mesh Il fade_target pu\u00f2 essere considerato come un offset Z aggiuntivo applicato all'intero piatto una volta completata la dissolvenza. In generale vorremmo che questo valore fosse 0, tuttavia ci sono circostanze in cui non dovrebbe esserlo. Ad esempio, supponiamo che la posizione di homing sul piatto sia un valore anomalo, ovvero 0,2 mm inferiore all'altezza media rilevata del piatto. Se fade_target \u00e8 0, la dissolvenza ridurr\u00e0 la stampa in media di 0,2 mm sul piano. Impostando fade_target su .2, l'area home si espander\u00e0 di 0,2 mm, tuttavia, il resto del piatto verr\u00e0 dimensionato accuratamente. Generalmente \u00e8 una buona idea lasciare \"fade_target\" fuori dalla configurazione in modo da utilizzare l'altezza media della mesh, tuttavia potrebbe essere preferibile regolare manualmente il target di dissolvenza se si desidera stampare su una porzione specifica del piano.","title":"Dissolvenza Mesh"},{"location":"Bed_Mesh.html#configuring-the-zero-reference-position","text":"Many probes are susceptible to \"drift\", ie: inaccuracies in probing introduced by heat or interference. This can make calculating the probe's z-offset challenging, particularly at different bed temperatures. As such, some printers use an endstop for homing the Z axis and a probe for calibrating the mesh. In this configuration it is possible offset the mesh so that the (X, Y) reference position applies zero adjustment. The reference postion should be the location on the bed where a Z_ENDSTOP_CALIBRATE paper test is performed. The bed_mesh module provides the zero_reference_position option for specifying this coordinate: [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 zero_reference_position: 125, 110 probe_count: 5, 3 zero_reference_position: Default Value: None (disabled) The zero_reference_position expects an (X, Y) coordinate matching that of the reference position described above. If the coordinate lies within the mesh then the mesh will be offset so the reference position applies zero adjustment. If the coordinate lies outside of the mesh then the coordinate will be probed after calibration, with the resulting z-value used as the z-offset. Note that this coordinate must NOT be in a location specified as a faulty_region if a probe is necessary.","title":"Configuring the zero reference position"},{"location":"Bed_Mesh.html#the-deprecated-relative_reference_index","text":"Existing configurations using the relative_reference_index option must be updated to use the zero_reference_position . The response to the BED_MESH_OUTPUT PGP=1 gcode command will include the (X, Y) coordinate associated with the index; this position may be used as the value for the zero_reference_position . The output will look similar to the following: // bed_mesh: generated points // Index | Tool Adjusted | Probe // 0 | (1.0, 1.0) | (24.0, 6.0) // 1 | (36.7, 1.0) | (59.7, 6.0) // 2 | (72.3, 1.0) | (95.3, 6.0) // 3 | (108.0, 1.0) | (131.0, 6.0) ... (additional generated points) // bed_mesh: relative_reference_index 24 is (131.5, 108.0) Note: The above output is also printed in klippy.log during initialization. Using the example above we see that the relative_reference_index is printed along with its coordinate. Thus the zero_reference_position is 131.5, 108 .","title":"The deprecated relative_reference_index"},{"location":"Bed_Mesh.html#regioni-difettose","text":"\u00c8 possibile che alcune aree di un piatto riportino risultati imprecisi durante il sondaggio a causa di un \"guasto\" in punti specifici. Il miglior esempio di ci\u00f2 sono i piatti con serie di magneti integrati utilizzati per trattenere le lamiere di acciaio rimovibili. Il campo magnetico su e intorno a questi magneti pu\u00f2 causare l'attivazione di una sonda induttiva a una distanza maggiore o minore di quanto sarebbe altrimenti, risultando in una mesh che non rappresenta accuratamente la superficie in queste posizioni. Nota: questo non deve essere confuso con la distorsione della posizione della sonda, che produce risultati imprecisi sull'intero letto. Le opzioni faulty_region possono essere configurate per compensare questo effetto. Se un punto generato si trova all'interno di una regione difettosa, la mesh del letto tenter\u00e0 di sondare fino a 4 punti ai confini di questa regione. Questi valori sondati verranno mediati e inseriti nella mesh come valore Z alla coordinata generata (X, Y). [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 probe_count: 5, 3 faulty_region_1_min: 130.0, 0.0 faulty_region_1_max: 145.0, 40.0 faulty_region_2_min: 225.0, 0.0 faulty_region_2_max: 250.0, 25.0 faulty_region_3_min: 165.0, 95.0 faulty_region_3_max: 205.0, 110.0 faulty_region_4_min: 30.0, 170.0 faulty_region_4_max: 45.0, 210.0 faulty_region_{1...99}_min faulty_region_{1..99}_max Valore predefinito: Nessuno (disabilitato) Le regioni difettose sono definite in modo simile a quello della mesh stessa, dove minimo e massimo (X , Y) delle coordinate devono essere specificate per ciascuna regione. Una regione difettosa pu\u00f2 estendersi al di fuori di una mesh, tuttavia i punti alternativi generati saranno sempre all'interno del confine della mesh. Non possono sovrapporsi due regioni. L'immagine seguente illustra come vengono generati i punti di sostituzione quando un punto generato si trova all'interno di una regione difettosa. Le regioni mostrate corrispondono a quelle nella configurazione di esempio sopra. I punti di sostituzione e le relative coordinate sono identificati in verde.","title":"Regioni difettose"},{"location":"Bed_Mesh.html#gcodes-della-mesh-del-piatto","text":"","title":"GCodes della mesh del piatto"},{"location":"Bed_Mesh.html#calibrazione","text":"BED_MESH_CALIBRATE PROFILE= METHOD=[manuale | automatico] [=] [=] Profilo predefinito: default Metodo predefinito: automatico se viene rilevata una sonda, altrimenti manuale Avvia la procedura di sondaggio per la calibrazione della mesh del piatto. La mesh verr\u00e0 salvata in un profilo specificato dal parametro PROFILE , o default se non specificato. Se viene selezionato METHOD=manual , si verificher\u00e0 il rilevamento manuale. Quando si passa dal probing automatico a quello manuale, i punti mesh generati verranno regolati automaticamente. \u00c8 possibile specificare parametri mesh per modificare l'area sondata. Sono disponibili i seguenti parametri: Piatti rettangolari (cartesiani): MESH_MIN MESH_MAX PROBE_COUNT Piatti rotondi (delta): MESH_RADIUS MESH_ORIGIN ROUND_PROBE_COUNT Tutti i piatti: ALGORITHM Vedere la documentazione di configurazione sopra per i dettagli su come ogni parametro si applica alla mesh.","title":"Calibrazione"},{"location":"Bed_Mesh.html#profili","text":"BED_MESH_PROFILE SAVE= LOAD= REMOVE= Dopo aver eseguito un BED_MESH_CALIBRATE, \u00e8 possibile salvare lo stato della mesh corrente in un profilo denominato. Ci\u00f2 consente di caricare una mesh senza risondare il piatto. Dopo che un profilo \u00e8 stato salvato usando BED_MESH_PROFILE SAVE= \u00e8 possibile eseguire il gcode SAVE_CONFIG per scrivere il profilo su printer.cfg. I profili possono essere caricati eseguendo BED_MESH_PROFILE LOAD= . Va notato che ogni volta che si verifica un BED_MESH_CALIBRATE, lo stato corrente viene automaticamente salvato nel profilo predefinito . Il profilo predefinito pu\u00f2 essere rimosso come segue: BED_MESH_PROFILE REMOVE=default Qualsiasi altro profilo salvato pu\u00f2 essere rimosso allo stesso modo, sostituendo default con il nome del profilo che desideri rimuovere.","title":"Profili"},{"location":"Bed_Mesh.html#caricamento-del-profilo-predefinito","text":"Le versioni precedenti di bed_mesh caricavano sempre il profilo denominato default all'avvio se era presente. Questo comportamento \u00e8 stato rimosso per consentire all'utente di determinare quando viene caricato un profilo. Se un utente desidera caricare il profilo predefinito , si consiglia di aggiungere BED_MESH_PROFILE LOAD=default alla macro START_PRINT o alla configurazione \"Start G-Code\" del proprio slicer, a seconda di quale sia applicabile. In alternativa, il vecchio comportamento di caricamento di un profilo all'avvio pu\u00f2 essere ripristinato con un [delayed_gcode] : [delayed_gcode bed_mesh_init] initial_duration : .01 gcode : BED_MESH_PROFILE LOAD = default","title":"Caricamento del profilo predefinito"},{"location":"Bed_Mesh.html#output","text":"BED_MESH_OUTPUT PGP=[0 | 1] Invia lo stato della mesh corrente al terminale. Si noti che viene emessa la mesh stessa Il parametro PGP \u00e8 un'abbreviazione per \"Print Generated Points\". Se \u00e8 impostato PGP=1 , i punti sondati generati verranno inviati al terminale: // bed_mesh: generated points // Index | Tool Adjusted | Probe // 0 | (11.0, 1.0) | (35.0, 6.0) // 1 | (62.2, 1.0) | (86.2, 6.0) // 2 | (113.5, 1.0) | (137.5, 6.0) // 3 | (164.8, 1.0) | (188.8, 6.0) // 4 | (216.0, 1.0) | (240.0, 6.0) // 5 | (216.0, 97.0) | (240.0, 102.0) // 6 | (164.8, 97.0) | (188.8, 102.0) // 7 | (113.5, 97.0) | (137.5, 102.0) // 8 | (62.2, 97.0) | (86.2, 102.0) // 9 | (11.0, 97.0) | (35.0, 102.0) // 10 | (11.0, 193.0) | (35.0, 198.0) // 11 | (62.2, 193.0) | (86.2, 198.0) // 12 | (113.5, 193.0) | (137.5, 198.0) // 13 | (164.8, 193.0) | (188.8, 198.0) // 14 | (216.0, 193.0) | (240.0, 198.0) I punti \"Tool Adjusted\" si riferiscono alla posizione dell'ugello per ciascun punto e i punti \"Probe\" si riferiscono alla posizione della sonda. Si noti che quando il probing \u00e8 manuale i punti \"sonda\" si riferiscono sia alla posizione dell'utensile che dell'ugello.","title":"Output"},{"location":"Bed_Mesh.html#cancella-stato-mesh","text":"BED_MESH_CLEAR Questo gcode pu\u00f2 essere utilizzato per cancellare lo stato della mesh interna.","title":"Cancella stato mesh"},{"location":"Bed_Mesh.html#applicare-gli-offset-xy","text":"BED_MESH_OFFSET [X=] [Y=] Ci\u00f2 \u00e8 utile per le stampanti con pi\u00f9 estrusori indipendenti, poich\u00e9 \u00e8 necessario un offset per produrre la corretta regolazione Z dopo un cambio utensile. Gli offset devono essere specificati rispetto all'estrusore primario. Vale a dire, \u00e8 necessario specificare un offset X positivo se l'estrusore secondario \u00e8 montato a destra dell'estrusore primario e un offset Y positivo se l'estrusore secondario \u00e8 montato \"dietro\" l'estrusore primario.","title":"Applicare gli offset X/Y"},{"location":"Benchmarks.html","text":"Benchmark \u00b6 Questo documento descrive i benchmark di Klipper. Benchmark del microcontrollore \u00b6 Questa sezione descrive il meccanismo utilizzato per generare i benchmark della velocit\u00e0 di passaggio del microcontrollore Klipper. L'obiettivo principale dei benchmark \u00e8 fornire un meccanismo coerente per misurare l'impatto delle modifiche alla codifica all'interno del software. Un obiettivo secondario \u00e8 fornire metriche di alto livello per confrontare le prestazioni tra i chip e tra le piattaforme software. Il benchmark dello step rate \u00e8 progettato per trovare la velocit\u00e0 di stepping massima che l'hardware e il software possono raggiungere. Questa velocit\u00e0 di stepping del benchmark non \u00e8 raggiungibile nell'uso quotidiano poich\u00e9 Klipper ha bisogno di eseguire altre attivit\u00e0 (ad esempio, comunicazione mcu/host, lettura della temperatura, controllo endstop) in qualsiasi utilizzo nel mondo reale. In generale, i pin per i test di benchmark sono scelti per far lampeggiare LED o altri pin innocui. Verifica sempre che sia sicuro guidare i pin configurati prima di eseguire un benchmark. Non \u00e8 consigliabile pilotare uno stepper reale durante un benchmark. Test di riferimento della frequenza di passi \u00b6 Il test viene eseguito utilizzando lo strumento console.py (descritto in ). Il microcontrollore \u00e8 configurato per la particolare piattaforma hardware (vedi sotto) e quindi quanto segue viene tagliato e incollato nella finestra del terminale console.py: SET start_clock {clock+freq} SET ticks 1000 reset_step_clock oid=0 clock={start_clock} set_next_step_dir oid=0 dir=0 queue_step oid=0 interval={ticks} count=60000 add=0 set_next_step_dir oid=0 dir=1 queue_step oid=0 interval=3000 count=1 add=0 reset_step_clock oid=1 clock={start_clock} set_next_step_dir oid=1 dir=0 queue_step oid=1 interval={ticks} count=60000 add=0 set_next_step_dir oid=1 dir=1 queue_step oid=1 interval=3000 count=1 add=0 reset_step_clock oid=2 clock={start_clock} set_next_step_dir oid=2 dir=0 queue_step oid=2 interval={ticks} count=60000 add=0 set_next_step_dir oid=2 dir=1 queue_step oid=2 interval=3000 count=1 add=0 Quanto sopra testa tre stepper che fanno un passo simultaneo. Se l'esecuzione di quanto sopra comporta un errore \"Rescheduled timer in the past\" o \"Stepper too far in past\", indica che il parametro ticks \u00e8 troppo basso (risulta in una velocit\u00e0 di incremento troppo veloce). L'obiettivo \u00e8 trovare l'impostazione pi\u00f9 bassa del parametro tick che si traduca in modo affidabile in un completamento positivo del test. Dovrebbe essere possibile dividere in due il parametro tick fino a trovare un valore stabile. In caso di errore, \u00e8 possibile copiare e incollare quanto segue per cancellare l'errore in preparazione per il test successivo: clear_shutdown Per ottenere i benchmark del singolo stepper, viene utilizzata la stessa sequenza di configurazione, ma solo il primo blocco del test precedente viene tagliato e incollato nella finestra di console.py. Per produrre i benchmark trovati nel documento Features , il numero totale di passi al secondo viene calcolato moltiplicando il numero di stepper attivi per la frequenza nominale mcu e dividendo per il parametro tick finale. I risultati vengono arrotondati alla K pi\u00f9 vicina. Ad esempio, con tre stepper attivi: ECHO Test result is: {\"%.0fK\" % (3. * freq / ticks / 1000.)} I benchmark vengono eseguiti con parametri adatti ai driver TMC. Per i microcontrollori che supportano STEPPER_BOTH_EDGE=1 (come riportato nella riga MCU config al primo avvio di console.py) usa step_pulse_duration=0 e invert_step=-1 per abilitare lo stepping ottimizzato su entrambi i bordi del impulso di passo. Per altri microcontrollori usa un step_pulse_duration corrispondente a 100ns. Benchmark rateo passi AVR \u00b6 La seguente sequenza di configurazione viene utilizzata sui chip AVR: allocate_oids count=3 config_stepper oid=0 step_pin=PA5 dir_pin=PA4 invert_step=0 step_pulse_ticks=32 config_stepper oid=1 step_pin=PA3 dir_pin=PA2 invert_step=0 step_pulse_ticks=32 config_stepper oid=2 step_pin=PC7 dir_pin=PC6 invert_step=0 step_pulse_ticks=32 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc avr-gcc (GCC) 5.4.0 . Entrambi i test a 16Mhz e 20Mhz sono stati eseguiti utilizzando simulavr configurato per un atmega644p (i test precedenti hanno confermato i risultati del simulavr match test su entrambi un 16Mhz at90usb e un 16Mhz atmega2560). avr ticks 1 stepper 102 3 stepper 486 Benchmark rateo passi Arduino Due \u00b6 Sul Due viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=PB27 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PB26 dir_pin=PC30 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PA21 dir_pin=PC30 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . sam3x8e ticks 1 stepper 66 3 stepper 257 Benchmark step rate Duet Maestro \u00b6 La seguente sequenza di configurazione viene utilizzata su Duet Maestro: allocate_oids count=3 config_stepper oid=0 step_pin=PC26 dir_pin=PC18 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PC26 dir_pin=PA8 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PC26 dir_pin=PB4 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . sam4s8c ticks 1 stepper 71 3 stepper 260 Benchmark step rate Duet Wifi \u00b6 La seguente sequenza di configurazione viene utilizzata su Duet Wifi: allocate_oids count=3 config_stepper oid=0 step_pin=PD6 dir_pin=PD11 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PD7 dir_pin=PD12 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PD8 dir_pin=PD13 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con gcc versione gcc versione 10.3.1 20210621 (rilascio) (GNU Arm Embedded Toolchain 10.3-2021.07) . sam4e8e ticks 1 stepper 48 3 stepper 215 Benchmark step rate Beaglebone PRU \u00b6 Sulla PRU viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=gpio0_23 dir_pin=gpio1_12 invert_step=0 step_pulse_ticks=20 config_stepper oid=1 step_pin=gpio1_15 dir_pin=gpio0_26 invert_step=0 step_pulse_ticks=20 config_stepper oid=2 step_pin=gpio0_22 dir_pin=gpio2_1 invert_step=0 step_pulse_ticks=20 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc pru-gcc (GCC) 8.0.0 20170530 (sperimentale) . pru ticks 1 stepper 231 3 stepper 847 Benchmark step rate STM32F042 \u00b6 La seguente sequenza di configurazione viene utilizzata sull'STM32F042: allocate_oids count=3 config_stepper oid=0 step_pin=PA1 dir_pin=PA2 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PA3 dir_pin=PA2 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PB8 dir_pin=PA2 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . stm32f042 ticks 1 stepper 59 3 stepper 249 Benchmark step rate STM32F103 \u00b6 Sull'STM32F103 viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=PC13 dir_pin=PB5 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PB3 dir_pin=PB6 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PA4 dir_pin=PB7 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . stm32f103 ticks 1 stepper 61 3 stepper 264 Benchmark step rate STM32F4 \u00b6 Sull'STM32F4 viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=PA5 dir_pin=PB5 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PB2 dir_pin=PB6 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PB3 dir_pin=PB7 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . I risultati dell'STM32F407 sono stati ottenuti eseguendo un binario STM32F407 su un STM32F446 (e quindi utilizzando un clock a 168 Mhz). stm32f446 ticks 1 stepper 46 3 stepper 205 stm32f407 ticks 1 stepper 46 3 stepper 205 STM32H7 benchmark della velocit\u00e0 di step \u00b6 La seguente sequenza di configurazione viene utilizzata su un STM32H743VIT6: allocate_oids count=3 config_stepper oid=0 step_pin=PD4 dir_pin=PD3 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PA15 dir_pin=PA8 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PE2 dir_pin=PE3 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 00191b5c con versione gcc arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revisione 273027] . stm32h7 ticks 1 stepper 44 3 stepper 198 Benchmark step rate STM32G0B1 \u00b6 Sull'STM32G0B1 viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=PB13 dir_pin=PB12 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PB10 dir_pin=PB2 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PB0 dir_pin=PC5 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 247cd753 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . stm32g0b1 ticks 1 stepper 58 3 stepper 243 Benchmark step rate LPC176x \u00b6 La seguente sequenza di configurazione viene utilizzata sull'LPC176x: allocate_oids count=3 config_stepper oid=0 step_pin=P1.20 dir_pin=P1.18 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=P1.21 dir_pin=P1.18 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=P1.23 dir_pin=P1.18 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . I risultati a 120 Mhz LPC1769 sono stati ottenuti overclockando un LPC1768 a 120 Mhz. lpc1768 ticks 1 stepper 52 3 stepper 222 lpc1769 ticks 1 stepper 51 3 stepper 222 Benchmark step rate SAMD21 \u00b6 La seguente sequenza di configurazione viene utilizzata sul SAMD21: allocate_oids count=3 config_stepper oid=0 step_pin=PA27 dir_pin=PA20 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PB3 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PA17 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 su un microcontrollore SAMD21G18. samd21 ticks 1 stepper 70 3 stepper 306 Benchmark step rate SAMD51 \u00b6 La seguente sequenza di configurazione viene utilizzata sul SAMD51: allocate_oids count=3 config_stepper oid=0 step_pin=PA22 dir_pin=PA20 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PA22 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PA22 dir_pin=PA19 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 su un microcontrollore SAMD51J19A. samd51 ticks 1 stepper 39 3 stepper 191 1 stepper (200Mhz) 39 3 stepper (200Mhz) 181 Benchmark della velocit\u00e0 di passo AR100 \u00b6 La seguente sequenza di configurazione viene utilizzata sulla CPU AR100 (Allwinner A64): allocate_oids count=3 config_stepper oid=0 step_pin=PL10 dir_pin=PE14 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PL11 dir_pin=PE15 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PL12 dir_pin=PE16 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta sul commit 08d037c6 con la versione gcc or1k-linux-musl-gcc (GCC) 9.2.0 su un microcontrollore Allwinner A64-H. AR100 R_PIO ticks 1 stepper 85 3 stepper 359 Benchmark step rate RP2040 \u00b6 Sull'RP2040 viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=gpio25 dir_pin=gpio3 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=gpio26 dir_pin=gpio4 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=gpio27 dir_pin=gpio5 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 su una scheda Raspberry Pi Pico. rp2040 ticks 1 stepper 5 3 stepper 22 Benchmark step rate MCU Linux \u00b6 La seguente sequenza di configurazione viene utilizzata su un Raspberry Pi: allocate_oids count=3 config_stepper oid=0 step_pin=gpio2 dir_pin=gpio3 invert_step=0 step_pulse_ticks=5 config_stepper oid=1 step_pin=gpio4 dir_pin=gpio5 invert_step=0 step_pulse_ticks=5 config_stepper oid=2 step_pin=gpio6 dir_pin=gpio17 invert_step=0 step_pulse_ticks=5 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc gcc (Raspbian 8.3.0-6+rpi1) 8.3.0 su un Raspberry Pi 3 (revisione a02082). \u00c8 stato difficile ottenere risultati stabili in questo benchmark. Linux (RPi3) ticks 1 stepper 160 3 stepper 380 Benchmark dispacciamento comandi \u00b6 Il benchmark di invio dei comandi verifica quanti comandi \"fittizi\" possono elaborare il microcontrollore. \u00c8 principalmente un test del meccanismo di comunicazione hardware. Il test viene eseguito utilizzando lo strumento console.py (descritto in ). Quanto segue \u00e8 taglia e incolla nella finestra del terminale console.py: DELAY {clock + 2*freq} get_uptime FLOOD 100000 0.0 debug_nop get_uptime Al termine del test, determinare la differenza tra gli orologi riportati nei due messaggi di risposta \"uptime\". Il numero totale di comandi al secondo \u00e8 quindi 100000 * mcu_frequency / clock_diff . Nota che questo test potrebbe saturare la capacit\u00e0 USB/CPU di un Raspberry Pi. Se \u00e8 in esecuzione su un computer host Raspberry Pi, Beaglebone o simile, aumenta il ritardo (ad esempio, DELAY {clock + 20*freq} get_uptime ). Ove applicabile, i benchmark seguenti riguardano console.py in esecuzione su una macchina di classe desktop con il dispositivo connesso tramite un hub ad alta velocit\u00e0. MCU Rateo Build Build compiler stm32f042 (CAN) 18K c105adc8 arm-none-eabi-gcc (GNU Tools 7-2018-q3-update) 7.3.1 atmega2560 (serial) 23K b161a69e avr-gcc (GCC) 4.8.1 sam3x8e (serial) 23K b161a69e arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 at90usb1286 (USB) 75K 01d2183f avr-gcc (GCC) 5.4.0 ar100 (seriale) 138K 08d037c6 or1k-linux-musl-gcc 9.3.0 samd21 (USB) 223K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 pru (shared memory) 260K c5968a08 pru-gcc (GCC) 8.0.0 20170530 (experimental) stm32f103 (USB) 355K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 sam3x8e (USB) 418K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 lpc1768 (USB) 534K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 lpc1769 (USB) 628K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 sam4s8c (USB) 650K 8d4a5c16 arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 samd51 (USB) 864K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 stm32f446 (USB) 870K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 rp2040 (USB) 873K c5667193 arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 Benchmark Host \u00b6 \u00c8 possibile eseguire test di temporizzazione sul software host utilizzando il meccanismo di elaborazione \"batch mode\" (descritto in ). Questo viene in genere fatto scegliendo un file G-Code grande e complesso e calcolando il tempo impiegato dal software host per elaborarlo. Per esempio: time ~/klippy-env/bin/python ./klippy/klippy.py config/example-cartesian.cfg -i something_complex.gcode -o /dev/null -d out/klipper.dict","title":"Benchmark"},{"location":"Benchmarks.html#benchmark","text":"Questo documento descrive i benchmark di Klipper.","title":"Benchmark"},{"location":"Benchmarks.html#benchmark-del-microcontrollore","text":"Questa sezione descrive il meccanismo utilizzato per generare i benchmark della velocit\u00e0 di passaggio del microcontrollore Klipper. L'obiettivo principale dei benchmark \u00e8 fornire un meccanismo coerente per misurare l'impatto delle modifiche alla codifica all'interno del software. Un obiettivo secondario \u00e8 fornire metriche di alto livello per confrontare le prestazioni tra i chip e tra le piattaforme software. Il benchmark dello step rate \u00e8 progettato per trovare la velocit\u00e0 di stepping massima che l'hardware e il software possono raggiungere. Questa velocit\u00e0 di stepping del benchmark non \u00e8 raggiungibile nell'uso quotidiano poich\u00e9 Klipper ha bisogno di eseguire altre attivit\u00e0 (ad esempio, comunicazione mcu/host, lettura della temperatura, controllo endstop) in qualsiasi utilizzo nel mondo reale. In generale, i pin per i test di benchmark sono scelti per far lampeggiare LED o altri pin innocui. Verifica sempre che sia sicuro guidare i pin configurati prima di eseguire un benchmark. Non \u00e8 consigliabile pilotare uno stepper reale durante un benchmark.","title":"Benchmark del microcontrollore"},{"location":"Benchmarks.html#test-di-riferimento-della-frequenza-di-passi","text":"Il test viene eseguito utilizzando lo strumento console.py (descritto in ). Il microcontrollore \u00e8 configurato per la particolare piattaforma hardware (vedi sotto) e quindi quanto segue viene tagliato e incollato nella finestra del terminale console.py: SET start_clock {clock+freq} SET ticks 1000 reset_step_clock oid=0 clock={start_clock} set_next_step_dir oid=0 dir=0 queue_step oid=0 interval={ticks} count=60000 add=0 set_next_step_dir oid=0 dir=1 queue_step oid=0 interval=3000 count=1 add=0 reset_step_clock oid=1 clock={start_clock} set_next_step_dir oid=1 dir=0 queue_step oid=1 interval={ticks} count=60000 add=0 set_next_step_dir oid=1 dir=1 queue_step oid=1 interval=3000 count=1 add=0 reset_step_clock oid=2 clock={start_clock} set_next_step_dir oid=2 dir=0 queue_step oid=2 interval={ticks} count=60000 add=0 set_next_step_dir oid=2 dir=1 queue_step oid=2 interval=3000 count=1 add=0 Quanto sopra testa tre stepper che fanno un passo simultaneo. Se l'esecuzione di quanto sopra comporta un errore \"Rescheduled timer in the past\" o \"Stepper too far in past\", indica che il parametro ticks \u00e8 troppo basso (risulta in una velocit\u00e0 di incremento troppo veloce). L'obiettivo \u00e8 trovare l'impostazione pi\u00f9 bassa del parametro tick che si traduca in modo affidabile in un completamento positivo del test. Dovrebbe essere possibile dividere in due il parametro tick fino a trovare un valore stabile. In caso di errore, \u00e8 possibile copiare e incollare quanto segue per cancellare l'errore in preparazione per il test successivo: clear_shutdown Per ottenere i benchmark del singolo stepper, viene utilizzata la stessa sequenza di configurazione, ma solo il primo blocco del test precedente viene tagliato e incollato nella finestra di console.py. Per produrre i benchmark trovati nel documento Features , il numero totale di passi al secondo viene calcolato moltiplicando il numero di stepper attivi per la frequenza nominale mcu e dividendo per il parametro tick finale. I risultati vengono arrotondati alla K pi\u00f9 vicina. Ad esempio, con tre stepper attivi: ECHO Test result is: {\"%.0fK\" % (3. * freq / ticks / 1000.)} I benchmark vengono eseguiti con parametri adatti ai driver TMC. Per i microcontrollori che supportano STEPPER_BOTH_EDGE=1 (come riportato nella riga MCU config al primo avvio di console.py) usa step_pulse_duration=0 e invert_step=-1 per abilitare lo stepping ottimizzato su entrambi i bordi del impulso di passo. Per altri microcontrollori usa un step_pulse_duration corrispondente a 100ns.","title":"Test di riferimento della frequenza di passi"},{"location":"Benchmarks.html#benchmark-rateo-passi-avr","text":"La seguente sequenza di configurazione viene utilizzata sui chip AVR: allocate_oids count=3 config_stepper oid=0 step_pin=PA5 dir_pin=PA4 invert_step=0 step_pulse_ticks=32 config_stepper oid=1 step_pin=PA3 dir_pin=PA2 invert_step=0 step_pulse_ticks=32 config_stepper oid=2 step_pin=PC7 dir_pin=PC6 invert_step=0 step_pulse_ticks=32 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc avr-gcc (GCC) 5.4.0 . Entrambi i test a 16Mhz e 20Mhz sono stati eseguiti utilizzando simulavr configurato per un atmega644p (i test precedenti hanno confermato i risultati del simulavr match test su entrambi un 16Mhz at90usb e un 16Mhz atmega2560). avr ticks 1 stepper 102 3 stepper 486","title":"Benchmark rateo passi AVR"},{"location":"Benchmarks.html#benchmark-rateo-passi-arduino-due","text":"Sul Due viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=PB27 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PB26 dir_pin=PC30 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PA21 dir_pin=PC30 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . sam3x8e ticks 1 stepper 66 3 stepper 257","title":"Benchmark rateo passi Arduino Due"},{"location":"Benchmarks.html#benchmark-step-rate-duet-maestro","text":"La seguente sequenza di configurazione viene utilizzata su Duet Maestro: allocate_oids count=3 config_stepper oid=0 step_pin=PC26 dir_pin=PC18 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PC26 dir_pin=PA8 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PC26 dir_pin=PB4 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . sam4s8c ticks 1 stepper 71 3 stepper 260","title":"Benchmark step rate Duet Maestro"},{"location":"Benchmarks.html#benchmark-step-rate-duet-wifi","text":"La seguente sequenza di configurazione viene utilizzata su Duet Wifi: allocate_oids count=3 config_stepper oid=0 step_pin=PD6 dir_pin=PD11 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PD7 dir_pin=PD12 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PD8 dir_pin=PD13 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con gcc versione gcc versione 10.3.1 20210621 (rilascio) (GNU Arm Embedded Toolchain 10.3-2021.07) . sam4e8e ticks 1 stepper 48 3 stepper 215","title":"Benchmark step rate Duet Wifi"},{"location":"Benchmarks.html#benchmark-step-rate-beaglebone-pru","text":"Sulla PRU viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=gpio0_23 dir_pin=gpio1_12 invert_step=0 step_pulse_ticks=20 config_stepper oid=1 step_pin=gpio1_15 dir_pin=gpio0_26 invert_step=0 step_pulse_ticks=20 config_stepper oid=2 step_pin=gpio0_22 dir_pin=gpio2_1 invert_step=0 step_pulse_ticks=20 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc pru-gcc (GCC) 8.0.0 20170530 (sperimentale) . pru ticks 1 stepper 231 3 stepper 847","title":"Benchmark step rate Beaglebone PRU"},{"location":"Benchmarks.html#benchmark-step-rate-stm32f042","text":"La seguente sequenza di configurazione viene utilizzata sull'STM32F042: allocate_oids count=3 config_stepper oid=0 step_pin=PA1 dir_pin=PA2 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PA3 dir_pin=PA2 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PB8 dir_pin=PA2 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . stm32f042 ticks 1 stepper 59 3 stepper 249","title":"Benchmark step rate STM32F042"},{"location":"Benchmarks.html#benchmark-step-rate-stm32f103","text":"Sull'STM32F103 viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=PC13 dir_pin=PB5 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PB3 dir_pin=PB6 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PA4 dir_pin=PB7 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . stm32f103 ticks 1 stepper 61 3 stepper 264","title":"Benchmark step rate STM32F103"},{"location":"Benchmarks.html#benchmark-step-rate-stm32f4","text":"Sull'STM32F4 viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=PA5 dir_pin=PB5 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PB2 dir_pin=PB6 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PB3 dir_pin=PB7 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . I risultati dell'STM32F407 sono stati ottenuti eseguendo un binario STM32F407 su un STM32F446 (e quindi utilizzando un clock a 168 Mhz). stm32f446 ticks 1 stepper 46 3 stepper 205 stm32f407 ticks 1 stepper 46 3 stepper 205","title":"Benchmark step rate STM32F4"},{"location":"Benchmarks.html#stm32h7-benchmark-della-velocita-di-step","text":"La seguente sequenza di configurazione viene utilizzata su un STM32H743VIT6: allocate_oids count=3 config_stepper oid=0 step_pin=PD4 dir_pin=PD3 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PA15 dir_pin=PA8 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PE2 dir_pin=PE3 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 00191b5c con versione gcc arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revisione 273027] . stm32h7 ticks 1 stepper 44 3 stepper 198","title":"STM32H7 benchmark della velocit\u00e0 di step"},{"location":"Benchmarks.html#benchmark-step-rate-stm32g0b1","text":"Sull'STM32G0B1 viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=PB13 dir_pin=PB12 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PB10 dir_pin=PB2 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PB0 dir_pin=PC5 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 247cd753 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . stm32g0b1 ticks 1 stepper 58 3 stepper 243","title":"Benchmark step rate STM32G0B1"},{"location":"Benchmarks.html#benchmark-step-rate-lpc176x","text":"La seguente sequenza di configurazione viene utilizzata sull'LPC176x: allocate_oids count=3 config_stepper oid=0 step_pin=P1.20 dir_pin=P1.18 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=P1.21 dir_pin=P1.18 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=P1.23 dir_pin=P1.18 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 . I risultati a 120 Mhz LPC1769 sono stati ottenuti overclockando un LPC1768 a 120 Mhz. lpc1768 ticks 1 stepper 52 3 stepper 222 lpc1769 ticks 1 stepper 51 3 stepper 222","title":"Benchmark step rate LPC176x"},{"location":"Benchmarks.html#benchmark-step-rate-samd21","text":"La seguente sequenza di configurazione viene utilizzata sul SAMD21: allocate_oids count=3 config_stepper oid=0 step_pin=PA27 dir_pin=PA20 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PB3 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PA17 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 su un microcontrollore SAMD21G18. samd21 ticks 1 stepper 70 3 stepper 306","title":"Benchmark step rate SAMD21"},{"location":"Benchmarks.html#benchmark-step-rate-samd51","text":"La seguente sequenza di configurazione viene utilizzata sul SAMD51: allocate_oids count=3 config_stepper oid=0 step_pin=PA22 dir_pin=PA20 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PA22 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PA22 dir_pin=PA19 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 su un microcontrollore SAMD51J19A. samd51 ticks 1 stepper 39 3 stepper 191 1 stepper (200Mhz) 39 3 stepper (200Mhz) 181","title":"Benchmark step rate SAMD51"},{"location":"Benchmarks.html#benchmark-della-velocita-di-passo-ar100","text":"La seguente sequenza di configurazione viene utilizzata sulla CPU AR100 (Allwinner A64): allocate_oids count=3 config_stepper oid=0 step_pin=PL10 dir_pin=PE14 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=PL11 dir_pin=PE15 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=PL12 dir_pin=PE16 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta sul commit 08d037c6 con la versione gcc or1k-linux-musl-gcc (GCC) 9.2.0 su un microcontrollore Allwinner A64-H. AR100 R_PIO ticks 1 stepper 85 3 stepper 359","title":"Benchmark della velocit\u00e0 di passo AR100"},{"location":"Benchmarks.html#benchmark-step-rate-rp2040","text":"Sull'RP2040 viene utilizzata la seguente sequenza di configurazione: allocate_oids count=3 config_stepper oid=0 step_pin=gpio25 dir_pin=gpio3 invert_step=-1 step_pulse_ticks=0 config_stepper oid=1 step_pin=gpio26 dir_pin=gpio4 invert_step=-1 step_pulse_ticks=0 config_stepper oid=2 step_pin=gpio27 dir_pin=gpio5 invert_step=-1 step_pulse_ticks=0 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 su una scheda Raspberry Pi Pico. rp2040 ticks 1 stepper 5 3 stepper 22","title":"Benchmark step rate RP2040"},{"location":"Benchmarks.html#benchmark-step-rate-mcu-linux","text":"La seguente sequenza di configurazione viene utilizzata su un Raspberry Pi: allocate_oids count=3 config_stepper oid=0 step_pin=gpio2 dir_pin=gpio3 invert_step=0 step_pulse_ticks=5 config_stepper oid=1 step_pin=gpio4 dir_pin=gpio5 invert_step=0 step_pulse_ticks=5 config_stepper oid=2 step_pin=gpio6 dir_pin=gpio17 invert_step=0 step_pulse_ticks=5 finalize_config crc=0 Il test \u00e8 stato eseguito l'ultima volta su commit 59314d99 con versione gcc gcc (Raspbian 8.3.0-6+rpi1) 8.3.0 su un Raspberry Pi 3 (revisione a02082). \u00c8 stato difficile ottenere risultati stabili in questo benchmark. Linux (RPi3) ticks 1 stepper 160 3 stepper 380","title":"Benchmark step rate MCU Linux"},{"location":"Benchmarks.html#benchmark-dispacciamento-comandi","text":"Il benchmark di invio dei comandi verifica quanti comandi \"fittizi\" possono elaborare il microcontrollore. \u00c8 principalmente un test del meccanismo di comunicazione hardware. Il test viene eseguito utilizzando lo strumento console.py (descritto in ). Quanto segue \u00e8 taglia e incolla nella finestra del terminale console.py: DELAY {clock + 2*freq} get_uptime FLOOD 100000 0.0 debug_nop get_uptime Al termine del test, determinare la differenza tra gli orologi riportati nei due messaggi di risposta \"uptime\". Il numero totale di comandi al secondo \u00e8 quindi 100000 * mcu_frequency / clock_diff . Nota che questo test potrebbe saturare la capacit\u00e0 USB/CPU di un Raspberry Pi. Se \u00e8 in esecuzione su un computer host Raspberry Pi, Beaglebone o simile, aumenta il ritardo (ad esempio, DELAY {clock + 20*freq} get_uptime ). Ove applicabile, i benchmark seguenti riguardano console.py in esecuzione su una macchina di classe desktop con il dispositivo connesso tramite un hub ad alta velocit\u00e0. MCU Rateo Build Build compiler stm32f042 (CAN) 18K c105adc8 arm-none-eabi-gcc (GNU Tools 7-2018-q3-update) 7.3.1 atmega2560 (serial) 23K b161a69e avr-gcc (GCC) 4.8.1 sam3x8e (serial) 23K b161a69e arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 at90usb1286 (USB) 75K 01d2183f avr-gcc (GCC) 5.4.0 ar100 (seriale) 138K 08d037c6 or1k-linux-musl-gcc 9.3.0 samd21 (USB) 223K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 pru (shared memory) 260K c5968a08 pru-gcc (GCC) 8.0.0 20170530 (experimental) stm32f103 (USB) 355K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 sam3x8e (USB) 418K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 lpc1768 (USB) 534K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 lpc1769 (USB) 628K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 sam4s8c (USB) 650K 8d4a5c16 arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 samd51 (USB) 864K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 stm32f446 (USB) 870K 01d2183f arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 rp2040 (USB) 873K c5667193 arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0","title":"Benchmark dispacciamento comandi"},{"location":"Benchmarks.html#benchmark-host","text":"\u00c8 possibile eseguire test di temporizzazione sul software host utilizzando il meccanismo di elaborazione \"batch mode\" (descritto in ). Questo viene in genere fatto scegliendo un file G-Code grande e complesso e calcolando il tempo impiegato dal software host per elaborarlo. Per esempio: time ~/klippy-env/bin/python ./klippy/klippy.py config/example-cartesian.cfg -i something_complex.gcode -o /dev/null -d out/klipper.dict","title":"Benchmark Host"},{"location":"Bootloader_Entry.html","text":"Bootloader Entry \u00b6 \u00c8 possibile impostare Klipper in modo che si riavvii in un Bootloader in uno dei seguenti modi: Richiesta del bootloader \u00b6 Seriale virtuale \u00b6 If a virtual (USB-ACM) serial port is in use, pulsing DTR while at 1200 baud will request the bootloader. Python (with flash_usb ) \u00b6 To enter the bootloader using python (using flash_usb ): > cd klipper/scripts > python3 -c 'import flash_usb as u; u.enter_bootloader(\"\")' Entering bootloader on Where is your serial device, such as /dev/serial.by-id/usb-Klipper[...] or /dev/ttyACM0 Note that if this fails, no output will be printed, success is indicated by printing Entering bootloader on . Picocom \u00b6 picocom -b 1200 Where is your serial device, such as /dev/serial.by-id/usb-Klipper[...] or /dev/ttyACM0 means holding Ctrl , pressing and releasing a , pressing and releasing p , then releasing Ctrl Physical serial \u00b6 If a physical serial port is being used on the MCU (even if a USB serial adapter is being used to connect to it), sending the string Request Serial Bootloader!!~ . is an ASCII literal space, 0x20. is the ASCII File Separator, 0x1c. Note that this is not a valid message as per the MCU Protocol , but sync characters( ~ ) are still respected. Because this message must be the only thing in the \"block\" it is received in, prefixing an extra sync character can increase reliability if other tools were previously accessing the serial port. Shell \u00b6 stty < /dev/ echo $'~ \\x1c Request Serial Bootloader!! ~' >> /dev/ Where is your serial port, such as /dev/ttyS0 , or /dev/serial/by-id/gpio-serial2 , and is the baud rate of the serial port, such as 115200 . CANBUS \u00b6 If CANBUS is in use, a special admin message will request the bootloader. This message will be respected even if the device already has a nodeid, and will also be processed if the mcu is shutdown. This method also applies to devices operating in CANBridge mode. Katapult's flashtool.py \u00b6 python3 ./katapult/scripts/flashtool.py -i -u -r Where is the can interface to use. If using can0 , both the -i and may be omitted. is the UUID of your CAN device. See the CANBUS Documentation for information on finding the CAN UUID of your devices. Entering the bootloader \u00b6 When klipper receives one of the above bootloader requests: If Katapult (formerly known as CANBoot) is available, klipper will request that Katapult stay active on the next boot, then reset the MCU (therefore entering Katapult). If Katapult is not available, klipper will then try to enter a platform-specific bootloader, such as STM32's DFU mode( see note ). In short, Klipper will reboot to Katapult if installed, then a hardware specific bootloader if available. For details about the specific bootloaders on various platforms see Bootloaders Notes \u00b6 STM32 DFU Warning \u00b6 Note that on some boards, like the Octopus Pro v1, entering DFU mode can cause undesired actions (such as powering the heater while in DFU mode). It is recommended to disconnect heaters, and otherwise prevent undesired operations when using DFU mode. Consult the documentation for your board for more details.","title":"Bootloader Entry"},{"location":"Bootloader_Entry.html#bootloader-entry","text":"\u00c8 possibile impostare Klipper in modo che si riavvii in un Bootloader in uno dei seguenti modi:","title":"Bootloader Entry"},{"location":"Bootloader_Entry.html#richiesta-del-bootloader","text":"","title":"Richiesta del bootloader"},{"location":"Bootloader_Entry.html#seriale-virtuale","text":"If a virtual (USB-ACM) serial port is in use, pulsing DTR while at 1200 baud will request the bootloader.","title":"Seriale virtuale"},{"location":"Bootloader_Entry.html#python-with-flash_usb","text":"To enter the bootloader using python (using flash_usb ): > cd klipper/scripts > python3 -c 'import flash_usb as u; u.enter_bootloader(\"\")' Entering bootloader on Where is your serial device, such as /dev/serial.by-id/usb-Klipper[...] or /dev/ttyACM0 Note that if this fails, no output will be printed, success is indicated by printing Entering bootloader on .","title":"Python (with flash_usb)"},{"location":"Bootloader_Entry.html#picocom","text":"picocom -b 1200 Where is your serial device, such as /dev/serial.by-id/usb-Klipper[...] or /dev/ttyACM0 means holding Ctrl , pressing and releasing a , pressing and releasing p , then releasing Ctrl","title":"Picocom"},{"location":"Bootloader_Entry.html#physical-serial","text":"If a physical serial port is being used on the MCU (even if a USB serial adapter is being used to connect to it), sending the string Request Serial Bootloader!!~ . is an ASCII literal space, 0x20. is the ASCII File Separator, 0x1c. Note that this is not a valid message as per the MCU Protocol , but sync characters( ~ ) are still respected. Because this message must be the only thing in the \"block\" it is received in, prefixing an extra sync character can increase reliability if other tools were previously accessing the serial port.","title":"Physical serial"},{"location":"Bootloader_Entry.html#shell","text":"stty < /dev/ echo $'~ \\x1c Request Serial Bootloader!! ~' >> /dev/ Where is your serial port, such as /dev/ttyS0 , or /dev/serial/by-id/gpio-serial2 , and is the baud rate of the serial port, such as 115200 .","title":"Shell"},{"location":"Bootloader_Entry.html#canbus","text":"If CANBUS is in use, a special admin message will request the bootloader. This message will be respected even if the device already has a nodeid, and will also be processed if the mcu is shutdown. This method also applies to devices operating in CANBridge mode.","title":"CANBUS"},{"location":"Bootloader_Entry.html#katapults-flashtoolpy","text":"python3 ./katapult/scripts/flashtool.py -i -u -r Where is the can interface to use. If using can0 , both the -i and may be omitted. is the UUID of your CAN device. See the CANBUS Documentation for information on finding the CAN UUID of your devices.","title":"Katapult's flashtool.py"},{"location":"Bootloader_Entry.html#entering-the-bootloader","text":"When klipper receives one of the above bootloader requests: If Katapult (formerly known as CANBoot) is available, klipper will request that Katapult stay active on the next boot, then reset the MCU (therefore entering Katapult). If Katapult is not available, klipper will then try to enter a platform-specific bootloader, such as STM32's DFU mode( see note ). In short, Klipper will reboot to Katapult if installed, then a hardware specific bootloader if available. For details about the specific bootloaders on various platforms see Bootloaders","title":"Entering the bootloader"},{"location":"Bootloader_Entry.html#notes","text":"","title":"Notes"},{"location":"Bootloader_Entry.html#stm32-dfu-warning","text":"Note that on some boards, like the Octopus Pro v1, entering DFU mode can cause undesired actions (such as powering the heater while in DFU mode). It is recommended to disconnect heaters, and otherwise prevent undesired operations when using DFU mode. Consult the documentation for your board for more details.","title":"STM32 DFU Warning"},{"location":"Bootloaders.html","text":"Bootloader \u00b6 Questo documento fornisce informazioni sui bootloader comuni scoperti sui microcontrollori che sono supportati da Klipper. Il bootloader \u00e8 un software di terze parti che viene eseguito sul microcontrollore quando viene acceso per la prima volta. Viene generalmente utilizzato per eseguire il flashing di una nuova applicazione (ad es. Klipper) sul microcontrollore senza richiedere hardware specializzato. Sfortunatamente, non esiste uno standard a livello di settore per il flashing di un microcontrollore, n\u00e9 esiste un bootloader standard che funzioni su tutti i microcontrollori. Peggio ancora, \u00e8 comune che ogni bootloader richieda una serie di passaggi diversa per eseguire il flashing di un'applicazione. Se si pu\u00f2 eseguire il flashing di un bootloader su un microcontrollore, generalmente si pu\u00f2 anche utilizzare quel meccanismo per eseguire il flashing di un'applicazione, ma \u00e8 necessario prestare attenzione quando si esegue questa operazione poich\u00e9 si potrebbe rimuovere inavvertitamente il bootloader. Al contrario, un bootloader generalmente consentir\u00e0 solo a un utente di eseguire il flashing di un'applicazione. Si consiglia pertanto di utilizzare un bootloader per eseguire il flashing di un'applicazione, ove possibile. Questo documento tenta di descrivere i bootloader comuni, i passaggi necessari per eseguire il flashing di un bootloader e i passaggi necessari per eseguire il flashing di un'applicazione. Questo documento non \u00e8 un riferimento autorevole; \u00e8 inteso come una raccolta di informazioni utili che gli sviluppatori di Klipper hanno accumulato. Microcontrollori AVR \u00b6 In generale, il progetto Arduino \u00e8 un buon riferimento per bootloader e procedure di flashing sui microcontrollori Atmel Atmega a 8 bit. In particolare, il file \"boards.txt\": https://github.com/arduino/Arduino/blob/1.8.5/hardware/arduino/avr/boards.txt \u00e8 un utile riferimento. Per eseguire il flashing di un bootloader, i chip AVR richiedono uno strumento di flashing hardware esterno (che comunica con il chip tramite SPI). Questo strumento pu\u00f2 essere acquistato (ad esempio, eseguire una ricerca sul Web per \"avr isp\", \"arduino isp\" o \"usb tiny isp\"). \u00c8 anche possibile utilizzare un altro Arduino o Raspberry Pi per eseguire il flashing di un bootloader AVR (ad esempio, eseguire una ricerca sul Web per \"programmare un avr utilizzando raspberry pi\"). Gli esempi seguenti sono scritti presupponendo che sia in uso un dispositivo di tipo \"AVR ISP Mk2\". Il programma \"avrdude\" \u00e8 lo strumento pi\u00f9 comune utilizzato per eseguire il flashing dei chip atmega (sia flash del bootloader che flash dell'applicazione). Atmega2560 \u00b6 Questo chip si trova in genere nell'\"Arduino Mega\" ed \u00e8 molto comune nelle schede per stampanti 3D. Per eseguire il flashing del bootloader stesso usa qualcosa come: wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/stk500v2/stk500boot_v2_mega2560.hex' avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xFD:m -U hfuse:w:0xD8:m -U lfuse:w:0xFF:m avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -U flash:w:stk500boot_v2_mega2560.hex avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: avrdude -cwiring -patmega2560 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i Atmega1280 \u00b6 Questo chip si trova in genere nelle prime versioni di \"Arduino Mega\". Per eseguire il flashing del bootloader stesso usa qualcosa come: wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega1280.hex' avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xF5:m -U hfuse:w:0xDA:m -U lfuse:w:0xFF:m avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -U flash:w:ATmegaBOOT_168_atmega1280.hex avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: avrdude -carduino -patmega1280 -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i Atmega1284p \u00b6 Questo chip si trova comunemente nelle schede per stampanti 3D in stile \"Melzi\". Per eseguire il flashing del bootloader stesso usa qualcosa come: wget 'https://github.com/Lauszus/Sanguino/raw/1.0.2/bootloaders/optiboot/optiboot_atmega1284p.hex' avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xFD:m -U hfuse:w:0xDE:m -U lfuse:w:0xFF:m avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -U flash:w:optiboot_atmega1284p.hex avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: avrdude -carduino -patmega1284p -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i Si noti che un certo numero di schede in stile \"Melzi\" sono precaricate con un bootloader che utilizza una velocit\u00e0 di trasmissione di 57600 baud. In questo caso, per eseguire il flashing di un'applicazione utilizzare invece qualcosa di simile: avrdude -carduino -patmega1284p -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i At90usb1286 \u00b6 Questo documento non copre il metodo per eseguire il flashing di un bootloader su At90usb1286 n\u00e9 copre il flashing di applicazioni generali su questo dispositivo. Il dispositivo Teensy++ di pjrc.com viene fornito con un bootloader proprietario. Richiede uno strumento di flashing personalizzato da https://github.com/PaulStoffregen/teensy_loader_cli . Si pu\u00f2 eseguire il flashing di un'applicazione usando qualcosa come: teensy_loader_cli --mcu=at90usb1286 out/klipper.elf.hex -v Atmega168 \u00b6 L'atmega168 ha uno spazio flash limitato. Se si utilizza un bootloader, si consiglia di utilizzare il bootloader Optiboot. Per eseguire il flashing di quel bootloader usa qualcosa come: wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega168.hex' avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0x04:m -U hfuse:w:0xDD:m -U lfuse:w:0xFF:m avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -U flash:w:optiboot_atmega168.hex avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m Per eseguire il flashing di un'applicazione tramite il bootloader Optiboot, utilizzare qualcosa come: avrdude -carduino -patmega168 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i Microcontrollori SAM3 (Arduino Due) \u00b6 Non \u00e8 comune utilizzare un bootloader con l'mcu SAM3. Il chip stesso ha una ROM che permette di programmare il flash da porta seriale 3.3V o da USB. Per abilitare la ROM, il pin \"erase\" viene tenuto alto durante un reset, che cancella il contenuto della flash e fa funzionare la ROM. Su un Arduino Due, questa sequenza pu\u00f2 essere realizzata impostando un baud rate di 1200 sulla \"porta usb di programmazione\" (la porta USB pi\u00f9 vicina all'alimentatore). Il codice in https://github.com/shumatech/BOSSA pu\u00f2 essere utilizzato per programmare il SAM3. Si consiglia di utilizzare la versione 1.9 o successiva. Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: bossac -U -p /dev/ttyACM0 -a -e -w out/klipper.bin -v -b bossac -U -p /dev/ttyACM0 -R Microcontrollori SAM4 (Duet Wifi) \u00b6 Non \u00e8 comune utilizzare un bootloader con l'mcu SAM4. Il chip stesso ha una ROM che permette di programmare la memoria flash da porta seriale 3.3V o da USB. Per abilitare la ROM, il pin \"erase\" viene tenuto alto durante un reset, che cancella il contenuto della memoria flash e fa funzionare la ROM. Il codice in https://github.com/shumatech/BOSSA pu\u00f2 essere utilizzato per programmare il SAM4. \u00c8 necessario utilizzare la versione 1.8.0 o successiva. Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: bossac --port=/dev/ttyACM0 -b -U -e -w -v -R out/klipper.bin SAMDC21 micro-controllers (Duet3D Toolboard 1LC) \u00b6 The SAMC21 is flashed via the ARM Serial Wire Debug (SWD) interface. This is commonly done with a dedicated SWD hardware dongle. Alternatively, one can use a Raspberry Pi with OpenOCD . When using OpenOCD with the SAMC21, extra steps must be taken to first put the chip into Cold Plugging mode if the board makes use of the SWD pins for other purposes. If using OpenOCD on a Rasberry Pi, this can be done by running the following commands before invoking OpenOCD. SWCLK=25 SWDIO=24 SRST=18 echo \"Exporting SWCLK and SRST pins.\" echo $SWCLK > /sys/class/gpio/export echo $SRST > /sys/class/gpio/export echo \"out\" > /sys/class/gpio/gpio$SWCLK/direction echo \"out\" > /sys/class/gpio/gpio$SRST/direction echo \"Setting SWCLK low and pulsing SRST.\" echo \"0\" > /sys/class/gpio/gpio$SWCLK/value echo \"0\" > /sys/class/gpio/gpio$SRST/value echo \"1\" > /sys/class/gpio/gpio$SRST/value echo \"Unexporting SWCLK and SRST pins.\" echo $SWCLK > /sys/class/gpio/unexport echo $SRST > /sys/class/gpio/unexport To flash a program with OpenOCD use the following chip config: source [find target/at91samdXX.cfg] Obtain a program; for instance, klipper can be built for this chip. Flash with OpenOCD commands similar to: at91samd chip-erase at91samd bootloader 0 program out/klipper.elf verify Microcontrollori SAMD21 (Arduino Zero) \u00b6 Il bootloader SAMD21 viene caricato in memoria flashing tramite l'interfaccia ARM Serial Wire Debug (SWD). Questo viene fatto comunemente con un dongle hardware SWD dedicato. In alternativa, \u00e8 possibile utilizzare un Raspberry Pi con OpenOCD . Per eseguire il flashing di un bootloader con OpenOCD, utilizzare la seguente configurazione del chip: source [find target/at91samdXX.cfg] Ottieni un bootloader, ad esempio: wget 'https://github.com/arduino/ArduinoCore-samd/raw/1.8.3/bootloaders/zero/samd21_sam_ba.bin' Carica la memoria Flash con comandi OpenOCD simili a: at91samd bootloader 0 program samd21_sam_ba.bin verify Il bootloader pi\u00f9 comune sul SAMD21 \u00e8 quello che si trova sull' \"Arduino Zero\". Utilizza un bootloader da 8KiB (l'applicazione deve essere compilata con un indirizzo iniziale di 8KiB). Si pu\u00f2 entrare in questo bootloader facendo doppio clic sul pulsante di ripristino. Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: bossac -U -p /dev/ttyACM0 --offset=0x2000 -w out/klipper.bin -v -b -R Al contrario, \"Arduino M0\" utilizza un bootloader da 16 KiB (l'applicazione deve essere compilata con un indirizzo iniziale di 16 KiB). Per eseguire il flashing di un'applicazione su questo bootloader, ripristinare il microcontrollore ed eseguire il comando flash entro i primi secondi dall'avvio, qualcosa del tipo: avrdude -c stk500v2 -p atmega2560 -P /dev/ttyACM0 -u -Uflash:w:out/klipper.elf.hex:i Microcontrollori SAMD51 (Adafruit Metro-M4 e simili) \u00b6 Come il SAMD21, il bootloader SAMD51 viene eseguito il flashing tramite l'interfaccia ARM Serial Wire Debug (SWD). Per eseguire il flashing di un bootloader con OpenOCD su un Raspberry Pi utilizzare la seguente configurazione del chip: source [find target/atsame5x.cfg] Ottieni un bootloader: diversi bootloader sono disponibili da https://github.com/adafruit/uf2-samdx1/releases/latest . Per esempio: wget 'https://github.com/adafruit/uf2-samdx1/releases/download/v3.7.0/bootloader-itsybitsy_m4-v3.7.0.bin' Carica la memoria Flash con comandi OpenOCD simili a: at91samd bootloader 0 program bootloader-itsybitsy_m4-v3.7.0.bin verify at91samd bootloader 16384 Il SAMD51 utilizza un bootloader da 16 KiB (l'applicazione deve essere compilata con un indirizzo iniziale di 16 KiB). Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: bossac -U -p /dev/ttyACM0 --offset=0x4000 -w out/klipper.bin -v -b -R Microcontrollori STM32F103 (dispositivi Blue Pill) \u00b6 I dispositivi STM32F103 dispongono di una ROM che pu\u00f2 eseguire il flashing di un bootloader o di un'applicazione tramite seriale a 3,3 V. In genere si collegano i pin PA10 (MCU Rx) e PA9 (MCU Tx) a un adattatore UART da 3,3 V. Per accedere alla ROM, \u00e8 necessario collegare il pin \"boot 0\" in alto e il pin \"boot 1\" in basso, quindi ripristinare il dispositivo. Il pacchetto \"stm32flash\" pu\u00f2 quindi essere utilizzato per eseguire il flashing del dispositivo utilizzando qualcosa come: stm32flash -w out/klipper.bin -v -g 0 /dev/ttyAMA0 Si noti che se si utilizza un Raspberry Pi per la seriale da 3,3 V, il protocollo stm32flash utilizza una modalit\u00e0 di parit\u00e0 seriale che il \"mini UART\" di Raspberry Pi non supporta. Vedere https://www.raspberrypi.com/documentation/computers/configuration.html#configuring-uarts per i dettagli sull'abilitazione dell'uart completo sui pin GPIO di Raspberry Pi. Dopo aver caricato la memoria flash, imposta \"boot 0\" e \"boot 1\" su basso in modo che in futuro ripristini l'avvio da flash. STM32F103 con bootloader stm32duino \u00b6 Il progetto \"stm32duino\" ha un bootloader compatibile con USB - vedere: https://github.com/rogerclarkmelbourne/STM32duino-bootloader Questo bootloader pu\u00f2 essere flashato tramite seriale 3.3V con qualcosa come: wget 'https://github.com/rogerclarkmelbourne/STM32duino-bootloader/raw/master/binaries/generic_boot20_pc13.bin' stm32flash -w generic_boot20_pc13.bin -v -g 0 /dev/ttyAMA0 Questo bootloader utilizza 8KiB di spazio flash (l'applicazione deve essere compilata con un indirizzo iniziale di 8KiB). Caricare in memoria flash un'applicazione con qualcosa come: dfu-util -d 1eaf:0003 -a 2 -R -D out/klipper.bin Il bootloader in genere viene eseguito solo per un breve periodo dopo l'avvio. Potrebbe essere necessario sincronizzare il comando sopra in modo che venga eseguito mentre il bootloader \u00e8 ancora attivo (il bootloader far\u00e0 lampeggiare un led della scheda mentre \u00e8 in esecuzione). In alternativa, imposta il pin \"boot 0\" su basso e il pin \"boot 1\" su alto per rimanere nel bootloader dopo un ripristino. STM32F103 con bootloader HID \u00b6 Il bootloader HID \u00e8 un bootloader compatto e senza driver in grado di eseguire il flashing attraverso USB. \u00c8 inoltre disponibile un fork con build specifiche per SKR Mini E3 1.2 . Per le schede STM32F103 generiche come la blue pill \u00e8 possibile eseguire il flashing del bootloader tramite seriale da 3,3 V utilizzando stm32flash come indicato nella sezione stm32duino sopra, sostituendo il nome del file con il binario del bootloader hid desiderato (ad esempio: hid_generic_pc13.bin per la blue pill ). Non \u00e8 possibile utilizzare stm32flash per SKR Mini E3 poich\u00e9 il pin boot0 \u00e8 collegato direttamente a terra e non disponibile tramite pin header. Si consiglia di utilizzare un STLink V2 con STM32Cubeprogrammer per eseguire il flashing del bootloader. Se non hai accesso a un STLink \u00e8 anche possibile utilizzare un Raspberry Pi e OpenOCD con la seguente configurazione del chip: source [find target/stm32f1x.cfg] Se lo desideri puoi fare un backup della flash corrente con il seguente comando. Tieni presente che il completamento potrebbe richiedere del tempo: flash read_bank 0 btt_skr_mini_e3_backup.bin infine, puoi eseguire il flashing con comandi simili a: stm32f1x mass_erase 0 program hid_btt_skr_mini_e3.bin verify 0x08000000 NOTE: L'esempio sopra cancella il chip, quindi programma il bootloader. Indipendentemente dal metodo scelto per eseguire il flashing, si consiglia di cancellare il chip prima del flashing. Prima di eseguire il flashing di SKR Mini E3 con questo bootloader, dovresti essere consapevole che non sarai pi\u00f9 in grado di aggiornare il firmware tramite la sdcard. You may need to hold down the reset button on the board while launching OpenOCD. It should display something like: Open On-Chip Debugger 0.10.0+dev-01204-gc60252ac-dirty (2020-04-27-16:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html DEPRECATED! use 'adapter speed' not 'adapter_khz' Info : BCM2835 GPIO JTAG/SWD bitbang driver Info : JTAG and SWD modes enabled Info : clock speed 40 kHz Info : SWD DPIDR 0x1ba01477 Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints Info : stm32f1x.cpu: external reset detected Info : starting gdb server for stm32f1x.cpu on 3333 Info : Listening on port 3333 for gdb connections Dopodich\u00e9 puoi rilasciare il pulsante di reset. Questo bootloader richiede 2KiB di spazio flash (l'applicazione deve essere compilata con un indirizzo iniziale di 2KiB). Il programma hid-flash viene utilizzato per caricare un file binario sul bootloader. \u00c8 possibile installare questo software con i seguenti comandi: sudo apt install libusb-1.0 cd ~/klipper/lib/hidflash make Se il bootloader \u00e8 in esecuzione, puoi eseguire il flash con qualcosa del tipo: ~/klipper/lib/hidflash/hid-flash ~/klipper/out/klipper.bin in alternativa, puoi usare make flash per flashare klipper direttamente: make flash FLASH_DEVICE=1209:BEBA O se klipper \u00e8 stato precedentemente flashato: make flash FLASH_DEVICE=/dev/ttyACM0 Potrebbe essere necessario accedere manualmente al bootloader, questo pu\u00f2 essere fatto impostando \"boot 0\" basso e \"boot 1\" alto. Sull'SKR Mini E3 \"Boot 1\" non \u00e8 disponibile, quindi pu\u00f2 essere fatto impostando il pin PA2 basso se hai flashato \"hid_btt_skr_mini_e3.bin\". Questo pin \u00e8 etichettato \"TX0\" sull'intestazione TFT nel documento \"PIN\" di SKR Mini E3. C'\u00e8 un pin di terra accanto a PA2 che puoi utilizzare per abbassare PA2. STM32F103/STM32F072 con bootloader MSC \u00b6 Il bootloader MSC \u00e8 un bootloader senza driver in grado di eseguire il flashing su USB. \u00c8 possibile eseguire il flashing del bootloader tramite seriale da 3,3 V utilizzando stm32flash come indicato nella sezione stm32duino sopra, sostituendo il nome del file con il binario del bootloader MSC desiderato (ad esempio: MSCboot-Bluepill.bin per la blue pill). Per le schede STM32F072 \u00e8 anche possibile eseguire il flashing del bootloader su USB (tramite DFU) con qualcosa del tipo: dfu-util -d 0483:df11 -a 0 -R -D MSCboot-STM32F072.bin -s0x08000000:leave Questo bootloader utilizza 8KiB o 16KiB di spazio flash, vedere la descrizione del bootloader (l'applicazione deve essere compilata con l'indirizzo iniziale corrispondente). Il bootloader pu\u00f2 essere attivato premendo due volte il pulsante di reset della scheda. Non appena il bootloader viene attivato, la scheda appare come una chiavetta USB su cui \u00e8 possibile copiare il file klipper.bin. STM32F103/STM32F0x2 con bootloader CanBoot \u00b6 Il bootloader CanBoot fornisce un'opzione per caricare il firmware Klipper su CANBUS. Il bootloader stesso \u00e8 derivato dal codice sorgente di Klipper. Attualmente CanBoot supporta i modelli STM32F103, STM32F042 e STM32F072. Si consiglia di utilizzare un programmatore ST-Link per eseguire il flashing di CanBoot, tuttavia dovrebbe essere possibile eseguire il flashing utilizzando stm32flash sui dispositivi STM32F103 e \"dfu-util\" sui dispositivi STM32F042/STM32F072. Consulta le sezioni precedenti di questo documento per istruzioni su questi metodi di flashing, sostituendo canboot.bin con il nome del file dove appropriato. Il repository CanBoot collegato sopra fornisce istruzioni per la creazione del bootloader. La prima volta che CanBoot \u00e8 stato flashato, dovrebbe rilevare che non \u00e8 presente alcuna applicazione e accedere al bootloader. Se ci\u00f2 non accade \u00e8 possibile entrare nel bootloader premendo due volte di seguito il pulsante di reset. L'utilit\u00e0 flash_can.py fornita nella cartella lib/canboot pu\u00f2 essere utilizzata per caricare il firmware di Klipper. E' necessario l'UUID del dispositivo per eseguire il flashing. Se non si dispone di un UUID \u00e8 possibile interrogare i nodi che attualmente eseguono il bootloader: python3 flash_can.py -q Ci\u00f2 restituir\u00e0 gli UUID per tutti i nodi collegati non attualmente assegnati a un UUID. Questo dovrebbe includere tutti i nodi attualmente nel bootloader. Una volta che hai un UUID, puoi caricare il firmware con il seguente comando: python3 flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u aabbccddeeff Dove aabbccddeeff \u00e8 sostituito dal tuo UUID. Nota che le opzioni -i e -f possono essere omesse, per impostazione predefinita sono rispettivamente can0 e ~/klipper/out/klipper.bin . Quando crei Klipper per l'uso con CanBoot, seleziona l'opzione Bootloader da 8 KiB. Microcontrollori STM32F4 (SKR Pro 1.1) \u00b6 I microcontrollori STM32F4 sono dotati di un bootloader di sistema integrato in grado di eseguire il flashing tramite USB (tramite DFU), seriale da 3,3 V e vari altri metodi (vedere il documento STM AN2606 per ulteriori informazioni). Alcune schede STM32F4, come SKR Pro 1.1, non sono in grado di accedere al bootloader DFU. Il bootloader HID \u00e8 disponibile per le schede basate su STM32F405/407 nel caso in cui l'utente preferisca eseguire il flashing tramite USB anzich\u00e9 utilizzare la scheda SD. Tieni presente che potrebbe essere necessario configurare e creare una versione specifica per la tua scheda, una build per SKR Pro 1.1 \u00e8 disponibile qui . A meno che la tua scheda non sia compatibile con DFU, il metodo di flashing pi\u00f9 accessibile \u00e8 probabilmente tramite seriale da 3,3 V, che segue la stessa procedura di flash di STM32F103 utilizzando stm32flash . Per esempio: wget https://github.com/Arksine/STM32_HID_Bootloader/releases/download/v0.5-beta/hid_bootloader_SKR_PRO.bin stm32flash -w hid_bootloader_SKR_PRO.bin -v -g 0 /dev/ttyAMA0 Questo bootloader richiede 16Kib di spazio flash sull'STM32F4 (l'applicazione deve essere compilata con un indirizzo iniziale di 16KiB). Come con l'STM32F1, l'STM32F4 utilizza lo strumento hid-flash per caricare i file binari nell'MCU. Consulta le istruzioni sopra per i dettagli su come creare e utilizzare hid-flash. Potrebbe essere necessario inserire manualmente il bootloader, questo pu\u00f2 essere fatto impostando \"boot 0\" basso, \"boot 1\" alto e collegando il dispositivo. Al termine della programmazione, scollegare il dispositivo e impostare \"boot 1\" su basso in modo che l'applicazione venga caricata. Microcontrollori LPC176x (Smoothieboards) \u00b6 Questo documento non descrive il metodo per eseguire il flashing di un bootloader stesso - vedere: http://smoothieware.org/flashing-the-bootloader per ulteriori informazioni su questo argomento. \u00c8 comune che per le Smoothieboard venga fornito con un bootloader da: https://github.com/triffid/LPC17xx-DFU-Bootloader . Quando si utilizza questo bootloader, l'applicazione deve essere compilata con un indirizzo iniziale di 16 KiB. Il modo pi\u00f9 semplice per eseguire il flashing di un'applicazione con questo bootloader \u00e8 copiare il file dell'applicazione (ad es. out/klipper.bin ) in un file denominato firmware.bin su una scheda SD, quindi riavviare il microcontrollore con quella scheda SD. Eseguire OpenOCD su Raspberry PI \u00b6 OpenOCD \u00e8 un pacchetto software in grado di eseguire il flashing e il debug di chip di basso livello. Pu\u00f2 utilizzare i pin GPIO su un Raspberry Pi per comunicare con una variet\u00e0 di chip ARM. Questa sezione descrive come installare e avviare OpenOCD. \u00c8 derivato dalle istruzioni su: https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi Inizia scaricando e compilando il software (ogni passaggio pu\u00f2 richiedere diversi minuti e il passaggio \"make\" pu\u00f2 richiedere pi\u00f9 di 30 minuti): sudo apt-get update sudo apt-get install autoconf libtool telnet mkdir ~/openocd cd ~/openocd/ git clone http://openocd.zylin.com/openocd cd openocd ./bootstrap ./configure --enable-sysfsgpio --enable-bcm2835gpio --prefix=/home/pi/openocd/install make make install Configurare OpenOCD \u00b6 Crea un file di configurazione OpenOCD: nano ~/openocd/openocd.cfg Utilizzare una configurazione simile alla seguente: # Uses RPi pins: GPIO25 for SWDCLK, GPIO24 for SWDIO, GPIO18 for nRST source [find interface/raspberrypi2-native.cfg] bcm2835gpio_swd_nums 25 24 bcm2835gpio_srst_num 18 transport select swd # Use hardware reset wire for chip resets reset_config srst_only adapter_nsrst_delay 100 adapter_nsrst_assert_width 100 # Specify the chip type source [find target/atsame5x.cfg] # Set the adapter speed adapter_khz 40 # Connect to chip init targets reset halt Collega il Raspberry Pi al chip di destinazione \u00b6 Spegni sia il Raspberry Pi che il chip di destinazione prima del cablaggio! Verificare che il chip di destinazione utilizzi 3,3 V prima di connettersi a un Raspberry Pi! Collega GND, SWDCLK, SWDIO e RST sul chip di destinazione rispettivamente a GND, GPIO25, GPIO24 e GPIO18 sul Raspberry Pi. Quindi accendi il Raspberry Pi e fornisci alimentazione al chip di destinazione. Eseguire OpenOCD \u00b6 Esegui OpenOCD: cd ~/openocd/ sudo ~/openocd/install/bin/openocd -f ~/openocd/openocd.cfg Quanto sopra dovrebbe far s\u00ec che OpenOCD emetta alcuni messaggi di testo e quindi attenda (non dovrebbe tornare immediatamente al prompt della shell Unix). Se OpenOCD termina da solo o se continua a emettere messaggi di testo, ricontrolla il cablaggio. Una volta che OpenOCD \u00e8 in esecuzione ed \u00e8 stabile, \u00e8 possibile inviargli comandi tramite telnet. Apri un'altra sessione ssh ed esegui quanto segue: telnet 127.0.0.1 4444 (Si pu\u00f2 uscire da telnet premendo ctrl+] e quindi eseguendo il comando \"quit\".) OpenOCD e gdb \u00b6 \u00c8 possibile utilizzare OpenOCD con gdb per eseguire il debug di Klipper. I seguenti comandi presuppongono che uno stia eseguendo gdb su una macchina di classe desktop. Aggiungi quanto segue al file di configurazione di OpenOCD: bindto 0.0.0.0 gdb_port 44444 Riavvia OpenOCD sul Raspberry Pi e quindi esegui il seguente comando Unix sul computer desktop: cd /path/to/klipper/ gdb out/klipper.elf All'interno di gdb esegui: target remote octopi:44444 (Sostituisci \"octopi\" con il nome host del Raspberry Pi.) Una volta che gdb \u00e8 in esecuzione, \u00e8 possibile impostare punti di interruzione e ispezionare i registri.","title":"Bootloader"},{"location":"Bootloaders.html#bootloader","text":"Questo documento fornisce informazioni sui bootloader comuni scoperti sui microcontrollori che sono supportati da Klipper. Il bootloader \u00e8 un software di terze parti che viene eseguito sul microcontrollore quando viene acceso per la prima volta. Viene generalmente utilizzato per eseguire il flashing di una nuova applicazione (ad es. Klipper) sul microcontrollore senza richiedere hardware specializzato. Sfortunatamente, non esiste uno standard a livello di settore per il flashing di un microcontrollore, n\u00e9 esiste un bootloader standard che funzioni su tutti i microcontrollori. Peggio ancora, \u00e8 comune che ogni bootloader richieda una serie di passaggi diversa per eseguire il flashing di un'applicazione. Se si pu\u00f2 eseguire il flashing di un bootloader su un microcontrollore, generalmente si pu\u00f2 anche utilizzare quel meccanismo per eseguire il flashing di un'applicazione, ma \u00e8 necessario prestare attenzione quando si esegue questa operazione poich\u00e9 si potrebbe rimuovere inavvertitamente il bootloader. Al contrario, un bootloader generalmente consentir\u00e0 solo a un utente di eseguire il flashing di un'applicazione. Si consiglia pertanto di utilizzare un bootloader per eseguire il flashing di un'applicazione, ove possibile. Questo documento tenta di descrivere i bootloader comuni, i passaggi necessari per eseguire il flashing di un bootloader e i passaggi necessari per eseguire il flashing di un'applicazione. Questo documento non \u00e8 un riferimento autorevole; \u00e8 inteso come una raccolta di informazioni utili che gli sviluppatori di Klipper hanno accumulato.","title":"Bootloader"},{"location":"Bootloaders.html#microcontrollori-avr","text":"In generale, il progetto Arduino \u00e8 un buon riferimento per bootloader e procedure di flashing sui microcontrollori Atmel Atmega a 8 bit. In particolare, il file \"boards.txt\": https://github.com/arduino/Arduino/blob/1.8.5/hardware/arduino/avr/boards.txt \u00e8 un utile riferimento. Per eseguire il flashing di un bootloader, i chip AVR richiedono uno strumento di flashing hardware esterno (che comunica con il chip tramite SPI). Questo strumento pu\u00f2 essere acquistato (ad esempio, eseguire una ricerca sul Web per \"avr isp\", \"arduino isp\" o \"usb tiny isp\"). \u00c8 anche possibile utilizzare un altro Arduino o Raspberry Pi per eseguire il flashing di un bootloader AVR (ad esempio, eseguire una ricerca sul Web per \"programmare un avr utilizzando raspberry pi\"). Gli esempi seguenti sono scritti presupponendo che sia in uso un dispositivo di tipo \"AVR ISP Mk2\". Il programma \"avrdude\" \u00e8 lo strumento pi\u00f9 comune utilizzato per eseguire il flashing dei chip atmega (sia flash del bootloader che flash dell'applicazione).","title":"Microcontrollori AVR"},{"location":"Bootloaders.html#atmega2560","text":"Questo chip si trova in genere nell'\"Arduino Mega\" ed \u00e8 molto comune nelle schede per stampanti 3D. Per eseguire il flashing del bootloader stesso usa qualcosa come: wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/stk500v2/stk500boot_v2_mega2560.hex' avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xFD:m -U hfuse:w:0xD8:m -U lfuse:w:0xFF:m avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -U flash:w:stk500boot_v2_mega2560.hex avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: avrdude -cwiring -patmega2560 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i","title":"Atmega2560"},{"location":"Bootloaders.html#atmega1280","text":"Questo chip si trova in genere nelle prime versioni di \"Arduino Mega\". Per eseguire il flashing del bootloader stesso usa qualcosa come: wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega1280.hex' avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xF5:m -U hfuse:w:0xDA:m -U lfuse:w:0xFF:m avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -U flash:w:ATmegaBOOT_168_atmega1280.hex avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: avrdude -carduino -patmega1280 -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i","title":"Atmega1280"},{"location":"Bootloaders.html#atmega1284p","text":"Questo chip si trova comunemente nelle schede per stampanti 3D in stile \"Melzi\". Per eseguire il flashing del bootloader stesso usa qualcosa come: wget 'https://github.com/Lauszus/Sanguino/raw/1.0.2/bootloaders/optiboot/optiboot_atmega1284p.hex' avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xFD:m -U hfuse:w:0xDE:m -U lfuse:w:0xFF:m avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -U flash:w:optiboot_atmega1284p.hex avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: avrdude -carduino -patmega1284p -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i Si noti che un certo numero di schede in stile \"Melzi\" sono precaricate con un bootloader che utilizza una velocit\u00e0 di trasmissione di 57600 baud. In questo caso, per eseguire il flashing di un'applicazione utilizzare invece qualcosa di simile: avrdude -carduino -patmega1284p -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i","title":"Atmega1284p"},{"location":"Bootloaders.html#at90usb1286","text":"Questo documento non copre il metodo per eseguire il flashing di un bootloader su At90usb1286 n\u00e9 copre il flashing di applicazioni generali su questo dispositivo. Il dispositivo Teensy++ di pjrc.com viene fornito con un bootloader proprietario. Richiede uno strumento di flashing personalizzato da https://github.com/PaulStoffregen/teensy_loader_cli . Si pu\u00f2 eseguire il flashing di un'applicazione usando qualcosa come: teensy_loader_cli --mcu=at90usb1286 out/klipper.elf.hex -v","title":"At90usb1286"},{"location":"Bootloaders.html#atmega168","text":"L'atmega168 ha uno spazio flash limitato. Se si utilizza un bootloader, si consiglia di utilizzare il bootloader Optiboot. Per eseguire il flashing di quel bootloader usa qualcosa come: wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega168.hex' avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0x04:m -U hfuse:w:0xDD:m -U lfuse:w:0xFF:m avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -U flash:w:optiboot_atmega168.hex avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m Per eseguire il flashing di un'applicazione tramite il bootloader Optiboot, utilizzare qualcosa come: avrdude -carduino -patmega168 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i","title":"Atmega168"},{"location":"Bootloaders.html#microcontrollori-sam3-arduino-due","text":"Non \u00e8 comune utilizzare un bootloader con l'mcu SAM3. Il chip stesso ha una ROM che permette di programmare il flash da porta seriale 3.3V o da USB. Per abilitare la ROM, il pin \"erase\" viene tenuto alto durante un reset, che cancella il contenuto della flash e fa funzionare la ROM. Su un Arduino Due, questa sequenza pu\u00f2 essere realizzata impostando un baud rate di 1200 sulla \"porta usb di programmazione\" (la porta USB pi\u00f9 vicina all'alimentatore). Il codice in https://github.com/shumatech/BOSSA pu\u00f2 essere utilizzato per programmare il SAM3. Si consiglia di utilizzare la versione 1.9 o successiva. Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: bossac -U -p /dev/ttyACM0 -a -e -w out/klipper.bin -v -b bossac -U -p /dev/ttyACM0 -R","title":"Microcontrollori SAM3 (Arduino Due)"},{"location":"Bootloaders.html#microcontrollori-sam4-duet-wifi","text":"Non \u00e8 comune utilizzare un bootloader con l'mcu SAM4. Il chip stesso ha una ROM che permette di programmare la memoria flash da porta seriale 3.3V o da USB. Per abilitare la ROM, il pin \"erase\" viene tenuto alto durante un reset, che cancella il contenuto della memoria flash e fa funzionare la ROM. Il codice in https://github.com/shumatech/BOSSA pu\u00f2 essere utilizzato per programmare il SAM4. \u00c8 necessario utilizzare la versione 1.8.0 o successiva. Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: bossac --port=/dev/ttyACM0 -b -U -e -w -v -R out/klipper.bin","title":"Microcontrollori SAM4 (Duet Wifi)"},{"location":"Bootloaders.html#samdc21-micro-controllers-duet3d-toolboard-1lc","text":"The SAMC21 is flashed via the ARM Serial Wire Debug (SWD) interface. This is commonly done with a dedicated SWD hardware dongle. Alternatively, one can use a Raspberry Pi with OpenOCD . When using OpenOCD with the SAMC21, extra steps must be taken to first put the chip into Cold Plugging mode if the board makes use of the SWD pins for other purposes. If using OpenOCD on a Rasberry Pi, this can be done by running the following commands before invoking OpenOCD. SWCLK=25 SWDIO=24 SRST=18 echo \"Exporting SWCLK and SRST pins.\" echo $SWCLK > /sys/class/gpio/export echo $SRST > /sys/class/gpio/export echo \"out\" > /sys/class/gpio/gpio$SWCLK/direction echo \"out\" > /sys/class/gpio/gpio$SRST/direction echo \"Setting SWCLK low and pulsing SRST.\" echo \"0\" > /sys/class/gpio/gpio$SWCLK/value echo \"0\" > /sys/class/gpio/gpio$SRST/value echo \"1\" > /sys/class/gpio/gpio$SRST/value echo \"Unexporting SWCLK and SRST pins.\" echo $SWCLK > /sys/class/gpio/unexport echo $SRST > /sys/class/gpio/unexport To flash a program with OpenOCD use the following chip config: source [find target/at91samdXX.cfg] Obtain a program; for instance, klipper can be built for this chip. Flash with OpenOCD commands similar to: at91samd chip-erase at91samd bootloader 0 program out/klipper.elf verify","title":"SAMDC21 micro-controllers (Duet3D Toolboard 1LC)"},{"location":"Bootloaders.html#microcontrollori-samd21-arduino-zero","text":"Il bootloader SAMD21 viene caricato in memoria flashing tramite l'interfaccia ARM Serial Wire Debug (SWD). Questo viene fatto comunemente con un dongle hardware SWD dedicato. In alternativa, \u00e8 possibile utilizzare un Raspberry Pi con OpenOCD . Per eseguire il flashing di un bootloader con OpenOCD, utilizzare la seguente configurazione del chip: source [find target/at91samdXX.cfg] Ottieni un bootloader, ad esempio: wget 'https://github.com/arduino/ArduinoCore-samd/raw/1.8.3/bootloaders/zero/samd21_sam_ba.bin' Carica la memoria Flash con comandi OpenOCD simili a: at91samd bootloader 0 program samd21_sam_ba.bin verify Il bootloader pi\u00f9 comune sul SAMD21 \u00e8 quello che si trova sull' \"Arduino Zero\". Utilizza un bootloader da 8KiB (l'applicazione deve essere compilata con un indirizzo iniziale di 8KiB). Si pu\u00f2 entrare in questo bootloader facendo doppio clic sul pulsante di ripristino. Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: bossac -U -p /dev/ttyACM0 --offset=0x2000 -w out/klipper.bin -v -b -R Al contrario, \"Arduino M0\" utilizza un bootloader da 16 KiB (l'applicazione deve essere compilata con un indirizzo iniziale di 16 KiB). Per eseguire il flashing di un'applicazione su questo bootloader, ripristinare il microcontrollore ed eseguire il comando flash entro i primi secondi dall'avvio, qualcosa del tipo: avrdude -c stk500v2 -p atmega2560 -P /dev/ttyACM0 -u -Uflash:w:out/klipper.elf.hex:i","title":"Microcontrollori SAMD21 (Arduino Zero)"},{"location":"Bootloaders.html#microcontrollori-samd51-adafruit-metro-m4-e-simili","text":"Come il SAMD21, il bootloader SAMD51 viene eseguito il flashing tramite l'interfaccia ARM Serial Wire Debug (SWD). Per eseguire il flashing di un bootloader con OpenOCD su un Raspberry Pi utilizzare la seguente configurazione del chip: source [find target/atsame5x.cfg] Ottieni un bootloader: diversi bootloader sono disponibili da https://github.com/adafruit/uf2-samdx1/releases/latest . Per esempio: wget 'https://github.com/adafruit/uf2-samdx1/releases/download/v3.7.0/bootloader-itsybitsy_m4-v3.7.0.bin' Carica la memoria Flash con comandi OpenOCD simili a: at91samd bootloader 0 program bootloader-itsybitsy_m4-v3.7.0.bin verify at91samd bootloader 16384 Il SAMD51 utilizza un bootloader da 16 KiB (l'applicazione deve essere compilata con un indirizzo iniziale di 16 KiB). Per eseguire il flashing di un'applicazione, utilizzare qualcosa come: bossac -U -p /dev/ttyACM0 --offset=0x4000 -w out/klipper.bin -v -b -R","title":"Microcontrollori SAMD51 (Adafruit Metro-M4 e simili)"},{"location":"Bootloaders.html#microcontrollori-stm32f103-dispositivi-blue-pill","text":"I dispositivi STM32F103 dispongono di una ROM che pu\u00f2 eseguire il flashing di un bootloader o di un'applicazione tramite seriale a 3,3 V. In genere si collegano i pin PA10 (MCU Rx) e PA9 (MCU Tx) a un adattatore UART da 3,3 V. Per accedere alla ROM, \u00e8 necessario collegare il pin \"boot 0\" in alto e il pin \"boot 1\" in basso, quindi ripristinare il dispositivo. Il pacchetto \"stm32flash\" pu\u00f2 quindi essere utilizzato per eseguire il flashing del dispositivo utilizzando qualcosa come: stm32flash -w out/klipper.bin -v -g 0 /dev/ttyAMA0 Si noti che se si utilizza un Raspberry Pi per la seriale da 3,3 V, il protocollo stm32flash utilizza una modalit\u00e0 di parit\u00e0 seriale che il \"mini UART\" di Raspberry Pi non supporta. Vedere https://www.raspberrypi.com/documentation/computers/configuration.html#configuring-uarts per i dettagli sull'abilitazione dell'uart completo sui pin GPIO di Raspberry Pi. Dopo aver caricato la memoria flash, imposta \"boot 0\" e \"boot 1\" su basso in modo che in futuro ripristini l'avvio da flash.","title":"Microcontrollori STM32F103 (dispositivi Blue Pill)"},{"location":"Bootloaders.html#stm32f103-con-bootloader-stm32duino","text":"Il progetto \"stm32duino\" ha un bootloader compatibile con USB - vedere: https://github.com/rogerclarkmelbourne/STM32duino-bootloader Questo bootloader pu\u00f2 essere flashato tramite seriale 3.3V con qualcosa come: wget 'https://github.com/rogerclarkmelbourne/STM32duino-bootloader/raw/master/binaries/generic_boot20_pc13.bin' stm32flash -w generic_boot20_pc13.bin -v -g 0 /dev/ttyAMA0 Questo bootloader utilizza 8KiB di spazio flash (l'applicazione deve essere compilata con un indirizzo iniziale di 8KiB). Caricare in memoria flash un'applicazione con qualcosa come: dfu-util -d 1eaf:0003 -a 2 -R -D out/klipper.bin Il bootloader in genere viene eseguito solo per un breve periodo dopo l'avvio. Potrebbe essere necessario sincronizzare il comando sopra in modo che venga eseguito mentre il bootloader \u00e8 ancora attivo (il bootloader far\u00e0 lampeggiare un led della scheda mentre \u00e8 in esecuzione). In alternativa, imposta il pin \"boot 0\" su basso e il pin \"boot 1\" su alto per rimanere nel bootloader dopo un ripristino.","title":"STM32F103 con bootloader stm32duino"},{"location":"Bootloaders.html#stm32f103-con-bootloader-hid","text":"Il bootloader HID \u00e8 un bootloader compatto e senza driver in grado di eseguire il flashing attraverso USB. \u00c8 inoltre disponibile un fork con build specifiche per SKR Mini E3 1.2 . Per le schede STM32F103 generiche come la blue pill \u00e8 possibile eseguire il flashing del bootloader tramite seriale da 3,3 V utilizzando stm32flash come indicato nella sezione stm32duino sopra, sostituendo il nome del file con il binario del bootloader hid desiderato (ad esempio: hid_generic_pc13.bin per la blue pill ). Non \u00e8 possibile utilizzare stm32flash per SKR Mini E3 poich\u00e9 il pin boot0 \u00e8 collegato direttamente a terra e non disponibile tramite pin header. Si consiglia di utilizzare un STLink V2 con STM32Cubeprogrammer per eseguire il flashing del bootloader. Se non hai accesso a un STLink \u00e8 anche possibile utilizzare un Raspberry Pi e OpenOCD con la seguente configurazione del chip: source [find target/stm32f1x.cfg] Se lo desideri puoi fare un backup della flash corrente con il seguente comando. Tieni presente che il completamento potrebbe richiedere del tempo: flash read_bank 0 btt_skr_mini_e3_backup.bin infine, puoi eseguire il flashing con comandi simili a: stm32f1x mass_erase 0 program hid_btt_skr_mini_e3.bin verify 0x08000000 NOTE: L'esempio sopra cancella il chip, quindi programma il bootloader. Indipendentemente dal metodo scelto per eseguire il flashing, si consiglia di cancellare il chip prima del flashing. Prima di eseguire il flashing di SKR Mini E3 con questo bootloader, dovresti essere consapevole che non sarai pi\u00f9 in grado di aggiornare il firmware tramite la sdcard. You may need to hold down the reset button on the board while launching OpenOCD. It should display something like: Open On-Chip Debugger 0.10.0+dev-01204-gc60252ac-dirty (2020-04-27-16:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html DEPRECATED! use 'adapter speed' not 'adapter_khz' Info : BCM2835 GPIO JTAG/SWD bitbang driver Info : JTAG and SWD modes enabled Info : clock speed 40 kHz Info : SWD DPIDR 0x1ba01477 Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints Info : stm32f1x.cpu: external reset detected Info : starting gdb server for stm32f1x.cpu on 3333 Info : Listening on port 3333 for gdb connections Dopodich\u00e9 puoi rilasciare il pulsante di reset. Questo bootloader richiede 2KiB di spazio flash (l'applicazione deve essere compilata con un indirizzo iniziale di 2KiB). Il programma hid-flash viene utilizzato per caricare un file binario sul bootloader. \u00c8 possibile installare questo software con i seguenti comandi: sudo apt install libusb-1.0 cd ~/klipper/lib/hidflash make Se il bootloader \u00e8 in esecuzione, puoi eseguire il flash con qualcosa del tipo: ~/klipper/lib/hidflash/hid-flash ~/klipper/out/klipper.bin in alternativa, puoi usare make flash per flashare klipper direttamente: make flash FLASH_DEVICE=1209:BEBA O se klipper \u00e8 stato precedentemente flashato: make flash FLASH_DEVICE=/dev/ttyACM0 Potrebbe essere necessario accedere manualmente al bootloader, questo pu\u00f2 essere fatto impostando \"boot 0\" basso e \"boot 1\" alto. Sull'SKR Mini E3 \"Boot 1\" non \u00e8 disponibile, quindi pu\u00f2 essere fatto impostando il pin PA2 basso se hai flashato \"hid_btt_skr_mini_e3.bin\". Questo pin \u00e8 etichettato \"TX0\" sull'intestazione TFT nel documento \"PIN\" di SKR Mini E3. C'\u00e8 un pin di terra accanto a PA2 che puoi utilizzare per abbassare PA2.","title":"STM32F103 con bootloader HID"},{"location":"Bootloaders.html#stm32f103stm32f072-con-bootloader-msc","text":"Il bootloader MSC \u00e8 un bootloader senza driver in grado di eseguire il flashing su USB. \u00c8 possibile eseguire il flashing del bootloader tramite seriale da 3,3 V utilizzando stm32flash come indicato nella sezione stm32duino sopra, sostituendo il nome del file con il binario del bootloader MSC desiderato (ad esempio: MSCboot-Bluepill.bin per la blue pill). Per le schede STM32F072 \u00e8 anche possibile eseguire il flashing del bootloader su USB (tramite DFU) con qualcosa del tipo: dfu-util -d 0483:df11 -a 0 -R -D MSCboot-STM32F072.bin -s0x08000000:leave Questo bootloader utilizza 8KiB o 16KiB di spazio flash, vedere la descrizione del bootloader (l'applicazione deve essere compilata con l'indirizzo iniziale corrispondente). Il bootloader pu\u00f2 essere attivato premendo due volte il pulsante di reset della scheda. Non appena il bootloader viene attivato, la scheda appare come una chiavetta USB su cui \u00e8 possibile copiare il file klipper.bin.","title":"STM32F103/STM32F072 con bootloader MSC"},{"location":"Bootloaders.html#stm32f103stm32f0x2-con-bootloader-canboot","text":"Il bootloader CanBoot fornisce un'opzione per caricare il firmware Klipper su CANBUS. Il bootloader stesso \u00e8 derivato dal codice sorgente di Klipper. Attualmente CanBoot supporta i modelli STM32F103, STM32F042 e STM32F072. Si consiglia di utilizzare un programmatore ST-Link per eseguire il flashing di CanBoot, tuttavia dovrebbe essere possibile eseguire il flashing utilizzando stm32flash sui dispositivi STM32F103 e \"dfu-util\" sui dispositivi STM32F042/STM32F072. Consulta le sezioni precedenti di questo documento per istruzioni su questi metodi di flashing, sostituendo canboot.bin con il nome del file dove appropriato. Il repository CanBoot collegato sopra fornisce istruzioni per la creazione del bootloader. La prima volta che CanBoot \u00e8 stato flashato, dovrebbe rilevare che non \u00e8 presente alcuna applicazione e accedere al bootloader. Se ci\u00f2 non accade \u00e8 possibile entrare nel bootloader premendo due volte di seguito il pulsante di reset. L'utilit\u00e0 flash_can.py fornita nella cartella lib/canboot pu\u00f2 essere utilizzata per caricare il firmware di Klipper. E' necessario l'UUID del dispositivo per eseguire il flashing. Se non si dispone di un UUID \u00e8 possibile interrogare i nodi che attualmente eseguono il bootloader: python3 flash_can.py -q Ci\u00f2 restituir\u00e0 gli UUID per tutti i nodi collegati non attualmente assegnati a un UUID. Questo dovrebbe includere tutti i nodi attualmente nel bootloader. Una volta che hai un UUID, puoi caricare il firmware con il seguente comando: python3 flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u aabbccddeeff Dove aabbccddeeff \u00e8 sostituito dal tuo UUID. Nota che le opzioni -i e -f possono essere omesse, per impostazione predefinita sono rispettivamente can0 e ~/klipper/out/klipper.bin . Quando crei Klipper per l'uso con CanBoot, seleziona l'opzione Bootloader da 8 KiB.","title":"STM32F103/STM32F0x2 con bootloader CanBoot"},{"location":"Bootloaders.html#microcontrollori-stm32f4-skr-pro-11","text":"I microcontrollori STM32F4 sono dotati di un bootloader di sistema integrato in grado di eseguire il flashing tramite USB (tramite DFU), seriale da 3,3 V e vari altri metodi (vedere il documento STM AN2606 per ulteriori informazioni). Alcune schede STM32F4, come SKR Pro 1.1, non sono in grado di accedere al bootloader DFU. Il bootloader HID \u00e8 disponibile per le schede basate su STM32F405/407 nel caso in cui l'utente preferisca eseguire il flashing tramite USB anzich\u00e9 utilizzare la scheda SD. Tieni presente che potrebbe essere necessario configurare e creare una versione specifica per la tua scheda, una build per SKR Pro 1.1 \u00e8 disponibile qui . A meno che la tua scheda non sia compatibile con DFU, il metodo di flashing pi\u00f9 accessibile \u00e8 probabilmente tramite seriale da 3,3 V, che segue la stessa procedura di flash di STM32F103 utilizzando stm32flash . Per esempio: wget https://github.com/Arksine/STM32_HID_Bootloader/releases/download/v0.5-beta/hid_bootloader_SKR_PRO.bin stm32flash -w hid_bootloader_SKR_PRO.bin -v -g 0 /dev/ttyAMA0 Questo bootloader richiede 16Kib di spazio flash sull'STM32F4 (l'applicazione deve essere compilata con un indirizzo iniziale di 16KiB). Come con l'STM32F1, l'STM32F4 utilizza lo strumento hid-flash per caricare i file binari nell'MCU. Consulta le istruzioni sopra per i dettagli su come creare e utilizzare hid-flash. Potrebbe essere necessario inserire manualmente il bootloader, questo pu\u00f2 essere fatto impostando \"boot 0\" basso, \"boot 1\" alto e collegando il dispositivo. Al termine della programmazione, scollegare il dispositivo e impostare \"boot 1\" su basso in modo che l'applicazione venga caricata.","title":"Microcontrollori STM32F4 (SKR Pro 1.1)"},{"location":"Bootloaders.html#microcontrollori-lpc176x-smoothieboards","text":"Questo documento non descrive il metodo per eseguire il flashing di un bootloader stesso - vedere: http://smoothieware.org/flashing-the-bootloader per ulteriori informazioni su questo argomento. \u00c8 comune che per le Smoothieboard venga fornito con un bootloader da: https://github.com/triffid/LPC17xx-DFU-Bootloader . Quando si utilizza questo bootloader, l'applicazione deve essere compilata con un indirizzo iniziale di 16 KiB. Il modo pi\u00f9 semplice per eseguire il flashing di un'applicazione con questo bootloader \u00e8 copiare il file dell'applicazione (ad es. out/klipper.bin ) in un file denominato firmware.bin su una scheda SD, quindi riavviare il microcontrollore con quella scheda SD.","title":"Microcontrollori LPC176x (Smoothieboards)"},{"location":"Bootloaders.html#eseguire-openocd-su-raspberry-pi","text":"OpenOCD \u00e8 un pacchetto software in grado di eseguire il flashing e il debug di chip di basso livello. Pu\u00f2 utilizzare i pin GPIO su un Raspberry Pi per comunicare con una variet\u00e0 di chip ARM. Questa sezione descrive come installare e avviare OpenOCD. \u00c8 derivato dalle istruzioni su: https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi Inizia scaricando e compilando il software (ogni passaggio pu\u00f2 richiedere diversi minuti e il passaggio \"make\" pu\u00f2 richiedere pi\u00f9 di 30 minuti): sudo apt-get update sudo apt-get install autoconf libtool telnet mkdir ~/openocd cd ~/openocd/ git clone http://openocd.zylin.com/openocd cd openocd ./bootstrap ./configure --enable-sysfsgpio --enable-bcm2835gpio --prefix=/home/pi/openocd/install make make install","title":"Eseguire OpenOCD su Raspberry PI"},{"location":"Bootloaders.html#configurare-openocd","text":"Crea un file di configurazione OpenOCD: nano ~/openocd/openocd.cfg Utilizzare una configurazione simile alla seguente: # Uses RPi pins: GPIO25 for SWDCLK, GPIO24 for SWDIO, GPIO18 for nRST source [find interface/raspberrypi2-native.cfg] bcm2835gpio_swd_nums 25 24 bcm2835gpio_srst_num 18 transport select swd # Use hardware reset wire for chip resets reset_config srst_only adapter_nsrst_delay 100 adapter_nsrst_assert_width 100 # Specify the chip type source [find target/atsame5x.cfg] # Set the adapter speed adapter_khz 40 # Connect to chip init targets reset halt","title":"Configurare OpenOCD"},{"location":"Bootloaders.html#collega-il-raspberry-pi-al-chip-di-destinazione","text":"Spegni sia il Raspberry Pi che il chip di destinazione prima del cablaggio! Verificare che il chip di destinazione utilizzi 3,3 V prima di connettersi a un Raspberry Pi! Collega GND, SWDCLK, SWDIO e RST sul chip di destinazione rispettivamente a GND, GPIO25, GPIO24 e GPIO18 sul Raspberry Pi. Quindi accendi il Raspberry Pi e fornisci alimentazione al chip di destinazione.","title":"Collega il Raspberry Pi al chip di destinazione"},{"location":"Bootloaders.html#eseguire-openocd","text":"Esegui OpenOCD: cd ~/openocd/ sudo ~/openocd/install/bin/openocd -f ~/openocd/openocd.cfg Quanto sopra dovrebbe far s\u00ec che OpenOCD emetta alcuni messaggi di testo e quindi attenda (non dovrebbe tornare immediatamente al prompt della shell Unix). Se OpenOCD termina da solo o se continua a emettere messaggi di testo, ricontrolla il cablaggio. Una volta che OpenOCD \u00e8 in esecuzione ed \u00e8 stabile, \u00e8 possibile inviargli comandi tramite telnet. Apri un'altra sessione ssh ed esegui quanto segue: telnet 127.0.0.1 4444 (Si pu\u00f2 uscire da telnet premendo ctrl+] e quindi eseguendo il comando \"quit\".)","title":"Eseguire OpenOCD"},{"location":"Bootloaders.html#openocd-e-gdb","text":"\u00c8 possibile utilizzare OpenOCD con gdb per eseguire il debug di Klipper. I seguenti comandi presuppongono che uno stia eseguendo gdb su una macchina di classe desktop. Aggiungi quanto segue al file di configurazione di OpenOCD: bindto 0.0.0.0 gdb_port 44444 Riavvia OpenOCD sul Raspberry Pi e quindi esegui il seguente comando Unix sul computer desktop: cd /path/to/klipper/ gdb out/klipper.elf All'interno di gdb esegui: target remote octopi:44444 (Sostituisci \"octopi\" con il nome host del Raspberry Pi.) Una volta che gdb \u00e8 in esecuzione, \u00e8 possibile impostare punti di interruzione e ispezionare i registri.","title":"OpenOCD e gdb"},{"location":"CANBUS.html","text":"CANBUS \u00b6 Questo documento descrive il supporto del CAN bus di Klipper. Hardware del dispositivo \u00b6 Klipper currently supports CAN on stm32, SAME5x, and rp2040 chips. In addition, the micro-controller chip must be on a board that has a CAN transceiver. Per compilare per CAN, eseguire make menuconfig e selezionare \"CAN bus\" come interfaccia di comunicazione. Infine, compila il codice del microcontrollore e flashalo sulla scheda di destinazione. Hardware Host \u00b6 In order to use a CAN bus, it is necessary to have a host adapter. It is recommended to use a \"USB to CAN adapter\". There are many different USB to CAN adapters available from different manufacturers. When choosing one, we recommend verifying that the firmware can be updated on it. (Unfortunately, we've found some USB adapters run defective firmware and are locked down, so verify before purchasing.) Look for adapters that can run Klipper directly (in its \"USB to CAN bridge mode\") or that run the candlelight firmware . \u00c8 inoltre necessario configurare il sistema operativo host per utilizzare l'adattatore. Questo viene in genere fatto creando un nuovo file chiamato /etc/network/interfaces.d/can0 con il seguente contenuto: allow-hotplug can0 iface can0 can static bitrate 1000000 up ifconfig $IFACE txqueuelen 128 Resistori di terminazione \u00b6 Un bus CAN dovrebbe avere due resistori da 120 ohm tra i cavi CANH e CANL. Idealmente, un resistore situato a ciascuna estremit\u00e0 del bus. Note that some devices have a builtin 120 ohm resistor that can not be easily removed. Some devices do not include a resistor at all. Other devices have a mechanism to select the resistor (typically by connecting a \"pin jumper\"). Be sure to check the schematics of all devices on the CAN bus to verify that there are two and only two 120 Ohm resistors on the bus. Per verificare che i resistori siano corretti, \u00e8 possibile rimuovere l'alimentazione alla stampante e utilizzare un multimetro per controllare la resistenza tra i cavi CNH e CANL: dovrebbe riportare ~60 ohm su un bus CAN cablato correttamente. Trovare canbus_uuid per nuovi microcontrollori \u00b6 A ogni microcontrollore sul bus CAN viene assegnato un ID univoco basato sull'identificatore del chip di fabbrica codificato in ciascun microcontrollore. Per trovare l'ID di ciascun dispositivo del microcontrollore, assicurati che l'hardware sia alimentato e cablato correttamente, quindi esegui: ~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0 Se vengono rilevati dispositivi CAN non inizializzati, il comando precedente riporter\u00e0 righe come le seguenti: Found canbus_uuid=11aa22bb33cc, Application: Klipper Ogni dispositivo avr\u00e0 un identificatore univoco. Nell'esempio sopra, 11aa22bb33cc \u00e8 il \"canbus_uuid\" del microcontrollore. Nota che lo strumento canbus_query.py riporter\u00e0 solo i dispositivi non inizializzati - se Klipper (o uno strumento simile) configura il dispositivo, non apparir\u00e0 pi\u00f9 nell'elenco. Configurare Klipper \u00b6 Aggiorna Klipper configurazione mcu per utilizzare il bus CAN per comunicare con il dispositivo, ad esempio: [mcu my_can_mcu] canbus_uuid: 11aa22bb33cc Modalit\u00e0 bridge da USB a CAN bus \u00b6 Some micro-controllers support selecting \"USB to CAN bus bridge\" mode during Klipper's \"make menuconfig\". This mode may allow one to use a micro-controller as both a \"USB to CAN bus adapter\" and as a Klipper node. When Klipper uses this mode the micro-controller appears as a \"USB CAN bus adapter\" under Linux. The \"Klipper bridge mcu\" itself will appear as if it was on this CAN bus - it can be identified via canbus_query.py and it must be configured like other CAN bus Klipper nodes. Alcune note importanti quando si utilizza questa modalit\u00e0: \u00c8 necessario configurare l'interfaccia can0 (o simile) in Linux per comunicare con il bus. Tuttavia, Klipper ignora la velocit\u00e0 del bus CAN di Linux e le opzioni di temporizzazione del bus CAN. Attualmente, la frequenza del bus CAN viene specificata durante \"make menuconfig\" e la velocit\u00e0 del bus specificata in Linux viene ignorata. Whenever the \"bridge mcu\" is reset, Linux will disable the corresponding can0 interface. To ensure proper handling of FIRMWARE_RESTART and RESTART commands, it is recommended to use allow-hotplug in the /etc/network/interfaces.d/can0 file. For example: allow-hotplug can0 iface can0 can static bitrate 1000000 up ifconfig $IFACE txqueuelen 128 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. 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 SHAPER_CALIBRATE test if both the XY steppers and the accelerometer all communicate via a single \"USB to CAN bus\" interface. A USB to CAN bridge board will not appear as a USB serial device, it will not show up when running ls /dev/serial/by-id , and it can not be configured in Klipper's printer.cfg file with a serial: parameter. The bridge board appears as a \"USB CAN adapter\" and it is configured in the printer.cfg as a CAN node . Tips for troubleshooting \u00b6 See the CAN bus troubleshooting document.","title":"CANBUS"},{"location":"CANBUS.html#canbus","text":"Questo documento descrive il supporto del CAN bus di Klipper.","title":"CANBUS"},{"location":"CANBUS.html#hardware-del-dispositivo","text":"Klipper currently supports CAN on stm32, SAME5x, and rp2040 chips. In addition, the micro-controller chip must be on a board that has a CAN transceiver. Per compilare per CAN, eseguire make menuconfig e selezionare \"CAN bus\" come interfaccia di comunicazione. Infine, compila il codice del microcontrollore e flashalo sulla scheda di destinazione.","title":"Hardware del dispositivo"},{"location":"CANBUS.html#hardware-host","text":"In order to use a CAN bus, it is necessary to have a host adapter. It is recommended to use a \"USB to CAN adapter\". There are many different USB to CAN adapters available from different manufacturers. When choosing one, we recommend verifying that the firmware can be updated on it. (Unfortunately, we've found some USB adapters run defective firmware and are locked down, so verify before purchasing.) Look for adapters that can run Klipper directly (in its \"USB to CAN bridge mode\") or that run the candlelight firmware . \u00c8 inoltre necessario configurare il sistema operativo host per utilizzare l'adattatore. Questo viene in genere fatto creando un nuovo file chiamato /etc/network/interfaces.d/can0 con il seguente contenuto: allow-hotplug can0 iface can0 can static bitrate 1000000 up ifconfig $IFACE txqueuelen 128","title":"Hardware Host"},{"location":"CANBUS.html#resistori-di-terminazione","text":"Un bus CAN dovrebbe avere due resistori da 120 ohm tra i cavi CANH e CANL. Idealmente, un resistore situato a ciascuna estremit\u00e0 del bus. Note that some devices have a builtin 120 ohm resistor that can not be easily removed. Some devices do not include a resistor at all. Other devices have a mechanism to select the resistor (typically by connecting a \"pin jumper\"). Be sure to check the schematics of all devices on the CAN bus to verify that there are two and only two 120 Ohm resistors on the bus. Per verificare che i resistori siano corretti, \u00e8 possibile rimuovere l'alimentazione alla stampante e utilizzare un multimetro per controllare la resistenza tra i cavi CNH e CANL: dovrebbe riportare ~60 ohm su un bus CAN cablato correttamente.","title":"Resistori di terminazione"},{"location":"CANBUS.html#trovare-canbus_uuid-per-nuovi-microcontrollori","text":"A ogni microcontrollore sul bus CAN viene assegnato un ID univoco basato sull'identificatore del chip di fabbrica codificato in ciascun microcontrollore. Per trovare l'ID di ciascun dispositivo del microcontrollore, assicurati che l'hardware sia alimentato e cablato correttamente, quindi esegui: ~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0 Se vengono rilevati dispositivi CAN non inizializzati, il comando precedente riporter\u00e0 righe come le seguenti: Found canbus_uuid=11aa22bb33cc, Application: Klipper Ogni dispositivo avr\u00e0 un identificatore univoco. Nell'esempio sopra, 11aa22bb33cc \u00e8 il \"canbus_uuid\" del microcontrollore. Nota che lo strumento canbus_query.py riporter\u00e0 solo i dispositivi non inizializzati - se Klipper (o uno strumento simile) configura il dispositivo, non apparir\u00e0 pi\u00f9 nell'elenco.","title":"Trovare canbus_uuid per nuovi microcontrollori"},{"location":"CANBUS.html#configurare-klipper","text":"Aggiorna Klipper configurazione mcu per utilizzare il bus CAN per comunicare con il dispositivo, ad esempio: [mcu my_can_mcu] canbus_uuid: 11aa22bb33cc","title":"Configurare Klipper"},{"location":"CANBUS.html#modalita-bridge-da-usb-a-can-bus","text":"Some micro-controllers support selecting \"USB to CAN bus bridge\" mode during Klipper's \"make menuconfig\". This mode may allow one to use a micro-controller as both a \"USB to CAN bus adapter\" and as a Klipper node. When Klipper uses this mode the micro-controller appears as a \"USB CAN bus adapter\" under Linux. The \"Klipper bridge mcu\" itself will appear as if it was on this CAN bus - it can be identified via canbus_query.py and it must be configured like other CAN bus Klipper nodes. Alcune note importanti quando si utilizza questa modalit\u00e0: \u00c8 necessario configurare l'interfaccia can0 (o simile) in Linux per comunicare con il bus. Tuttavia, Klipper ignora la velocit\u00e0 del bus CAN di Linux e le opzioni di temporizzazione del bus CAN. Attualmente, la frequenza del bus CAN viene specificata durante \"make menuconfig\" e la velocit\u00e0 del bus specificata in Linux viene ignorata. Whenever the \"bridge mcu\" is reset, Linux will disable the corresponding can0 interface. To ensure proper handling of FIRMWARE_RESTART and RESTART commands, it is recommended to use allow-hotplug in the /etc/network/interfaces.d/can0 file. For example: allow-hotplug can0 iface can0 can static bitrate 1000000 up ifconfig $IFACE txqueuelen 128 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. 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 SHAPER_CALIBRATE test if both the XY steppers and the accelerometer all communicate via a single \"USB to CAN bus\" interface. A USB to CAN bridge board will not appear as a USB serial device, it will not show up when running ls /dev/serial/by-id , and it can not be configured in Klipper's printer.cfg file with a serial: parameter. The bridge board appears as a \"USB CAN adapter\" and it is configured in the printer.cfg as a CAN node .","title":"Modalit\u00e0 bridge da USB a CAN bus"},{"location":"CANBUS.html#tips-for-troubleshooting","text":"See the CAN bus troubleshooting document.","title":"Tips for troubleshooting"},{"location":"CANBUS_Troubleshooting.html","text":"Risoluzione dei problemi CANBUS \u00b6 Questo documento fornisce informazioni sulla risoluzione dei problemi di comunicazione quando si utilizza Klipper with CAN bus . Verificare la connessione CAN bus \u00b6 Il primo passo nella risoluzione dei problemi di comunicazione \u00e8 verificare il cablaggio del CAN bus. Be sure there are exactly two 120 Ohm terminating resistors on the CAN bus. If the resistors are not properly installed then messages may not be able to be sent at all or the connection may have sporadic instability. The CANH and CANL bus wiring should be twisted around each other. At a minimum, the wiring should have a twist every few centimeters. Avoid twisting the CANH and CANL wiring around power wires and ensure that power wires that travel parallel to the CANH and CANL wires do not have the same amount of twists. Verify that all plugs and wire crimps on the CAN bus wiring are fully secured. Movement of the printer toolhead may jostle the CAN bus wiring causing a bad wire crimp or unsecured plug to result in intermittent communication errors. Check for incrementing bytes_invalid counter \u00b6 The Klipper log file will report a Stats line once a second when the printer is active. These \"Stats\" lines will have a bytes_invalid counter for each micro-controller. This counter should not increment during normal printer operation (it is normal for the counter to be non-zero after a RESTART and it is not a concern if the counter increments once a month or so). If this counter increments on a CAN bus micro-controller during normal printing (it increments every few hours or more frequently) then it is an indication of a severe problem. Incrementing bytes_invalid on a CAN bus connection is a symptom of reordered messages on the CAN bus. There are two known causes of reordered messages: Old versions of the popular candlight_firmware for USB CAN adapters had a bug that could cause reordered messages. If using a USB CAN adapter running this firmware then make sure to update to the latest firmware if incrementing bytes_invalid is observed. Some Linux kernel builds for embedded devices have been known to reorder CAN bus messages. It may be necessary to use an alternative Linux kernel or to use alternative hardware that supports mainstream Linux kernels that do not exhibit this problem. Reordered messages is a severe problem that must be fixed. It will result in unstable behavior and can lead to confusing errors at any part of a print. Obtaining candump logs \u00b6 The CAN bus messages sent to and from the micro-controller are handled by the Linux kernel. It is possible to capture these messages from the kernel for debugging purposes. A log of these messages may be of use in diagnostics. The Linux can-utils tool provides the capture software. It is typically installed on a machine by running: sudo apt-get update && sudo apt-get install can-utils Once installed, one may obtain a capture of all CAN bus messages on an interface with the following command: candump -tz -Ddex can0,#FFFFFFFF > mycanlog One can view the resulting log file ( mycanlog in the example above) to see each raw CAN bus message that was sent and received by Klipper. Understanding the content of these messages will likely require low-level knowledge of Klipper's CANBUS protocol and Klipper's MCU commands . Parsing Klipper messages in a candump log \u00b6 One may use the parsecandump.py tool to parse the low-level Klipper micro-controller messages contained in a candump log. Using this tool is an advanced topic that requires knowledge of Klipper MCU commands . For example: ./scripts/parsecandump.py mycanlog 108 ./out/klipper.dict This tool produces output similar to the parsedump tool . See the documentation for that tool for information on generating the Klipper micro-controller data dictionary. In the above example, 108 is the CAN bus id . It is a hexadecimal number. The id 108 is assigned by Klipper to the first micro-controller. If the CAN bus has multiple micro-controllers on it, then the second micro-controller would be 10a , the third would be 10c , and so on. The candump log must be produced using the -tz -Ddex command-line arguments (for example: candump -tz -Ddex can0,#FFFFFFFF ) in order to use the parsecandump.py tool. Using a logic analyzer on the canbus wiring \u00b6 The Sigrok Pulseview software along with a low-cost logic analyzer can be useful for diagnosing CAN bus signaling. This is an advanced topic likely only of interest to experts. One can often find \"USB logic analyzers\" for under $15 (US pricing as of 2023). These devices are often listed as \"Saleae logic clones\" or as \"24MHz 8 channel USB logic analyzers\". The above picture was taken while using Pulseview with a \"Saleae clone\" logic analyzer. The Sigrok and Pulseview software was installed on a desktop machine (also install the \"fx2lafw\" firmware if that is packaged separately). The CH0 pin on the logic analyzer was routed to the CAN Rx line, the CH1 pin was wired to the CAN Tx pin, and GND was wired to GND. Pulseview was configured to only display the D0 and D1 lines (red \"probe\" icon center top toolbar). The number of samples was set to 5 million (top toolbar) and the sample rate was set to 24Mhz (top toolbar). The CAN decoder was added (yellow and green \"bubble icon\" right top toolbar). The D0 channel was labeled as RX and set to trigger on a falling edge (click on black D0 label at left). The D1 channel was labeled as TX (click on brown D1 label at left). The CAN decoder was configured for 1Mbit rate (click on green CAN label at left). The CAN decoder was moved to the top of the display (click and drag green CAN label). Finally, the capture was started (click \"Run\" at top left) and a packet was transmitted on the CAN bus ( cansend can0 123#121212121212 ). The logic analyzer provides an independent tool for capturing packets and verifying bit timing.","title":"Risoluzione dei problemi CANBUS"},{"location":"CANBUS_Troubleshooting.html#risoluzione-dei-problemi-canbus","text":"Questo documento fornisce informazioni sulla risoluzione dei problemi di comunicazione quando si utilizza Klipper with CAN bus .","title":"Risoluzione dei problemi CANBUS"},{"location":"CANBUS_Troubleshooting.html#verificare-la-connessione-can-bus","text":"Il primo passo nella risoluzione dei problemi di comunicazione \u00e8 verificare il cablaggio del CAN bus. Be sure there are exactly two 120 Ohm terminating resistors on the CAN bus. If the resistors are not properly installed then messages may not be able to be sent at all or the connection may have sporadic instability. The CANH and CANL bus wiring should be twisted around each other. At a minimum, the wiring should have a twist every few centimeters. Avoid twisting the CANH and CANL wiring around power wires and ensure that power wires that travel parallel to the CANH and CANL wires do not have the same amount of twists. Verify that all plugs and wire crimps on the CAN bus wiring are fully secured. Movement of the printer toolhead may jostle the CAN bus wiring causing a bad wire crimp or unsecured plug to result in intermittent communication errors.","title":"Verificare la connessione CAN bus"},{"location":"CANBUS_Troubleshooting.html#check-for-incrementing-bytes_invalid-counter","text":"The Klipper log file will report a Stats line once a second when the printer is active. These \"Stats\" lines will have a bytes_invalid counter for each micro-controller. This counter should not increment during normal printer operation (it is normal for the counter to be non-zero after a RESTART and it is not a concern if the counter increments once a month or so). If this counter increments on a CAN bus micro-controller during normal printing (it increments every few hours or more frequently) then it is an indication of a severe problem. Incrementing bytes_invalid on a CAN bus connection is a symptom of reordered messages on the CAN bus. There are two known causes of reordered messages: Old versions of the popular candlight_firmware for USB CAN adapters had a bug that could cause reordered messages. If using a USB CAN adapter running this firmware then make sure to update to the latest firmware if incrementing bytes_invalid is observed. Some Linux kernel builds for embedded devices have been known to reorder CAN bus messages. It may be necessary to use an alternative Linux kernel or to use alternative hardware that supports mainstream Linux kernels that do not exhibit this problem. Reordered messages is a severe problem that must be fixed. It will result in unstable behavior and can lead to confusing errors at any part of a print.","title":"Check for incrementing bytes_invalid counter"},{"location":"CANBUS_Troubleshooting.html#obtaining-candump-logs","text":"The CAN bus messages sent to and from the micro-controller are handled by the Linux kernel. It is possible to capture these messages from the kernel for debugging purposes. A log of these messages may be of use in diagnostics. The Linux can-utils tool provides the capture software. It is typically installed on a machine by running: sudo apt-get update && sudo apt-get install can-utils Once installed, one may obtain a capture of all CAN bus messages on an interface with the following command: candump -tz -Ddex can0,#FFFFFFFF > mycanlog One can view the resulting log file ( mycanlog in the example above) to see each raw CAN bus message that was sent and received by Klipper. Understanding the content of these messages will likely require low-level knowledge of Klipper's CANBUS protocol and Klipper's MCU commands .","title":"Obtaining candump logs"},{"location":"CANBUS_Troubleshooting.html#parsing-klipper-messages-in-a-candump-log","text":"One may use the parsecandump.py tool to parse the low-level Klipper micro-controller messages contained in a candump log. Using this tool is an advanced topic that requires knowledge of Klipper MCU commands . For example: ./scripts/parsecandump.py mycanlog 108 ./out/klipper.dict This tool produces output similar to the parsedump tool . See the documentation for that tool for information on generating the Klipper micro-controller data dictionary. In the above example, 108 is the CAN bus id . It is a hexadecimal number. The id 108 is assigned by Klipper to the first micro-controller. If the CAN bus has multiple micro-controllers on it, then the second micro-controller would be 10a , the third would be 10c , and so on. The candump log must be produced using the -tz -Ddex command-line arguments (for example: candump -tz -Ddex can0,#FFFFFFFF ) in order to use the parsecandump.py tool.","title":"Parsing Klipper messages in a candump log"},{"location":"CANBUS_Troubleshooting.html#using-a-logic-analyzer-on-the-canbus-wiring","text":"The Sigrok Pulseview software along with a low-cost logic analyzer can be useful for diagnosing CAN bus signaling. This is an advanced topic likely only of interest to experts. One can often find \"USB logic analyzers\" for under $15 (US pricing as of 2023). These devices are often listed as \"Saleae logic clones\" or as \"24MHz 8 channel USB logic analyzers\". The above picture was taken while using Pulseview with a \"Saleae clone\" logic analyzer. The Sigrok and Pulseview software was installed on a desktop machine (also install the \"fx2lafw\" firmware if that is packaged separately). The CH0 pin on the logic analyzer was routed to the CAN Rx line, the CH1 pin was wired to the CAN Tx pin, and GND was wired to GND. Pulseview was configured to only display the D0 and D1 lines (red \"probe\" icon center top toolbar). The number of samples was set to 5 million (top toolbar) and the sample rate was set to 24Mhz (top toolbar). The CAN decoder was added (yellow and green \"bubble icon\" right top toolbar). The D0 channel was labeled as RX and set to trigger on a falling edge (click on black D0 label at left). The D1 channel was labeled as TX (click on brown D1 label at left). The CAN decoder was configured for 1Mbit rate (click on green CAN label at left). The CAN decoder was moved to the top of the display (click and drag green CAN label). Finally, the capture was started (click \"Run\" at top left) and a packet was transmitted on the CAN bus ( cansend can0 123#121212121212 ). The logic analyzer provides an independent tool for capturing packets and verifying bit timing.","title":"Using a logic analyzer on the canbus wiring"},{"location":"CANBUS_protocol.html","text":"Protocollo CANBUS \u00b6 Questo documento descrive il protocollo utilizzato da Klipper per comunicare su CAN bus . Vedere per informazioni sulla configurazione di Klipper con CANBUS. Assegnazione dell'id del microcontrollore \u00b6 Klipper utilizza solo pacchetti CAN bus di dimensioni standard CAN 2.0A, che sono limitati a 8 byte di dati e un identificatore bus CAN a 11 bit. Per supportare una comunicazione efficiente, a ogni microcontrollore viene assegnato in fase di esecuzione un ID nodo bus CAN univoco a 1 byte (\"canbus_nodeid\") per il traffico generale di comandi e risposte Klipper. I messaggi di comando di Klipper che vanno dall'host al microcontrollore utilizzano l'ID bus CAN di canbus_nodeid * 2 + 256 , mentre i messaggi di risposta di Klipper dal microcontrollore all'host usano canbus_nodeid * 2 + 256 + 1 . Ogni microcontrollore ha un identificatore di chip univoco assegnato in fabbrica che viene utilizzato durante l'assegnazione dell'ID. Questo identificatore pu\u00f2 superare la lunghezza di un pacchetto CAN, quindi una funzione hash viene utilizzata per generare un ID univoco a 6 byte ( canbus_uuid ) dall'ID di fabbrica. Messaggi dell'amministratore \u00b6 I messaggi dell'amministratore vengono utilizzati per l'assegnazione dell'ID. I messaggi di amministrazione inviati dall'host al microcontrollore utilizzano l'ID bus CAN \"0x3f0\" e i messaggi inviati dal microcontrollore all'host utilizzano l'ID bus CAN \"0x3f1\". Tutti i microcontrollori ascoltano i messaggi sull'id 0x3f0 ; quell'ID pu\u00f2 essere considerato un \"indirizzo di trasmissione\". messaggio CMD_QUERY_UNASSIGNED \u00b6 Questo comando interroga tutti i microcontrollori a cui non \u00e8 stato ancora assegnato un canbus_nodeid . I microcontrollori non assegnati risponderanno con un messaggio di risposta RESP_NEED_NODEID. Il formato del messaggio CMD_QUERY_UNASSIGNED \u00e8: <1 byte message_id = 0x00> CMD_SET_KLIPPER_NODEID messaggio \u00b6 Questo comando assegna un canbus_nodeid al microcontrollore con un dato canbus_uuid . Il formato del messaggio CMD_SET_KLIPPER_NODEID \u00e8: <1-byte message_id = 0x01><6-byte canbus_uuid><1-byte canbus_nodeid> Messaggio RESP_NEED_NODEID \u00b6 Il formato del messaggio RESP_NEED_NODEID \u00e8: <1-byte message_id = 0x20><6-byte canbus_uuid><1-byte set_klipper_nodeid = 0x01> Pacchetti dati \u00b6 Un microcontrollore a cui \u00e8 stato assegnato un nodeid tramite il comando CMD_SET_KLIPPER_NODEID pu\u00f2 inviare e ricevere pacchetti di dati. I dati del pacchetto nei messaggi che utilizzano l'ID bus CAN di ricezione del nodo ( canbus_nodeid * 2 + 256 ) vengono semplicemente aggiunti a un buffer e quando viene trovato un mcu protocol message completo, il suo contenuto viene analizzato ed elaborato . I dati vengono trattati come un flusso di byte: non \u00e8 necessario che l'inizio di un blocco di messaggi Klipper sia allineato con l'inizio di un pacchetto bus CAN. Allo stesso modo, le risposte ai messaggi del protocollo mcu vengono inviate dal microcontrollore all'host copiando i dati del messaggio in uno o pi\u00f9 pacchetti con l'ID del bus CAN di trasmissione del nodo ( canbus_nodeid * 2 + 256 + 1 ).","title":"Protocollo CANBUS"},{"location":"CANBUS_protocol.html#protocollo-canbus","text":"Questo documento descrive il protocollo utilizzato da Klipper per comunicare su CAN bus . Vedere per informazioni sulla configurazione di Klipper con CANBUS.","title":"Protocollo CANBUS"},{"location":"CANBUS_protocol.html#assegnazione-dellid-del-microcontrollore","text":"Klipper utilizza solo pacchetti CAN bus di dimensioni standard CAN 2.0A, che sono limitati a 8 byte di dati e un identificatore bus CAN a 11 bit. Per supportare una comunicazione efficiente, a ogni microcontrollore viene assegnato in fase di esecuzione un ID nodo bus CAN univoco a 1 byte (\"canbus_nodeid\") per il traffico generale di comandi e risposte Klipper. I messaggi di comando di Klipper che vanno dall'host al microcontrollore utilizzano l'ID bus CAN di canbus_nodeid * 2 + 256 , mentre i messaggi di risposta di Klipper dal microcontrollore all'host usano canbus_nodeid * 2 + 256 + 1 . Ogni microcontrollore ha un identificatore di chip univoco assegnato in fabbrica che viene utilizzato durante l'assegnazione dell'ID. Questo identificatore pu\u00f2 superare la lunghezza di un pacchetto CAN, quindi una funzione hash viene utilizzata per generare un ID univoco a 6 byte ( canbus_uuid ) dall'ID di fabbrica.","title":"Assegnazione dell'id del microcontrollore"},{"location":"CANBUS_protocol.html#messaggi-dellamministratore","text":"I messaggi dell'amministratore vengono utilizzati per l'assegnazione dell'ID. I messaggi di amministrazione inviati dall'host al microcontrollore utilizzano l'ID bus CAN \"0x3f0\" e i messaggi inviati dal microcontrollore all'host utilizzano l'ID bus CAN \"0x3f1\". Tutti i microcontrollori ascoltano i messaggi sull'id 0x3f0 ; quell'ID pu\u00f2 essere considerato un \"indirizzo di trasmissione\".","title":"Messaggi dell'amministratore"},{"location":"CANBUS_protocol.html#messaggio-cmd_query_unassigned","text":"Questo comando interroga tutti i microcontrollori a cui non \u00e8 stato ancora assegnato un canbus_nodeid . I microcontrollori non assegnati risponderanno con un messaggio di risposta RESP_NEED_NODEID. Il formato del messaggio CMD_QUERY_UNASSIGNED \u00e8: <1 byte message_id = 0x00>","title":"messaggio CMD_QUERY_UNASSIGNED"},{"location":"CANBUS_protocol.html#cmd_set_klipper_nodeid-messaggio","text":"Questo comando assegna un canbus_nodeid al microcontrollore con un dato canbus_uuid . Il formato del messaggio CMD_SET_KLIPPER_NODEID \u00e8: <1-byte message_id = 0x01><6-byte canbus_uuid><1-byte canbus_nodeid>","title":"CMD_SET_KLIPPER_NODEID messaggio"},{"location":"CANBUS_protocol.html#messaggio-resp_need_nodeid","text":"Il formato del messaggio RESP_NEED_NODEID \u00e8: <1-byte message_id = 0x20><6-byte canbus_uuid><1-byte set_klipper_nodeid = 0x01>","title":"Messaggio RESP_NEED_NODEID"},{"location":"CANBUS_protocol.html#pacchetti-dati","text":"Un microcontrollore a cui \u00e8 stato assegnato un nodeid tramite il comando CMD_SET_KLIPPER_NODEID pu\u00f2 inviare e ricevere pacchetti di dati. I dati del pacchetto nei messaggi che utilizzano l'ID bus CAN di ricezione del nodo ( canbus_nodeid * 2 + 256 ) vengono semplicemente aggiunti a un buffer e quando viene trovato un mcu protocol message completo, il suo contenuto viene analizzato ed elaborato . I dati vengono trattati come un flusso di byte: non \u00e8 necessario che l'inizio di un blocco di messaggi Klipper sia allineato con l'inizio di un pacchetto bus CAN. Allo stesso modo, le risposte ai messaggi del protocollo mcu vengono inviate dal microcontrollore all'host copiando i dati del messaggio in uno o pi\u00f9 pacchetti con l'ID del bus CAN di trasmissione del nodo ( canbus_nodeid * 2 + 256 + 1 ).","title":"Pacchetti dati"},{"location":"CONTRIBUTING.html","text":"Contribuire a Klipper \u00b6 Grazie per aver contribuito a Klipper! Questo documento descrive il processo per contribuire alle modifiche di Klipper. Consulta la contact page per informazioni sulla segnalazione di un problema o per i dettagli su come contattare gli sviluppatori. Panoramica del processo di contribuzione \u00b6 I contributi a Klipper seguono generalmente un processo di alto livello: Inizia creando una Richiesta pull GitHub quando un proposta \u00e8 pronta per la diffusione. Quando un reviewer \u00e8 disponibile per review l'invio, si assegner\u00e0 la richiesta pull su GitHub. L'obiettivo della revisione \u00e8 cercare i difetti e verificare che la proposta segua linee guida documentate. Dopo una revisione riuscita, il revisore \"approver\u00e0 la revisione\" su GitHub e un maintainer eseguir\u00e0 il commit della modifica al ramo principale di Klipper. Quando lavori sui miglioramenti, considera di iniziare (o contribuire a) un argomento su Klipper Discourse . Una discussione in corso sul forum pu\u00f2 migliorare la visibilit\u00e0 del lavoro di sviluppo e pu\u00f2 attirare altri interessati a testare nuovi lavori. Cosa aspettarsi da una revisione \u00b6 I contributi a Klipper vengono rivisti prima del merging. L'obiettivo principale del processo di revisione \u00e8 verificare la presenza di difetti e verificare che la presentazione segua le linee guida specificate nella documentazione di Klipper. Resta inteso che ci sono molti modi per portare a termine un compito; non \u00e8 intenzione della revisione discutere la \"migliore\" implementazione. Ove possibile, sono preferibili discussioni di revisione incentrate su fatti e misurazioni. La maggior parte degli invii otterr\u00e0 in feedback da una recensione. Preparati a ottenere feedback, fornire ulteriori dettagli e aggiornare l'invio, se necessario. Cose comuni che un revisore cercher\u00e0: L'invio \u00e8 privo di difetti ed \u00e8 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\u00e0 degli invii \u00e8 quindi considerata una priorit\u00e0. Il repository GitHub principale Klipper3d/klipper non accetta lavori sperimentali. I realizzatori di contributi devono eseguire la sperimentazione, il debug e il test nei propri repository. Il server Klipper Discourse \u00e8 un buon posto per aumentare la consapevolezza del nuovo lavoro e per trovare utenti interessati a fornire feedback nel mondo reale. Gli invii devono superare tutti i test di regressione . 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. Gli contributi di codice non devono contenere codice di debug eccessivo, opzioni di debug o registrazione del debug in fase di runtime. I commenti negli invii di codice dovrebbero concentrarsi sul miglioramento della manutenzione del codice. Gli invii non devono contenere \"codice commentato\" n\u00e9 commenti eccessivi che descrivono implementazioni passate. Non dovrebbero esserci commenti \"todo\" eccessivi. Gli aggiornamenti alla documentazione non devono dichiarare che si tratta di un \"work in progress\". L'invio fornisce un vantaggio \"ad alto impatto\" per gli utenti del mondo reale che svolgono attivit\u00e0 nel mondo reale?I revisori devono identificare, almeno nella loro mente, approssimativamente \"chi \u00e8 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\u00e0 ovvio sia per il mittente che per il revisore e non \u00e8 esplicitamente dichiarato durante una revisione. 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. 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 \u00e8 una parte naturale di una revisione. Quando si discute dei benefici \u00e8 preferibile discutere di \"fatti e misurazioni\". In generale, i revisori non cercano risposte del modulo \"qualcuno potrebbe trovare utile l'opzione X\", n\u00e9 cercano risposte del modulo \"questo invio aggiunge una funzionalit\u00e0 implementata dal firmware X\". Invece, \u00e8 generalmente preferibile discutere i dettagli su come \u00e8 stato misurato il miglioramento della qualit\u00e0 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 \u00e8 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\u00f9 importanti di Klipper hanno richiesto mesi di discussioni, rielaborazioni, test e documentazione prima di essere fuse nel ramo principale. Tutti i nuovi moduli, opzioni di configurazione, comandi, parametri di comando e documenti dovrebbero avere un \"impatto elevato\". Non vogliamo appesantire gli utenti con opzioni che non possono configurare ragionevolmente n\u00e9 vogliamo appesantirli con opzioni che non forniscono un vantaggio notevole. Un revisore pu\u00f2 chiedere chiarimenti su come un utente deve configurare un'opzione - una risposta ideale conterr\u00e0 dettagli sul processo - ad esempio, \"gli utenti del MegaX500 dovrebbero impostare l'opzione X su 99,3 mentre gli utenti dell'Elite100Y dovrebbero calibrare l'opzione X usando la procedura ...\". Se l'obiettivo di un'opzione \u00e8 rendere il codice pi\u00f9 modulare, \u00e8 preferibile utilizzare le costanti del codice invece delle opzioni di configurazione rivolte all'utente. Nuovi moduli, nuove opzioni e nuovi parametri non dovrebbero fornire funzionalit\u00e0 simili ai moduli esistenti: se le differenze sono arbitrarie, \u00e8 preferibile utilizzare il sistema esistente o effettuare refactoring del codice esistente. Il copyright dell'invio \u00e8 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. \u00c8 sconsigliato dichiarare un copyright su un file esistente quando si apportano modifiche minori a quel file. 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 lib/ (e seguire il formato descritto in lib/README ). I mittenti devono fornire una Signed-off-line utilizzando il loro vero nome completo. Indica che il mittente \u00e8 d'accordo con il developer certificate of origin . L'invio segue le linee guida specificate nella documentazione di Klipper?In particolare, il codice deve seguire le linee guida in e i file di configurazione devono seguire le linee guida in . La documentazione di Klipper \u00e8 aggiornata per riflettere le nuove modifiche?Come minimo, la documentazione di riferimento deve essere aggiornata con le relative modifiche al codice: Tutti i comandi e i relativi parametri devono essere documentati in . Tutti i moduli rivolti all'utente e i relativi parametri di configurazione devono essere documentati in . Tutte le \"variabili di stato\" esportate devono essere documentate in . Tutti i nuovi \"webhook\" e i relativi parametri devono essere documentati in . 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 . I nuovi documenti dovrebbero essere aggiunti a e all'indice del sito web docs/_klipper3d/mkdocs.yml . I commit sono ben formati, affrontano un singolo argomento per commit e sono indipendenti?I messaggi di commit devono seguire il formato preferito . 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 \u00e8 necessario che i propositori uniscano nuovamente il loro invio ad ogni aggiornamento al repository principale di Klipper. Tuttavia, se c'\u00e8 un conflitto in fase di merge, si consiglia ai mittenti di usare git rebase per risolvere il conflitto. Ogni commit dovrebbe affrontare una singola modifica di alto livello. Le modifiche di grandi dimensioni dovrebbero essere suddivise in pi\u00f9 commit indipendenti. Ogni commit dovrebbe \"stare in piedi da solo\" in modo che strumenti come git bisect e git revert funzionino in modo affidabile. 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. Klipper non implementa una rigida \"guida allo stile di codifica\", ma le modifiche al codice esistente dovrebbero seguire il flusso di codice di alto livello, lo stile di indentazione del codice e il formato di quel codice esistente. Gli invii di nuovi moduli e sistemi hanno una maggiore flessibilit\u00e0 nello stile di codifica, ma \u00e8 preferibile che il nuovo codice segua uno stile internamente coerente e generalmente segua le norme di codifica. Non \u00e8 un obiettivo di una revisione discutere di \"migliori implementazioni\". Tuttavia, se un revisore ha difficolt\u00e0 a comprendere l'implementazione di un invio, pu\u00f2 richiedere modifiche per rendere l'implementazione pi\u00f9 trasparente. In particolare, se i revisori non riescono a convincersi che un contributo \u00e8 privo di difetti, potrebbero essere necessarie modifiche. Come parte di una revisione, un revisore pu\u00f2 creare una richiesta pull alternativa per un argomento. Questo pu\u00f2 essere fatto per evitare eccessivi \"avanti e indietro\" su elementi procedurali minori e quindi snellire il processo di proposta. Pu\u00f2 anche essere fatto perch\u00e9 la discussione ispira un revisore a costruire un'implementazione alternativa. Entrambe le situazioni sono il normale risultato di una revisione e non devono essere considerate critiche alla proposta originale. Aiutare con le revisioni \u00b6 Apprezziamo l'aiuto con le recensioni! Non \u00e8 necessario essere un revisore elencato per eseguire una revisione. I propositori di richieste pull di GitHub sono inoltre incoraggiati a rivedere i propri invii. Per aiutare con una revisione, segui i passaggi descritti in cosa aspettarsi in una revisione per verificare l'invio. Dopo aver completato la revisione, aggiungi un commento alla richiesta pull di GitHub con i tuoi risultati. Se l'invio supera la revisione, si prega di dichiararlo esplicitamente nel commento, ad esempio qualcosa del tipo \"Ho esaminato questa modifica in base ai passaggi del documento CONTRIBUTING e tutto mi sembra a posto\". Se non \u00e8 possibile completare alcuni passaggi della revisione, indicare esplicitamente quali passaggi sono stati rivisti e quali non sono stati rivisti, ad esempio qualcosa del tipo \"Non ho verificato la presenza di difetti nel codice, ma ho rivisto tutto il resto nel documento CONTRIBUTING e sembra buono\". Apprezziamo anche il test degli invii. Se il codice \u00e8 stato testato, aggiungi un commento alla richiesta pull di GitHub con i risultati del tuo test: successo o fallimento. Si prega di affermare esplicitamente che il codice \u00e8 stato testato e i risultati, ad esempio qualcosa del tipo \"Ho testato questo codice sulla mia stampante Acme900Z con una stampa a vaso e i risultati sono stati buoni\". Revisori \u00b6 I \"revisori\" di Klipper sono: Nome GitHub Id Aree di interesse Dmitry Butyugin @dmbutyugin Input shaping, test di risonanza, cinematica Eric Callahan @Arksine Livellamento del piatto, flashing MCU James Hartley @JamesH1978 File di configurazione Kevin O'Connor @KevinOConnor Core motion system, codice microcontrollore Si prega di non eseguire il \"ping\" di nessuno dei revisori e di non indirizzare gli invii a loro. Tutti i revisori controllano i forum e le PR e si occuperanno delle revisioni quando ne avranno il tempo. I \"manutentori\" di Klipper sono: Nome nome GitHub Kevin O'Connor @KevinOConnor Formato dei messaggi di commit \u00b6 Ogni commit dovrebbe avere un messaggio di commit formattato in modo simile al seguente: modulo: Riepilogo breve (50 caratteri o meno) in maiuscolo Testo esplicativo pi\u00f9 dettagliato, se necessario. Incolonna a circa 75 caratteri o gi\u00f9 di l\u00ec. In alcuni contesti, la prima riga \u00e8 trattata come l'oggetto di un'e-mail e il resto del testo come corpo. La riga vuota che separa il riassunto dal corpo \u00e8 critica (a meno che non si ometta del tutto il corpo); strumenti come rebase possono confondersi se li metti due insieme. Ulteriori paragrafi vengono dopo le righe vuote.. Firmato da: Il mio nome Nell'esempio sopra, module dovrebbe essere il nome di un file o di una directory nel repository (senza un'estensione di file). Ad esempio, clocksync: fix di errore di battitura nella chiamata pause() al momento della connessione . Lo scopo di specificare un nome di modulo nel messaggio di commit \u00e8 di aiutare a fornire il contesto per i commenti di commit. \u00c8 importante avere una riga \"Signed-off-by\" su ogni commit - certifica che accetti il developer certificate of origin . Deve contenere il tuo vero nome (mi dispiace, niente pseudonimi o contributi anonimi) e contenere un indirizzo email corrente. Contribuire a Traduzioni Klipper \u00b6 Klipper-translations Project \u00e8 un progetto dedicato alla traduzione di Klipper in diverse lingue. Weblate ospita tutte le stringhe Gettext per la traduzione e la revisione. Le impostazioni locali possono essere visualizzate su klipper3d.org una volta che soddisfano i seguenti requisiti: 75% Copertura totale Tutti i titoli (H1) sono tradotti Una gerarchia di navigazione PR aggiornata nelle traduzioni klipper. Per ridurre la frustrazione di tradurre termini specifici del dominio e acquisire consapevolezza delle traduzioni in corso, puoi inviare un PR modificando il Klipper-translations Project readme.md . Una volta che una traduzione \u00e8 pronta, \u00e8 possibile apportare la modifica corrispondente al progetto Klipper. Se una traduzione esiste gi\u00e0 nel repository Klipper e non soddisfa pi\u00f9 l'elenco di controllo di cui sopra, verr\u00e0 contrassegnata come obsoleta dopo un mese senza aggiornamenti. Una volta soddisfatti i requisiti, \u00e8 necessario: aggiorna il repository di klipper-translations active_translations Opzionale: aggiungi un file manual-index.md nella cartella docs\\locals\\ del repository klipper-translations per sostituire index.md specifico della lingua (il file index.md generato non viene visualizzato correttamente). Problemi noti: Al momento, non esiste un metodo per tradurre correttamente le immagini nella documentazione \u00c8 impossibile tradurre i titoli in mkdocs.yml.","title":"Contribuire a Klipper"},{"location":"CONTRIBUTING.html#contribuire-a-klipper","text":"Grazie per aver contribuito a Klipper! Questo documento descrive il processo per contribuire alle modifiche di Klipper. Consulta la contact page per informazioni sulla segnalazione di un problema o per i dettagli su come contattare gli sviluppatori.","title":"Contribuire a Klipper"},{"location":"CONTRIBUTING.html#panoramica-del-processo-di-contribuzione","text":"I contributi a Klipper seguono generalmente un processo di alto livello: Inizia creando una Richiesta pull GitHub quando un proposta \u00e8 pronta per la diffusione. Quando un reviewer \u00e8 disponibile per review l'invio, si assegner\u00e0 la richiesta pull su GitHub. L'obiettivo della revisione \u00e8 cercare i difetti e verificare che la proposta segua linee guida documentate. Dopo una revisione riuscita, il revisore \"approver\u00e0 la revisione\" su GitHub e un maintainer eseguir\u00e0 il commit della modifica al ramo principale di Klipper. Quando lavori sui miglioramenti, considera di iniziare (o contribuire a) un argomento su Klipper Discourse . Una discussione in corso sul forum pu\u00f2 migliorare la visibilit\u00e0 del lavoro di sviluppo e pu\u00f2 attirare altri interessati a testare nuovi lavori.","title":"Panoramica del processo di contribuzione"},{"location":"CONTRIBUTING.html#cosa-aspettarsi-da-una-revisione","text":"I contributi a Klipper vengono rivisti prima del merging. L'obiettivo principale del processo di revisione \u00e8 verificare la presenza di difetti e verificare che la presentazione segua le linee guida specificate nella documentazione di Klipper. Resta inteso che ci sono molti modi per portare a termine un compito; non \u00e8 intenzione della revisione discutere la \"migliore\" implementazione. Ove possibile, sono preferibili discussioni di revisione incentrate su fatti e misurazioni. La maggior parte degli invii otterr\u00e0 in feedback da una recensione. Preparati a ottenere feedback, fornire ulteriori dettagli e aggiornare l'invio, se necessario. Cose comuni che un revisore cercher\u00e0: L'invio \u00e8 privo di difetti ed \u00e8 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\u00e0 degli invii \u00e8 quindi considerata una priorit\u00e0. Il repository GitHub principale Klipper3d/klipper non accetta lavori sperimentali. I realizzatori di contributi devono eseguire la sperimentazione, il debug e il test nei propri repository. Il server Klipper Discourse \u00e8 un buon posto per aumentare la consapevolezza del nuovo lavoro e per trovare utenti interessati a fornire feedback nel mondo reale. Gli invii devono superare tutti i test di regressione . 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. Gli contributi di codice non devono contenere codice di debug eccessivo, opzioni di debug o registrazione del debug in fase di runtime. I commenti negli invii di codice dovrebbero concentrarsi sul miglioramento della manutenzione del codice. Gli invii non devono contenere \"codice commentato\" n\u00e9 commenti eccessivi che descrivono implementazioni passate. Non dovrebbero esserci commenti \"todo\" eccessivi. Gli aggiornamenti alla documentazione non devono dichiarare che si tratta di un \"work in progress\". L'invio fornisce un vantaggio \"ad alto impatto\" per gli utenti del mondo reale che svolgono attivit\u00e0 nel mondo reale?I revisori devono identificare, almeno nella loro mente, approssimativamente \"chi \u00e8 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\u00e0 ovvio sia per il mittente che per il revisore e non \u00e8 esplicitamente dichiarato durante una revisione. 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. 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 \u00e8 una parte naturale di una revisione. Quando si discute dei benefici \u00e8 preferibile discutere di \"fatti e misurazioni\". In generale, i revisori non cercano risposte del modulo \"qualcuno potrebbe trovare utile l'opzione X\", n\u00e9 cercano risposte del modulo \"questo invio aggiunge una funzionalit\u00e0 implementata dal firmware X\". Invece, \u00e8 generalmente preferibile discutere i dettagli su come \u00e8 stato misurato il miglioramento della qualit\u00e0 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 \u00e8 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\u00f9 importanti di Klipper hanno richiesto mesi di discussioni, rielaborazioni, test e documentazione prima di essere fuse nel ramo principale. Tutti i nuovi moduli, opzioni di configurazione, comandi, parametri di comando e documenti dovrebbero avere un \"impatto elevato\". Non vogliamo appesantire gli utenti con opzioni che non possono configurare ragionevolmente n\u00e9 vogliamo appesantirli con opzioni che non forniscono un vantaggio notevole. Un revisore pu\u00f2 chiedere chiarimenti su come un utente deve configurare un'opzione - una risposta ideale conterr\u00e0 dettagli sul processo - ad esempio, \"gli utenti del MegaX500 dovrebbero impostare l'opzione X su 99,3 mentre gli utenti dell'Elite100Y dovrebbero calibrare l'opzione X usando la procedura ...\". Se l'obiettivo di un'opzione \u00e8 rendere il codice pi\u00f9 modulare, \u00e8 preferibile utilizzare le costanti del codice invece delle opzioni di configurazione rivolte all'utente. Nuovi moduli, nuove opzioni e nuovi parametri non dovrebbero fornire funzionalit\u00e0 simili ai moduli esistenti: se le differenze sono arbitrarie, \u00e8 preferibile utilizzare il sistema esistente o effettuare refactoring del codice esistente. Il copyright dell'invio \u00e8 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. \u00c8 sconsigliato dichiarare un copyright su un file esistente quando si apportano modifiche minori a quel file. 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 lib/ (e seguire il formato descritto in lib/README ). I mittenti devono fornire una Signed-off-line utilizzando il loro vero nome completo. Indica che il mittente \u00e8 d'accordo con il developer certificate of origin . L'invio segue le linee guida specificate nella documentazione di Klipper?In particolare, il codice deve seguire le linee guida in e i file di configurazione devono seguire le linee guida in . La documentazione di Klipper \u00e8 aggiornata per riflettere le nuove modifiche?Come minimo, la documentazione di riferimento deve essere aggiornata con le relative modifiche al codice: Tutti i comandi e i relativi parametri devono essere documentati in . Tutti i moduli rivolti all'utente e i relativi parametri di configurazione devono essere documentati in . Tutte le \"variabili di stato\" esportate devono essere documentate in . Tutti i nuovi \"webhook\" e i relativi parametri devono essere documentati in . 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 . I nuovi documenti dovrebbero essere aggiunti a e all'indice del sito web docs/_klipper3d/mkdocs.yml . I commit sono ben formati, affrontano un singolo argomento per commit e sono indipendenti?I messaggi di commit devono seguire il formato preferito . 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 \u00e8 necessario che i propositori uniscano nuovamente il loro invio ad ogni aggiornamento al repository principale di Klipper. Tuttavia, se c'\u00e8 un conflitto in fase di merge, si consiglia ai mittenti di usare git rebase per risolvere il conflitto. Ogni commit dovrebbe affrontare una singola modifica di alto livello. Le modifiche di grandi dimensioni dovrebbero essere suddivise in pi\u00f9 commit indipendenti. Ogni commit dovrebbe \"stare in piedi da solo\" in modo che strumenti come git bisect e git revert funzionino in modo affidabile. 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. Klipper non implementa una rigida \"guida allo stile di codifica\", ma le modifiche al codice esistente dovrebbero seguire il flusso di codice di alto livello, lo stile di indentazione del codice e il formato di quel codice esistente. Gli invii di nuovi moduli e sistemi hanno una maggiore flessibilit\u00e0 nello stile di codifica, ma \u00e8 preferibile che il nuovo codice segua uno stile internamente coerente e generalmente segua le norme di codifica. Non \u00e8 un obiettivo di una revisione discutere di \"migliori implementazioni\". Tuttavia, se un revisore ha difficolt\u00e0 a comprendere l'implementazione di un invio, pu\u00f2 richiedere modifiche per rendere l'implementazione pi\u00f9 trasparente. In particolare, se i revisori non riescono a convincersi che un contributo \u00e8 privo di difetti, potrebbero essere necessarie modifiche. Come parte di una revisione, un revisore pu\u00f2 creare una richiesta pull alternativa per un argomento. Questo pu\u00f2 essere fatto per evitare eccessivi \"avanti e indietro\" su elementi procedurali minori e quindi snellire il processo di proposta. Pu\u00f2 anche essere fatto perch\u00e9 la discussione ispira un revisore a costruire un'implementazione alternativa. Entrambe le situazioni sono il normale risultato di una revisione e non devono essere considerate critiche alla proposta originale.","title":"Cosa aspettarsi da una revisione"},{"location":"CONTRIBUTING.html#aiutare-con-le-revisioni","text":"Apprezziamo l'aiuto con le recensioni! Non \u00e8 necessario essere un revisore elencato per eseguire una revisione. I propositori di richieste pull di GitHub sono inoltre incoraggiati a rivedere i propri invii. Per aiutare con una revisione, segui i passaggi descritti in cosa aspettarsi in una revisione per verificare l'invio. Dopo aver completato la revisione, aggiungi un commento alla richiesta pull di GitHub con i tuoi risultati. Se l'invio supera la revisione, si prega di dichiararlo esplicitamente nel commento, ad esempio qualcosa del tipo \"Ho esaminato questa modifica in base ai passaggi del documento CONTRIBUTING e tutto mi sembra a posto\". Se non \u00e8 possibile completare alcuni passaggi della revisione, indicare esplicitamente quali passaggi sono stati rivisti e quali non sono stati rivisti, ad esempio qualcosa del tipo \"Non ho verificato la presenza di difetti nel codice, ma ho rivisto tutto il resto nel documento CONTRIBUTING e sembra buono\". Apprezziamo anche il test degli invii. Se il codice \u00e8 stato testato, aggiungi un commento alla richiesta pull di GitHub con i risultati del tuo test: successo o fallimento. Si prega di affermare esplicitamente che il codice \u00e8 stato testato e i risultati, ad esempio qualcosa del tipo \"Ho testato questo codice sulla mia stampante Acme900Z con una stampa a vaso e i risultati sono stati buoni\".","title":"Aiutare con le revisioni"},{"location":"CONTRIBUTING.html#revisori","text":"I \"revisori\" di Klipper sono: Nome GitHub Id Aree di interesse Dmitry Butyugin @dmbutyugin Input shaping, test di risonanza, cinematica Eric Callahan @Arksine Livellamento del piatto, flashing MCU James Hartley @JamesH1978 File di configurazione Kevin O'Connor @KevinOConnor Core motion system, codice microcontrollore Si prega di non eseguire il \"ping\" di nessuno dei revisori e di non indirizzare gli invii a loro. Tutti i revisori controllano i forum e le PR e si occuperanno delle revisioni quando ne avranno il tempo. I \"manutentori\" di Klipper sono: Nome nome GitHub Kevin O'Connor @KevinOConnor","title":"Revisori"},{"location":"CONTRIBUTING.html#formato-dei-messaggi-di-commit","text":"Ogni commit dovrebbe avere un messaggio di commit formattato in modo simile al seguente: modulo: Riepilogo breve (50 caratteri o meno) in maiuscolo Testo esplicativo pi\u00f9 dettagliato, se necessario. Incolonna a circa 75 caratteri o gi\u00f9 di l\u00ec. In alcuni contesti, la prima riga \u00e8 trattata come l'oggetto di un'e-mail e il resto del testo come corpo. La riga vuota che separa il riassunto dal corpo \u00e8 critica (a meno che non si ometta del tutto il corpo); strumenti come rebase possono confondersi se li metti due insieme. Ulteriori paragrafi vengono dopo le righe vuote.. Firmato da: Il mio nome Nell'esempio sopra, module dovrebbe essere il nome di un file o di una directory nel repository (senza un'estensione di file). Ad esempio, clocksync: fix di errore di battitura nella chiamata pause() al momento della connessione . Lo scopo di specificare un nome di modulo nel messaggio di commit \u00e8 di aiutare a fornire il contesto per i commenti di commit. \u00c8 importante avere una riga \"Signed-off-by\" su ogni commit - certifica che accetti il developer certificate of origin . Deve contenere il tuo vero nome (mi dispiace, niente pseudonimi o contributi anonimi) e contenere un indirizzo email corrente.","title":"Formato dei messaggi di commit"},{"location":"CONTRIBUTING.html#contribuire-a-traduzioni-klipper","text":"Klipper-translations Project \u00e8 un progetto dedicato alla traduzione di Klipper in diverse lingue. Weblate ospita tutte le stringhe Gettext per la traduzione e la revisione. Le impostazioni locali possono essere visualizzate su klipper3d.org una volta che soddisfano i seguenti requisiti: 75% Copertura totale Tutti i titoli (H1) sono tradotti Una gerarchia di navigazione PR aggiornata nelle traduzioni klipper. Per ridurre la frustrazione di tradurre termini specifici del dominio e acquisire consapevolezza delle traduzioni in corso, puoi inviare un PR modificando il Klipper-translations Project readme.md . Una volta che una traduzione \u00e8 pronta, \u00e8 possibile apportare la modifica corrispondente al progetto Klipper. Se una traduzione esiste gi\u00e0 nel repository Klipper e non soddisfa pi\u00f9 l'elenco di controllo di cui sopra, verr\u00e0 contrassegnata come obsoleta dopo un mese senza aggiornamenti. Una volta soddisfatti i requisiti, \u00e8 necessario: aggiorna il repository di klipper-translations active_translations Opzionale: aggiungi un file manual-index.md nella cartella docs\\locals\\ del repository klipper-translations per sostituire index.md specifico della lingua (il file index.md generato non viene visualizzato correttamente). Problemi noti: Al momento, non esiste un metodo per tradurre correttamente le immagini nella documentazione \u00c8 impossibile tradurre i titoli in mkdocs.yml.","title":"Contribuire a Traduzioni Klipper"},{"location":"Code_Overview.html","text":"Panoramica del codice \u00b6 Questo documento descrive il formato generale del codice e il flusso principale del codice di Klipper. Directory Layout \u00b6 La directory src/ contiene il sorgente C per il codice del microcontrollore. src/atsam/ , src/atsamd/ , src/avr/ , src/linux/ , src/lpc176x/ , src/ Le directory pru/ e src/stm32/ contengono il codice del microcontrollore specifico dell'architettura. src/simulator/ contiene stub di codice che consentono la compilazione di test del microcontrollore su altre architetture. La directory src/generic/ contiene codice di supporto che pu\u00f2 essere utile in diverse architetture. La build fa in modo che le include di \"board/somefile.h\" guardino prima nella directory dell'architettura corrente (ad esempio, src/avr/somefile.h) e poi nella directory generica (ad esempio, src/generic/somefile.h). La directory klippy/ contiene il software host. La maggior parte del software host \u00e8 scritto in Python, tuttavia la directory klippy/chelper/ contiene alcuni helper del codice C. La directory klippy/kinematics/ contiene il codice della cinematica del robot. La directory klippy/extras/ contiene i \"moduli\" estensibili del codice host. La directory lib/ contiene il codice della libreria di terze parti esterne necessarie per creare alcune destinazioni. La directory config/ contiene file di configurazione della stampante di esempio. La directory scripts/ contiene script di build-time utili per compilare il codice del microcontrollore. La directory test/ contiene test case automatizzati. Durante la compilazione, la build potrebbe creare una directory out/ . Questa contiene oggetti temporanei di compilazione. L'oggetto microcontrollore finale che viene creato \u00e8 out/klipper.elf.hex su AVR e out/klipper.bin su ARM. Flusso del codice del microcontrollore \u00b6 L'esecuzione del codice del microcontrollore inizia nel codice specifico dell'architettura (ad esempio, src/avr/main.c ) che alla fine chiama sched_main() che si trova in src/sched.c . Il codice sched_main() inizia eseguendo tutte le funzioni che sono state contrassegnate con la macro DECL_INIT(). Quindi continua a eseguire ripetutamente tutte le funzioni contrassegnate con la macro DECL_TASK(). Una delle principali funzioni dell'attivit\u00e0 \u00e8 command_dispatch() che si trova in src/command.c . Questa funzione viene richiamata dal codice input/output specifico della scheda (es. src/avr/serial.c , src/generic/serial_irq.c ) ed esegue le funzioni di comando associate ai comandi trovati nel flusso di input. Le funzioni di comando vengono dichiarate utilizzando la macro DECL_COMMAND() (consultare il documento protocol per ulteriori informazioni). Le funzioni task, init e comando vengono sempre eseguite con gli interrupt abilitati (tuttavia, possono disabilitare temporaneamente gli interrupt se necessario). Queste funzioni dovrebbero evitare lunghe pause, ritardi o eseguire lavori che durano un tempo significativo. (Lunghi ritardi in queste funzioni di \"attivit\u00e0\" provocano un jitter di pianificazione per altre \"attivit\u00e0\" - ritardi superiori a 100us possono diventare evidenti, ritardi superiori a 500us possono causare ritrasmissioni dei comandi, ritardi superiori a 100 ms possono causare riavvii del watchdog.) Queste funzioni pianificano il lavoro a orari specifici programmando i timer. Le funzioni timer vengono pianificate chiamando sched_add_timer() (che si trova in src/sched.c ). Il codice di pianificazione far\u00e0 in modo che la funzione data venga chiamata all'ora richiesta. Gli interrupt timer sono inizialmente gestiti in un gestore di interrupt specifico dell'architettura (ad esempio, src/avr/timer.c ) che chiama sched_timer_dispatch() situato in src/sched.c . L'interruzione del timer porta all'esecuzione delle funzioni del timer di pianificazione. Le funzioni timer vengono eseguite sempre con gli interrupt disabilitati. Le funzioni del timer dovrebbero sempre completarsi entro pochi microsecondi. Al completamento dell'evento timer, la funzione pu\u00f2 scegliere di riprogrammare se stessa. Nel caso in cui venga rilevato un errore, il codice pu\u00f2 invocare shutdown() (una macro che chiama sched_shutdown() situata in src/sched.c ). Il richiamo di shutdown() provoca l'esecuzione di tutte le funzioni contrassegnate con la macro DECL_SHUTDOWN(). Le funzioni di spegnimento vengono eseguite sempre con gli interrupt disabilitati. Gran parte delle funzionalit\u00e0 del microcontrollore implica il lavoro con pin di input/output per uso generico (GPIO). Per astrarre il codice specifico dell'architettura di basso livello dal codice dell'attivit\u00e0 di alto livello, tutti gli eventi GPIO sono implementati in wrapper specifici dell'architettura (ad esempio, src/avr/gpio.c ). Il codice \u00e8 compilato con l'ottimizzazione \"-flto -fwhole-program\" di gcc che fa un ottimo lavoro di inlining delle funzioni tra le unit\u00e0 di compilazione, quindi la maggior parte di queste minuscole funzioni gpio sono integrate nei loro chiamanti e non ci sono costi di runtime per l'utilizzo loro. Panoramica del codice Klippy \u00b6 Il codice host (Klippy) deve essere eseguito su un computer a basso costo (come un Raspberry Pi) abbinato al microcontrollore. Il codice \u00e8 scritto principalmente in Python, tuttavia utilizza CFFI per implementare alcune funzionalit\u00e0 nel codice C. L'esecuzione iniziale comincia in klippy/klippy.py . Questo legge gli argomenti della riga di comando, apre il file di configurazione della stampante, crea un'istanza degli oggetti principali della stampante e avvia la connessione seriale. L'esecuzione principale dei comandi G-code \u00e8 nel metodo process_commands() in klippy/gcode.py . Questo codice traduce i comandi del codice G in chiamate a oggetti stampante, che spesso traducono le azioni in comandi da eseguire sul microcontrollore (come dichiarato tramite la macro DECL_COMMAND nel codice del microcontrollore). Ci sono quattro thread nel codice host di Klippy. Il thread principale gestisce i comandi gcode in arrivo. Un secondo thread (che risiede interamente nel codice C klippy/chelper/serialqueue.c ) gestisce l'IO di basso livello con la porta seriale. Il terzo thread viene utilizzato per elaborare i messaggi di risposta dal microcontrollore nel codice Python (vedi klippy/serialhdl.py ). Il quarto thread scrive i messaggi di debug nel log (vedi klippy/queuelogger.py ) in modo che gli altri thread non blocchino mai le scritture del log. Flusso di codice di un comando di spostamento \u00b6 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 cinematica fornisce ulteriori informazioni sulla meccanica dei movimenti. L'elaborazione di un comando di spostamento inizia in gcode.py. L'obiettivo di gcode.py \u00e8 tradurre il G-code in chiamate interne. Un comando G1 invocher\u00e0 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\u00e0 (ad esempio, F6000=100mm/s). Il percorso del codice per una mossa \u00e8: _process_data() -> _process_commands() -> cmd_G1() . Infine viene invocata la classe ToolHead per eseguire la richiesta effettiva: cmd_G1() -> ToolHead.move() La classe ToolHead (in toolhead.py) gestisce \"look-ahead\" e tiene traccia dei tempi delle azioni di stampa. Il percorso di codice principale per una mossa \u00e8: ToolHead.move() -> MoveQueue.add_move() -> MoveQueue.flush() -> Move.set_junction() -> ToolHead._process_moves() . ToolHead.move() crea un oggetto Move() con i parametri del movimento (in spazio cartesiano e in unit\u00e0 di secondi e millimetri). Alla classe cinematica viene data l'opportunit\u00e0 di controllare ogni movimento ( ToolHead.move() -> kin.check_move() ). Le classi cinematiche si trovano nella directory klippy/cinematica/. Il codice check_move() pu\u00f2 generare un errore se il movimento non \u00e8 valida. Se check_move() viene completato correttamente, la cinematica sottostante deve essere in grado di gestire lo spostamento. MoveQueue.add_move() posiziona l'oggetto di spostamento nella coda \"look-ahead\". MoveQueue.flush() determina le velocit\u00e0 di inizio e fine di ogni movimento. 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\u00e0 costante, seguita da una fase di decelerazione costante. Ogni mossa contiene queste tre fasi in questo ordine, ma alcune fasi possono avere durata zero. Quando viene chiamato ToolHead._process_moves(), tutto ci\u00f2 che riguarda lo spostamento \u00e8 noto: la sua posizione iniziale, la sua posizione finale, la sua accelerazione, la sua velocit\u00e0 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\u00e0 di millimetri e secondi. Klipper utilizza un risolutore iterativo per generare i tempi di passaggio per ogni stepper. Per motivi di efficienza, i tempi di impulso stepper sono generati in codice C. I movimenti vengono prima posizionati su una \"coda di movimento trapezoidale\": ToolHead._process_moves() -> trapq_append() (in klippy/chelper/trapq.c). Vengono quindi generati i tempi di passaggio: ToolHead._process_moves() -> ToolHead._update_move_time() -> MCU_Stepper.generate_steps() -> itersolve_generate_steps() -> itersolve_gen_steps_range() (in klippy/chelper/itersolve.c). L'obiettivo del risolutore iterativo \u00e8 trovare i tempi di passaggio data una funzione che calcola una posizione passo-passo da un tempo. Questo viene fatto \"indovinando\" ripetutamente varie volte fino a quando la formula della posizione dello stepper non restituisce la posizione desiderata del passaggio successivo sullo stepper. Il feedback prodotto da ciascuna ipotesi viene utilizzato per migliorare le ipotesi future in modo che il processo converga rapidamente al tempo desiderato. Le formule della posizione dello stepper cinematico si trovano nella directory klippy/chelper/ (ad es. kin_cart.c, kin_corexy.c, kin_delta.c, kin_extruder.c). Si noti che l'estrusore \u00e8 gestito nella propria classe cinematica: ToolHead._process_moves() -> PrinterExtruder.move() . Poich\u00e9 la classe Move() specifica l'esatto tempo di movimento e poich\u00e9 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. Dopo che il risolutore iterativo ha calcolato i tempi di passaggio, questi vengono aggiunti a un array: itersolve_gen_steps_range() -> stepcompress_append() (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 - \u00e8 relativo a quando il microcontrollore \u00e8 stato acceso l'ultima volta. Il prossimo passo importante \u00e8 comprimere i passaggi: stepcompress_flush() -> compress_bisect_add() (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\u00e0 e inviati al microcontrollore (tramite stepcompress.c:steppersync e serialqueue.c:serialqueue). L'elaborazione dei comandi queue_step sul microcontrollore inizia in src/command.c che analizza il comando e chiama command_queue_step() . 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 stepper_event() . 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: do_step(); next_wake_time = last_wake_time + intervallo; intervallo += aggiungi; Quanto sopra pu\u00f2 sembrare un sacco di complessit\u00e0 per eseguire un movimento. Tuttavia, le uniche parti veramente interessanti sono nelle classi ToolHead e cinematica. \u00c8 questa parte del codice che specifica i movimenti e le loro tempistiche. Le restanti parti dell'elaborazione sono per lo pi\u00f9 solo comunicazioni e collegamenti. Aggiunta di un modulo host \u00b6 Il codice host Klippy ha una capacit\u00e0 di caricamento dinamico dei moduli. Se nel file di configurazione della stampante viene trovata una sezione di configurazione denominata \"[my_module]\", il software tenter\u00e0 automaticamente di caricare il modulo python klippy/extras/my_module.py . Questo sistema di moduli \u00e8 il metodo preferito per aggiungere nuove funzionalit\u00e0 a Klipper. Il modo pi\u00f9 semplice per aggiungere un nuovo modulo \u00e8 utilizzare un modulo esistente come riferimento - vedere klippy/extras/servo.py come esempio. Possono essere utili anche: L'esecuzione del modulo inizia nella funzione load_config() a livello di modulo (per le sezioni di configurazione del modulo [my_module]) o in load_config_prefix() (per le sezioni di configurazione del modulo [my_module my_name]). A questa funzione viene passato un oggetto \"config\" e deve restituire un nuovo \"oggetto stampante\" associato alla sezione di configurazione specificata. Durante il processo di creazione di un'istanza di un nuovo oggetto stampante, l'oggetto di configurazione pu\u00f2 essere utilizzato per leggere i parametri dalla sezione di configurazione specificata. Questo viene fatto usando i metodi config.get() , config.getfloat() , config.getint() , ecc. Assicurati di leggere tutti i valori dalla configurazione durante la costruzione dell'oggetto stampante: se l'utente specifica un parametro di configurazione che non viene letto durante questa fase, si presumer\u00e0 che si tratti di un errore di battitura nella configurazione e verr\u00e0 generato un errore. Usa il metodo config.get_printer() per ottenere un riferimento alla classe principale \"printer\". Questa classe \"stampante\" memorizza i riferimenti a tutti gli \"oggetti stampante\" di cui \u00e8 stata creata un'istanza. Usa il metodo printer.lookup_object() per trovare riferimenti ad altri oggetti stampante. Quasi tutte le funzionalit\u00e0 (anche i moduli cinematici principali) sono incapsulate in uno di questi oggetti stampante. Si noti, tuttavia, che quando viene istanziato un nuovo modulo, non saranno stati istanziati tutti gli altri oggetti stampante. I moduli \"gcode\" e \"pins\" saranno sempre disponibili, ma per altri moduli \u00e8 una buona idea rinviare la ricerca. Registra i gestori di eventi usando il metodo printer.register_event_handler() se il codice deve essere chiamato durante gli \"events\" generati da altri oggetti stampante. Ogni nome di evento \u00e8 una stringa e, per convenzione, \u00e8 il nome del modulo sorgente principale che genera l'evento insieme a un nome breve per l'azione che si sta verificando (ad esempio, \"klippy:connect\"). I parametri passati a ciascun gestore di eventi sono specifici dell'evento dato (cos\u00ec come la gestione delle eccezioni e il contesto di esecuzione). Due eventi di avvio comuni sono: klippy:connect - Questo evento viene generato dopo che tutti gli oggetti stampante sono stati istanziati. Viene comunemente utilizzato per cercare altri oggetti stampante, verificare le impostazioni di configurazione ed eseguire un \"handshake\" iniziale con l'hardware della stampante. klippy:ready - Questo evento viene generato dopo che tutti i gestori di connessione sono stati completati correttamente. Indica che la stampante sta passando a uno stato pronto per gestire le normali operazioni. Non generare un errore in questo callback. Se c'\u00e8 un errore nella configurazione dell'utente, assicurati di sollevarlo durante le fasi load_config() o \"connect event\". Utilizzare raise config.error(\"my error\") o raise printer.config_error (\"my error\") per segnalare l'errore. Utilizzare il modulo \"pin\" per configurare un pin su un microcontrollore. Questo \u00e8 in genere fatto con qualcosa di simile a printer.lookup_object(\"pins\").setup_pin(\"pwm\", config.get(\"my_pin\")) . L'oggetto restituito pu\u00f2 quindi essere comandato in fase di esecuzione. Se l'oggetto stampante definisce un metodo get_status() , il modulo pu\u00f2 esportare informazioni sullo stato tramite macro e tramite Server API . Il metodo get_status() deve restituire un dizionario Python con chiavi che sono stringhe e valori che sono interi, float, stringhe, elenchi, dizionari, True, False o None. \u00c8 possibile utilizzare anche tuple (e tuple con nome) (appaiono come elenchi quando si accede tramite il server API). Gli elenchi e i dizionari esportati devono essere trattati come \"immutabili\" - se il loro contenuto cambia, \u00e8 necessario restituire un nuovo oggetto da get_status() , altrimenti il server API non rilever\u00e0 tali modifiche. Se il modulo necessita dell'accesso alla temporizzazione del sistema o a descrittori di file esterni, utilizzare printer.get_reactor() per ottenere l'accesso alla classe globale \"event reactor\". Questa classe reattore consente di programmare i timer, attendere l'input sui descrittori di file e di \"sopprimere\" il codice host. Non utilizzare variabili globali. Tutto lo stato dovrebbe essere memorizzato nell'oggetto stampante restituito dalla funzione load_config() . Questo \u00e8 importante, altrimenti il comando RESTART potrebbe non funzionare come previsto. Inoltre, per ragioni simili, se vengono aperti file (o socket) esterni, assicurati di registrare un gestore di eventi \"klippy:disconnect\" e chiuderli da quella richiamata. Evitare di accedere alle variabili dei membri interni (o di chiamare metodi che iniziano con un trattino basso) di altri oggetti stampante. L'osservanza di questa convenzione semplifica la gestione delle modifiche future. Si consiglia di assegnare un valore a tutte le variabili membro nel costruttore Python delle classi Python. (E quindi evita di utilizzare la capacit\u00e0 di Python di creare dinamicamente nuove variabili membro.) Se una variabile Python deve memorizzare un valore in virgola mobile, si consiglia di assegnare e manipolare sempre quella variabile con costanti in virgola mobile (e non utilizzare mai costanti intere). Ad esempio, preferisci self.speed = 1. su self.speed = 1 e preferisci self.speed = 2. * x su self.speed = 2 * x . L'uso coerente di valori in virgola mobile pu\u00f2 evitare difficolt\u00e0 di debug nelle conversioni di tipo Python. Se invii il modulo per l'inclusione nel codice Klipper principale, assicurati di inserire un avviso di copyright nella parte superiore del modulo. Vedere i moduli esistenti per il formato preferito. Aggiunta di una nuova cinematica \u00b6 Questa sezione fornisce alcuni suggerimenti sull'aggiunta del supporto a Klipper per ulteriori tipi di cinematica della stampante. Questo tipo di attivit\u00e0 richiede un'ottima comprensione delle formule matematiche per la cinematica di destinazione. Richiede anche capacit\u00e0 di sviluppo software, sebbene sia necessario solo aggiornare il software host. Passi utili: Inizia studiando la sezione \" flusso di codice di un movimento \" e il documento di cinematica . Esaminare le classi cinematiche esistenti nella directory klippy/kinematics/. Le classi cinematiche hanno il compito di convertire una mossa in coordinate cartesiane nel movimento su ogni stepper. Si dovrebbe essere in grado di copiare uno di questi file come punto di partenza. Implementa in C le funzioni di posizione cinematica dello stepper per ogni stepper se non sono gi\u00e0 disponibili (vedi kin_cart.c, kin_corexy.c e kin_delta.c in klippy/chelper/). La funzione dovrebbe chiamare move_get_coord() per convertire un dato tempo di spostamento (in secondi) in una coordinata cartesiana (in millimetri), e quindi calcolare la posizione dello stepper desiderata (in millimetri) da quella coordinata cartesiana. Implementa il metodo calc_position() nella nuova classe cinematica. Questo metodo calcola la posizione della testa di stampa in coordinate cartesiane dalla posizione di ogni stepper. Non \u00e8 necessario che sia efficiente poich\u00e9 in genere viene chiamato solo durante le operazioni di homing e probing. Altri metodi. Implementa i metodi check_move() , get_status() , get_steppers() , home() e set_position() . Queste funzioni sono in genere utilizzate per fornire verifiche cinematiche specifiche. Tuttavia, all'inizio dello sviluppo \u00e8 possibile utilizzare il codice boilerplate qui. Implementare casi di prova. Crea un file g-code con una serie di movimenti che possono testare casi importanti per la cinematica data. Segui la documentazione di debug per convertire questo file di codice G in comandi del microcontrollore. Questo \u00e8 utile per esercitare corner case e per verificare la presenza di regressioni. Porting su un nuovo microcontrollore \u00b6 Questa sezione fornisce alcuni suggerimenti sul porting del codice del microcontrollore di Klipper su una nuova architettura. Questo tipo di attivit\u00e0 richiede una buona conoscenza dello sviluppo embedded e un accesso diretto al microcontrollore di destinazione. Passi utili: Inizia identificando eventuali librerie di terze parti che verranno utilizzate durante il trasferimento. Esempi comuni includono wrapper \"CMSIS\" e librerie \"HAL\" del produttore. Tutto il codice di terze parti deve essere compatibile con GNU GPLv3. Il codice di terze parti dovrebbe essere salvato nella directory lib/ di Klipper. Aggiorna il file lib/README con informazioni su dove e quando \u00e8 stata ottenuta la libreria. \u00c8 preferibile copiare il codice nel repository di Klipper senza modifiche, ma se sono necessarie modifiche, tali modifiche dovrebbero essere elencate esplicitamente nel file lib/README. Crea una nuova sottodirectory di architettura nella directory src/ e aggiungi il supporto iniziale di Kconfig e Makefile. Utilizzare le architetture esistenti come guida. src/simulator fornisce un esempio di base di un punto di partenza minimo. Il primo compito di programmazione \u00e8 portare il supporto di comunicazione alla scheda di destinazione. Questo \u00e8 il passo pi\u00f9 difficile in un nuovo porting. Una volta che la comunicazione di base funziona, i passaggi rimanenti tendono a essere molto pi\u00f9 semplici. \u00c8 tipico utilizzare un dispositivo seriale di tipo UART durante lo sviluppo iniziale poich\u00e9 questi tipi di dispositivi hardware sono generalmente pi\u00f9 facili da abilitare e controllare. Durante questa fase, fai un uso generoso del codice di supporto dalla directory src/generic/ (controlla come src/simulator/Makefile include il codice C generico nella build). \u00c8 inoltre necessario definire timer_read_time() (che restituisce l'orologio di sistema corrente) in questa fase, ma non \u00e8 necessario supportare completamente la gestione di timer irq. Acquisisci familiarit\u00e0 con lo strumento console.py (come descritto nel documento di debug ) e verifica la connettivit\u00e0 al microcontrollore con esso. Questo strumento traduce il protocollo di comunicazione del microcontrollore di basso livello in un formato leggibile dall'uomo. Aggiungi il supporto per l'invio del timer da interrupt hardware. Vedere Klipper commit 970831ee come esempio dei passaggi 1-5 eseguiti per l'architettura LPC176x. Visualizza il supporto di input e output GPIO di base. Vedi Klipper commit c78b9076 come esempio di questo. Riporta periferiche aggiuntive, ad esempio consulta il commit di Klipper 65613aed , c812a40a , e c381d03a . Crea un file di configurazione di Klipper di esempio nella directory config/. Testare il microcontrollore con il programma principale klippy.py. Prendi in considerazione l'aggiunta di build test case nella directory test/. Ulteriori suggerimenti per la programmazione: Evitare di utilizzare \"C bitfields\" per accedere ai registri IO; preferire operazioni di lettura e scrittura dirette di numeri interi a 32 bit, 16 bit o 8 bit. Le specifiche del linguaggio C non specificano chiaramente come il compilatore deve implementare campi di bit C (ad esempio, endianness e layout di bit), ed \u00e8 difficile determinare quali operazioni di I/O si verificheranno su un campo di bit C letto o scritto. Preferibilmente scrivere valori espliciti nei registri IO invece di usare operazioni di lettura-modifica-scrittura. Cio\u00e8, se si aggiorna un campo in un registro IO in cui gli altri campi hanno valori noti, \u00e8 preferibile scrivere in modo esplicito il contenuto completo del registro. Le scritture esplicite producono codice pi\u00f9 piccolo, pi\u00f9 veloce e pi\u00f9 facile da eseguire il debug. Sistemi di coordinate \u00b6 Internamente, Klipper tiene traccia principalmente della posizione della testa di stampa in coordinate cartesiane relative al sistema di coordinate specificato nel file di configurazione. Cio\u00e8, la maggior parte del codice Klipper non subir\u00e0 mai un cambiamento nei sistemi di coordinate. Se l'utente fa una richiesta per cambiare l'origine (ad esempio, un comando G92 ), allora quell'effetto si ottiene traducendo i comandi futuri nel sistema di coordinate primario. Tuttavia, in alcuni casi \u00e8 utile ottenere la posizione della testa di stampa in qualche altro sistema di coordinate e Klipper ha diversi strumenti per facilitarlo. Questo pu\u00f2 essere visto eseguendo il comando GET_POSITION. Per esempio: Send: GET_POSITION Recv: // mcu: stepper_a:-2060 stepper_b:-1169 stepper_c:-1613 Recv: // stepper: stepper_a:457.254159 stepper_b:466.085669 stepper_c:465.382132 Recv: // kinematic: X:8.339144 Y:-3.131558 Z:233.347121 Recv: // toolhead: X:8.338078 Y:-3.123175 Z:233.347878 E:0.000000 Recv: // gcode: X:8.338078 Y:-3.123175 Z:233.347878 E:0.000000 Recv: // gcode base: X:0.000000 Y:0.000000 Z:0.000000 E:0.000000 Recv: // gcode homing: X:0.000000 Y:0.000000 Z:0.000000 La posizione \"mcu\" ( stepper.get_mcu_position() nel codice) \u00e8 il numero totale di passaggi che il microcontrollore ha emesso in direzione positiva meno il numero di passaggi emessi in direzione negativa dall'ultimo microcontrollore Ripristina. Se il robot \u00e8 in movimento quando viene emessa la query, il valore riportato include le mosse memorizzate nel buffer del microcontrollore, ma non include le mosse nella coda di previsione. La posizione \"stepper\" ( stepper.get_commanded_position() ) \u00e8 la posizione del dato stepper come tracciato dal codice della cinematica. Questo corrisponde generalmente alla posizione (in mm) del carrello lungo il suo binario, rispetto a position_endstop specificato nel file di configurazione. (Alcune cinematiche tracciano le posizioni dello stepper in radianti anzich\u00e9 in millimetri.) Se il robot \u00e8 in movimento quando viene emessa la query, il valore riportato include i movimenti memorizzati nel buffer del microcontrollore, ma non include i movimenti sulla coda di previsione. Si possono usare le chiamate toolhead.flush_step_generation() o toolhead.wait_moves() per svuotare completamente il codice look-ahead e generazione di passaggi. La posizione \"cinematica\" ( kin.calc_position() ) \u00e8 la posizione cartesiana della testa di stampa come derivata dalle posizioni \"stepper\" ed \u00e8 relativa al sistema di coordinate specificato nel file di configurazione. Questo pu\u00f2 differire dalla posizione cartesiana richiesta a causa della granularit\u00e0 dei motori passo-passo. Se il robot \u00e8 in movimento quando vengono prese le posizioni \"stepper\", il valore riportato include i movimenti memorizzati nel buffer del microcontrollore, ma non include i movimenti sulla coda di previsione. Si possono usare le chiamate toolhead.flush_step_generation() o toolhead.wait_moves() per svuotare completamente il codice look-ahead e generazione di passaggi. La posizione della \"testa di stampa\" ( toolhead.get_position() ) \u00e8 l'ultima posizione richiesta della testa di stampa in coordinate cartesiane rispetto al sistema di coordinate specificato nel file di configurazione. Se il robot \u00e8 in movimento quando viene emessa la richiesta, il valore riportato include tutti i movimenti richiesti (anche quelli nei buffer in attesa di essere inviati ai driver del motore passo-passo). La posizione \"gcode\" \u00e8 l'ultima posizione richiesta da un comando G1 (o G0 ) in coordinate cartesiane relative al sistema di coordinate specificato nel file di configurazione. Questo pu\u00f2 differire dalla posizione \"toolhead\" se \u00e8 attiva una trasformazione del g-code (ad es. bed_mesh, bed_tilt, skew_correction). Questo pu\u00f2 differire dalle coordinate effettive specificate nell'ultimo comando G1 se l'origine del g-code \u00e8 stata modificata (ad esempio, G92 , SET_GCODE_OFFSET , M221 ). Il comando M114 ( gcode_move.get_status()['gcode_position'] ) riporter\u00e0 l'ultima posizione del g-code rispetto al sistema di coordinate del g-code corrente. La \"gcode base\" \u00e8 la posizione dell'origine del codice g in coordinate cartesiane rispetto al sistema di coordinate specificato nel file di configurazione. Comandi come G92 , SET_GCODE_OFFSET e M221 alterano questo valore. Il \"gcode homing\" \u00e8 la posizione da usare per l'origine del g-code (in coordinate cartesiane relative al sistema di coordinate specificato nel file di configurazione) dopo un comando home G28 . Il comando SET_GCODE_OFFSET pu\u00f2 alterare questo valore. Time \u00b6 Fondamentale per il funzionamento di Klipper \u00e8 la gestione di orologi, orari e timestamp. Klipper esegue azioni sulla stampante programmando eventi che si verificheranno nel prossimo futuro. Ad esempio, per accendere una ventola, il codice potrebbe programmare una modifica a un pin GPIO in 100 ms. \u00c8 raro che il codice tenti di eseguire un'azione istantanea. Pertanto, la gestione del tempo all'interno di Klipper \u00e8 fondamentale per il corretto funzionamento. Esistono tre tipi di tempi tracciati internamente nel software host di Klipper: Ora di sistema. L'ora del sistema utilizza l'orologio del sistema: \u00e8 un numero in virgola mobile memorizzato come secondi ed \u00e8 (generalmente) relativo all'ultimo avvio del computer host. I tempi di sistema hanno un uso limitato nel software: vengono utilizzati principalmente durante l'interazione con il sistema operativo. All'interno del codice host, gli orari di sistema sono spesso archiviati in variabili denominate eventtime o curtime . Tempo di stampa. Il tempo di stampa \u00e8 sincronizzato con l'orologio principale del microcontrollore (il microcontrollore definito nella sezione di configurazione \"[mcu]\"). \u00c8 un numero in virgola mobile memorizzato come secondi ed \u00e8 relativo all'ultimo riavvio dell'mcu principale. \u00c8 possibile convertire da un \"tempo di stampa\" all'orologio hardware del microcontrollore principale moltiplicando il tempo di stampa per la frequenza di frequenza configurata staticamente dell'mcu. Il codice host di alto livello utilizza i tempi di stampa per calcolare quasi tutte le azioni fisiche (ad es. movimento della testa, modifiche del riscaldatore, ecc.). All'interno del codice host, i tempi di stampa sono generalmente memorizzati in variabili denominate print_time o move_time . Orologio MCU. Questo \u00e8 il contatore dell'orologio hardware su ogni microcontrollore. Viene memorizzato come numero intero e la sua velocit\u00e0 di aggiornamento \u00e8 relativa alla frequenza del microcontrollore specificato. Il software host traduce i suoi tempi interni in orologi prima della trasmissione all'mcu. Il codice mcu tiene traccia del tempo solo in tick dell'orologio. All'interno del codice host, i valori di clock vengono tracciati come interi a 64 bit, mentre il codice mcu utilizza interi a 32 bit. All'interno del codice host, gli orologi sono generalmente memorizzati in variabili con nomi contenenti clock o tick . La conversione tra i diversi formati dell'ora \u00e8 implementata principalmente nel codice klippy/clocksync.py . Alcune cose da tenere presenti durante la revisione del codice: Orologi a 32 bit e 64 bit: per ridurre la larghezza di banda e migliorare l'efficienza del microcontrollore, gli orologi sul microcontrollore vengono tracciati come numeri interi a 32 bit. Quando si confrontano due orologi nel codice mcu, la funzione timer_is_before() deve essere sempre utilizzata per garantire che i rollover interi siano gestiti correttamente. Il software host converte gli orologi a 32 bit in orologi a 64 bit aggiungendo i bit di ordine superiore dall'ultimo timestamp mcu che ha ricevuto - nessun messaggio dall'mcu \u00e8 mai pi\u00f9 di 2^31 tick di clock in futuro o nel passato, quindi questa conversione non \u00e8 mai ambigua . L'host converte da clock a 64 bit a clock a 32 bit semplicemente troncando i bit di ordine superiore. Per garantire che non vi siano ambiguit\u00e0 in questa conversione, il codice klippy/chelper/serialqueue.c memorizza i messaggi nel buffer finch\u00e9 non si trovano entro 2^31 tick di clock dall'ora target. Microcontrollori multipli: il software host supporta l'utilizzo di pi\u00f9 microcontrollori su una singola stampante. In questo caso, il \"clock MCU\" di ogni microcontrollore viene tracciato separatamente. Il codice clocksync.py gestisce la deriva dell'orologio tra i microcontrollori modificando il modo in cui converte da \"tempo di stampa\" a \"orologio MCU\". Sul mcus secondario, la frequenza mcu utilizzata in questa conversione viene regolarmente aggiornata per tenere conto della deriva misurata.","title":"Panoramica del codice"},{"location":"Code_Overview.html#panoramica-del-codice","text":"Questo documento descrive il formato generale del codice e il flusso principale del codice di Klipper.","title":"Panoramica del codice"},{"location":"Code_Overview.html#directory-layout","text":"La directory src/ contiene il sorgente C per il codice del microcontrollore. src/atsam/ , src/atsamd/ , src/avr/ , src/linux/ , src/lpc176x/ , src/ Le directory pru/ e src/stm32/ contengono il codice del microcontrollore specifico dell'architettura. src/simulator/ contiene stub di codice che consentono la compilazione di test del microcontrollore su altre architetture. La directory src/generic/ contiene codice di supporto che pu\u00f2 essere utile in diverse architetture. La build fa in modo che le include di \"board/somefile.h\" guardino prima nella directory dell'architettura corrente (ad esempio, src/avr/somefile.h) e poi nella directory generica (ad esempio, src/generic/somefile.h). La directory klippy/ contiene il software host. La maggior parte del software host \u00e8 scritto in Python, tuttavia la directory klippy/chelper/ contiene alcuni helper del codice C. La directory klippy/kinematics/ contiene il codice della cinematica del robot. La directory klippy/extras/ contiene i \"moduli\" estensibili del codice host. La directory lib/ contiene il codice della libreria di terze parti esterne necessarie per creare alcune destinazioni. La directory config/ contiene file di configurazione della stampante di esempio. La directory scripts/ contiene script di build-time utili per compilare il codice del microcontrollore. La directory test/ contiene test case automatizzati. Durante la compilazione, la build potrebbe creare una directory out/ . Questa contiene oggetti temporanei di compilazione. L'oggetto microcontrollore finale che viene creato \u00e8 out/klipper.elf.hex su AVR e out/klipper.bin su ARM.","title":"Directory Layout"},{"location":"Code_Overview.html#flusso-del-codice-del-microcontrollore","text":"L'esecuzione del codice del microcontrollore inizia nel codice specifico dell'architettura (ad esempio, src/avr/main.c ) che alla fine chiama sched_main() che si trova in src/sched.c . Il codice sched_main() inizia eseguendo tutte le funzioni che sono state contrassegnate con la macro DECL_INIT(). Quindi continua a eseguire ripetutamente tutte le funzioni contrassegnate con la macro DECL_TASK(). Una delle principali funzioni dell'attivit\u00e0 \u00e8 command_dispatch() che si trova in src/command.c . Questa funzione viene richiamata dal codice input/output specifico della scheda (es. src/avr/serial.c , src/generic/serial_irq.c ) ed esegue le funzioni di comando associate ai comandi trovati nel flusso di input. Le funzioni di comando vengono dichiarate utilizzando la macro DECL_COMMAND() (consultare il documento protocol per ulteriori informazioni). Le funzioni task, init e comando vengono sempre eseguite con gli interrupt abilitati (tuttavia, possono disabilitare temporaneamente gli interrupt se necessario). Queste funzioni dovrebbero evitare lunghe pause, ritardi o eseguire lavori che durano un tempo significativo. (Lunghi ritardi in queste funzioni di \"attivit\u00e0\" provocano un jitter di pianificazione per altre \"attivit\u00e0\" - ritardi superiori a 100us possono diventare evidenti, ritardi superiori a 500us possono causare ritrasmissioni dei comandi, ritardi superiori a 100 ms possono causare riavvii del watchdog.) Queste funzioni pianificano il lavoro a orari specifici programmando i timer. Le funzioni timer vengono pianificate chiamando sched_add_timer() (che si trova in src/sched.c ). Il codice di pianificazione far\u00e0 in modo che la funzione data venga chiamata all'ora richiesta. Gli interrupt timer sono inizialmente gestiti in un gestore di interrupt specifico dell'architettura (ad esempio, src/avr/timer.c ) che chiama sched_timer_dispatch() situato in src/sched.c . L'interruzione del timer porta all'esecuzione delle funzioni del timer di pianificazione. Le funzioni timer vengono eseguite sempre con gli interrupt disabilitati. Le funzioni del timer dovrebbero sempre completarsi entro pochi microsecondi. Al completamento dell'evento timer, la funzione pu\u00f2 scegliere di riprogrammare se stessa. Nel caso in cui venga rilevato un errore, il codice pu\u00f2 invocare shutdown() (una macro che chiama sched_shutdown() situata in src/sched.c ). Il richiamo di shutdown() provoca l'esecuzione di tutte le funzioni contrassegnate con la macro DECL_SHUTDOWN(). Le funzioni di spegnimento vengono eseguite sempre con gli interrupt disabilitati. Gran parte delle funzionalit\u00e0 del microcontrollore implica il lavoro con pin di input/output per uso generico (GPIO). Per astrarre il codice specifico dell'architettura di basso livello dal codice dell'attivit\u00e0 di alto livello, tutti gli eventi GPIO sono implementati in wrapper specifici dell'architettura (ad esempio, src/avr/gpio.c ). Il codice \u00e8 compilato con l'ottimizzazione \"-flto -fwhole-program\" di gcc che fa un ottimo lavoro di inlining delle funzioni tra le unit\u00e0 di compilazione, quindi la maggior parte di queste minuscole funzioni gpio sono integrate nei loro chiamanti e non ci sono costi di runtime per l'utilizzo loro.","title":"Flusso del codice del microcontrollore"},{"location":"Code_Overview.html#panoramica-del-codice-klippy","text":"Il codice host (Klippy) deve essere eseguito su un computer a basso costo (come un Raspberry Pi) abbinato al microcontrollore. Il codice \u00e8 scritto principalmente in Python, tuttavia utilizza CFFI per implementare alcune funzionalit\u00e0 nel codice C. L'esecuzione iniziale comincia in klippy/klippy.py . Questo legge gli argomenti della riga di comando, apre il file di configurazione della stampante, crea un'istanza degli oggetti principali della stampante e avvia la connessione seriale. L'esecuzione principale dei comandi G-code \u00e8 nel metodo process_commands() in klippy/gcode.py . Questo codice traduce i comandi del codice G in chiamate a oggetti stampante, che spesso traducono le azioni in comandi da eseguire sul microcontrollore (come dichiarato tramite la macro DECL_COMMAND nel codice del microcontrollore). Ci sono quattro thread nel codice host di Klippy. Il thread principale gestisce i comandi gcode in arrivo. Un secondo thread (che risiede interamente nel codice C klippy/chelper/serialqueue.c ) gestisce l'IO di basso livello con la porta seriale. Il terzo thread viene utilizzato per elaborare i messaggi di risposta dal microcontrollore nel codice Python (vedi klippy/serialhdl.py ). Il quarto thread scrive i messaggi di debug nel log (vedi klippy/queuelogger.py ) in modo che gli altri thread non blocchino mai le scritture del log.","title":"Panoramica del codice Klippy"},{"location":"Code_Overview.html#flusso-di-codice-di-un-comando-di-spostamento","text":"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 cinematica fornisce ulteriori informazioni sulla meccanica dei movimenti. L'elaborazione di un comando di spostamento inizia in gcode.py. L'obiettivo di gcode.py \u00e8 tradurre il G-code in chiamate interne. Un comando G1 invocher\u00e0 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\u00e0 (ad esempio, F6000=100mm/s). Il percorso del codice per una mossa \u00e8: _process_data() -> _process_commands() -> cmd_G1() . Infine viene invocata la classe ToolHead per eseguire la richiesta effettiva: cmd_G1() -> ToolHead.move() La classe ToolHead (in toolhead.py) gestisce \"look-ahead\" e tiene traccia dei tempi delle azioni di stampa. Il percorso di codice principale per una mossa \u00e8: ToolHead.move() -> MoveQueue.add_move() -> MoveQueue.flush() -> Move.set_junction() -> ToolHead._process_moves() . ToolHead.move() crea un oggetto Move() con i parametri del movimento (in spazio cartesiano e in unit\u00e0 di secondi e millimetri). Alla classe cinematica viene data l'opportunit\u00e0 di controllare ogni movimento ( ToolHead.move() -> kin.check_move() ). Le classi cinematiche si trovano nella directory klippy/cinematica/. Il codice check_move() pu\u00f2 generare un errore se il movimento non \u00e8 valida. Se check_move() viene completato correttamente, la cinematica sottostante deve essere in grado di gestire lo spostamento. MoveQueue.add_move() posiziona l'oggetto di spostamento nella coda \"look-ahead\". MoveQueue.flush() determina le velocit\u00e0 di inizio e fine di ogni movimento. 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\u00e0 costante, seguita da una fase di decelerazione costante. Ogni mossa contiene queste tre fasi in questo ordine, ma alcune fasi possono avere durata zero. Quando viene chiamato ToolHead._process_moves(), tutto ci\u00f2 che riguarda lo spostamento \u00e8 noto: la sua posizione iniziale, la sua posizione finale, la sua accelerazione, la sua velocit\u00e0 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\u00e0 di millimetri e secondi. Klipper utilizza un risolutore iterativo per generare i tempi di passaggio per ogni stepper. Per motivi di efficienza, i tempi di impulso stepper sono generati in codice C. I movimenti vengono prima posizionati su una \"coda di movimento trapezoidale\": ToolHead._process_moves() -> trapq_append() (in klippy/chelper/trapq.c). Vengono quindi generati i tempi di passaggio: ToolHead._process_moves() -> ToolHead._update_move_time() -> MCU_Stepper.generate_steps() -> itersolve_generate_steps() -> itersolve_gen_steps_range() (in klippy/chelper/itersolve.c). L'obiettivo del risolutore iterativo \u00e8 trovare i tempi di passaggio data una funzione che calcola una posizione passo-passo da un tempo. Questo viene fatto \"indovinando\" ripetutamente varie volte fino a quando la formula della posizione dello stepper non restituisce la posizione desiderata del passaggio successivo sullo stepper. Il feedback prodotto da ciascuna ipotesi viene utilizzato per migliorare le ipotesi future in modo che il processo converga rapidamente al tempo desiderato. Le formule della posizione dello stepper cinematico si trovano nella directory klippy/chelper/ (ad es. kin_cart.c, kin_corexy.c, kin_delta.c, kin_extruder.c). Si noti che l'estrusore \u00e8 gestito nella propria classe cinematica: ToolHead._process_moves() -> PrinterExtruder.move() . Poich\u00e9 la classe Move() specifica l'esatto tempo di movimento e poich\u00e9 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. Dopo che il risolutore iterativo ha calcolato i tempi di passaggio, questi vengono aggiunti a un array: itersolve_gen_steps_range() -> stepcompress_append() (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 - \u00e8 relativo a quando il microcontrollore \u00e8 stato acceso l'ultima volta. Il prossimo passo importante \u00e8 comprimere i passaggi: stepcompress_flush() -> compress_bisect_add() (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\u00e0 e inviati al microcontrollore (tramite stepcompress.c:steppersync e serialqueue.c:serialqueue). L'elaborazione dei comandi queue_step sul microcontrollore inizia in src/command.c che analizza il comando e chiama command_queue_step() . 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 stepper_event() . 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: do_step(); next_wake_time = last_wake_time + intervallo; intervallo += aggiungi; Quanto sopra pu\u00f2 sembrare un sacco di complessit\u00e0 per eseguire un movimento. Tuttavia, le uniche parti veramente interessanti sono nelle classi ToolHead e cinematica. \u00c8 questa parte del codice che specifica i movimenti e le loro tempistiche. Le restanti parti dell'elaborazione sono per lo pi\u00f9 solo comunicazioni e collegamenti.","title":"Flusso di codice di un comando di spostamento"},{"location":"Code_Overview.html#aggiunta-di-un-modulo-host","text":"Il codice host Klippy ha una capacit\u00e0 di caricamento dinamico dei moduli. Se nel file di configurazione della stampante viene trovata una sezione di configurazione denominata \"[my_module]\", il software tenter\u00e0 automaticamente di caricare il modulo python klippy/extras/my_module.py . Questo sistema di moduli \u00e8 il metodo preferito per aggiungere nuove funzionalit\u00e0 a Klipper. Il modo pi\u00f9 semplice per aggiungere un nuovo modulo \u00e8 utilizzare un modulo esistente come riferimento - vedere klippy/extras/servo.py come esempio. Possono essere utili anche: L'esecuzione del modulo inizia nella funzione load_config() a livello di modulo (per le sezioni di configurazione del modulo [my_module]) o in load_config_prefix() (per le sezioni di configurazione del modulo [my_module my_name]). A questa funzione viene passato un oggetto \"config\" e deve restituire un nuovo \"oggetto stampante\" associato alla sezione di configurazione specificata. Durante il processo di creazione di un'istanza di un nuovo oggetto stampante, l'oggetto di configurazione pu\u00f2 essere utilizzato per leggere i parametri dalla sezione di configurazione specificata. Questo viene fatto usando i metodi config.get() , config.getfloat() , config.getint() , ecc. Assicurati di leggere tutti i valori dalla configurazione durante la costruzione dell'oggetto stampante: se l'utente specifica un parametro di configurazione che non viene letto durante questa fase, si presumer\u00e0 che si tratti di un errore di battitura nella configurazione e verr\u00e0 generato un errore. Usa il metodo config.get_printer() per ottenere un riferimento alla classe principale \"printer\". Questa classe \"stampante\" memorizza i riferimenti a tutti gli \"oggetti stampante\" di cui \u00e8 stata creata un'istanza. Usa il metodo printer.lookup_object() per trovare riferimenti ad altri oggetti stampante. Quasi tutte le funzionalit\u00e0 (anche i moduli cinematici principali) sono incapsulate in uno di questi oggetti stampante. Si noti, tuttavia, che quando viene istanziato un nuovo modulo, non saranno stati istanziati tutti gli altri oggetti stampante. I moduli \"gcode\" e \"pins\" saranno sempre disponibili, ma per altri moduli \u00e8 una buona idea rinviare la ricerca. Registra i gestori di eventi usando il metodo printer.register_event_handler() se il codice deve essere chiamato durante gli \"events\" generati da altri oggetti stampante. Ogni nome di evento \u00e8 una stringa e, per convenzione, \u00e8 il nome del modulo sorgente principale che genera l'evento insieme a un nome breve per l'azione che si sta verificando (ad esempio, \"klippy:connect\"). I parametri passati a ciascun gestore di eventi sono specifici dell'evento dato (cos\u00ec come la gestione delle eccezioni e il contesto di esecuzione). Due eventi di avvio comuni sono: klippy:connect - Questo evento viene generato dopo che tutti gli oggetti stampante sono stati istanziati. Viene comunemente utilizzato per cercare altri oggetti stampante, verificare le impostazioni di configurazione ed eseguire un \"handshake\" iniziale con l'hardware della stampante. klippy:ready - Questo evento viene generato dopo che tutti i gestori di connessione sono stati completati correttamente. Indica che la stampante sta passando a uno stato pronto per gestire le normali operazioni. Non generare un errore in questo callback. Se c'\u00e8 un errore nella configurazione dell'utente, assicurati di sollevarlo durante le fasi load_config() o \"connect event\". Utilizzare raise config.error(\"my error\") o raise printer.config_error (\"my error\") per segnalare l'errore. Utilizzare il modulo \"pin\" per configurare un pin su un microcontrollore. Questo \u00e8 in genere fatto con qualcosa di simile a printer.lookup_object(\"pins\").setup_pin(\"pwm\", config.get(\"my_pin\")) . L'oggetto restituito pu\u00f2 quindi essere comandato in fase di esecuzione. Se l'oggetto stampante definisce un metodo get_status() , il modulo pu\u00f2 esportare informazioni sullo stato tramite macro e tramite Server API . Il metodo get_status() deve restituire un dizionario Python con chiavi che sono stringhe e valori che sono interi, float, stringhe, elenchi, dizionari, True, False o None. \u00c8 possibile utilizzare anche tuple (e tuple con nome) (appaiono come elenchi quando si accede tramite il server API). Gli elenchi e i dizionari esportati devono essere trattati come \"immutabili\" - se il loro contenuto cambia, \u00e8 necessario restituire un nuovo oggetto da get_status() , altrimenti il server API non rilever\u00e0 tali modifiche. Se il modulo necessita dell'accesso alla temporizzazione del sistema o a descrittori di file esterni, utilizzare printer.get_reactor() per ottenere l'accesso alla classe globale \"event reactor\". Questa classe reattore consente di programmare i timer, attendere l'input sui descrittori di file e di \"sopprimere\" il codice host. Non utilizzare variabili globali. Tutto lo stato dovrebbe essere memorizzato nell'oggetto stampante restituito dalla funzione load_config() . Questo \u00e8 importante, altrimenti il comando RESTART potrebbe non funzionare come previsto. Inoltre, per ragioni simili, se vengono aperti file (o socket) esterni, assicurati di registrare un gestore di eventi \"klippy:disconnect\" e chiuderli da quella richiamata. Evitare di accedere alle variabili dei membri interni (o di chiamare metodi che iniziano con un trattino basso) di altri oggetti stampante. L'osservanza di questa convenzione semplifica la gestione delle modifiche future. Si consiglia di assegnare un valore a tutte le variabili membro nel costruttore Python delle classi Python. (E quindi evita di utilizzare la capacit\u00e0 di Python di creare dinamicamente nuove variabili membro.) Se una variabile Python deve memorizzare un valore in virgola mobile, si consiglia di assegnare e manipolare sempre quella variabile con costanti in virgola mobile (e non utilizzare mai costanti intere). Ad esempio, preferisci self.speed = 1. su self.speed = 1 e preferisci self.speed = 2. * x su self.speed = 2 * x . L'uso coerente di valori in virgola mobile pu\u00f2 evitare difficolt\u00e0 di debug nelle conversioni di tipo Python. Se invii il modulo per l'inclusione nel codice Klipper principale, assicurati di inserire un avviso di copyright nella parte superiore del modulo. Vedere i moduli esistenti per il formato preferito.","title":"Aggiunta di un modulo host"},{"location":"Code_Overview.html#aggiunta-di-una-nuova-cinematica","text":"Questa sezione fornisce alcuni suggerimenti sull'aggiunta del supporto a Klipper per ulteriori tipi di cinematica della stampante. Questo tipo di attivit\u00e0 richiede un'ottima comprensione delle formule matematiche per la cinematica di destinazione. Richiede anche capacit\u00e0 di sviluppo software, sebbene sia necessario solo aggiornare il software host. Passi utili: Inizia studiando la sezione \" flusso di codice di un movimento \" e il documento di cinematica . Esaminare le classi cinematiche esistenti nella directory klippy/kinematics/. Le classi cinematiche hanno il compito di convertire una mossa in coordinate cartesiane nel movimento su ogni stepper. Si dovrebbe essere in grado di copiare uno di questi file come punto di partenza. Implementa in C le funzioni di posizione cinematica dello stepper per ogni stepper se non sono gi\u00e0 disponibili (vedi kin_cart.c, kin_corexy.c e kin_delta.c in klippy/chelper/). La funzione dovrebbe chiamare move_get_coord() per convertire un dato tempo di spostamento (in secondi) in una coordinata cartesiana (in millimetri), e quindi calcolare la posizione dello stepper desiderata (in millimetri) da quella coordinata cartesiana. Implementa il metodo calc_position() nella nuova classe cinematica. Questo metodo calcola la posizione della testa di stampa in coordinate cartesiane dalla posizione di ogni stepper. Non \u00e8 necessario che sia efficiente poich\u00e9 in genere viene chiamato solo durante le operazioni di homing e probing. Altri metodi. Implementa i metodi check_move() , get_status() , get_steppers() , home() e set_position() . Queste funzioni sono in genere utilizzate per fornire verifiche cinematiche specifiche. Tuttavia, all'inizio dello sviluppo \u00e8 possibile utilizzare il codice boilerplate qui. Implementare casi di prova. Crea un file g-code con una serie di movimenti che possono testare casi importanti per la cinematica data. Segui la documentazione di debug per convertire questo file di codice G in comandi del microcontrollore. Questo \u00e8 utile per esercitare corner case e per verificare la presenza di regressioni.","title":"Aggiunta di una nuova cinematica"},{"location":"Code_Overview.html#porting-su-un-nuovo-microcontrollore","text":"Questa sezione fornisce alcuni suggerimenti sul porting del codice del microcontrollore di Klipper su una nuova architettura. Questo tipo di attivit\u00e0 richiede una buona conoscenza dello sviluppo embedded e un accesso diretto al microcontrollore di destinazione. Passi utili: Inizia identificando eventuali librerie di terze parti che verranno utilizzate durante il trasferimento. Esempi comuni includono wrapper \"CMSIS\" e librerie \"HAL\" del produttore. Tutto il codice di terze parti deve essere compatibile con GNU GPLv3. Il codice di terze parti dovrebbe essere salvato nella directory lib/ di Klipper. Aggiorna il file lib/README con informazioni su dove e quando \u00e8 stata ottenuta la libreria. \u00c8 preferibile copiare il codice nel repository di Klipper senza modifiche, ma se sono necessarie modifiche, tali modifiche dovrebbero essere elencate esplicitamente nel file lib/README. Crea una nuova sottodirectory di architettura nella directory src/ e aggiungi il supporto iniziale di Kconfig e Makefile. Utilizzare le architetture esistenti come guida. src/simulator fornisce un esempio di base di un punto di partenza minimo. Il primo compito di programmazione \u00e8 portare il supporto di comunicazione alla scheda di destinazione. Questo \u00e8 il passo pi\u00f9 difficile in un nuovo porting. Una volta che la comunicazione di base funziona, i passaggi rimanenti tendono a essere molto pi\u00f9 semplici. \u00c8 tipico utilizzare un dispositivo seriale di tipo UART durante lo sviluppo iniziale poich\u00e9 questi tipi di dispositivi hardware sono generalmente pi\u00f9 facili da abilitare e controllare. Durante questa fase, fai un uso generoso del codice di supporto dalla directory src/generic/ (controlla come src/simulator/Makefile include il codice C generico nella build). \u00c8 inoltre necessario definire timer_read_time() (che restituisce l'orologio di sistema corrente) in questa fase, ma non \u00e8 necessario supportare completamente la gestione di timer irq. Acquisisci familiarit\u00e0 con lo strumento console.py (come descritto nel documento di debug ) e verifica la connettivit\u00e0 al microcontrollore con esso. Questo strumento traduce il protocollo di comunicazione del microcontrollore di basso livello in un formato leggibile dall'uomo. Aggiungi il supporto per l'invio del timer da interrupt hardware. Vedere Klipper commit 970831ee come esempio dei passaggi 1-5 eseguiti per l'architettura LPC176x. Visualizza il supporto di input e output GPIO di base. Vedi Klipper commit c78b9076 come esempio di questo. Riporta periferiche aggiuntive, ad esempio consulta il commit di Klipper 65613aed , c812a40a , e c381d03a . Crea un file di configurazione di Klipper di esempio nella directory config/. Testare il microcontrollore con il programma principale klippy.py. Prendi in considerazione l'aggiunta di build test case nella directory test/. Ulteriori suggerimenti per la programmazione: Evitare di utilizzare \"C bitfields\" per accedere ai registri IO; preferire operazioni di lettura e scrittura dirette di numeri interi a 32 bit, 16 bit o 8 bit. Le specifiche del linguaggio C non specificano chiaramente come il compilatore deve implementare campi di bit C (ad esempio, endianness e layout di bit), ed \u00e8 difficile determinare quali operazioni di I/O si verificheranno su un campo di bit C letto o scritto. Preferibilmente scrivere valori espliciti nei registri IO invece di usare operazioni di lettura-modifica-scrittura. Cio\u00e8, se si aggiorna un campo in un registro IO in cui gli altri campi hanno valori noti, \u00e8 preferibile scrivere in modo esplicito il contenuto completo del registro. Le scritture esplicite producono codice pi\u00f9 piccolo, pi\u00f9 veloce e pi\u00f9 facile da eseguire il debug.","title":"Porting su un nuovo microcontrollore"},{"location":"Code_Overview.html#sistemi-di-coordinate","text":"Internamente, Klipper tiene traccia principalmente della posizione della testa di stampa in coordinate cartesiane relative al sistema di coordinate specificato nel file di configurazione. Cio\u00e8, la maggior parte del codice Klipper non subir\u00e0 mai un cambiamento nei sistemi di coordinate. Se l'utente fa una richiesta per cambiare l'origine (ad esempio, un comando G92 ), allora quell'effetto si ottiene traducendo i comandi futuri nel sistema di coordinate primario. Tuttavia, in alcuni casi \u00e8 utile ottenere la posizione della testa di stampa in qualche altro sistema di coordinate e Klipper ha diversi strumenti per facilitarlo. Questo pu\u00f2 essere visto eseguendo il comando GET_POSITION. Per esempio: Send: GET_POSITION Recv: // mcu: stepper_a:-2060 stepper_b:-1169 stepper_c:-1613 Recv: // stepper: stepper_a:457.254159 stepper_b:466.085669 stepper_c:465.382132 Recv: // kinematic: X:8.339144 Y:-3.131558 Z:233.347121 Recv: // toolhead: X:8.338078 Y:-3.123175 Z:233.347878 E:0.000000 Recv: // gcode: X:8.338078 Y:-3.123175 Z:233.347878 E:0.000000 Recv: // gcode base: X:0.000000 Y:0.000000 Z:0.000000 E:0.000000 Recv: // gcode homing: X:0.000000 Y:0.000000 Z:0.000000 La posizione \"mcu\" ( stepper.get_mcu_position() nel codice) \u00e8 il numero totale di passaggi che il microcontrollore ha emesso in direzione positiva meno il numero di passaggi emessi in direzione negativa dall'ultimo microcontrollore Ripristina. Se il robot \u00e8 in movimento quando viene emessa la query, il valore riportato include le mosse memorizzate nel buffer del microcontrollore, ma non include le mosse nella coda di previsione. La posizione \"stepper\" ( stepper.get_commanded_position() ) \u00e8 la posizione del dato stepper come tracciato dal codice della cinematica. Questo corrisponde generalmente alla posizione (in mm) del carrello lungo il suo binario, rispetto a position_endstop specificato nel file di configurazione. (Alcune cinematiche tracciano le posizioni dello stepper in radianti anzich\u00e9 in millimetri.) Se il robot \u00e8 in movimento quando viene emessa la query, il valore riportato include i movimenti memorizzati nel buffer del microcontrollore, ma non include i movimenti sulla coda di previsione. Si possono usare le chiamate toolhead.flush_step_generation() o toolhead.wait_moves() per svuotare completamente il codice look-ahead e generazione di passaggi. La posizione \"cinematica\" ( kin.calc_position() ) \u00e8 la posizione cartesiana della testa di stampa come derivata dalle posizioni \"stepper\" ed \u00e8 relativa al sistema di coordinate specificato nel file di configurazione. Questo pu\u00f2 differire dalla posizione cartesiana richiesta a causa della granularit\u00e0 dei motori passo-passo. Se il robot \u00e8 in movimento quando vengono prese le posizioni \"stepper\", il valore riportato include i movimenti memorizzati nel buffer del microcontrollore, ma non include i movimenti sulla coda di previsione. Si possono usare le chiamate toolhead.flush_step_generation() o toolhead.wait_moves() per svuotare completamente il codice look-ahead e generazione di passaggi. La posizione della \"testa di stampa\" ( toolhead.get_position() ) \u00e8 l'ultima posizione richiesta della testa di stampa in coordinate cartesiane rispetto al sistema di coordinate specificato nel file di configurazione. Se il robot \u00e8 in movimento quando viene emessa la richiesta, il valore riportato include tutti i movimenti richiesti (anche quelli nei buffer in attesa di essere inviati ai driver del motore passo-passo). La posizione \"gcode\" \u00e8 l'ultima posizione richiesta da un comando G1 (o G0 ) in coordinate cartesiane relative al sistema di coordinate specificato nel file di configurazione. Questo pu\u00f2 differire dalla posizione \"toolhead\" se \u00e8 attiva una trasformazione del g-code (ad es. bed_mesh, bed_tilt, skew_correction). Questo pu\u00f2 differire dalle coordinate effettive specificate nell'ultimo comando G1 se l'origine del g-code \u00e8 stata modificata (ad esempio, G92 , SET_GCODE_OFFSET , M221 ). Il comando M114 ( gcode_move.get_status()['gcode_position'] ) riporter\u00e0 l'ultima posizione del g-code rispetto al sistema di coordinate del g-code corrente. La \"gcode base\" \u00e8 la posizione dell'origine del codice g in coordinate cartesiane rispetto al sistema di coordinate specificato nel file di configurazione. Comandi come G92 , SET_GCODE_OFFSET e M221 alterano questo valore. Il \"gcode homing\" \u00e8 la posizione da usare per l'origine del g-code (in coordinate cartesiane relative al sistema di coordinate specificato nel file di configurazione) dopo un comando home G28 . Il comando SET_GCODE_OFFSET pu\u00f2 alterare questo valore.","title":"Sistemi di coordinate"},{"location":"Code_Overview.html#time","text":"Fondamentale per il funzionamento di Klipper \u00e8 la gestione di orologi, orari e timestamp. Klipper esegue azioni sulla stampante programmando eventi che si verificheranno nel prossimo futuro. Ad esempio, per accendere una ventola, il codice potrebbe programmare una modifica a un pin GPIO in 100 ms. \u00c8 raro che il codice tenti di eseguire un'azione istantanea. Pertanto, la gestione del tempo all'interno di Klipper \u00e8 fondamentale per il corretto funzionamento. Esistono tre tipi di tempi tracciati internamente nel software host di Klipper: Ora di sistema. L'ora del sistema utilizza l'orologio del sistema: \u00e8 un numero in virgola mobile memorizzato come secondi ed \u00e8 (generalmente) relativo all'ultimo avvio del computer host. I tempi di sistema hanno un uso limitato nel software: vengono utilizzati principalmente durante l'interazione con il sistema operativo. All'interno del codice host, gli orari di sistema sono spesso archiviati in variabili denominate eventtime o curtime . Tempo di stampa. Il tempo di stampa \u00e8 sincronizzato con l'orologio principale del microcontrollore (il microcontrollore definito nella sezione di configurazione \"[mcu]\"). \u00c8 un numero in virgola mobile memorizzato come secondi ed \u00e8 relativo all'ultimo riavvio dell'mcu principale. \u00c8 possibile convertire da un \"tempo di stampa\" all'orologio hardware del microcontrollore principale moltiplicando il tempo di stampa per la frequenza di frequenza configurata staticamente dell'mcu. Il codice host di alto livello utilizza i tempi di stampa per calcolare quasi tutte le azioni fisiche (ad es. movimento della testa, modifiche del riscaldatore, ecc.). All'interno del codice host, i tempi di stampa sono generalmente memorizzati in variabili denominate print_time o move_time . Orologio MCU. Questo \u00e8 il contatore dell'orologio hardware su ogni microcontrollore. Viene memorizzato come numero intero e la sua velocit\u00e0 di aggiornamento \u00e8 relativa alla frequenza del microcontrollore specificato. Il software host traduce i suoi tempi interni in orologi prima della trasmissione all'mcu. Il codice mcu tiene traccia del tempo solo in tick dell'orologio. All'interno del codice host, i valori di clock vengono tracciati come interi a 64 bit, mentre il codice mcu utilizza interi a 32 bit. All'interno del codice host, gli orologi sono generalmente memorizzati in variabili con nomi contenenti clock o tick . La conversione tra i diversi formati dell'ora \u00e8 implementata principalmente nel codice klippy/clocksync.py . Alcune cose da tenere presenti durante la revisione del codice: Orologi a 32 bit e 64 bit: per ridurre la larghezza di banda e migliorare l'efficienza del microcontrollore, gli orologi sul microcontrollore vengono tracciati come numeri interi a 32 bit. Quando si confrontano due orologi nel codice mcu, la funzione timer_is_before() deve essere sempre utilizzata per garantire che i rollover interi siano gestiti correttamente. Il software host converte gli orologi a 32 bit in orologi a 64 bit aggiungendo i bit di ordine superiore dall'ultimo timestamp mcu che ha ricevuto - nessun messaggio dall'mcu \u00e8 mai pi\u00f9 di 2^31 tick di clock in futuro o nel passato, quindi questa conversione non \u00e8 mai ambigua . L'host converte da clock a 64 bit a clock a 32 bit semplicemente troncando i bit di ordine superiore. Per garantire che non vi siano ambiguit\u00e0 in questa conversione, il codice klippy/chelper/serialqueue.c memorizza i messaggi nel buffer finch\u00e9 non si trovano entro 2^31 tick di clock dall'ora target. Microcontrollori multipli: il software host supporta l'utilizzo di pi\u00f9 microcontrollori su una singola stampante. In questo caso, il \"clock MCU\" di ogni microcontrollore viene tracciato separatamente. Il codice clocksync.py gestisce la deriva dell'orologio tra i microcontrollori modificando il modo in cui converte da \"tempo di stampa\" a \"orologio MCU\". Sul mcus secondario, la frequenza mcu utilizzata in questa conversione viene regolarmente aggiornata per tenere conto della deriva misurata.","title":"Time"},{"location":"Command_Templates.html","text":"Modelli di comandi \u00b6 Questo documento fornisce informazioni sull'implementazione di sequenze di comandi G-Code nelle sezioni di configurazione gcode_macro (e simili). Denominazione macro G-Code \u00b6 Le maiuscole non sono importanti per il nome della macro G-Code: MY_MACRO e my_macro saranno considerate allo stesso modo e possono essere chiamati in maiuscolo o minuscolo. Se nel nome della macro vengono utilizzati dei numeri, devono trovarsi tutti alla fine del nome (ad es. TEST_MACRO25 \u00e8 valido, ma MACRO25_TEST3 non lo \u00e8). Formattazione di G-Code nel config \u00b6 L'indentazione \u00e8 importante quando si definisce una macro nel file di configurazione. Per specificare una sequenza G-Code su pi\u00f9 righe \u00e8 importante che ogni riga abbia un'indentazione adeguata. Per esempio: [gcode_macro led_lampeggiante] gcode: SET_PIN PIN=my_led VALUE=1 G4 P2000 SET_PIN PIN=my_led VALUE=0 Nota come l'opzione di configurazione gcode: inizia sempre all'inizio della riga e le righe successive nella macro G-Code non iniziano mai all'inizio. Aggiungi una descrizione alla tua macro \u00b6 Per aiutare a identificare la funzionalit\u00e0 \u00e8 possibile aggiungere una breve descrizione. Aggiungi descrizione: con un breve testo per descrivere la funzionalit\u00e0. L'impostazione predefinita \u00e8 \"Macro codice G\" se non specificato. Per esempio: [gcode_macro led_lampeggiante] description: Esegue lampeggio del led una volta gcode: SET_PIN PIN=my_led VALUE=1 G4 P2000 SET_PIN PIN=my_led VALUE=0 Il terminale visualizzer\u00e0 la descrizione quando si utilizza il comando HELP o la funzione di completamento automatico. Salva/ripristina lo stato per i movimenti G-Code \u00b6 Sfortunatamente, il linguaggio di comando G-Code pu\u00f2 essere difficile da usare. Il meccanismo standard per spostare la testa di stampa \u00e8 tramite il comando G1 (il comando G0 \u00e8 un alias per G1 e pu\u00f2 essere usato in modo intercambiabile con esso). Tuttavia, questo comando si basa sull'impostazione dello \"stato di analisi del codice G\" da M82 , M83 , G90 , G91 , G92 e precedenti comandi G1 . Quando si crea una macro G-Code \u00e8 una buona idea impostare sempre in modo esplicito lo stato di analisi del G-Code prima di emettere un comando G1 . (Altrimenti, c'\u00e8 il rischio che il comando G1 faccia una richiesta indesiderabile.) Un modo comune per farlo \u00e8 avvolgere le mosse G1 in SAVE_GCODE_STATE , G91 e RESTORE_GCODE_STATE . Per esempio: [gcode_macro MOVE_UP] gcode: SAVE_GCODE_STATE NAME=my_move_up_state G91 G1 Z10 F300 RESTORE_GCODE_STATE NAME=my_move_up_state Il comando G91 pone lo stato di analisi del codice G in \"modalit\u00e0 di spostamento relativo\" e il comando RESTORE_GCODE_STATE ripristina lo stato a quello che era prima di entrare nella macro. Assicurati di specificare una velocit\u00e0 esplicita (tramite il parametro F ) sul primo comando G1 . Espansione del modello \u00b6 La sezione di configurazione di gcode_macro gcode: viene valutata utilizzando il linguaggio del modello Jinja2. \u00c8 possibile valutare le espressioni in fase di esecuzione racchiudendole in caratteri { } o utilizzando istruzioni condizionali racchiuse in {% %} . Vedere la documentazione Jinja2 per ulteriori informazioni sulla sintassi. Un esempio di macro complessa: [gcode_macro clean_nozzle] gcode: {% set wipe_count = 8 %} SAVE_GCODE_STATE NAME=clean_nozzle_state G90 G0 Z15 F300 {% for wipe in range(wipe_count) %} {% for coordinate in [(275, 4),(235, 4)] %} G0 X{coordinate[0]} Y{coordinate[1] + 0.25 * wipe} Z9.7 F12000 {% endfor %} {% endfor %} RESTORE_GCODE_STATE NAME=clean_nozzle_state Parametri Macro \u00b6 Spesso \u00e8 utile controllare i parametri passati alla macro quando viene chiamata. Questi parametri sono disponibili tramite la pseudo-variabile params . Ad esempio, se la macro: [gcode_macro SET_PERCENT] gcode: M117 Now at { params.VALUE|float * 100 }% sono stati invocati come SET_PERCENT VALUE=.2 verrebbero valutati in M117 Now at 20% . Si noti che i nomi dei parametri sono sempre in maiuscolo quando vengono valutati nella macro e vengono sempre passati come stringhe. Se si eseguono calcoli matematici, devono essere convertiti esplicitamente in numeri interi o float. \u00c8 comune usare la direttiva Jinja2 set per usare un parametro predefinito e assegnare il risultato a un nome locale. Per esempio: [gcode_macro SET_BED_TEMPERATURE] gcode: {% set bed_temp = params.TEMPERATURE|default(40)|float %} M140 S{bed_temp La variabile \"rawparams\" \u00b6 \u00c8 possibile accedere ai parametri completi non analizzati per la macro in esecuzione tramite la pseudo-variabile rawparams . Nota che questo includer\u00e0 tutti i commenti che facevano parte del comando originale. Vedere il file sample-macros.cfg per un esempio che mostra come sovrascrivere il comando M117 usando rawparams . La variabile \"printer\" \u00b6 \u00c8 possibile ispezionare (e modificare) lo stato corrente della stampante tramite la pseudo-variabile printer . Per esempio: [gcode_macro slow_fan] gcode: M106 S{ printer.fan.speed * 0.9 * 255} I campi disponibili sono definiti nel documento Status Reference . Importante! Le macro vengono prima valutate per intero e solo dopo vengono eseguiti i comandi risultanti. Se una macro emette un comando che altera lo stato della stampante, i risultati di tale cambiamento di stato non saranno visibili durante la valutazione della macro. Ci\u00f2 pu\u00f2 anche comportare un comportamento impercettibile quando una macro genera comandi che chiamano altre macro, poich\u00e9 la macro chiamata viene valutata quando viene richiamata (che avviene dopo l'intera valutazione della macro chiamante). Per convenzione, il nome immediatamente successivo a printer \u00e8 il nome di una sezione di configurazione. Quindi, ad esempio, printer.fan si riferisce all'oggetto fan creato dalla sezione di configurazione [fan] . Ci sono alcune eccezioni a questa regola, in particolare gli oggetti gcode_move e toolhead . Se la sezione di configurazione contiene spazi, \u00e8 possibile accedervi tramite l'accessor [ ] , ad esempio: printer[\"generic_heater my_chamber_heater\"].temperature . Si noti che la direttiva Jinja2 set pu\u00f2 assegnare un nome locale a un oggetto nella gerarchia printer . Ci\u00f2 pu\u00f2 rendere le macro pi\u00f9 leggibili e ridurre la digitazione. Per esempio: [gcode_macro QUERY_HTU21D] gcode: {% set sensor = printer[\"htu21d my_sensor\"] %} M117 Temp:{sensor.temperature} Humidity:{sensor.humidity} Azioni \u00b6 Sono disponibili alcuni comandi che possono alterare lo stato della stampante. Ad esempio, { action_emergency_stop() } provocherebbe l'arresto della stampante. Si noti che queste azioni vengono eseguite nel momento in cui viene valutata la macro, il che potrebbe richiedere un periodo di tempo significativo prima dell'esecuzione dei comandi g-code generati. Comandi \"azione\" disponibili: action_respond_info(msg) : scrive il dato msg sullo pseudo-terminale /tmp/printer. Ogni riga di msg verr\u00e0 inviata con un prefisso \"//\". action_raise_error(msg) : annulla la macro corrente (e qualsiasi macro chiamante) e scrivie il dato msg sullo pseudo-terminale /tmp/printer. La prima riga di msg verr\u00e0 inviata con un prefisso \"!!\" e le righe successive avranno un prefisso \"//\". action_emergency_stop(msg) : fa passare la stampante a uno stato di spegnimento. Il parametro msg \u00e8 opzionale, pu\u00f2 essere utile per descrivere il motivo dell'arresto. action_call_remote_method(method_name) : chiama un metodo registrato da un client remoto. Se il metodo accetta parametri, questi dovrebbero essere forniti tramite argomenti chiave, ad esempio: action_call_remote_method(\"print_stuff\", my_arg=\"hello_world\") Variabili \u00b6 Il comando SET_GCODE_VARIABLE pu\u00f2 essere utile per salvare lo stato tra le chiamate di macro. I nomi delle variabili non possono contenere caratteri maiuscoli. Per esempio: [gcode_macro start_probe] variable_bed_temp: 0 gcode: # Salva la temperatura target nella variabile bed_temp SET_GCODE_VARIABLE MACRO=start_probe VARIABLE=bed_temp VALUE={printer.heater_bed.target} # Disattiva il riscaldamento del piatto M140 # Esegue sonda PROBE # Chiama la macro finish_probe al completamento finish_probe [gcode_macro finish_probe] gcode: # Ripristinare la temperatura del piatto M140 S{printer[\"gcode_macro start_probe\"].bed_temp} Assicurarsi di tenere in considerazione i tempi della valutazione della macro e dell'esecuzione dei comandi quando si utilizza SET_GCODE_VARIABLE. Gcode ritardati \u00b6 L'opzione di configurazione [delayed_gcode] pu\u00f2 essere utilizzata per eseguire una sequenza gcode ritardata: [delayed_gcode clear_display] gcode: M117 [gcode_macro load_filament] gcode: G91 G1 E50 G90 M400 M117 Load Complete! UPDATE_DELAYED_GCODE ID=clear_display DURATION=10 Quando viene eseguita la macro load_filament sopra, visualizzer\u00e0 un \"Load Complete!\" messaggio al termine dell'estrusione. L'ultima riga di gcode abilita il delay_gcode \"clear_display\", impostato per essere eseguito in 10 secondi. L'opzione di configurazione initial_duration pu\u00f2 essere impostata per eseguire il delay_gcode all'avvio della stampante. Il conto alla rovescia inizia quando la stampante entra nello stato \"ready\". Ad esempio, il codice delay_g riportato di seguito verr\u00e0 eseguito 5 secondi dopo che la stampante \u00e8 pronta, inizializzando il display con un messaggio\"Welcome!\": [delayed_gcode welcome] initial_duration: 5. gcode: M117 Welcome! \u00c8 possibile che un gcode ritardato si ripeta aggiornandosi nell'opzione gcode: [delayed_gcode report_temp] initial_duration: 2. gcode: {action_respond_info(\"Extruder Temp: %.1f\" % (printer.extruder0.temperature))} UPDATE_DELAYED_GCODE ID=report_temp DURATION=2 Il codice delayed_gcode sopra riportato invier\u00e0 \"// Extruder Temp: [ex0_temp]\" a Octoprint ogni 2 secondi. Questo pu\u00f2 essere annullato con il seguente gcode: UPDATE_DELAYED_GCODE ID=report_temp DURATION=0 Modelli di menu \u00b6 Se \u00e8 abilitata una sezione di configurazione display , \u00e8 possibile personalizzare il menu con le sezioni di configurazione menu . I seguenti attributi di sola lettura sono disponibili nei modelli di menu: menu.width - larghezza dell'elemento (numero di colonne di visualizzazione) menu.ns - namespace del elemento menu.event - nome dell'evento che ha attivato lo script menu.input - valore di input, disponibile solo nel contesto dello script di input Le seguenti azioni sono disponibili nei modelli di menu: menu.back(force, update) : eseguir\u00e0 il comando menu back, parametri booleani opzionali e . Quando \u00e8 impostato su True, interromper\u00e0 anche la modifica. Il valore predefinito \u00e8 False. Quando \u00e8 impostato su False, gli elementi del contenitore padre non vengono aggiornati. Il valore predefinito \u00e8 True. menu.exit(force) - eseguir\u00e0 il comando di uscita dal menu, parametro booleano opzionale valore predefinito False. Quando \u00e8 impostato su True, interromper\u00e0 anche la modifica. Il valore predefinito \u00e8 False. Salvare variabili su disco \u00b6 Se \u00e8 stata abilitata una sezione di configurazione save_variables , SAVE_VARIABLE VARIABLE= VALUE= pu\u00f2 essere utilizzato per salvare la variabile su disco in modo che possa essere utilizzata tra i riavvii. Tutte le variabili memorizzate vengono caricate nel dict printer.save_variables.variables all'avvio e possono essere utilizzate nelle macro gcode. per evitare righe troppo lunghe puoi aggiungere quanto segue nella parte superiore della macro: {% set svv = printer.save_variables.variables %} Ad esempio, potrebbe essere utilizzato per salvare lo stato dell'hotend 2-in-1-out e quando si avvia una stampa assicurarsi che venga utilizzato l'estrusore attivo, anzich\u00e9 T0: [gcode_macro T1] gcode: ACTIVATE_EXTRUDER extruder=extruder1 SAVE_VARIABLE VARIABLE=currentextruder VALUE='\"extruder1\"' [gcode_macro T0] gcode: ACTIVATE_EXTRUDER extruder=extruder SAVE_VARIABLE VARIABLE=currentextruder VALUE='\"extruder\"' [gcode_macro START_GCODE] gcode: {% set svv = printer.save_variables.variables %} ACTIVATE_EXTRUDER extruder={svv.currentextruder}","title":"Modelli di comandi"},{"location":"Command_Templates.html#modelli-di-comandi","text":"Questo documento fornisce informazioni sull'implementazione di sequenze di comandi G-Code nelle sezioni di configurazione gcode_macro (e simili).","title":"Modelli di comandi"},{"location":"Command_Templates.html#denominazione-macro-g-code","text":"Le maiuscole non sono importanti per il nome della macro G-Code: MY_MACRO e my_macro saranno considerate allo stesso modo e possono essere chiamati in maiuscolo o minuscolo. Se nel nome della macro vengono utilizzati dei numeri, devono trovarsi tutti alla fine del nome (ad es. TEST_MACRO25 \u00e8 valido, ma MACRO25_TEST3 non lo \u00e8).","title":"Denominazione macro G-Code"},{"location":"Command_Templates.html#formattazione-di-g-code-nel-config","text":"L'indentazione \u00e8 importante quando si definisce una macro nel file di configurazione. Per specificare una sequenza G-Code su pi\u00f9 righe \u00e8 importante che ogni riga abbia un'indentazione adeguata. Per esempio: [gcode_macro led_lampeggiante] gcode: SET_PIN PIN=my_led VALUE=1 G4 P2000 SET_PIN PIN=my_led VALUE=0 Nota come l'opzione di configurazione gcode: inizia sempre all'inizio della riga e le righe successive nella macro G-Code non iniziano mai all'inizio.","title":"Formattazione di G-Code nel config"},{"location":"Command_Templates.html#aggiungi-una-descrizione-alla-tua-macro","text":"Per aiutare a identificare la funzionalit\u00e0 \u00e8 possibile aggiungere una breve descrizione. Aggiungi descrizione: con un breve testo per descrivere la funzionalit\u00e0. L'impostazione predefinita \u00e8 \"Macro codice G\" se non specificato. Per esempio: [gcode_macro led_lampeggiante] description: Esegue lampeggio del led una volta gcode: SET_PIN PIN=my_led VALUE=1 G4 P2000 SET_PIN PIN=my_led VALUE=0 Il terminale visualizzer\u00e0 la descrizione quando si utilizza il comando HELP o la funzione di completamento automatico.","title":"Aggiungi una descrizione alla tua macro"},{"location":"Command_Templates.html#salvaripristina-lo-stato-per-i-movimenti-g-code","text":"Sfortunatamente, il linguaggio di comando G-Code pu\u00f2 essere difficile da usare. Il meccanismo standard per spostare la testa di stampa \u00e8 tramite il comando G1 (il comando G0 \u00e8 un alias per G1 e pu\u00f2 essere usato in modo intercambiabile con esso). Tuttavia, questo comando si basa sull'impostazione dello \"stato di analisi del codice G\" da M82 , M83 , G90 , G91 , G92 e precedenti comandi G1 . Quando si crea una macro G-Code \u00e8 una buona idea impostare sempre in modo esplicito lo stato di analisi del G-Code prima di emettere un comando G1 . (Altrimenti, c'\u00e8 il rischio che il comando G1 faccia una richiesta indesiderabile.) Un modo comune per farlo \u00e8 avvolgere le mosse G1 in SAVE_GCODE_STATE , G91 e RESTORE_GCODE_STATE . Per esempio: [gcode_macro MOVE_UP] gcode: SAVE_GCODE_STATE NAME=my_move_up_state G91 G1 Z10 F300 RESTORE_GCODE_STATE NAME=my_move_up_state Il comando G91 pone lo stato di analisi del codice G in \"modalit\u00e0 di spostamento relativo\" e il comando RESTORE_GCODE_STATE ripristina lo stato a quello che era prima di entrare nella macro. Assicurati di specificare una velocit\u00e0 esplicita (tramite il parametro F ) sul primo comando G1 .","title":"Salva/ripristina lo stato per i movimenti G-Code"},{"location":"Command_Templates.html#espansione-del-modello","text":"La sezione di configurazione di gcode_macro gcode: viene valutata utilizzando il linguaggio del modello Jinja2. \u00c8 possibile valutare le espressioni in fase di esecuzione racchiudendole in caratteri { } o utilizzando istruzioni condizionali racchiuse in {% %} . Vedere la documentazione Jinja2 per ulteriori informazioni sulla sintassi. Un esempio di macro complessa: [gcode_macro clean_nozzle] gcode: {% set wipe_count = 8 %} SAVE_GCODE_STATE NAME=clean_nozzle_state G90 G0 Z15 F300 {% for wipe in range(wipe_count) %} {% for coordinate in [(275, 4),(235, 4)] %} G0 X{coordinate[0]} Y{coordinate[1] + 0.25 * wipe} Z9.7 F12000 {% endfor %} {% endfor %} RESTORE_GCODE_STATE NAME=clean_nozzle_state","title":"Espansione del modello"},{"location":"Command_Templates.html#parametri-macro","text":"Spesso \u00e8 utile controllare i parametri passati alla macro quando viene chiamata. Questi parametri sono disponibili tramite la pseudo-variabile params . Ad esempio, se la macro: [gcode_macro SET_PERCENT] gcode: M117 Now at { params.VALUE|float * 100 }% sono stati invocati come SET_PERCENT VALUE=.2 verrebbero valutati in M117 Now at 20% . Si noti che i nomi dei parametri sono sempre in maiuscolo quando vengono valutati nella macro e vengono sempre passati come stringhe. Se si eseguono calcoli matematici, devono essere convertiti esplicitamente in numeri interi o float. \u00c8 comune usare la direttiva Jinja2 set per usare un parametro predefinito e assegnare il risultato a un nome locale. Per esempio: [gcode_macro SET_BED_TEMPERATURE] gcode: {% set bed_temp = params.TEMPERATURE|default(40)|float %} M140 S{bed_temp","title":"Parametri Macro"},{"location":"Command_Templates.html#la-variabile-rawparams","text":"\u00c8 possibile accedere ai parametri completi non analizzati per la macro in esecuzione tramite la pseudo-variabile rawparams . Nota che questo includer\u00e0 tutti i commenti che facevano parte del comando originale. Vedere il file sample-macros.cfg per un esempio che mostra come sovrascrivere il comando M117 usando rawparams .","title":"La variabile \"rawparams\""},{"location":"Command_Templates.html#la-variabile-printer","text":"\u00c8 possibile ispezionare (e modificare) lo stato corrente della stampante tramite la pseudo-variabile printer . Per esempio: [gcode_macro slow_fan] gcode: M106 S{ printer.fan.speed * 0.9 * 255} I campi disponibili sono definiti nel documento Status Reference . Importante! Le macro vengono prima valutate per intero e solo dopo vengono eseguiti i comandi risultanti. Se una macro emette un comando che altera lo stato della stampante, i risultati di tale cambiamento di stato non saranno visibili durante la valutazione della macro. Ci\u00f2 pu\u00f2 anche comportare un comportamento impercettibile quando una macro genera comandi che chiamano altre macro, poich\u00e9 la macro chiamata viene valutata quando viene richiamata (che avviene dopo l'intera valutazione della macro chiamante). Per convenzione, il nome immediatamente successivo a printer \u00e8 il nome di una sezione di configurazione. Quindi, ad esempio, printer.fan si riferisce all'oggetto fan creato dalla sezione di configurazione [fan] . Ci sono alcune eccezioni a questa regola, in particolare gli oggetti gcode_move e toolhead . Se la sezione di configurazione contiene spazi, \u00e8 possibile accedervi tramite l'accessor [ ] , ad esempio: printer[\"generic_heater my_chamber_heater\"].temperature . Si noti che la direttiva Jinja2 set pu\u00f2 assegnare un nome locale a un oggetto nella gerarchia printer . Ci\u00f2 pu\u00f2 rendere le macro pi\u00f9 leggibili e ridurre la digitazione. Per esempio: [gcode_macro QUERY_HTU21D] gcode: {% set sensor = printer[\"htu21d my_sensor\"] %} M117 Temp:{sensor.temperature} Humidity:{sensor.humidity}","title":"La variabile \"printer\""},{"location":"Command_Templates.html#azioni","text":"Sono disponibili alcuni comandi che possono alterare lo stato della stampante. Ad esempio, { action_emergency_stop() } provocherebbe l'arresto della stampante. Si noti che queste azioni vengono eseguite nel momento in cui viene valutata la macro, il che potrebbe richiedere un periodo di tempo significativo prima dell'esecuzione dei comandi g-code generati. Comandi \"azione\" disponibili: action_respond_info(msg) : scrive il dato msg sullo pseudo-terminale /tmp/printer. Ogni riga di msg verr\u00e0 inviata con un prefisso \"//\". action_raise_error(msg) : annulla la macro corrente (e qualsiasi macro chiamante) e scrivie il dato msg sullo pseudo-terminale /tmp/printer. La prima riga di msg verr\u00e0 inviata con un prefisso \"!!\" e le righe successive avranno un prefisso \"//\". action_emergency_stop(msg) : fa passare la stampante a uno stato di spegnimento. Il parametro msg \u00e8 opzionale, pu\u00f2 essere utile per descrivere il motivo dell'arresto. action_call_remote_method(method_name) : chiama un metodo registrato da un client remoto. Se il metodo accetta parametri, questi dovrebbero essere forniti tramite argomenti chiave, ad esempio: action_call_remote_method(\"print_stuff\", my_arg=\"hello_world\")","title":"Azioni"},{"location":"Command_Templates.html#variabili","text":"Il comando SET_GCODE_VARIABLE pu\u00f2 essere utile per salvare lo stato tra le chiamate di macro. I nomi delle variabili non possono contenere caratteri maiuscoli. Per esempio: [gcode_macro start_probe] variable_bed_temp: 0 gcode: # Salva la temperatura target nella variabile bed_temp SET_GCODE_VARIABLE MACRO=start_probe VARIABLE=bed_temp VALUE={printer.heater_bed.target} # Disattiva il riscaldamento del piatto M140 # Esegue sonda PROBE # Chiama la macro finish_probe al completamento finish_probe [gcode_macro finish_probe] gcode: # Ripristinare la temperatura del piatto M140 S{printer[\"gcode_macro start_probe\"].bed_temp} Assicurarsi di tenere in considerazione i tempi della valutazione della macro e dell'esecuzione dei comandi quando si utilizza SET_GCODE_VARIABLE.","title":"Variabili"},{"location":"Command_Templates.html#gcode-ritardati","text":"L'opzione di configurazione [delayed_gcode] pu\u00f2 essere utilizzata per eseguire una sequenza gcode ritardata: [delayed_gcode clear_display] gcode: M117 [gcode_macro load_filament] gcode: G91 G1 E50 G90 M400 M117 Load Complete! UPDATE_DELAYED_GCODE ID=clear_display DURATION=10 Quando viene eseguita la macro load_filament sopra, visualizzer\u00e0 un \"Load Complete!\" messaggio al termine dell'estrusione. L'ultima riga di gcode abilita il delay_gcode \"clear_display\", impostato per essere eseguito in 10 secondi. L'opzione di configurazione initial_duration pu\u00f2 essere impostata per eseguire il delay_gcode all'avvio della stampante. Il conto alla rovescia inizia quando la stampante entra nello stato \"ready\". Ad esempio, il codice delay_g riportato di seguito verr\u00e0 eseguito 5 secondi dopo che la stampante \u00e8 pronta, inizializzando il display con un messaggio\"Welcome!\": [delayed_gcode welcome] initial_duration: 5. gcode: M117 Welcome! \u00c8 possibile che un gcode ritardato si ripeta aggiornandosi nell'opzione gcode: [delayed_gcode report_temp] initial_duration: 2. gcode: {action_respond_info(\"Extruder Temp: %.1f\" % (printer.extruder0.temperature))} UPDATE_DELAYED_GCODE ID=report_temp DURATION=2 Il codice delayed_gcode sopra riportato invier\u00e0 \"// Extruder Temp: [ex0_temp]\" a Octoprint ogni 2 secondi. Questo pu\u00f2 essere annullato con il seguente gcode: UPDATE_DELAYED_GCODE ID=report_temp DURATION=0","title":"Gcode ritardati"},{"location":"Command_Templates.html#modelli-di-menu","text":"Se \u00e8 abilitata una sezione di configurazione display , \u00e8 possibile personalizzare il menu con le sezioni di configurazione menu . I seguenti attributi di sola lettura sono disponibili nei modelli di menu: menu.width - larghezza dell'elemento (numero di colonne di visualizzazione) menu.ns - namespace del elemento menu.event - nome dell'evento che ha attivato lo script menu.input - valore di input, disponibile solo nel contesto dello script di input Le seguenti azioni sono disponibili nei modelli di menu: menu.back(force, update) : eseguir\u00e0 il comando menu back, parametri booleani opzionali e . Quando \u00e8 impostato su True, interromper\u00e0 anche la modifica. Il valore predefinito \u00e8 False. Quando \u00e8 impostato su False, gli elementi del contenitore padre non vengono aggiornati. Il valore predefinito \u00e8 True. menu.exit(force) - eseguir\u00e0 il comando di uscita dal menu, parametro booleano opzionale valore predefinito False. Quando \u00e8 impostato su True, interromper\u00e0 anche la modifica. Il valore predefinito \u00e8 False.","title":"Modelli di menu"},{"location":"Command_Templates.html#salvare-variabili-su-disco","text":"Se \u00e8 stata abilitata una sezione di configurazione save_variables , SAVE_VARIABLE VARIABLE= VALUE= pu\u00f2 essere utilizzato per salvare la variabile su disco in modo che possa essere utilizzata tra i riavvii. Tutte le variabili memorizzate vengono caricate nel dict printer.save_variables.variables all'avvio e possono essere utilizzate nelle macro gcode. per evitare righe troppo lunghe puoi aggiungere quanto segue nella parte superiore della macro: {% set svv = printer.save_variables.variables %} Ad esempio, potrebbe essere utilizzato per salvare lo stato dell'hotend 2-in-1-out e quando si avvia una stampa assicurarsi che venga utilizzato l'estrusore attivo, anzich\u00e9 T0: [gcode_macro T1] gcode: ACTIVATE_EXTRUDER extruder=extruder1 SAVE_VARIABLE VARIABLE=currentextruder VALUE='\"extruder1\"' [gcode_macro T0] gcode: ACTIVATE_EXTRUDER extruder=extruder SAVE_VARIABLE VARIABLE=currentextruder VALUE='\"extruder\"' [gcode_macro START_GCODE] gcode: {% set svv = printer.save_variables.variables %} ACTIVATE_EXTRUDER extruder={svv.currentextruder}","title":"Salvare variabili su disco"},{"location":"Config_Changes.html","text":"Modifiche alla configurazione \u00b6 Questo documento copre le modifiche software recenti al file di configurazione che non sono compatibili con le versioni precedenti. \u00c8 una buona idea rivedere questo documento durante l'aggiornamento del software Klipper. Tutte le date in questo documento sono approssimative. Cambiamenti \u00b6 20230826: If safe_distance is set or calculated to be 0 in [dual_carriage] , the carriages proximity checks will be disabled as per documentation. A user may wish to configure safe_distance explicitly to prevent accidental crashes of the carriages with each other. Additionally, the homing order of the primary and the dual carriage is changed in some configurations (certain configurations when both carriages home in the same direction, see [dual_carriage] configuration reference for more details). 20230810: The flash-sdcard.sh script now supports both variants of the Bigtreetech SKR-3, STM32H743 and STM32H723. For this, the original tag of btt-skr-3 now has changed to be either btt-skr-3-h743 or btt-skr-3-h723. 20230729: The exported status for dual_carriage is changed. Instead of exporting mode and active_carriage , the individual modes for each carriage are exported as printer.dual_carriage.carriage_0 and printer.dual_carriage.carriage_1 . 20230619: The relative_reference_index option has been deprecated and superceded by the zero_reference_position option. Refer to the Bed Mesh Documentation for details on how to update the configuration. With this deprecation the RELATIVE_REFERENCE_INDEX is no longer available as a parameter for the BED_MESH_CALIBRATE gcode command. 20230530: The default canbus frequency in \"make menuconfig\" is now 1000000. If using canbus and using canbus with some other frequency is required, then be sure to select \"Enable extra low-level configuration options\" and specify the desired \"CAN bus speed\" in \"make menuconfig\" when compiling and flashing the micro-controller. 20230525: SHAPER_CALIBRATE command immediately applies input shaper parameters if [input_shaper] was enabled already. 20230407: The stalled_bytes counter in the log and in the printer.mcu.last_stats field has been renamed to upcoming_bytes . 20230323: On tmc5160 drivers multistep_filt is now enabled by default. Set driver_MULTISTEP_FILT: False in the tmc5160 config for the previous behavior. 20230304: Il comando SET_TMC_CURRENT ora regola correttamente il registro globalscaler per i driver che lo dispongono. Ci\u00f2 rimuove una limitazione per cui su tmc5160, le correnti non potevano essere aumentate con SET_TMC_CURRENT rispetto al valore run_current impostato nel file di configurazione. Tuttavia, questo ha un effetto collaterale: dopo aver eseguito SET_TMC_CURRENT , lo stepper deve essere tenuto fermo per >130 ms nel caso in cui venga utilizzato StealthChop2 in modo che la calibrazione AT#1 venga eseguita dal driver. 20230202: il formato delle informazioni sullo stato di printer.screws_tilt_adjust \u00e8 stato modificato. Le informazioni vengono ora memorizzate come dizionario delle viti con le misurazioni risultanti. Consulta il riferimento sullo stato per i dettagli. 20230201: Il modulo [bed_mesh] non carica pi\u00f9 il profilo default all'avvio. Si consiglia agli utenti che usano il profilo default di aggiungere BED_MESH_PROFILE LOAD=default alla loro macro START_PRINT (o alla configurazione \"Start G-Code\" del loro slicer quando applicabile). 20230103: Ora \u00e8 possibile con lo script flash-sdcard.sh eseguire il flashing di entrambe le varianti di Bigtreetech SKR-2, STM32F407 e STM32F429. Ci\u00f2 significa che il tag originale di btt-skr2 ora \u00e8 cambiato in btt-skr-2-f407 o btt-skr-2-f429. 20221128: rilascio di Klipper v0.11.0. 20221122: In precedenza, con safe_z_home, era possibile che z_hop dopo l'homing g28 andasse nella direzione z negativa. Ora, uno z_hop viene eseguito dopo g28 solo se risulta in un hop positivo, rispecchiando il comportamento dello z_hop che si verifica prima dell'homing g28. 20220616: in precedenza era possibile eseguire il flashing di un rp2040 in modalit\u00e0 bootloader eseguendo make flash FLASH_DEVICE=first . Il comando equivalente \u00e8 ora make flash FLASH_DEVICE=2e8a:0003 . 20220612: Il microcontrollore rp2040 ora ha una soluzione alternativa per l'errata USB \"rp2040-e5\". Ci\u00f2 dovrebbe rendere pi\u00f9 affidabili le connessioni USB iniziali. Tuttavia, potrebbe comportare un cambiamento nel comportamento del pin gpio15. \u00c8 improbabile che il cambiamento di comportamento di gpio15 sia evidente. 20220407: l'opzione di configurazione temperature_fan pid_integral_max \u00e8 stata rimossa (era deprecata su 20210612). 20220407: L'ordine dei colori predefinito per i LED pca9632 \u00e8 ora \"RGBW\". Aggiungi un'impostazione esplicita color_order: RBGW alla sezione di configurazione di pca9632 per ottenere il comportamento precedente. 20220330: Il formato delle informazioni di stato printer.neopixel.color_data per i moduli neopixel e dotstar \u00e8 cambiato. Le informazioni sono ora memorizzate come un elenco di elenchi di colori (invece di un elenco di dizionari). Per i dettagli, vedere il riferimento dello stato . 20220307: M73 non imposter\u00e0 pi\u00f9 l'avanzamento della stampa su 0 se manca P . 20220304: Non esiste pi\u00f9 un valore predefinito per il parametro extruder delle sezioni di configurazione extruder_stepper . Se lo si desidera, specificare esplicitamente extruder: extruder per associare il motore passo-passo alla coda di movimento \"estrusore\" all'avvio. 20220210: Il comando SYNC_STEPPER_TO_EXTRUDER \u00e8 deprecato; il comando SET_EXTRUDER_STEP_DISTANCE \u00e8 deprecato; l'opzione di configurazione extruder shared_heater \u00e8 deprecata. Queste funzionalit\u00e0 verranno rimosse nel prossimo futuro. Sostituisci SET_EXTRUDER_STEP_DISTANCE con SET_EXTRUDER_ROTATION_DISTANCE . Sostituisci SYNC_STEPPER_TO_EXTRUDER con SYNC_EXTRUDER_MOTION . Sostituisci le sezioni di configurazione dell'estrusore usando shared_heater con le sezioni di configurazione extruder_stepper e aggiorna le macro di attivazione per usare SYNC_EXTRUDER_MOTION . 20220116: Il codice di calcolo della run_current per tmc2130, tmc2208, tmc2209 e tmc2660 \u00e8 cambiato. Per alcune impostazioni di run_current i driver possono ora essere configurati in modo diverso. Questa nuova configurazione dovrebbe essere pi\u00f9 accurata, ma potrebbe invalidare la precedente ottimizzazione del driver tmc. 20211230: Gli script per ottimizzare l'input shaper ( scripts/calibrate_shaper.py e scripts/graph_accelerometer.py ) sono stati migrati per utilizzare Python3 per impostazione predefinita. Di conseguenza, gli utenti devono installare le versioni Python3 di determinati pacchetti (ad esempio sudo apt install python3-numpy python3-matplotlib ) per continuare a utilizzare questi script. Per maggiori dettagli, fare riferimento a Installazione del software . In alternativa, gli utenti possono forzare temporaneamente l'esecuzione di questi script in Python 2 chiamando esplicitamente l'interprete Python2 nella console: python2 ~/klipper/scripts/calibrate_shaper.py ... 20211110: Il sensore di temperatura \"NTC 100K beta 3950\" \u00e8 obsoleto. Questo sensore verr\u00e0 rimosso nel prossimo futuro. La maggior parte degli utenti trover\u00e0 il sensore di temperatura \"Generico 3950\" pi\u00f9 accurato. Per continuare a utilizzare la definizione precedente (in genere meno accurata), definire un termistore personalizzato con temperature1: 25 , resistance1: 100000 e beta: 3950 . 20211104: L'opzione \"step pulse duration\" in \"make menuconfig\" \u00e8 stata rimossa. La durata del passaggio predefinita per i driver TMC configurati in modalit\u00e0 UART o SPI \u00e8 ora di 100 ns. Una nuova impostazione step_pulse_duration nella sezione stepper config dovrebbe essere impostata per tutti gli stepper che necessitano di una durata dell'impulso personalizzata. 20211102: diverse funzionalit\u00e0 deprecate sono state rimosse. L'opzione stepper step_distance \u00e8 stata rimossa (obsoleta nel 20201222). L'alias del sensore rpi_temperature \u00e8 stato rimosso (obsoleto il 20210219). L'opzione mcu pin_map \u00e8 stata rimossa (deprecata su 20210325). La gcode_macro default_parameter_ e l'accesso macro ai parametri dei comandi diversi dalla pseudo-variabile params sono stati rimossi (deprecato in 20210503). L'opzione del riscaldatore pid_integral_max \u00e8 stata rimossa (obsoleta il 20210612). 20210929: Klipper v0.10.0 rilasciato. 20210903: Il valore predefinito smooth_time per i riscaldatori \u00e8 cambiato in 1 secondo (da 2 secondi). Per la maggior parte delle stampanti ci\u00f2 si tradurr\u00e0 in un controllo della temperatura pi\u00f9 stabile. 20210830: il nome adxl345 predefinito \u00e8 ora \"adxl345\". Il parametro CHIP predefinito per ACCELEROMETER_MEASURE e ACCELEROMETER_QUERY ora \u00e8 \"adxl345\". 20210830: il comando adxl345 ACCELEROMETER_MEASURE non supporta pi\u00f9 un parametro RATE. Per modificare la frequenza delle query, aggiornare il file printer.cfg ed eseguire un comando RESTART. 20210821: Diverse impostazioni di configurazione in printer.configfile.settings verranno ora riportate come elenchi anzich\u00e9 come stringhe grezze. Se si desidera la stringa grezza effettiva, utilizzare invece printer.configfile.config . 20210819: In alcuni casi, un movimento di riferimento G28 pu\u00f2 terminare in una posizione che \u00e8 nominalmente al di fuori dell'intervallo di movimento valido. In rare situazioni ci\u00f2 pu\u00f2 causare errori di \"spostamento fuori portata\" confusi dopo l'homing. In tal caso, modificare gli script di avvio per spostare la testa utensile in una posizione valida subito dopo l'homing. 20210814: Gli pseudo-pin solo analogici su atmega168 e atmega328 sono stati rinominati da PE0/PE1 a PE2/PE3. 20210720: una sezione controller_fan ora monitora tutti i motori passo-passo per impostazione predefinita (non solo i motori passo-passo cinematici). Se si desidera il comportamento precedente, vedere l'opzione di configurazione stepper nel riferimento di configurazione . 20210703: Una sezione di configurazione samd_sercom deve ora specificare il bus sercom che sta configurando tramite l'opzione sercom . 20210612: L'opzione di configurazione pid_integral_max nelle sezioni riscaldatore e temperature_fan \u00e8 obsoleta. L'opzione verr\u00e0 rimossa nel prossimo futuro. 20210503: The gcode_macro default_parameter_ config option is deprecated. Use the params pseudo-variable to access macro parameters. Other methods for accessing macro parameters will be removed in the near future. Most users can replace a default_parameter_NAME: VALUE config option with a line like the following in the start of the macro: {% set NAME = params.NAME|default(VALUE)|float %} . See the Command Templates document for examples. 20210430: il comando SET_VELOCITY_LIMIT (e M204) ora pu\u00f2 impostare una velocit\u00e0, un'accelerazione e una square_corner_velocity maggiori dei valori specificati nel file di configurazione. 20210325: il supporto per l'opzione di configurazione pin_map \u00e8 deprecato. Utilizzare il file sample-aliases.cfg per tradurre i nomi dei pin del microcontroller effettivi. L'opzione di configurazione pin_map verr\u00e0 rimossa nel prossimo futuro. 20210313: Il supporto di Klipper per i microcontrollori che comunicano con il bus CAN \u00e8 cambiato. Se si utilizza il bus CAN, \u00e8 necessario eseguire nuovamente il flashing di tutti i microcontrollori e la configurazione di Klipper deve essere aggiornata . 20210310: Il valore predefinito TMC2660 per driver_SFILT \u00e8 stato modificato da 1 a 0. 20210227: I driver del motore passo-passo TMC in modalit\u00e0 UART o SPI ora vengono interrogati una volta al secondo ogni volta che sono abilitati - se il driver non pu\u00f2 essere contattato o se il driver segnala un errore, Klipper passer\u00e0 allo stato di spegnimento. 20210219: Il modulo rpi_temperature \u00e8 stato rinominato in temperature_host . Sostituisci tutte le occorrenze di sensor_type: rpi_temperature con sensor_type: temperature_host . Il percorso del file di temperatura pu\u00f2 essere specificato nella variabile di configurazione sensor_path . Il nome rpi_temperature \u00e8 deprecato e verr\u00e0 rimosso nel prossimo futuro. 20210201: Il comando TEST_RESONANCES ora disabiliter\u00e0 l'input shaping se era stato precedentemente abilitato (e lo riattiver\u00e0 dopo il test). Per ignorare questo comportamento e mantenere abilitato lo shaping dell'input, \u00e8 possibile passare un parametro aggiuntivo INPUT_SHAPING=1 al comando. 20210201: Il comando ACCELEROMETER_MEASURE aggiunger\u00e0 ora il nome del chip dell'accelerometro al nome del file di output se al chip \u00e8 stato assegnato un nome nella corrispondente sezione adxl345 di printer.cfg. 20201222: L'impostazione step_distance nelle sezioni di configurazione dello stepper \u00e8 obsoleta. Si consiglia di aggiornare la configurazione per utilizzare l'impostazione rotation_distance . Il supporto per step_distance verr\u00e0 rimosso nel prossimo futuro. 20201218: L'impostazione endstop_phase nel modulo endstop_phase \u00e8 stata sostituita con trigger_phase . Se si utilizza il modulo fasi endstop, sar\u00e0 necessario convertire in rotation_distance e ricalibrare eventuali fasi endstop eseguendo il comando ENDSTOP_PHASE_CALIBRATE. 20201218: le stampanti rotanti delta e polari ora devono specificare un gear_ratio per i loro stepper rotanti e potrebbero non specificare pi\u00f9 un parametro step_distance . Vedere il riferimento di configurazione per il formato del nuovo parametro gear_ratio. 20201213: Non \u00e8 valido specificare una Z \"position_endstop\" quando si utilizza \"probe:z_virtual_endstop\". Verr\u00e0 ora generato un errore se viene specificata una Z \"position_endstop\" con \"probe:z_virtual_endstop\". Rimuovere la definizione Z \"position_endstop\" per correggere l'errore. 20201120: La sezione di configurazione [board_pins] ora specifica il nome mcu in un parametro esplicito mcu: . Se si utilizza board_pins per un mcu secondario, \u00e8 necessario aggiornare la configurazione per specificare quel nome. Vedere il riferimento di configurazione per ulteriori dettagli. 20201112: Il tempo riportato da print_stats.print_duration \u00e8 cambiato. La durata precedente alla prima estrusione rilevata \u00e8 ora esclusa. 20201029: L'opzione di configurazione color_order_GRB di neopixel \u00e8 stata rimossa. Se necessario, aggiorna la configurazione per impostare la nuova opzione color_order su RGB, GRB, RGBW o GRBW. 20201029: L'opzione seriale nella sezione di configurazione di mcu non \u00e8 pi\u00f9 impostata su /dev/ttyS0. Nella rara situazione in cui /dev/ttyS0 \u00e8 la porta seriale desiderata, deve essere specificata esplicitamente. 20201020: Klipper v0.9.0 rilasciato. 20200902: Il calcolo della resistenza-to-temperatura dell'RTD per i convertitori MAX31865 \u00e8 stato corretto in modo che non fosse basso. Se si utilizza un dispositivo di questo tipo, \u00e8 necessario ricalibrare la temperatura di stampa e le impostazioni PID. 20200816: L'oggetto printer.gcode della macro gcode \u00e8 stato rinominato in printer.gcode_move . Diverse variabili non documentate in printer.toolhead e printer.gcode sono state rimosse. Vedere docs/Command_Templates.md per un elenco delle variabili di modello disponibili. 20200816: Il sistema \"action_\" della macro gcode \u00e8 cambiato. Sostituisci tutte le chiamate a printer.gcode.action_emergency_stop() con action_emergency_stop() , printer.gcode.action_respond_info() con action_respond_info() e printer.gcode.action_respond_error() con action_raise_error( ) . 20200809: Il sistema di menu \u00e8 stato riscritto. Se il menu \u00e8 stato personalizzato sar\u00e0 necessario aggiornare alla nuova configurazione. Vedere config/example-menu.cfg per i dettagli di configurazione e vedere klippy/extras/display/menu.cfg per esempi. 20200731: Il comportamento dell'attributo progress riportato dall'oggetto stampante virtual_sdcard \u00e8 cambiato. L'avanzamento non viene pi\u00f9 reimpostato su 0 quando una stampa viene sospesa. Ora riporter\u00e0 sempre lo stato di avanzamento in base alla posizione interna del file o 0 se nessun file \u00e8 attualmente caricato. 20200725: Il parametro di configurazione servo enable e il parametro SET_SERVO ENABLE sono stati rimossi. Aggiorna qualsiasi macro per usare SET_SERVO SERVO=my_servo WIDTH=0 per disabilitare un servo. 20200608: Il supporto del display LCD ha cambiato il nome di alcuni \"glifi\" interni. Se \u00e8 stato implementato un layout di visualizzazione personalizzato, potrebbe essere necessario aggiornare ai nomi dei glifi pi\u00f9 recenti (consultare klippy/extras/display/display.cfg per un elenco dei glifi disponibili). 20200606: i nomi dei pin su Linux Mcu sono cambiati. I pin ora hanno nomi nella forma gpiochip/gpio . Per gpiochip0 puoi anche usare un breve gpio . Ad esempio, ci\u00f2 che prima veniva chiamato P20 ora diventa gpio20 o gpiochip0/gpio20 . 20200603: il layout LCD 16x4 predefinito non mostrer\u00e0 pi\u00f9 il tempo rimanente stimato in una stampa. (Verr\u00e0 mostrato solo il tempo trascorso.) Se si desidera il vecchio comportamento, \u00e8 possibile personalizzare la visualizzazione del menu con tali informazioni (vedere la descrizione di display_data in config/example-extras.cfg per i dettagli). 20200531: l'ID prodotto/fornitore USB predefinito \u00e8 ora 0x1d50/0x614e. Questi nuovi ID sono riservati a Klipper (grazie al progetto openmoko). Questa modifica non dovrebbe richiedere alcuna modifica alla configurazione, ma i nuovi ID potrebbero essere visualizzati nei registri di sistema. 20200524: Il valore predefinito per il campo tmc5160 pwm_freq \u00e8 ora zero (anzich\u00e9 uno). 20200425: La variabile del modello di comando gcode_macro printer.heater \u00e8 stata rinominata printer.heaters . 20200313: Il layout lcd predefinito per le stampanti multiestrusore con schermo 16x4 \u00e8 cambiato. Il layout dello schermo del singolo estrusore \u00e8 ora quello predefinito e mostrer\u00e0 l'estrusore attualmente attivo. Per utilizzare il layout di visualizzazione precedente, impostare \"display_group: _multiextruder_16x4\" nella sezione [display] del file printer.cfg. 20200308: La voce di menu predefinita __test \u00e8 stata rimossa. Se il file di configurazione ha un menu personalizzato, assicurati di rimuovere tutti i riferimenti a questa voce di menu __test . 20200308: le opzioni del menu \"deck\" e \"card\" sono state rimosse. Per personalizzare il layout di uno schermo lcd utilizzare le nuove sezioni display_data config (vedi config/example-extras.cfg per i dettagli). 20200109: Il modulo bed_mesh ora fa riferimento alla posizione della sonda per la configurazione della mesh. Pertanto, alcune opzioni di configurazione sono state rinominate per riflettere in modo pi\u00f9 accurato la funzionalit\u00e0 prevista. Per i piatti rettangolari, min_point e max_point sono stati rinominati rispettivamente in mesh_min e mesh_max . Per i piatti rotondi, bed_radius \u00e8 stato rinominato in mesh_radius . \u00c8 stata aggiunta anche una nuova opzione mesh_origin per i piatti rotondi. Si noti che queste modifiche sono anche incompatibili con i profili mesh salvati in precedenza. Se viene rilevato un profilo incompatibile, verr\u00e0 ignorato e pianificato per la rimozione. Il processo di rimozione pu\u00f2 essere completato emettendo il comando SAVE_CONFIG. L'utente dovr\u00e0 ricalibrare ogni profilo. 20191218: la sezione di configurazione del display non supporta pi\u00f9 \"lcd_type: st7567\". Usa invece il tipo di visualizzazione \"uc1701\" - imposta \"lcd_type: uc1701\" e cambia \"rs_pin: some_pin\" in \"rst_pin: some_pin\". Potrebbe anche essere necessario aggiungere un'impostazione di configurazione \"contrasto: 60\". 20191210: I comandi integrati T0, T1, T2, ... sono stati rimossi. Le opzioni di configurazione activate_gcode e deactivate_gcode dell'estrusore sono state rimosse. Se questi comandi (e script) sono necessari, definire le singole macro di stile [gcode_macro T0] che chiamano il comando ACTIVATE_EXTRUDER. Vedere i file config/sample-idex.cfg e sample-multi-extruder.cfg per esempi. 20191210: il supporto per il comando M206 \u00e8 stato rimosso. Sostituisci con chiamate a SET_GCODE_OFFSET. Se \u00e8 necessario il supporto per M206, aggiungere una sezione di configurazione [gcode_macro M206] che richiami SET_GCODE_OFFSET. (Ad esempio \"SET_GCODE_OFFSET Z=-{params.Z}\".) 20191202: il supporto per il parametro \"S\" non documentato del comando \"G4\" \u00e8 stato rimosso. Sostituire eventuali occorrenze di S con il parametro \"P\" standard (il ritardo specificato in millisecondi). 20191126: i nomi USB sono cambiati sui microcontrollori con supporto USB nativo. Ora usano un ID chip univoco per impostazione predefinita (ove disponibile). Se una sezione di configurazione \"mcu\" utilizza un'impostazione \"serial\" che inizia con \"/dev/serial/by-id/\", potrebbe essere necessario aggiornare la configurazione. Esegui \"ls /dev/serial/by-id/*\" in un terminale ssh per determinare il nuovo ID. 20191121: il parametro pressure_advance_lookahead_time \u00e8 stato rimosso. Vedere example.cfg per impostazioni di configurazione alternative. 20191112: la funzionalit\u00e0 di abilitazione virtuale del driver stepper tmc \u00e8 ora abilitata automaticamente se lo stepper non dispone di un pin di abilitazione stepper dedicato. Rimuovere i riferimenti a tmcXXXX:virtual_enable dal file config. La possibilit\u00e0 di controllare pi\u00f9 pin nella configurazione stepper enable_pin \u00e8 stata rimossa. Se sono necessari pi\u00f9 pin, utilizzare una sezione di configurazione multi_pin. 20191107: La sezione di configurazione dell'estrusore primario deve essere specificata come \"extruder\" e non pu\u00f2 pi\u00f9 essere specificata come \"extruder0\". I modelli di comando Gcode che richiedono lo stato dell'estrusore sono ora accessibili tramite \"{printer.extruder}\". 20191021: Klipper v0.8.0 rilasciato 20191003: L'opzione move_to_previous in [safe_z_homing] ora \u00e8 impostata su False. (Era effettivamente Falso prima del 20190918.) 20190918: L'opzione zhop in [safe_z_homing] viene sempre riapplicata dopo il completamento dell'homing dell'asse Z. Ci\u00f2 potrebbe richiedere agli utenti di aggiornare gli script personalizzati basati su questo modulo. 20190806: Il comando SET_NEOPIXEL \u00e8 stato rinominato in SET_LED. 20190726: il codice del dac mcp4728 \u00e8 cambiato. L'indirizzo i2c predefinito \u00e8 ora 0x60 e il riferimento di tensione \u00e8 ora relativo al riferimento interno di 2,048 volt del mcp4728. 20190710: l'opzione z_hop \u00e8 stata rimossa dalla sezione di configurazione [firmware_retract]. Il supporto z_hop era incompleto e potrebbe causare un comportamento errato con diversi filtri dei dati comuni. 20190710: I parametri opzionali del comando PROBE_ACCURACY sono stati modificati. Potrebbe essere necessario aggiornare eventuali macro o script che utilizzano quel comando. 20190628: tutte le opzioni di configurazione sono state rimosse dalla sezione [skew_correction]. La configurazione per skew_correction viene ora eseguita tramite il gcode SET_SKEW. Vedere Correzione inclinazione per l'utilizzo consigliato. 20190607: I parametri \"variable_X\" di gcode_macro (insieme al parametro VALUE di SET_GCODE_VARIABLE) vengono ora analizzati come valori literals di Python. Se \u00e8 necessario assegnare un valore a una stringa, racchiudere il valore tra virgolette in modo che venga valutato come una stringa. 20190606: le opzioni di configurazione \"samples\", \"samples_result\" e \"sample_retract_dist\" sono state spostate nella sezione di configurazione \"probe\". Queste opzioni non sono pi\u00f9 supportate nelle sezioni di configurazione \"delta_calibrate\", \"bed_tilt\", \"bed_mesh\", \"screws_tilt_adjust\", \"z_tilt\" o \"quad_gantry_level\". 20190528: La variabile magica \"status\" nella valutazione del modello gcode_macro \u00e8 stata rinominata \"printer\". 20190520: Il comando SET_GCODE_OFFSET \u00e8 stato modificato; aggiorna tutte le macro del codice g di conseguenza. Il comando non applicher\u00e0 pi\u00f9 l'offset richiesto al successivo comando G1. Il vecchio comportamento pu\u00f2 essere approssimato utilizzando il nuovo parametro \"MOVE=1\". 20190404: i pacchetti software host Python sono stati aggiornati. Gli utenti dovranno eseguire nuovamente lo script ~/klipper/scripts/install-octopi.sh (o in altro modo aggiornare le dipendenze di Python se non si utilizza un'installazione OctoPi standard). 20190404: I parametri i2c_bus e spi_bus (in varie sezioni di configurazione) ora prendono un nome bus anzich\u00e9 un numero. 20190404: I parametri di configurazione sx1509 sono stati modificati. Il parametro 'address' ora \u00e8 'i2c_address' e deve essere specificato come numero decimale. Dove 0x3E \u00e8 stato utilizzato in precedenza, specificare 62. 20190328: Il valore min_speed nella configurazione [temperature_fan] verr\u00e0 ora rispettato e la ventola funzioner\u00e0 sempre a questa velocit\u00e0 o superiore in modalit\u00e0 PID. 20190322: il valore predefinito per \"driver_HEND\" nelle sezioni di configurazione [tmc2660] \u00e8 stato modificato da 6 a 3. Il campo \"driver_VSENSE\" \u00e8 stato rimosso (ora viene calcolato automaticamente da run_current). 20190310: La sezione di configurazione [controller_fan] ora prende sempre un nome (come [controller_fan my_controller_fan]). 20190308: Il campo \"driver_BLANK_TIME_SELECT\" nelle sezioni di configurazione [tmc2130] e [tmc2208] \u00e8 stato rinominato in \"driver_TBL\". 20190308: la sezione di configurazione [tmc2660] \u00e8 stata modificata. Ora deve essere fornito un nuovo parametro di configurazione sense_resistor. Il significato di molti dei parametri driver_XXX \u00e8 cambiato. 20190228: gli utenti di SPI o I2C su schede SAMD21 devono ora specificare i pin del bus tramite una sezione di configurazione [samd_sercom]. 20190224: l'opzione bed_shape \u00e8 stata rimossa da bed_mesh. L'opzione raggio \u00e8 stata rinominata bed_radius. Gli utenti con letti rotondi dovrebbero fornire le opzioni bed_radius e round_probe_count. 20190107: il parametro i2c_address nella sezione di configurazione mcp4451 \u00e8 stato modificato. Questa \u00e8 un'impostazione comune su Smoothieboards. Il nuovo valore \u00e8 la met\u00e0 del vecchio valore (88 dovrebbe essere cambiato in 44 e 90 dovrebbe essere cambiato in 45). 20181220: Klipper v0.7.0 rilasciato","title":"Modifiche alla configurazione"},{"location":"Config_Changes.html#modifiche-alla-configurazione","text":"Questo documento copre le modifiche software recenti al file di configurazione che non sono compatibili con le versioni precedenti. \u00c8 una buona idea rivedere questo documento durante l'aggiornamento del software Klipper. Tutte le date in questo documento sono approssimative.","title":"Modifiche alla configurazione"},{"location":"Config_Changes.html#cambiamenti","text":"20230826: If safe_distance is set or calculated to be 0 in [dual_carriage] , the carriages proximity checks will be disabled as per documentation. A user may wish to configure safe_distance explicitly to prevent accidental crashes of the carriages with each other. Additionally, the homing order of the primary and the dual carriage is changed in some configurations (certain configurations when both carriages home in the same direction, see [dual_carriage] configuration reference for more details). 20230810: The flash-sdcard.sh script now supports both variants of the Bigtreetech SKR-3, STM32H743 and STM32H723. For this, the original tag of btt-skr-3 now has changed to be either btt-skr-3-h743 or btt-skr-3-h723. 20230729: The exported status for dual_carriage is changed. Instead of exporting mode and active_carriage , the individual modes for each carriage are exported as printer.dual_carriage.carriage_0 and printer.dual_carriage.carriage_1 . 20230619: The relative_reference_index option has been deprecated and superceded by the zero_reference_position option. Refer to the Bed Mesh Documentation for details on how to update the configuration. With this deprecation the RELATIVE_REFERENCE_INDEX is no longer available as a parameter for the BED_MESH_CALIBRATE gcode command. 20230530: The default canbus frequency in \"make menuconfig\" is now 1000000. If using canbus and using canbus with some other frequency is required, then be sure to select \"Enable extra low-level configuration options\" and specify the desired \"CAN bus speed\" in \"make menuconfig\" when compiling and flashing the micro-controller. 20230525: SHAPER_CALIBRATE command immediately applies input shaper parameters if [input_shaper] was enabled already. 20230407: The stalled_bytes counter in the log and in the printer.mcu.last_stats field has been renamed to upcoming_bytes . 20230323: On tmc5160 drivers multistep_filt is now enabled by default. Set driver_MULTISTEP_FILT: False in the tmc5160 config for the previous behavior. 20230304: Il comando SET_TMC_CURRENT ora regola correttamente il registro globalscaler per i driver che lo dispongono. Ci\u00f2 rimuove una limitazione per cui su tmc5160, le correnti non potevano essere aumentate con SET_TMC_CURRENT rispetto al valore run_current impostato nel file di configurazione. Tuttavia, questo ha un effetto collaterale: dopo aver eseguito SET_TMC_CURRENT , lo stepper deve essere tenuto fermo per >130 ms nel caso in cui venga utilizzato StealthChop2 in modo che la calibrazione AT#1 venga eseguita dal driver. 20230202: il formato delle informazioni sullo stato di printer.screws_tilt_adjust \u00e8 stato modificato. Le informazioni vengono ora memorizzate come dizionario delle viti con le misurazioni risultanti. Consulta il riferimento sullo stato per i dettagli. 20230201: Il modulo [bed_mesh] non carica pi\u00f9 il profilo default all'avvio. Si consiglia agli utenti che usano il profilo default di aggiungere BED_MESH_PROFILE LOAD=default alla loro macro START_PRINT (o alla configurazione \"Start G-Code\" del loro slicer quando applicabile). 20230103: Ora \u00e8 possibile con lo script flash-sdcard.sh eseguire il flashing di entrambe le varianti di Bigtreetech SKR-2, STM32F407 e STM32F429. Ci\u00f2 significa che il tag originale di btt-skr2 ora \u00e8 cambiato in btt-skr-2-f407 o btt-skr-2-f429. 20221128: rilascio di Klipper v0.11.0. 20221122: In precedenza, con safe_z_home, era possibile che z_hop dopo l'homing g28 andasse nella direzione z negativa. Ora, uno z_hop viene eseguito dopo g28 solo se risulta in un hop positivo, rispecchiando il comportamento dello z_hop che si verifica prima dell'homing g28. 20220616: in precedenza era possibile eseguire il flashing di un rp2040 in modalit\u00e0 bootloader eseguendo make flash FLASH_DEVICE=first . Il comando equivalente \u00e8 ora make flash FLASH_DEVICE=2e8a:0003 . 20220612: Il microcontrollore rp2040 ora ha una soluzione alternativa per l'errata USB \"rp2040-e5\". Ci\u00f2 dovrebbe rendere pi\u00f9 affidabili le connessioni USB iniziali. Tuttavia, potrebbe comportare un cambiamento nel comportamento del pin gpio15. \u00c8 improbabile che il cambiamento di comportamento di gpio15 sia evidente. 20220407: l'opzione di configurazione temperature_fan pid_integral_max \u00e8 stata rimossa (era deprecata su 20210612). 20220407: L'ordine dei colori predefinito per i LED pca9632 \u00e8 ora \"RGBW\". Aggiungi un'impostazione esplicita color_order: RBGW alla sezione di configurazione di pca9632 per ottenere il comportamento precedente. 20220330: Il formato delle informazioni di stato printer.neopixel.color_data per i moduli neopixel e dotstar \u00e8 cambiato. Le informazioni sono ora memorizzate come un elenco di elenchi di colori (invece di un elenco di dizionari). Per i dettagli, vedere il riferimento dello stato . 20220307: M73 non imposter\u00e0 pi\u00f9 l'avanzamento della stampa su 0 se manca P . 20220304: Non esiste pi\u00f9 un valore predefinito per il parametro extruder delle sezioni di configurazione extruder_stepper . Se lo si desidera, specificare esplicitamente extruder: extruder per associare il motore passo-passo alla coda di movimento \"estrusore\" all'avvio. 20220210: Il comando SYNC_STEPPER_TO_EXTRUDER \u00e8 deprecato; il comando SET_EXTRUDER_STEP_DISTANCE \u00e8 deprecato; l'opzione di configurazione extruder shared_heater \u00e8 deprecata. Queste funzionalit\u00e0 verranno rimosse nel prossimo futuro. Sostituisci SET_EXTRUDER_STEP_DISTANCE con SET_EXTRUDER_ROTATION_DISTANCE . Sostituisci SYNC_STEPPER_TO_EXTRUDER con SYNC_EXTRUDER_MOTION . Sostituisci le sezioni di configurazione dell'estrusore usando shared_heater con le sezioni di configurazione extruder_stepper e aggiorna le macro di attivazione per usare SYNC_EXTRUDER_MOTION . 20220116: Il codice di calcolo della run_current per tmc2130, tmc2208, tmc2209 e tmc2660 \u00e8 cambiato. Per alcune impostazioni di run_current i driver possono ora essere configurati in modo diverso. Questa nuova configurazione dovrebbe essere pi\u00f9 accurata, ma potrebbe invalidare la precedente ottimizzazione del driver tmc. 20211230: Gli script per ottimizzare l'input shaper ( scripts/calibrate_shaper.py e scripts/graph_accelerometer.py ) sono stati migrati per utilizzare Python3 per impostazione predefinita. Di conseguenza, gli utenti devono installare le versioni Python3 di determinati pacchetti (ad esempio sudo apt install python3-numpy python3-matplotlib ) per continuare a utilizzare questi script. Per maggiori dettagli, fare riferimento a Installazione del software . In alternativa, gli utenti possono forzare temporaneamente l'esecuzione di questi script in Python 2 chiamando esplicitamente l'interprete Python2 nella console: python2 ~/klipper/scripts/calibrate_shaper.py ... 20211110: Il sensore di temperatura \"NTC 100K beta 3950\" \u00e8 obsoleto. Questo sensore verr\u00e0 rimosso nel prossimo futuro. La maggior parte degli utenti trover\u00e0 il sensore di temperatura \"Generico 3950\" pi\u00f9 accurato. Per continuare a utilizzare la definizione precedente (in genere meno accurata), definire un termistore personalizzato con temperature1: 25 , resistance1: 100000 e beta: 3950 . 20211104: L'opzione \"step pulse duration\" in \"make menuconfig\" \u00e8 stata rimossa. La durata del passaggio predefinita per i driver TMC configurati in modalit\u00e0 UART o SPI \u00e8 ora di 100 ns. Una nuova impostazione step_pulse_duration nella sezione stepper config dovrebbe essere impostata per tutti gli stepper che necessitano di una durata dell'impulso personalizzata. 20211102: diverse funzionalit\u00e0 deprecate sono state rimosse. L'opzione stepper step_distance \u00e8 stata rimossa (obsoleta nel 20201222). L'alias del sensore rpi_temperature \u00e8 stato rimosso (obsoleto il 20210219). L'opzione mcu pin_map \u00e8 stata rimossa (deprecata su 20210325). La gcode_macro default_parameter_ e l'accesso macro ai parametri dei comandi diversi dalla pseudo-variabile params sono stati rimossi (deprecato in 20210503). L'opzione del riscaldatore pid_integral_max \u00e8 stata rimossa (obsoleta il 20210612). 20210929: Klipper v0.10.0 rilasciato. 20210903: Il valore predefinito smooth_time per i riscaldatori \u00e8 cambiato in 1 secondo (da 2 secondi). Per la maggior parte delle stampanti ci\u00f2 si tradurr\u00e0 in un controllo della temperatura pi\u00f9 stabile. 20210830: il nome adxl345 predefinito \u00e8 ora \"adxl345\". Il parametro CHIP predefinito per ACCELEROMETER_MEASURE e ACCELEROMETER_QUERY ora \u00e8 \"adxl345\". 20210830: il comando adxl345 ACCELEROMETER_MEASURE non supporta pi\u00f9 un parametro RATE. Per modificare la frequenza delle query, aggiornare il file printer.cfg ed eseguire un comando RESTART. 20210821: Diverse impostazioni di configurazione in printer.configfile.settings verranno ora riportate come elenchi anzich\u00e9 come stringhe grezze. Se si desidera la stringa grezza effettiva, utilizzare invece printer.configfile.config . 20210819: In alcuni casi, un movimento di riferimento G28 pu\u00f2 terminare in una posizione che \u00e8 nominalmente al di fuori dell'intervallo di movimento valido. In rare situazioni ci\u00f2 pu\u00f2 causare errori di \"spostamento fuori portata\" confusi dopo l'homing. In tal caso, modificare gli script di avvio per spostare la testa utensile in una posizione valida subito dopo l'homing. 20210814: Gli pseudo-pin solo analogici su atmega168 e atmega328 sono stati rinominati da PE0/PE1 a PE2/PE3. 20210720: una sezione controller_fan ora monitora tutti i motori passo-passo per impostazione predefinita (non solo i motori passo-passo cinematici). Se si desidera il comportamento precedente, vedere l'opzione di configurazione stepper nel riferimento di configurazione . 20210703: Una sezione di configurazione samd_sercom deve ora specificare il bus sercom che sta configurando tramite l'opzione sercom . 20210612: L'opzione di configurazione pid_integral_max nelle sezioni riscaldatore e temperature_fan \u00e8 obsoleta. L'opzione verr\u00e0 rimossa nel prossimo futuro. 20210503: The gcode_macro default_parameter_ config option is deprecated. Use the params pseudo-variable to access macro parameters. Other methods for accessing macro parameters will be removed in the near future. Most users can replace a default_parameter_NAME: VALUE config option with a line like the following in the start of the macro: {% set NAME = params.NAME|default(VALUE)|float %} . See the Command Templates document for examples. 20210430: il comando SET_VELOCITY_LIMIT (e M204) ora pu\u00f2 impostare una velocit\u00e0, un'accelerazione e una square_corner_velocity maggiori dei valori specificati nel file di configurazione. 20210325: il supporto per l'opzione di configurazione pin_map \u00e8 deprecato. Utilizzare il file sample-aliases.cfg per tradurre i nomi dei pin del microcontroller effettivi. L'opzione di configurazione pin_map verr\u00e0 rimossa nel prossimo futuro. 20210313: Il supporto di Klipper per i microcontrollori che comunicano con il bus CAN \u00e8 cambiato. Se si utilizza il bus CAN, \u00e8 necessario eseguire nuovamente il flashing di tutti i microcontrollori e la configurazione di Klipper deve essere aggiornata . 20210310: Il valore predefinito TMC2660 per driver_SFILT \u00e8 stato modificato da 1 a 0. 20210227: I driver del motore passo-passo TMC in modalit\u00e0 UART o SPI ora vengono interrogati una volta al secondo ogni volta che sono abilitati - se il driver non pu\u00f2 essere contattato o se il driver segnala un errore, Klipper passer\u00e0 allo stato di spegnimento. 20210219: Il modulo rpi_temperature \u00e8 stato rinominato in temperature_host . Sostituisci tutte le occorrenze di sensor_type: rpi_temperature con sensor_type: temperature_host . Il percorso del file di temperatura pu\u00f2 essere specificato nella variabile di configurazione sensor_path . Il nome rpi_temperature \u00e8 deprecato e verr\u00e0 rimosso nel prossimo futuro. 20210201: Il comando TEST_RESONANCES ora disabiliter\u00e0 l'input shaping se era stato precedentemente abilitato (e lo riattiver\u00e0 dopo il test). Per ignorare questo comportamento e mantenere abilitato lo shaping dell'input, \u00e8 possibile passare un parametro aggiuntivo INPUT_SHAPING=1 al comando. 20210201: Il comando ACCELEROMETER_MEASURE aggiunger\u00e0 ora il nome del chip dell'accelerometro al nome del file di output se al chip \u00e8 stato assegnato un nome nella corrispondente sezione adxl345 di printer.cfg. 20201222: L'impostazione step_distance nelle sezioni di configurazione dello stepper \u00e8 obsoleta. Si consiglia di aggiornare la configurazione per utilizzare l'impostazione rotation_distance . Il supporto per step_distance verr\u00e0 rimosso nel prossimo futuro. 20201218: L'impostazione endstop_phase nel modulo endstop_phase \u00e8 stata sostituita con trigger_phase . Se si utilizza il modulo fasi endstop, sar\u00e0 necessario convertire in rotation_distance e ricalibrare eventuali fasi endstop eseguendo il comando ENDSTOP_PHASE_CALIBRATE. 20201218: le stampanti rotanti delta e polari ora devono specificare un gear_ratio per i loro stepper rotanti e potrebbero non specificare pi\u00f9 un parametro step_distance . Vedere il riferimento di configurazione per il formato del nuovo parametro gear_ratio. 20201213: Non \u00e8 valido specificare una Z \"position_endstop\" quando si utilizza \"probe:z_virtual_endstop\". Verr\u00e0 ora generato un errore se viene specificata una Z \"position_endstop\" con \"probe:z_virtual_endstop\". Rimuovere la definizione Z \"position_endstop\" per correggere l'errore. 20201120: La sezione di configurazione [board_pins] ora specifica il nome mcu in un parametro esplicito mcu: . Se si utilizza board_pins per un mcu secondario, \u00e8 necessario aggiornare la configurazione per specificare quel nome. Vedere il riferimento di configurazione per ulteriori dettagli. 20201112: Il tempo riportato da print_stats.print_duration \u00e8 cambiato. La durata precedente alla prima estrusione rilevata \u00e8 ora esclusa. 20201029: L'opzione di configurazione color_order_GRB di neopixel \u00e8 stata rimossa. Se necessario, aggiorna la configurazione per impostare la nuova opzione color_order su RGB, GRB, RGBW o GRBW. 20201029: L'opzione seriale nella sezione di configurazione di mcu non \u00e8 pi\u00f9 impostata su /dev/ttyS0. Nella rara situazione in cui /dev/ttyS0 \u00e8 la porta seriale desiderata, deve essere specificata esplicitamente. 20201020: Klipper v0.9.0 rilasciato. 20200902: Il calcolo della resistenza-to-temperatura dell'RTD per i convertitori MAX31865 \u00e8 stato corretto in modo che non fosse basso. Se si utilizza un dispositivo di questo tipo, \u00e8 necessario ricalibrare la temperatura di stampa e le impostazioni PID. 20200816: L'oggetto printer.gcode della macro gcode \u00e8 stato rinominato in printer.gcode_move . Diverse variabili non documentate in printer.toolhead e printer.gcode sono state rimosse. Vedere docs/Command_Templates.md per un elenco delle variabili di modello disponibili. 20200816: Il sistema \"action_\" della macro gcode \u00e8 cambiato. Sostituisci tutte le chiamate a printer.gcode.action_emergency_stop() con action_emergency_stop() , printer.gcode.action_respond_info() con action_respond_info() e printer.gcode.action_respond_error() con action_raise_error( ) . 20200809: Il sistema di menu \u00e8 stato riscritto. Se il menu \u00e8 stato personalizzato sar\u00e0 necessario aggiornare alla nuova configurazione. Vedere config/example-menu.cfg per i dettagli di configurazione e vedere klippy/extras/display/menu.cfg per esempi. 20200731: Il comportamento dell'attributo progress riportato dall'oggetto stampante virtual_sdcard \u00e8 cambiato. L'avanzamento non viene pi\u00f9 reimpostato su 0 quando una stampa viene sospesa. Ora riporter\u00e0 sempre lo stato di avanzamento in base alla posizione interna del file o 0 se nessun file \u00e8 attualmente caricato. 20200725: Il parametro di configurazione servo enable e il parametro SET_SERVO ENABLE sono stati rimossi. Aggiorna qualsiasi macro per usare SET_SERVO SERVO=my_servo WIDTH=0 per disabilitare un servo. 20200608: Il supporto del display LCD ha cambiato il nome di alcuni \"glifi\" interni. Se \u00e8 stato implementato un layout di visualizzazione personalizzato, potrebbe essere necessario aggiornare ai nomi dei glifi pi\u00f9 recenti (consultare klippy/extras/display/display.cfg per un elenco dei glifi disponibili). 20200606: i nomi dei pin su Linux Mcu sono cambiati. I pin ora hanno nomi nella forma gpiochip/gpio . Per gpiochip0 puoi anche usare un breve gpio . Ad esempio, ci\u00f2 che prima veniva chiamato P20 ora diventa gpio20 o gpiochip0/gpio20 . 20200603: il layout LCD 16x4 predefinito non mostrer\u00e0 pi\u00f9 il tempo rimanente stimato in una stampa. (Verr\u00e0 mostrato solo il tempo trascorso.) Se si desidera il vecchio comportamento, \u00e8 possibile personalizzare la visualizzazione del menu con tali informazioni (vedere la descrizione di display_data in config/example-extras.cfg per i dettagli). 20200531: l'ID prodotto/fornitore USB predefinito \u00e8 ora 0x1d50/0x614e. Questi nuovi ID sono riservati a Klipper (grazie al progetto openmoko). Questa modifica non dovrebbe richiedere alcuna modifica alla configurazione, ma i nuovi ID potrebbero essere visualizzati nei registri di sistema. 20200524: Il valore predefinito per il campo tmc5160 pwm_freq \u00e8 ora zero (anzich\u00e9 uno). 20200425: La variabile del modello di comando gcode_macro printer.heater \u00e8 stata rinominata printer.heaters . 20200313: Il layout lcd predefinito per le stampanti multiestrusore con schermo 16x4 \u00e8 cambiato. Il layout dello schermo del singolo estrusore \u00e8 ora quello predefinito e mostrer\u00e0 l'estrusore attualmente attivo. Per utilizzare il layout di visualizzazione precedente, impostare \"display_group: _multiextruder_16x4\" nella sezione [display] del file printer.cfg. 20200308: La voce di menu predefinita __test \u00e8 stata rimossa. Se il file di configurazione ha un menu personalizzato, assicurati di rimuovere tutti i riferimenti a questa voce di menu __test . 20200308: le opzioni del menu \"deck\" e \"card\" sono state rimosse. Per personalizzare il layout di uno schermo lcd utilizzare le nuove sezioni display_data config (vedi config/example-extras.cfg per i dettagli). 20200109: Il modulo bed_mesh ora fa riferimento alla posizione della sonda per la configurazione della mesh. Pertanto, alcune opzioni di configurazione sono state rinominate per riflettere in modo pi\u00f9 accurato la funzionalit\u00e0 prevista. Per i piatti rettangolari, min_point e max_point sono stati rinominati rispettivamente in mesh_min e mesh_max . Per i piatti rotondi, bed_radius \u00e8 stato rinominato in mesh_radius . \u00c8 stata aggiunta anche una nuova opzione mesh_origin per i piatti rotondi. Si noti che queste modifiche sono anche incompatibili con i profili mesh salvati in precedenza. Se viene rilevato un profilo incompatibile, verr\u00e0 ignorato e pianificato per la rimozione. Il processo di rimozione pu\u00f2 essere completato emettendo il comando SAVE_CONFIG. L'utente dovr\u00e0 ricalibrare ogni profilo. 20191218: la sezione di configurazione del display non supporta pi\u00f9 \"lcd_type: st7567\". Usa invece il tipo di visualizzazione \"uc1701\" - imposta \"lcd_type: uc1701\" e cambia \"rs_pin: some_pin\" in \"rst_pin: some_pin\". Potrebbe anche essere necessario aggiungere un'impostazione di configurazione \"contrasto: 60\". 20191210: I comandi integrati T0, T1, T2, ... sono stati rimossi. Le opzioni di configurazione activate_gcode e deactivate_gcode dell'estrusore sono state rimosse. Se questi comandi (e script) sono necessari, definire le singole macro di stile [gcode_macro T0] che chiamano il comando ACTIVATE_EXTRUDER. Vedere i file config/sample-idex.cfg e sample-multi-extruder.cfg per esempi. 20191210: il supporto per il comando M206 \u00e8 stato rimosso. Sostituisci con chiamate a SET_GCODE_OFFSET. Se \u00e8 necessario il supporto per M206, aggiungere una sezione di configurazione [gcode_macro M206] che richiami SET_GCODE_OFFSET. (Ad esempio \"SET_GCODE_OFFSET Z=-{params.Z}\".) 20191202: il supporto per il parametro \"S\" non documentato del comando \"G4\" \u00e8 stato rimosso. Sostituire eventuali occorrenze di S con il parametro \"P\" standard (il ritardo specificato in millisecondi). 20191126: i nomi USB sono cambiati sui microcontrollori con supporto USB nativo. Ora usano un ID chip univoco per impostazione predefinita (ove disponibile). Se una sezione di configurazione \"mcu\" utilizza un'impostazione \"serial\" che inizia con \"/dev/serial/by-id/\", potrebbe essere necessario aggiornare la configurazione. Esegui \"ls /dev/serial/by-id/*\" in un terminale ssh per determinare il nuovo ID. 20191121: il parametro pressure_advance_lookahead_time \u00e8 stato rimosso. Vedere example.cfg per impostazioni di configurazione alternative. 20191112: la funzionalit\u00e0 di abilitazione virtuale del driver stepper tmc \u00e8 ora abilitata automaticamente se lo stepper non dispone di un pin di abilitazione stepper dedicato. Rimuovere i riferimenti a tmcXXXX:virtual_enable dal file config. La possibilit\u00e0 di controllare pi\u00f9 pin nella configurazione stepper enable_pin \u00e8 stata rimossa. Se sono necessari pi\u00f9 pin, utilizzare una sezione di configurazione multi_pin. 20191107: La sezione di configurazione dell'estrusore primario deve essere specificata come \"extruder\" e non pu\u00f2 pi\u00f9 essere specificata come \"extruder0\". I modelli di comando Gcode che richiedono lo stato dell'estrusore sono ora accessibili tramite \"{printer.extruder}\". 20191021: Klipper v0.8.0 rilasciato 20191003: L'opzione move_to_previous in [safe_z_homing] ora \u00e8 impostata su False. (Era effettivamente Falso prima del 20190918.) 20190918: L'opzione zhop in [safe_z_homing] viene sempre riapplicata dopo il completamento dell'homing dell'asse Z. Ci\u00f2 potrebbe richiedere agli utenti di aggiornare gli script personalizzati basati su questo modulo. 20190806: Il comando SET_NEOPIXEL \u00e8 stato rinominato in SET_LED. 20190726: il codice del dac mcp4728 \u00e8 cambiato. L'indirizzo i2c predefinito \u00e8 ora 0x60 e il riferimento di tensione \u00e8 ora relativo al riferimento interno di 2,048 volt del mcp4728. 20190710: l'opzione z_hop \u00e8 stata rimossa dalla sezione di configurazione [firmware_retract]. Il supporto z_hop era incompleto e potrebbe causare un comportamento errato con diversi filtri dei dati comuni. 20190710: I parametri opzionali del comando PROBE_ACCURACY sono stati modificati. Potrebbe essere necessario aggiornare eventuali macro o script che utilizzano quel comando. 20190628: tutte le opzioni di configurazione sono state rimosse dalla sezione [skew_correction]. La configurazione per skew_correction viene ora eseguita tramite il gcode SET_SKEW. Vedere Correzione inclinazione per l'utilizzo consigliato. 20190607: I parametri \"variable_X\" di gcode_macro (insieme al parametro VALUE di SET_GCODE_VARIABLE) vengono ora analizzati come valori literals di Python. Se \u00e8 necessario assegnare un valore a una stringa, racchiudere il valore tra virgolette in modo che venga valutato come una stringa. 20190606: le opzioni di configurazione \"samples\", \"samples_result\" e \"sample_retract_dist\" sono state spostate nella sezione di configurazione \"probe\". Queste opzioni non sono pi\u00f9 supportate nelle sezioni di configurazione \"delta_calibrate\", \"bed_tilt\", \"bed_mesh\", \"screws_tilt_adjust\", \"z_tilt\" o \"quad_gantry_level\". 20190528: La variabile magica \"status\" nella valutazione del modello gcode_macro \u00e8 stata rinominata \"printer\". 20190520: Il comando SET_GCODE_OFFSET \u00e8 stato modificato; aggiorna tutte le macro del codice g di conseguenza. Il comando non applicher\u00e0 pi\u00f9 l'offset richiesto al successivo comando G1. Il vecchio comportamento pu\u00f2 essere approssimato utilizzando il nuovo parametro \"MOVE=1\". 20190404: i pacchetti software host Python sono stati aggiornati. Gli utenti dovranno eseguire nuovamente lo script ~/klipper/scripts/install-octopi.sh (o in altro modo aggiornare le dipendenze di Python se non si utilizza un'installazione OctoPi standard). 20190404: I parametri i2c_bus e spi_bus (in varie sezioni di configurazione) ora prendono un nome bus anzich\u00e9 un numero. 20190404: I parametri di configurazione sx1509 sono stati modificati. Il parametro 'address' ora \u00e8 'i2c_address' e deve essere specificato come numero decimale. Dove 0x3E \u00e8 stato utilizzato in precedenza, specificare 62. 20190328: Il valore min_speed nella configurazione [temperature_fan] verr\u00e0 ora rispettato e la ventola funzioner\u00e0 sempre a questa velocit\u00e0 o superiore in modalit\u00e0 PID. 20190322: il valore predefinito per \"driver_HEND\" nelle sezioni di configurazione [tmc2660] \u00e8 stato modificato da 6 a 3. Il campo \"driver_VSENSE\" \u00e8 stato rimosso (ora viene calcolato automaticamente da run_current). 20190310: La sezione di configurazione [controller_fan] ora prende sempre un nome (come [controller_fan my_controller_fan]). 20190308: Il campo \"driver_BLANK_TIME_SELECT\" nelle sezioni di configurazione [tmc2130] e [tmc2208] \u00e8 stato rinominato in \"driver_TBL\". 20190308: la sezione di configurazione [tmc2660] \u00e8 stata modificata. Ora deve essere fornito un nuovo parametro di configurazione sense_resistor. Il significato di molti dei parametri driver_XXX \u00e8 cambiato. 20190228: gli utenti di SPI o I2C su schede SAMD21 devono ora specificare i pin del bus tramite una sezione di configurazione [samd_sercom]. 20190224: l'opzione bed_shape \u00e8 stata rimossa da bed_mesh. L'opzione raggio \u00e8 stata rinominata bed_radius. Gli utenti con letti rotondi dovrebbero fornire le opzioni bed_radius e round_probe_count. 20190107: il parametro i2c_address nella sezione di configurazione mcp4451 \u00e8 stato modificato. Questa \u00e8 un'impostazione comune su Smoothieboards. Il nuovo valore \u00e8 la met\u00e0 del vecchio valore (88 dovrebbe essere cambiato in 44 e 90 dovrebbe essere cambiato in 45). 20181220: Klipper v0.7.0 rilasciato","title":"Cambiamenti"},{"location":"Config_Reference.html","text":"Riferimenti configurazione \u00b6 Questo documento \u00e8 un riferimento per le opzioni disponibili nel file di configurazione di Klipper. Le descrizioni in questo documento sono formattate in modo che sia possibile tagliarle e incollarle in un file di configurazione della stampante. Consulta il documento di installazione per informazioni sulla configurazione di Klipper e sulla scelta di un file di configurazione iniziale. Configurazione del microcontrollore \u00b6 Formato dei nomi dei pin del microcontrollore \u00b6 Molte opzioni di configurazione richiedono il nome di un pin del microcontrollore. Klipper usa i nomi hardware per questi pin, ad esempio \"PA4\". I nomi dei pin possono essere preceduti da ! per indicare che deve essere utilizzata una polarit\u00e0 inversa (ad esempio, trigger su basso anzich\u00e9 alto). I pin di input possono essere preceduti da ^ per indicare che un resistore di pull-up hardware deve essere abilitato per il pin. Se il microcontrollore supporta resistori pull-down, un pin di ingresso pu\u00f2 in alternativa essere preceduto da ~ . Nota, alcune sezioni di configurazione potrebbero \"creare\" pin aggiuntivi. Quando ci\u00f2 si verifica, la sezione di configurazione che definisce i pin deve essere elencata nel file di configurazione prima di qualsiasi sezione che utilizza tali pin. [mcu] \u00b6 Configurazione del microcontrollore primario. [mcu] serial: # La porta seriale per la connessione all'MCU. In caso di dubbi (o se # cambia) vedere \"Dov'\u00e8 la mia porta seriale?\" sezione delle FAQ. # Questo parametro deve essere fornito quando si utilizza una # porta seriale. #baud: 250000 # La velocit\u00e0 di trasmissione da utilizzare. Il valore predefinito \u00e8 250000. #canbus_uuid: # Se si utilizza un dispositivo collegato a un bus CAN, questo imposta # l'identificatore univoco del chip a cui connettersi. Questo valore deve # essere fornito quando si utilizza il bus CAN per la comunicazione. #canbus_interface: # Se si utilizza un dispositivo collegato a un bus CAN, viene impostata # l'interfaccia di rete CAN da utilizzare. L'impostazione predefinita \u00e8 'can0'. #restart_method: # Questo controlla il meccanismo che l'host utilizzer\u00e0 per reimpostare # il microcontrollore. Le scelte sono \"arduino\", \"cheetah\", \"rpi_usb\" e # \"command\". Il metodo 'arduino' (attiva/disattiva DTR) \u00e8 comune su # schede Arduino e cloni. Il metodo 'cheetah' \u00e8 un metodo speciale # necessario per alcune schede Fysetc Cheetah. Il metodo \"rpi_usb\" # \u00e8 utile sulle schede Raspberry Pi con microcontrollori alimentati # tramite USB: disabilita brevemente l'alimentazione a tutte le porte # USB per eseguire un ripristino del microcontrollore. Il metodo # \"comando\" prevede l'invio di un comando Klipper al microcontrollore # in modo che possa reimpostarsi. L'impostazione predefinita \u00e8 # 'arduino' se il microcontrollore comunica su una porta seriale, # altrimenti 'comando'. [mcu my_extra_mcu] \u00b6 Microcontrollori aggiuntivi (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"mcu\"). Microcontrollori aggiuntivi introducono pin aggiuntivi che possono essere configurati come riscaldatori, stepper, ventole, ecc. Ad esempio, se viene introdotta una sezione \"[mcu extra_mcu]\", i pin come \"extra_mcu:ar9\" possono quindi essere utilizzati altrove nella configurazione (dove \"ar9\" \u00e8 un nome pin hardware o un nome alias sul dato mcu). [mcu my_extra_mcu] # Vedere la sezione \"mcu\" per i parametri di configurazione. Impostazioni cinematiche comuni \u00b6 [printer] \u00b6 La sezione printer controlla le impostazioni di alto livello della stampante. [printer] kinematics: # Il tipo di stampante in uso. Questa opzione pu\u00f2 essere una delle # seguenti: cartesian, corexy, corexz, hybrid_corexy, hybrid_corexz, # rotary_delta, delta, deltesian, polar, winch o nessuno. # Questo parametro deve essere specificato. max_velocity: # Velocit\u00e0 massima (in mm/s) della testa di stampa (relativa alla stampa). # Questo parametro deve essere specificato. max_accel: # Accelerazione massima (in mm/s^2) della testina (relativa alla stampa). # Questo parametro deve essere specificato. #max_accel_to_decel: # Una pseudo accelerazione (in mm/s^2) che controlla la velocit\u00e0 con cui # la testa di stampa pu\u00f2 passare dall'accelerazione alla decelerazione. Viene # utilizzato per ridurre la velocit\u00e0 massima di brevi movimenti a zig-zag # (e quindi ridurre le vibrazioni della stampante dovute a questi movimenti). # Il valore predefinito \u00e8 met\u00e0 di max_accel. #square_corner_velocity: 5.0 # La velocit\u00e0 massima (in mm/s) alla quale la testa di stampa pu\u00f2 viaggiare # su un angolo di 90 gradi. Un valore diverso da zero pu\u00f2 ridurre le variazioni # delle portate dell'estrusore consentendo variazioni istantanee della velocit\u00e0 # della testa utensile durante le curve. Questo valore configura l'algoritmo # interno di cornering della velocit\u00e0 centripeta; gli angoli con angoli maggiori # di 90 gradi avranno una velocit\u00e0 in curva maggiore mentre gli angoli con # angoli inferiori a 90 gradi avranno una velocit\u00e0 in curva inferiore. Se questo # \u00e8 impostato su zero, la testa utensile decelerer\u00e0 fino a zero ad ogni angolo. # Il valore predefinito \u00e8 5 mm/s. [stepper] \u00b6 Definizioni di motori passo-passo. Diversi tipi di stampante (come specificato dall'opzione \"cinematica\" nella sezione di configurazione [stampante]) richiedono nomi diversi per lo stepper (ad esempio, stepper_x vs stepper_a ). Di seguito sono riportate le definizioni comuni di stepper. Vedere il documento distanza di rotazione per informazioni sul calcolo del parametro rotation_distance . Consultare il documento Multi-MCU homing per informazioni sull'homing utilizzando pi\u00f9 microcontrollori. [stepper_x] step_pin: # Pin GPIO Step (attivato in alto) . Questo parametro deve essere fornito. dir_pin: # Pin GPIO di direzione (alto indica una direzione positiva). # Questo parametro deve essere fornito. enable_pin: # Pin GPIO di abilitazione (l'impostazione predefinita \u00e8 abilita alto; usa ! # per indicare abilita basso). Se questo parametro non viene fornito, il # driver del motore passo-passo deve essere sempre abilitato. rotation_distance: # Distanza (in mm) che l'asse percorre con una rotazione completa del # motore passo-passo (o viene specificata la marcia finale del rapporto di # trasmissione). Questo parametro deve essere fornito. microsteps: # Il numero di micropassi utilizzati dal driver del motore passo-passo. # Questo parametro deve essere fornito. #full_steps_per_rotation: 200 # Il numero di passi completi per una rotazione del motore passo-passo. # Impostarlo su 200 per un motore passo-passo da 1.8 gradi o su 400 per # un motore da 0.9 gradi. Il valore predefinito \u00e8 200. #gear_ratio: # Il rapporto di trasmissione se il motore passo-passo \u00e8 collegato all'asse # tramite un riduttore. Ad esempio, si pu\u00f2 specificare \"5:1\" se \u00e8 in uso un # riduttore 5 a 1. Se l'asse ha pi\u00f9 riduttori, \u00e8 possibile specificare un elenco # di rapporti di trasmissione separati da virgole (ad esempio, \"57:11, 2:1\"). # Se viene specificato gear_ratio, rotation_distance specifica la distanza # percorsa dall'asse per una rotazione completa dell'ingranaggio finale. # L'impostazione predefinita \u00e8 di non utilizzare un rapporto di trasmissione. #step_pulse_duration: # Il tempo minimo tra il fronte del segnale dell'impulso del passo e il # successivo fronte del segnale \"non passo\". Viene utilizzato anche per # impostare il tempo minimo tra un impulso di passo e un segnale di cambio # di direzione. L'impostazione predefinita \u00e8 0.000000100 (100ns) per gli # stepper TMC configurati in modalit\u00e0 UART o SPI e l'impostazione # predefinita \u00e8 0.000002 (che \u00e8 2us) per tutti gli altri stepper. endstop_pin: # Pin di rilevamento interruttore di fine corsa. Se questo pin di fine corsa # si trova su un mcu diverso dal motore passo-passo, abilita il # \"homing multi-mcu\". Questo parametro deve essere fornito per gli # stepper X, Y e Z su stampanti in stile cartesiano. #position_min: 0 # Distanza minima valida (in mm) alla quale l'utente pu\u00f2 comandare # il movimento dello stepper. Il valore predefinito \u00e8 0 mm. position_endstop: # Posizione del finecorsa (in mm). Questo parametro deve essere fornito # per gli stepper X, Y e Z su stampanti in stile cartesiano. position_max: # Distanza massima valida (in mm) alla quale l'utente pu\u00f2 comandare lo # spostamento dello stepper. Questo parametro deve essere fornito per # gli stepper X, Y e Z su stampanti in stile cartesiano. #homing_speed: 5.0 # Velocit\u00e0 massima (in mm/s) dello stepper durante l'homing. # Il valore predefinito \u00e8 5 mm/s. #homing_retract_dist: 5.0 # Distanza dall'arretramento (in mm) prima della corsa di riferimento # una seconda volta durante la corsa di riferimento. Impostalo a zero per # disabilitare la seconda casa. Il valore predefinito \u00e8 5 mm. #homing_retract_speed: # Velocit\u00e0 da utilizzare nella corsa di ritorno dopo l'homing nel caso in # cui questa dovesse essere diversa dalla velocit\u00e0 di homing, che \u00e8 # l'impostazione predefinita per questo parametro #second_homing_speed: # Velocit\u00e0 (in mm/s) dello stepper durante l'esecuzione del secondo # homing. L'impostazione predefinita \u00e8 homing_speed/2. #homing_positive_dir: # Se true, l'homing far\u00e0 muovere lo stepper in una direzione positiva # (allontanandosi da zero); se falso, home verso zero. \u00c8 meglio utilizzare # l'impostazione predefinita piuttosto che specificare questo parametro. # Il valore predefinito \u00e8 true se position_endstop \u00e8 vicino a position_max # false se vicino a position_min. Cinematica cartesiana \u00b6 Vedere example-cartesian.cfg per un file di configurazione della cinematica cartesiana di esempio. Qui sono descritti solo i parametri specifici delle stampanti cartesiane - vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: cartesian max_z_velocity: # Imposta la velocit\u00e0 massima (in mm/s) di movimento lungo # l'asse z. Questa impostazione pu\u00f2 essere utilizzata per limitare # la velocit\u00e0 massima del motore passo-passo z. L'impostazione # predefinita \u00e8 utilizzare max_velocity per max_z_velocity. max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento # lungo l'asse z. Limita l'accelerazione del motore passo-passo z. # L'impostazione predefinita \u00e8 utilizzare max_accel per max_z_accel. # La sezione stepper_x viene utilizzata per descrivere lo stepper # che controlla l'asse X in un robot cartesiano. [stepper_x] # La sezione stepper_y viene utilizzata per descrivere lo stepper # che controlla l'asse Y in un robot cartesiano. [stepper_y] # La sezione stepper_z viene utilizzata per descrivere lo stepper # che controlla l'asse Z in un robot cartesiano. [stepper_z] Cinematica Delta lineare \u00b6 Vedere example-delta.cfg per un file di configurazione della cinematica delta lineare di esempio. Consultare la guida alla calibrazione delta per informazioni sulla calibrazione. Qui vengono descritti solo i parametri specifici per le stampanti delta lineari - vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: delta max_z_velocity: # Per le stampanti delta questo limita la velocit\u00e0 massima (in mm/s) dei # movimenti con movimento dell'asse z. Questa impostazione pu\u00f2 essere # utilizzata per ridurre la velocit\u00e0 massima dei movimenti su/gi\u00f9 (che # richiedono una velocit\u00e0 di incremento maggiore rispetto ad altri # movimenti su una stampante delta). L'impostazione predefinita \u00e8 # utilizzare max_velocity per max_z_velocity. #max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento lungo # l'asse z. L'impostazione pu\u00f2 essere utile se la stampante pu\u00f2 # raggiungere un'accelerazione maggiore sui movimenti XY rispetto ai # movimenti Z (ad esempio, quando si utilizza l'input shaper). # L'impostazione predefinita \u00e8 utilizzare max_accel per max_z_accel. #minimum_z_position: 0 # La posizione Z minima in cui l'utente pu\u00f2 comandare alla testa di # spostarsi. Il valore predefinito \u00e8 0. delta_radius: # Raggio (in mm) del cerchio orizzontale formato dalle tre torri ad # asse lineare. Questo parametro pu\u00f2 anche essere calcolato come: # delta_radius = smooth_rod_offset - effector_offset - carriage_offset # Questo parametro deve essere fornito. #print_radius: # Il raggio (in mm) delle coordinate XY della testa di stampa valide. # \u00c8 possibile utilizzare questa impostazione per personalizzare il # controllo dell'intervallo dei movimenti della testa. Se qui # viene specificato un valore elevato, potrebbe essere possibile # comandare la collisione della testa di stampa con una torre. # L'impostazione predefinita \u00e8 usare delta_radius per print_radius # (che normalmente impedirebbe una collisione con torri). # La sezione stepper_a descrive lo stepper che controlla la torre # anteriore sinistra (a 210 gradi). Questa sezione controlla anche i # parametri di homing (velocit\u00e0 di homing, homing retract_dist) # per tutte le torri. [stepper_a] position_endstop: # Distanza (in mm) tra l'ugello e il piatto quando l'ugello si trova al # centro dell'area di costruzione e si attiva il finecorsa. Questo # parametro deve essere fornito per stepper_a; per stepper_b e # stepper_c questo parametro \u00e8 predefinito sul valore specificato # per stepper_a. arm_length: # Lunghezza (in mm) dell'asta diagonale che collega questa torre # alla testa di stampa. Questo parametro deve essere fornito per # stepper_a; per stepper_b e stepper_c questo parametro \u00e8 predefinito sul valore specificato per stepper_a. #angle: # Questa opzione specifica l'angolo (in gradi) a cui si trova la torre. # Il valore predefinito \u00e8 210 per stepper_a, 330 per stepper_b e 90 # per stepper_c. # La sezione stepper_b descrive lo stepper che controlla la torre # anteriore destra (a 330 gradi). [stepper_b] # La sezione stepper_c descrive lo stepper che controlla la torre # posteriore (a 90 gradi). [stepper_c] # La sezione delta_calibrate abilita un comando G-code esteso # DELTA_CALIBRATE in grado di calibrare le posizioni e gli angoli # dei finecorsa della torre. [delta_calibrate] radius: # Raggio (in mm) dell'area che pu\u00f2 essere sondata. Questo \u00e8 # il raggio delle coordinate dell'ugello da sondare; se si utilizza # una sonda automatica con un offset XY, scegliere un raggio # sufficientemente piccolo in modo che la sonda si adatti sempre # al piatto. Questo parametro deve essere fornito. #speed: 50 # La velocit\u00e0 (in mm/s) degli spostamenti senza probing durante # la calibrazione. Il valore predefinito \u00e8 50. #horizontal_move_z: 5 # L'altezza (in mm) a cui la testa deve essere comandata di # spostarsi appena prima di avviare un'operazione di sonda. # L'impostazione predefinita \u00e8 5. Cinematica Deltesiana \u00b6 Vedere example-deltesian.cfg per un esempio di file di configurazione della cinematica deltesiana. Qui sono descritti solo i parametri specifici per le stampanti deltesiane - vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: deltesian max_z_velocity: # For deltesian printers, this limits the maximum velocity (in mm/s) of # moves with z axis movement. This setting can be used to reduce the # maximum speed of up/down moves (which require a higher step rate # than other moves on a deltesian printer). The default is to use # max_velocity for max_z_velocity. #max_z_accel: # This sets the maximum acceleration (in mm/s^2) of movement along # the z axis. Setting this may be useful if the printer can reach higher # acceleration on XY moves than Z moves (eg, when using input shaper). # The default is to use max_accel for max_z_accel. #minimum_z_position: 0 # The minimum Z position that the user may command the head to move # to. The default is 0. #min_angle: 5 # This represents the minimum angle (in degrees) relative to horizontal # that the deltesian arms are allowed to achieve. This parameter is # intended to restrict the arms from becoming completely horizontal, # which would risk accidental inversion of the XZ axis. The default is 5. #print_width: # The distance (in mm) of valid toolhead X coordinates. One may use # this setting to customize the range checking of toolhead moves. If # a large value is specified here then it may be possible to command # the toolhead into a collision with a tower. This setting usually # corresponds to bed width (in mm). #slow_ratio: 3 # The ratio used to limit velocity and acceleration on moves near the # extremes of the X axis. If vertical distance divided by horizontal # distance exceeds the value of slow_ratio, then velocity and # acceleration are limited to half their nominal values. If vertical # distance divided by horizontal distance exceeds twice the value of # the slow_ratio, then velocity and acceleration are limited to one # quarter of their nominal values. The default is 3. # The stepper_left section is used to describe the stepper controlling # the left tower. This section also controls the homing parameters # (homing_speed, homing_retract_dist) for all towers. [stepper_left] position_endstop: # Distance (in mm) between the nozzle and the bed when the nozzle is # in the center of the build area and the endstops are triggered. This # parameter must be provided for stepper_left; for stepper_right this # parameter defaults to the value specified for stepper_left. arm_length: # Length (in mm) of the diagonal rod that connects the tower carriage to # the print head. This parameter must be provided for stepper_left; for # stepper_right, this parameter defaults to the value specified for # stepper_left. arm_x_length: # Horizontal distance between the print head and the tower when the # printers is homed. This parameter must be provided for stepper_left; # for stepper_right, this parameter defaults to the value specified for # stepper_left. # The stepper_right section is used to describe the stepper controlling the # right tower. [stepper_right] # The stepper_y section is used to describe the stepper controlling # the Y axis in a deltesian robot. [stepper_y] Cinematica CoreXY \u00b6 Vedere example-corexy.cfg per un file cinematico corexy (e h-bot) di esempio. Qui sono descritti solo i parametri specifici per le stampanti corexy - vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: corexy max_z_velocity: # Imposta la velocit\u00e0 massima (in mm/s) di movimento lungo l'asse z. # Questa impostazione pu\u00f2 essere utilizzata per limitare la velocit\u00e0 # massima del motore passo-passo z. L'impostazione predefinita \u00e8 # utilizzare max_velocity per max_z_velocity. max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento # lungo l'asse z. Limita l'accelerazione del motore passo-passo z. # L'impostazione predefinita \u00e8 utilizzare max_accel per max_z_accel. # La sezione stepper_x viene utilizzata per descrivere l'asse X e lo # stepper che controlla il movimento X+Y. [stepper_x] # La sezione stepper_y viene utilizzata per descrivere l'asse Y e lo # stepper che controlla il movimento X+Y. [stepper_y] # La sezione stepper_z viene utilizzata per descrivere l'asse Z [stepper_z] Cinematica CoreXZ \u00b6 Vedere example-corexz.cfg per un file di configurazione della cinematica corexz di esempio. Qui sono descritti solo i parametri specifici per le stampanti corexz - vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: corexz max_z_velocity: # Imposta la velocit\u00e0 massima (in mm/s) di movimento lungo l'asse z. # L'impostazione predefinita \u00e8 utilizzare max_velocity per # max_z_velocity. max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento lungo # l'asse z. L'impostazione predefinita \u00e8 utilizzare max_accel per # max_z_accel. # La sezione stepper_x viene utilizzata per descrivere l'asse X e lo # stepper che controlla il movimento X+Z. [stepper_x] # La sezione stepper_y viene utilizzata per descrivere l'asse Y [stepper_y] # La sezione stepper_z viene utilizzata per descrivere l'asse Z e lo # stepper che controlla il movimento X+Z. [stepper_z] Cinematica Hybrid-CoreXY \u00b6 Vedere example-hybrid-corexy.cfg per un file di configurazione della cinematica corexy ibrida di esempio. Questa cinematica \u00e8 anche nota come cinematica Markforged. Qui vengono descritti solo i parametri specifici delle stampanti corexy ibride, vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: hybrid_corexy max_z_velocity: # Imposta la velocit\u00e0 massima (in mm/s) di movimento lungo # l'asse z. L'impostazione predefinita \u00e8 utilizzare max_velocity # per max_z_velocity. max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento # lungo l'asse z. L'impostazione predefinita \u00e8 utilizzare max_accel # per max_z_accel. # La sezione stepper_x viene utilizzata per descrivere l'asse X e lo # stepper che controlla il movimento X-Y. [stepper_x] # La sezione stepper_y viene utilizzata per descrivere lo stepper # che controlla l'asse Y. [stepper_y] # La sezione stepper_z viene utilizzata per descrivere lo stepper # che controlla l'asse Z. [stepper_z] Cinematica Hybrid-CoreXZ \u00b6 Vedere example-hybrid-corexz.cfg per un file di configurazione della cinematica corexz ibrido di esempio. Questa cinematica \u00e8 anche nota come cinematica Markforged. Qui vengono descritti solo i parametri specifici delle stampanti corexy ibride, vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: hybrid_corexz max_z_velocity: # Questo imposta la velocit\u00e0 massima (in mm/s) di movimento lungo # l'asse z. L'impostazione predefinita \u00e8 utilizzare max_velocity per # max_z_velocity. max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento lungo # l'asse z. L'impostazione predefinita \u00e8 utilizzare max_accel per # max_z_accel. # La sezione stepper_x viene utilizzata per descrivere l'asse X e lo # stepper che controlla il movimento X-Z. [stepper_x] # La sezione stepper_y viene utilizzata per descrivere lo stepper che # controlla l'asse Y. [stepper_y] # La sezione stepper_z viene utilizzata per descrivere lo stepper che # controlla l'asse Z. [stepper_z] Cinematica polare \u00b6 Vedere example-polar.cfg per un file di configurazione della cinematica polare di esempio. Qui sono descritti solo i parametri specifici per le stampanti polari - vedere impostazioni cinematiche comuni per i parametri disponibili. LA CINEMATICA POLARE \u00c8 UN LAVORO IN CORSO. \u00c8 noto che i movimenti intorno alla posizione 0, 0 non funzionano correttamente. [printer] kinematics: polar max_z_velocity: # Imposta la velocit\u00e0 massima (in mm/s) di movimento lungo l'asse z. # Questa impostazione pu\u00f2 essere utilizzata per limitare la velocit\u00e0 # massima del motore passo-passo z. L'impostazione predefinita \u00e8 # utilizzare max_velocity per max_z_velocity. max_z_accel: # Questo imposta l'accelerazione massima (in mm/s^2) del # movimento lungo l'asse z. Limita l'accelerazione del motore # passo-passo z. L'impostazione predefinita \u00e8 utilizzare max_accel # per max_z_accel. # La sezione stepper_bed viene utilizzata per descrivere lo stepper # che controlla il piatto [stepper_bed] gear_ratio: # \u00c8 necessario specificare un gear_ratio e rotation_distance # potrebbe non essere specificato. Ad esempio, se il piatto ha una # ruota a 80 denti azionata da uno stepper con una ruota a 16 # denti, si dovrebbe specificare un rapporto di trasmissione di \"80:16\". # Questo parametro deve essere fornito. # La sezione stepper_arm \u00e8 usata per descrivere lo stepper che # controlla il carrello sul braccio. [stepper_arm] # La sezione stepper_z viene utilizzata per descrivere lo stepper che # controlla l'asse Z. [stepper_z] Cinematica delta rotatoria \u00b6 Vedere example-rotary-delta.cfg per un esempio di file di configurazione della cinematica delta rotante. Qui vengono descritti solo i parametri specifici delle stampanti delta rotative - vedere impostazioni cinematiche comuni per i parametri disponibili. LA CINEMATICA DELTA ROTANTE \u00c8 UN LAVORO IN CORSO. Gli spostamenti di homing potrebbero scadere e alcuni controlli dei confini non vengono implementati. [printer] kinematics: rotary_delta max_z_velocity: # For delta printers this limits the maximum velocity (in mm/s) of # moves with z axis movement. This setting can be used to reduce the # maximum speed of up/down moves (which require a higher step rate # than other moves on a delta printer). The default is to use # max_velocity for max_z_velocity. #minimum_z_position: 0 # The minimum Z position that the user may command the head to move # to. The default is 0. shoulder_radius: # Radius (in mm) of the horizontal circle formed by the three # shoulder joints, minus the radius of the circle formed by the # effector joints. This parameter may also be calculated as: # shoulder_radius = (delta_f - delta_e) / sqrt(12) # This parameter must be provided. shoulder_height: # Distance (in mm) of the shoulder joints from the bed, minus the # effector toolhead height. This parameter must be provided. # The stepper_a section describes the stepper controlling the rear # right arm (at 30 degrees). This section also controls the homing # parameters (homing_speed, homing_retract_dist) for all arms. [stepper_a] gear_ratio: # A gear_ratio must be specified and rotation_distance may not be # specified. For example, if the arm has an 80 toothed pulley driven # by a pulley with 16 teeth, which is in turn connected to a 60 # toothed pulley driven by a stepper with a 16 toothed pulley, then # one would specify a gear ratio of \"80:16, 60:16\". This parameter # must be provided. position_endstop: # Distance (in mm) between the nozzle and the bed when the nozzle is # in the center of the build area and the endstop triggers. This # parameter must be provided for stepper_a; for stepper_b and # stepper_c this parameter defaults to the value specified for # stepper_a. upper_arm_length: # Length (in mm) of the arm connecting the \"shoulder joint\" to the # \"elbow joint\". This parameter must be provided for stepper_a; for # stepper_b and stepper_c this parameter defaults to the value # specified for stepper_a. lower_arm_length: # Length (in mm) of the arm connecting the \"elbow joint\" to the # \"effector joint\". This parameter must be provided for stepper_a; # for stepper_b and stepper_c this parameter defaults to the value # specified for stepper_a. #angle: # This option specifies the angle (in degrees) that the arm is at. # The default is 30 for stepper_a, 150 for stepper_b, and 270 for # stepper_c. # The stepper_b section describes the stepper controlling the rear # left arm (at 150 degrees). [stepper_b] # The stepper_c section describes the stepper controlling the front # arm (at 270 degrees). [stepper_c] # The delta_calibrate section enables a DELTA_CALIBRATE extended # g-code command that can calibrate the shoulder endstop positions. [delta_calibrate] radius: # Radius (in mm) of the area that may be probed. This is the radius # of nozzle coordinates to be probed; if using an automatic probe # with an XY offset then choose a radius small enough so that the # probe always fits over the bed. This parameter must be provided. #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5. Cinematica dell'argano a fune \u00b6 Vedere example-winch.cfg per un esempio di file di configurazione della cinematica con verricello, cable winch. Qui sono descritti solo i parametri specifici per le stampanti cavo verricello - vedere impostazioni comuni cinematiche per i parametri disponibili. IL SUPPORTO DEL VERRICELLO \u00c8 SPERIMENTALE. L'homing non \u00e8 implementato nella cinematica del verricello. Per riportare la stampante alla posizione iniziale, inviare manualmente i comandi di movimento finch\u00e9 la testa utensile non si trova su 0, 0, 0, quindi emettere un comando \"G28\". [printer] kinematics: winch # The stepper_a section describes the stepper connected to the first # cable winch. A minimum of 3 and a maximum of 26 cable winches may be # defined (stepper_a to stepper_z) though it is common to define 4. [stepper_a] rotation_distance: # The rotation_distance is the nominal distance (in mm) the toolhead # moves towards the cable winch for each full rotation of the # stepper motor. This parameter must be provided. anchor_x: anchor_y: anchor_z: # The X, Y, and Z position of the cable winch in cartesian space. # These parameters must be provided. Nessuna cinematica \u00b6 \u00c8 possibile definire una cinematica speciale \"none\" per disabilitare il supporto cinematico in Klipper. Questo pu\u00f2 essere utile per controllare dispositivi che non sono le tipiche stampanti 3D o per scopi di debug. [printer] kinematics: none max_velocity: 1 max_accel: 1 # \u00c8 necessario definire i parametri max_velocity e max_accel. I valori # non vengono utilizzati per la cinematica \"none\". Supporto per estrusore e piatto riscaldato comuni \u00b6 [extruder] \u00b6 La sezione dell'estrusore viene utilizzata per descrivere i parametri del riscaldatore per l'hotend dell'ugello insieme allo stepper che controlla l'estrusore. Per ulteriori informazioni, vedere riferimento comando . Consultare la Guida all'avanzamento della pressione per informazioni sulla regolazione dell'anticipo della pressione. [extruder] step_pin: dir_pin: enable_pin: microsteps: rotation_distance: #full_steps_per_rotation: #gear_ratio: # Vedere la sezione \"stepper\" per una descrizione di quanto sopra # Se nessuno dei parametri precedenti \u00e8 specificato, nessuno stepper # sar\u00e0 associato all'hotend dell'ugello (sebbene un comando # SYNC_EXTRUDER_MOTION possa associarne uno in fase di esecuzione). nozzle_diameter: # Diametro dell'orifizio dell'ugello (in mm). Questo parametro deve essere fornito. filament_diameter:: # Il diametro nominale del filamento grezzo (in mm) quando # entra nell'estrusore. Questo parametro deve essere fornito. #max_extrude_cross_section: # Area massima (in mm^2) di una sezione trasversale dell'estrusione # (ad es. larghezza dell'estrusione moltiplicata per l'altezza dello strato). # Questa impostazione previene quantit\u00e0 eccessive di estrusione # durante spostamenti XY relativamente piccoli. # Se un movimento richiede una velocit\u00e0 di estrusione che supererebbe questo valore # causer\u00e0 la restituzione di un errore. L'impostazione predefinita # \u00e8: 4.0 * diametro_ugello^2 instantaneous_corner_velocity: 1.000 # La variazione di velocit\u00e0 istantanea massima (in mm/s) del # estrusore durante il collegamento di due movimenti. Il valore predefinito \u00e8 1 mm/s. #max_extrude_only_distance: 50.0 # Lunghezza massima (in mm di filamento grezzo) che pu\u00f2 avere un movimento # di retrazione o di sola estrusione. Se uno spostamento di retrazione # o di sola estrusione richiede una distanza maggiore di questo valore, # verr\u00e0 restituito un errore. Il valore predefinito \u00e8 50 mm. #max_extrude_only_velocity: #max_extrude_only_accel: # Velocit\u00e0 massima (in mm/s) e accelerazione (in mm/s^2) del # motore estrusore per retrazioni e movimenti di sola estrusione. # Queste impostazioni non hanno alcun impatto sui normali movimenti di stampa. # Se non specificati, vengono calcolati per corrispondere al limite che avrebbe # un movimento di stampa XY con una sezione trasversale di 4,0*diametro_ugello^2. #pressure_advance: 0.0 # La quantit\u00e0 di filamento grezzo da spingere nell'estrusore durante # accelerazione dell'estrusore. Una uguale quantit\u00e0 di filamento viene # retratta durante la decelerazione. Si misura in millimetri per # millimetro/secondo. Il valore predefinito \u00e8 0, che disabilita l'avanzamento della pressione. #pressure_advance_smooth_time: 0,040 # Un intervallo di tempo (in secondi) da utilizzare per calcolare la velocit\u00e0 media # dell'estrusore per l'avanzamento della pressione. Un valore maggiore si traduce # in movimenti pi\u00f9 fluidi dell'estrusore. Questo parametro non pu\u00f2 superare i 200 ms. # Questa impostazione si applica solo se pressure_advance \u00e8 diverso da zero. # Il valore predefinito \u00e8 0,040 (40 millisecondi). # # Le restanti variabili descrivono il riscaldatore dell'estrusore. heater_pin: # Pin di uscita PWM che controlla il riscaldatore. Questo parametro deve essere fornito. #max_power: 1.0 # La potenza massima (espressa come un valore compreso tra 0,0 e 1,0) a cui # pu\u00f2 essere impostato il riscaldatore_pin. Il valore 1.0 consente di impostare il pin # completamente abilitato per periodi prolungati, mentre un valore di 0,5 # consentirebbe di abilitare il pin per non pi\u00f9 della met\u00e0 del tempo. Questo # l'impostazione pu\u00f2 essere utilizzata per limitare la potenza totale # (per periodi prolungati) al riscaldatore. L'impostazione predefinita \u00e8 1.0. sensor_type: # Tipo di sensore - i termistori comuni sono \"EPCOS 100K B57560G104F\", # \"ATC Semitec 104GT-2\", \"ATC Semitec 104NT-4-R025H42G\", \"Generico # 3950\",\"Honeywell 100K 135-104LAG-J01\", \"NTC 100K MGB18-104F39050L32\", # \"SliceEngineering 450\" e \"TDK NTCG104LH104JT1\". Vedere la sezione # \"Sensori di temperatura\" per altri sensori. Questo parametro deve essere fornito. sensor_pin: # Pin di ingresso analogico collegato al sensore. Questo parametro deve essere fornito. #pullup_resistor: 4700 # La resistenza (in ohm) del pullup collegato al termistore. Questo parametro # \u00e8 valido solo quando il sensore \u00e8 un termistore. Il valore predefinito \u00e8 4700 ohm. #smooth_time: 1.0 # Un valore di tempo (in secondi) durante il quale le misurazioni della # temperatura verranno uniformate per ridurre l'impatto del rumore # di misurazione. Il valore predefinito \u00e8 1 secondo. control: # Algoritmo di controllo (pid o filigrana). Questo parametro deve # essere fornito. pid_Kp: pid_Ki: pid_Kd: # Il proporzionale (pid_Kp), l'integrale (pid_Ki) e la derivata # (pid_Kd) impostazioni per il sistema di controllo del feedback PID. Klipper # valuta le impostazioni PID con la seguente formula generale: # riscaldatore_pwm = (Kp*errore + Ki*integrale(errore) - Kd*derivato(errore)) / 255 # Dove \"errore\" \u00e8 \"temperatura_richiesta - temperatura_misurata\" # e \"heater_pwm\" \u00e8 la velocit\u00e0 di riscaldamento richiesta con 0,0 completamente # off e 1.0 completamente on. Prendi in considerazione l'utilizzo di PID_CALIBRATE # comando per ottenere questi parametri. pid_Kp, pid_Ki e pid_Kd # i parametri devono essere forniti per i riscaldatori PID. #delta_max: 2.0 # Sui riscaldatori controllati questo \u00e8 il numero di gradi in # Celsius al di sopra della temperatura target prima di disattivare il riscaldatore # cos\u00ec come il numero di gradi sotto il target prima # riattivare il riscaldatore. L'impostazione predefinita \u00e8 2 gradi Celsius. #pwm_cycle_time: 0,100 # Tempo in secondi per ogni ciclo PWM software del riscaldatore. # non \u00e8 consigliabile impostarlo a meno che non ci sia necessario come # requisito accendere il riscaldatore pi\u00f9 velocemente di 10 volte al secondo. # Il valore predefinito \u00e8 0,100 secondi. #min_extrude_temp: 170 # La temperatura minima (in gradi Celsius) alla quale possono essere # impartiti comandi all'estrusore. L'impostazione predefinita \u00e8 170 gradi Celsius. min_temp: max_temp: # L'intervallo massimo di temperature valide (in gradi Celsius) in cui # il riscaldatore deve rimanere all'interno. Questo controlla una funzione di sicurezza # implementata nel codice del microcontrollore , la temperatura # non cadr\u00e0 mai al di fuori di questo intervallo, altrimenti il microcontrollore # entrer\u00e0 in uno stato di arresto. Questo controllo pu\u00f2 aiutare a rilevarne alcuni # guasti hardware del riscaldatore e del sensore. Imposta questo intervallo solo in modo ampio # abbastanza in modo che temperature ragionevoli non si traducano in un errore. # Questi parametri devono essere forniti. [heater_bed] \u00b6 La sezione heater_bed descrive un piatto riscaldato. Utilizza le stesse impostazioni del riscaldatore descritte nella sezione \"extruder\". [heater_bed] heater_pin: sensor_type: sensor_pin: control: min_temp: max_temp: # Vedere la sezione \"extruder\" per una descrizione dei parametri sopra. Supporto livellamento del piatto \u00b6 [bed_mesh] \u00b6 Mesh Bed Leveling. Si pu\u00f2 definire una sezione di configurazione bed_mesh per abilitare trasformazioni di spostamento che sfalsano l'asse z in base a una mesh generata da punti sondati. Quando si utilizza una sonda per la posizione di riferimento sull'asse z, si consiglia di definire una sezione safe_z_home in printer.cfg per la posizione di riferimento verso il centro dell'area di stampa. Per ulteriori informazioni, vedere la bed mesh guide e riferimento del comando . Esempi visivi: rectangular bed, probe_count = 3, 3: x---x---x (max_point) | x---x---x | (min_point) x---x---x round bed, round_probe_count = 5, bed_radius = r: x (0, r) end / x---x---x \\ (-r, 0) x---x---x---x---x (r, 0) \\ x---x---x / x (0, -r) start [bed_mesh] #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5. #mesh_radius: # Defines the radius of the mesh to probe for round beds. Note that # the radius is relative to the coordinate specified by the # mesh_origin option. This parameter must be provided for round beds # and omitted for rectangular beds. #mesh_origin: # Defines the center X, Y coordinate of the mesh for round beds. This # coordinate is relative to the probe's location. It may be useful # to adjust the mesh_origin in an effort to maximize the size of the # mesh radius. Default is 0, 0. This parameter must be omitted for # rectangular beds. #mesh_min: # Defines the minimum X, Y coordinate of the mesh for rectangular # beds. This coordinate is relative to the probe's location. This # will be the first point probed, nearest to the origin. This # parameter must be provided for rectangular beds. #mesh_max: # Defines the maximum X, Y coordinate of the mesh for rectangular # beds. Adheres to the same principle as mesh_min, however this will # be the furthest point probed from the bed's origin. This parameter # must be provided for rectangular beds. #probe_count: 3, 3 # For rectangular beds, this is a comma separate pair of integer # values X, Y defining the number of points to probe along each # axis. A single value is also valid, in which case that value will # be applied to both axes. Default is 3, 3. #round_probe_count: 5 # For round beds, this integer value defines the maximum number of # points to probe along each axis. This value must be an odd number. # Default is 5. #fade_start: 1.0 # The gcode z position in which to start phasing out z-adjustment # when fade is enabled. Default is 1.0. #fade_end: 0.0 # The gcode z position in which phasing out completes. When set to a # value below fade_start, fade is disabled. It should be noted that # fade may add unwanted scaling along the z-axis of a print. If a # user wishes to enable fade, a value of 10.0 is recommended. # Default is 0.0, which disables fade. #fade_target: # The z position in which fade should converge. When this value is # set to a non-zero value it must be within the range of z-values in # the mesh. Users that wish to converge to the z homing position # should set this to 0. Default is the average z value of the mesh. #split_delta_z: .025 # The amount of Z difference (in mm) along a move that will trigger # a split. Default is .025. #move_check_distance: 5.0 # The distance (in mm) along a move to check for split_delta_z. # This is also the minimum length that a move can be split. Default # is 5.0. #mesh_pps: 2, 2 # A comma separated pair of integers X, Y defining the number of # points per segment to interpolate in the mesh along each axis. A # \"segment\" can be defined as the space between each probed point. # The user may enter a single value which will be applied to both # axes. Default is 2, 2. #algorithm: lagrange # The interpolation algorithm to use. May be either \"lagrange\" or # \"bicubic\". This option will not affect 3x3 grids, which are forced # to use lagrange sampling. Default is lagrange. #bicubic_tension: .2 # When using the bicubic algorithm the tension parameter above may # be applied to change the amount of slope interpolated. Larger # numbers will increase the amount of slope, which results in more # curvature in the mesh. Default is .2. #zero_reference_position: # An optional X,Y coordinate that specifies the location on the bed # where Z = 0. When this option is specified the mesh will be offset # so that zero Z adjustment occurs at this location. The default is # no zero reference. #relative_reference_index: # **DEPRECATED, use the \"zero_reference_position\" option** # The legacy option superceded by the \"zero reference position\". # Rather than a coordinate this option takes an integer \"index\" that # refers to the location of one of the generated points. It is recommended # to use the \"zero_reference_position\" instead of this option for new # configurations. The default is no relative reference index. #faulty_region_1_min: #faulty_region_1_max: # Optional points that define a faulty region. See docs/Bed_Mesh.md # for details on faulty regions. Up to 99 faulty regions may be added. # By default no faulty regions are set. [bed_tilt] \u00b6 Compensazione dell'inclinazione del piatto. Si pu\u00f2 definire una sezione di configurazione bed_tilt per abilitare le trasformazioni di movimento che tengono conto di un piatto inclinato. Nota che bed_mesh e bed_tilt sono incompatibili; entrambi non possono essere definiti. Per ulteriori informazioni, vedere riferimento comando . [bed_tilt] #x_adjust: 0 # The amount to add to each move's Z height for each mm on the X # axis. The default is 0. #y_adjust: 0 # The amount to add to each move's Z height for each mm on the Y # axis. The default is 0. #z_adjust: 0 # The amount to add to the Z height when the nozzle is nominally at # 0, 0. The default is 0. # The remaining parameters control a BED_TILT_CALIBRATE extended # g-code command that may be used to calibrate appropriate x and y # adjustment parameters. #points: # A list of X, Y coordinates (one per line; subsequent lines # indented) that should be probed during a BED_TILT_CALIBRATE # command. Specify coordinates of the nozzle and be sure the probe # is above the bed at the given nozzle coordinates. The default is # to not enable the command. #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5. [bed_screws] \u00b6 Strumento per aiutare a regolare le viti di livellamento del letto. Si pu\u00f2 definire una sezione di configurazione [bed_screws] per abilitare un comando g-code BED_SCREWS_ADJUST. Per ulteriori informazioni, vedere la guida al livellamento e il riferimento al comando . [bed_screws] #screw1: # The X, Y coordinate of the first bed leveling screw. This is a # position to command the nozzle to that is directly above the bed # screw (or as close as possible while still being above the bed). # This parameter must be provided. #screw1_name: # An arbitrary name for the given screw. This name is displayed when # the helper script runs. The default is to use a name based upon # the screw XY location. #screw1_fine_adjust: # An X, Y coordinate to command the nozzle to so that one can fine # tune the bed leveling screw. The default is to not perform fine # adjustments on the bed screw. #screw2: #screw2_name: #screw2_fine_adjust: #... # Additional bed leveling screws. At least three screws must be # defined. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # when moving from one screw location to the next. The default is 5. #probe_height: 0 # The height of the probe (in mm) after adjusting for the thermal # expansion of bed and nozzle. The default is zero. #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #probe_speed: 5 # The speed (in mm/s) when moving from a horizontal_move_z position # to a probe_height position. The default is 5. [screws_tilt_adjust] \u00b6 Strumento per aiutare a regolare l'inclinazione delle viti del piatto utilizzando la sonda Z. Si pu\u00f2 definire una sezione di configurazione Screws_tilt_adjust per abilitare un comando g-code SCREWS_TILT_CALCULATE. Per ulteriori informazioni, vedere la guida al livellamento e riferimento al comando . [screws_tilt_adjust] #screw1: # The (X, Y) coordinate of the first bed leveling screw. This is a # position to command the nozzle to so that the probe is directly # above the bed screw (or as close as possible while still being # above the bed). This is the base screw used in calculations. This # parameter must be provided. #screw1_name: # An arbitrary name for the given screw. This name is displayed when # the helper script runs. The default is to use a name based upon # the screw XY location. #screw2: #screw2_name: #... # Additional bed leveling screws. At least two screws must be # defined. #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5. #screw_thread: CW-M3 # The type of screw used for bed leveling, M3, M4, or M5, and the # rotation direction of the knob that is used to level the bed. # Accepted values: CW-M3, CCW-M3, CW-M4, CCW-M4, CW-M5, CCW-M5. # Default value is CW-M3 which most printers use. A clockwise # rotation of the knob decreases the gap between the nozzle and the # bed. Conversely, a counter-clockwise rotation increases the gap. [z_tilt] \u00b6 Regolazione multipla dell'inclinazione dello stepper Z. Questa funzione consente la regolazione indipendente di pi\u00f9 stepper z (vedere la sezione \"stepper_z1\") per regolare l'inclinazione. Se questa sezione \u00e8 presente, diventa disponibile un comando G-Code esteso Z_TILT_ADJUST. [z_tilt] #z_positions: # Un elenco di coordinate X, Y (una per riga; le righe successive # identate) che descrivono la posizione di ciascun \"pivot point\" # del piattotto. Il \"pivot point\" \u00e8 il punto in cui il piatto si attacca # al dato stepper Z. Viene descritto utilizzando le coordinate dell'ugello # (la posizione X, Y dell'ugello se potesse spostarsi direttamente sopra # il punto). La prima voce corrisponde a stepper_z, la seconda a # stepper_z1, la terza a stepper_z2, ecc. # Questo parametro deve essere fornito. #points: # Un elenco di coordinate X, Y (una per riga; righe successive identate) # che devono essere rilevate durante un comando Z_TILT_ADJUST. # Specificare le coordinate dell'ugello e assicurarsi che la sonda sia # sopra il piatto alle coordinate dell'ugello date. # Questo parametro deve essere fornito. #speed: 50 # La velocit\u00e0 (in mm/s) degli spostamenti senza probing durante # la calibrazione. Il valore predefinito \u00e8 50. #horizontal_move_z: 5 # L'altezza (in mm) a cui la testa deve essere comandata per spostarsi # appena prima di avviare un'operazione di probing. # L'impostazione predefinita \u00e8 5. #retries: 0 # Numero di volte per riprovare se i punti rilevati non sono all'interno # della tolleranza. #retry_tolerance: 0 # Se i tentativi sono abilitati, riprovare se i punti sondati pi\u00f9 grande e # pi\u00f9 piccolo differiscono pi\u00f9 di retry_tolerance. Nota che l'unit\u00e0 di # modifica pi\u00f9 piccola qui sarebbe un singolo passaggio. # Tuttavia, se stai sondando pi\u00f9 punti rispetto agli stepper, # probabilmente avrai un valore minimo fisso per l'intervallo di punti # sondati che puoi apprendere osservando l'output del comando. [quad_gantry_level] \u00b6 Livellamento del gantly mediante 4 motori Z controllati in modo indipendente. Corregge gli effetti della parabola iperbolica (patatine fritte) sul portale mobile che \u00e8 pi\u00f9 flessibile. ATTENZIONE: l'utilizzo su un letto mobile pu\u00f2 portare a risultati indesiderati. Se questa sezione \u00e8 presente, diventa disponibile un comando G-Code esteso QUAD_GANTRY_LEVEL. Questa routine presuppone la seguente configurazione del motore Z: ---------------- |Z1 Z2| | --------- | | | | | | | | | | x-------- | |Z Z3| ---------------- Dove x \u00e8 il punto 0, 0 sul piatto [quad_gantry_level] #gantry_corners: # A newline separated list of X, Y coordinates describing the two # opposing corners of the gantry. The first entry corresponds to Z, # the second to Z2. This parameter must be provided. #points: # A newline separated list of four X, Y points that should be probed # during a QUAD_GANTRY_LEVEL command. Order of the locations is # important, and should correspond to Z, Z1, Z2, and Z3 location in # order. This parameter must be provided. For maximum accuracy, # ensure your probe offsets are configured. #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5. #max_adjust: 4 # Safety limit if an adjustment greater than this value is requested # quad_gantry_level will abort. #retries: 0 # Number of times to retry if the probed points aren't within # tolerance. #retry_tolerance: 0 # If retries are enabled then retry if largest and smallest probed # points differ more than retry_tolerance. [skew_correction] \u00b6 Correzione dell'inclinazione della stampante. \u00c8 possibile utilizzare il software per correggere l'inclinazione della stampante su 3 piani, xy, xz, yz. Questo viene fatto stampando un modello di calibrazione lungo un piano e misurando tre lunghezze. A causa della natura della correzione dell'inclinazione, queste lunghezze vengono impostate tramite gcode. Per i dettagli, vedere Correzione inclinazione e Command Reference . [skew_correction] [z_thermal_adjust] \u00b6 Regolazione della posizione Z della testa di stampa in funzione della temperatura. Compensare il movimento verticale della testina utensile causato dall'espansione termica del telaio della stampante in tempo reale utilizzando un sensore di temperatura (tipicamente accoppiato a una sezione verticale del telaio). Vedi anche: comandi g-code estesi . [z_thermal_adjust] #temp_coeff: # Il coefficiente di dilatazione della temperatura, in mm/degC. Ad esempio, un # temp_coeff di 0,01 mm/degC sposter\u00e0 l'asse Z verso il basso di 0,01 mm per ogni # grado Celsius di auemnto del sensore di temperatura . Il valore predefinito \u00e8 # 0,0 mm/degC, che non applica alcuna regolazione. #smooth_time: # Finestra di smoothing applicata al sensore di temperatura, in secondi. Pu\u00f2 # ridurre il rumore del motore da piccole correzioni eccessive in risposta al # rumore del sensore. Il valore predefinito \u00e8 2,0 secondi. #z_adjust_off_above: # Disattiva le regolazioni al di sopra di questa altezza Z [mm]. L'ultima correzione # calcolata rimarr\u00e0 applicata finch\u00e9 la testa utensile non si sposter\u00e0 nuovamente # al di sotto dell'altezza Z specificata. # Il valore predefinito \u00e8 99999999,0 mm (sempre attivo). #max_z_adjustment: # Massima regolazione assoluta applicabile all'asse Z [mm]. Il valore predefinito # \u00e8 99999999,0 mm (illimitato). #sensor_type: #sensor_pin: #min_temp: #max_temp: # Configurazione del sensore di temperatura. Vedere la sezione \"extruder\" per # la definizione dei parametri di cui sopra. #gcode_id: # Vedere la sezione \"heater_generic\" per la definizione di questo parametro. Homing personalizzato \u00b6 [safe_z_home] \u00b6 Homing Z sicuro. Si pu\u00f2 utilizzare questo meccanismo per posizionare l'asse Z su una specifica coordinata X, Y. Ci\u00f2 \u00e8 utile se la testa portautensili, ad esempio, deve spostarsi al centro del letto prima che Z possa essere riposizionato. [safe_z_home] home_xy_position: # Una coordinata X, Y (ad es. 100, 100) dove deve essere eseguita # homing Z. Questo parametro deve essere fornito. #speed: 50.0 # Velocit\u00e0 alla quale la testa di stampa viene spostata sulla # coordinata Z sicura. Il valore predefinito \u00e8 50 mm/s #z_hop: # Distanza (in mm) per sollevare l'asse Z prima dell'homing. # Questo si applica a qualsiasi comando di homing, anche se non # si trova sull'asse Z. Se l'asse Z \u00e8 gi\u00e0 azzerato e la posizione Z # corrente \u00e8 inferiore a z_hop, questo sollever\u00e0 la testa a un'altezza # di z_hop. Se l'asse Z non \u00e8 gi\u00e0 azzerato la testina viene sollevata # di z_hop. L'impostazione predefinita \u00e8 di non implementare Z hop. #z_hop_speed: 15.0 # Velocit\u00e0 (in mm/s) alla quale l'asse Z viene sollevato prima # del homing. Il valore predefinito \u00e8 15 mm/s. #move_to_previous: False # Quando \u00e8 impostato su True, gli assi X e Y vengono ripristinati alle # posizioni precedenti dopo l'homing dell'asse Z. # L'impostazione predefinita \u00e8 False. [homing_override] \u00b6 Homing Override. Si pu\u00f2 utilizzare questo meccanismo per eseguire una serie di comandi g-code al posto di un G28 che si trova nel normale input di g-code. Questo pu\u00f2 essere utile su stampanti che richiedono una procedura specifica per l'home della macchina. [homing_override] gcode: # Un elenco di comandi G-Code da eseguire al posto dei comandi # G28 trovati nel normale input di G-Code. # Vedi docs/Command_Templates.md per il formato G-Code. # Se un G28 \u00e8 contenuto in questo elenco di comandi, invocher\u00e0 # la normale procedura di homing per la stampante. I comandi # qui elencati devono eseguire l'home di tutti gli assi. # Questo parametro deve essere fornito. #axes: xyz # Gli assi da sovrascrivere. Ad esempio, se questo \u00e8 impostato # su \"z\", lo script di override verr\u00e0 eseguito solo quando l'asse z # \u00e8 azzerato (ad esempio, tramite un comando \"G28\" o \"G28 Z0\"). # Nota, lo script di sovrascrittura dovrebbe comunque ospitare # tutti gli assi. L'impostazione predefinita \u00e8 \"xyz\" che fa s\u00ec che lo # script di override venga eseguito al posto di tutti i comandi G28. #set_position_x: #set_position_y: #set_position_z: # Se specificato, la stampante presumer\u00e0 che l'asse si trovi # nella posizione specificata prima di eseguire i comandi g-code # precedenti. L'impostazione di questa opzione disabilita i # controlli di riferimento per quell'asse. Questo pu\u00f2 essere utile # se la testa deve muoversi prima di invocare il normale # meccanismo G28 per un asse. L'impostazione predefinita \u00e8 # di non forzare una posizione per un asse. [endstop_phase] \u00b6 Finecorsa regolati in fase stepper. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso \"endstop_phase\" seguito dal nome della corrispondente sezione di configurazione dello stepper (ad esempio, \"[endstop_phase stepper_z]\"). Questa funzione pu\u00f2 migliorare la precisione degli interruttori di fine corsa. Aggiungi una semplice dichiarazione \"[endstop_phase]\" per abilitare il comando ENDSTOP_PHASE_CALIBRATE. Per ulteriori informazioni, vedere la endstop phases guide e command reference . [endstop_phase stepper_z] #endstop_accuracy: # Imposta la precisione prevista (in mm) del finecorsa. Questo rappresenta # la distanza massima di errore che il finecorsa pu\u00f2 attivare (ad es. se un # finecorsa pu\u00f2 occasionalmente attivarsi 100um in anticipo o fino a 100um in ritardo # quindi impostalo su 0,200 per 200 um). L'impostazione predefinita \u00e8 # 4*distanza_rotazione/passi_completi_per_rotazione. #trigger_phase: # Questo specifica la fase del driver del motore passo-passo da aspettarsi # quando si raggiunge il finecorsa. \u00c8 composto da due numeri separati # da un '/' - la fase e il numero totale di # fasi (ad es. \"7/64\"). Impostare questo valore solo se si \u00e8 sicuri che il # driver del motore passo-passo viene ripristinato ogni volta che viene ripristinato l'mcu. Se questo # non \u00e8 impostato, la prima fase verr\u00e0 rilevata al primo home # e quella fase sar\u00e0 utilizzata su tutte le abitazioni successive. #endstop_align_zero: False # Se true, la posizione_endstop dell'asse sar\u00e0 effettivamente # modificato in modo che la posizione zero dell'asse avvenga a passo pieno # sul motore. (Se utilizzato sull'asse Z e la stampa # l'altezza del livello \u00e8 un multiplo di una distanza di un passo intero, allora ogni # layer si eseguir\u00e0 in un step completo.) L'impostazione predefinita \u00e8 False. Macro ed eventi G-Code \u00b6 [gcode_macro] \u00b6 Macro G-Code (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"gcode_macro\"). Per ulteriori informazioni, consulta la Guida ai modelli di comando . [gcode_macro my_cmd] #gcode: # Un elenco di comandi G-Code da eseguire al posto di \"my_cmd\". # Vedi docs/Command_Templates.md per il formato G-Code. # Questo parametro deve essere fornito. #variable_: # Si pu\u00f2 specificare un numero qualsiasi di opzioni con un prefisso # \"variable_\". Al nome della variabile data verr\u00e0 assegnato il valore dato # (analizzato come un valore letterale Python) e sar\u00e0 disponibile durante # l'espansione della macro. Ad esempio, una configurazione con # \"variable_fan_speed = 75\" potrebbe avere comandi gcode contenenti # \"M106 S{ fan_speed * 255 }\". Le variabili possono essere modificate in # fase di esecuzione utilizzando il comando SET_GCODE_VARIABLE # (consultare docs/Command_Templates.md per i dettagli). # I nomi delle variabili potrebbero non utilizzare caratteri maiuscoli. #rename_existing: # Questa opzione far\u00e0 s\u00ec che la macro ignori un comando G-Code # esistente e fornisca la definizione precedente del comando tramite # il nome fornito qui. Questo pu\u00f2 essere usato per sovrascrivere i # comandi G-Code integrati. Prestare attenzione quando si ignorano # i comandi poich\u00e9 possono causare risultati complessi e imprevisti. # L'impostazione predefinita \u00e8 di non sovrascrivere un comando # G-Code esistente. #description: G-Code macro # Ci\u00f2 aggiunger\u00e0 una breve descrizione utilizzata al comando HELP # o durante l'utilizzo della funzione di completamento automatico. # Predefinito \"G-Code macro\" [delayed_gcode] \u00b6 Esegui un gcode con un ritardo impostato. Per ulteriori informazioni, consulta la Guida template dei comandi e riferimento al comando . [delayed_gcode my_delayed_gcode] gcode: # A list of G-Code commands to execute when the delay duration has # elapsed. G-Code templates are supported. This parameter must be # provided. #initial_duration: 0.0 # The duration of the initial delay (in seconds). If set to a # non-zero value the delayed_gcode will execute the specified number # of seconds after the printer enters the \"ready\" state. This can be # useful for initialization procedures or a repeating delayed_gcode. # If set to 0 the delayed_gcode will not execute on startup. # Default is 0. [save_variables] \u00b6 Supporta il salvataggio delle variabili su disco in modo che vengano mantenute durante i riavvii. Per ulteriori informazioni, vedere template dei comandi e G-Code reference . [save_variables] filename: # Richiesto: fornire un nome file che verrebbe utilizzato per salvare # le variabili su disco, ad es. ~/variables.cfg [idle_timeout] \u00b6 Timeout di inattivit\u00e0. Viene automaticamente abilitato un timeout di inattivit\u00e0: aggiungi una sezione di configurazione di idle_timeout esplicita per modificare le impostazioni predefinite. [idle_timeout] #gcode: # Un elenco di comandi G-Code da eseguire in un timeout di # inattivit\u00e0. Vedi docs/Command Templates.md per il formato # G-Code. L'impostazione predefinita \u00e8 # eseguire \"TURN_OFF HEATERS\" e \"M84\". #timeout: 600 # Tempo di inattivit\u00e0 (in secondi) da attendere prima di eseguire # i comandi G-Code sopra. Il valore predefinito \u00e8 600 secondi. Funzionalit\u00e0 opzionali G-Code \u00b6 [virtual_sdcard] \u00b6 Una scheda SD virtuale pu\u00f2 essere utile se la macchina host non \u00e8 abbastanza veloce per eseguire bene OctoPrint. Consente al software host Klipper di stampare direttamente i file gcode archiviati in una directory sull'host utilizzando i comandi G-Code standard (ad esempio, M24). [virtual_sdcard] path: # Il percorso della directory locale sulla macchina host per cercare # i file di Gcode. Questa \u00e8 una directory di sola lettura (le scritture # di file sdcard non sono supportate). Si pu\u00f2 indicare questo alla # directory di caricamento di OctoPrint # (generalmente ~/.octoprint/uploads/ ). # Questo parametro deve essere fornito. #on_error_gcode: # Un elenco di comandi G-Code da eseguire quando viene segnalato # un errore. [sdcard_loop] \u00b6 Alcune stampanti con funzionalit\u00e0 di pulizia del piatto, come un espulsore di parti o una stampante a nastro, possono trovare impiego nelle sezioni di loop del file sdcard. (Ad esempio, per stampare la stessa parte pi\u00f9 e pi\u00f9 volte, o ripetere la sezione a di una parte per una catena o un altro motivo ripetuto). Consulta il command reference per i comandi supportati. Vedere il file sample-macros.cfg per una macro M808 G-Code compatibile con Marlin. [sdcard_loop] [force_move] \u00b6 Supporta lo spostamento manuale dei motori passo-passo per scopi diagnostici. Nota, l'utilizzo di questa funzione potrebbe mettere la stampante in uno stato non valido - vedere il command reference per dettagli importanti. [force_move] #enable_force_move: False # Impostare su True per abilitare FORCE_MOVE e SET_KINEMATIC_POSITION # i comandi G-Code estesi. L'impostazione predefinita \u00e8 False. [pause_resume] \u00b6 Funzionalit\u00e0 di Pause/Resume con supporto di acquisizione e ripristino della posizione. Per ulteriori informazioni, vedere riferimento comando . [pause_resume] #recover_velocity: 50. # Quando si abilita pause_resume, la velocit\u00e0 con cui tornare alla # posizione catturata (in mm/s). Il valore predefinito \u00e8 50,0 mm/s. [firmware_retraction] \u00b6 Retrazione del filamento del firmware. Ci\u00f2 abilita i comandi GCODE G10 (ritiro) e G11 (non ritirati) emessi da molti slicer. I parametri seguenti forniscono le impostazioni predefinite di avvio, sebbene i valori possano essere regolati tramite il [comando] SET_RETRACTION (G-Codes.md#firmware_retraction)), consentendo l'impostazione e l'ottimizzazione del filamento a runtime. [firmware_retraction] #retract_length: 0 # La lunghezza del filamento (in mm) da ritrarre quando G10 # \u00e8 attivato e da ritrarre quando G11 \u00e8 attivato (ma vedere # unretract_extra_length di seguito). I# l valore predefinito \u00e8 0 mm. #retract_speed: 20 # La velocit\u00e0 di retrazione, in mm/s. # Il valore predefinito \u00e8 20 mm/s. #unretract_extra_length: 0 # La lunghezza (in mm) del filamento *aggiuntivo* da # sommare quando non si ritrae. #unretract_speed: 10 # La velocit\u00e0 di srotolamento, in mm/s. # Il valore predefinito \u00e8 10 mm/s. [gcode_arcs] \u00b6 Supporto per i comandi Gcode arc (G2/G3). [gcode_arcs] #resolution: 1.0 # Un arco sar\u00e0 diviso in segmenti. La lunghezza di ciascun segmento # sar\u00e0 uguale alla risoluzione in mm impostata sopra. Valori pi\u00f9 bassi # produrranno un arco pi\u00f9 fine, ma anche pi\u00f9 lavoro per la tua macchina. # Archi pi\u00f9 piccoli del valore configurato diventer\u00e0 linee rette. # L'impostazione predefinita \u00e8 # 1mm. [respond] \u00b6 Abilita i comandi estesi \"M118\" e \"RESPOND\" commands . [respond] #default_type: echo # Imposta il prefisso predefinito dell'output \"M118\" e \"RESPOND\" su uno dei seguenti: # echo: \"echo: \" (Questa \u00e8 l'impostazione predefinita) # command: \"// \" # error: \"!! \" #default_prefix: echo: # Imposta direttamente il prefisso predefinito. Se presente # questo valore sovrascriver\u00e0 il \"default_type\". [exclude_object] \u00b6 Abilita il supporto per escludere o cancellare singoli oggetti durante il processo di stampa. Per ulteriori informazioni, vedere la guida escludi oggetti e riferimento ai comandi . Vedere il file sample-macros.cfg per una macro G-Code M486 compatibile con Marlin/RepRapFirmware. [exclude_object] Compensazione della risonanza \u00b6 [input_shaper] \u00b6 Abilita compensazione della risonanza . Vedere anche il command reference . [input_shaper] #shaper_freq_x: 0 # Una frequenza (in Hz) dell'input shaper per l'asse X. Questa \u00e8 # solitamente una frequenza di risonanza dell'asse X che l'input # shaper dovrebbe sopprimere. Per shaper pi\u00f9 complessi, come # shaper di input EI a 2 e 3 gobbe, questo parametro pu\u00f2 essere # impostato in base a diverse considerazioni. # Il valore predefinito \u00e8 0, che disabilita la modellatura dell'input # per l'asse X. #shaper_freq_y: 0 # Una frequenza (in Hz) dell'input shaper per l'asse Y. Questa \u00e8 # solitamente una frequenza di risonanza dell'asse Y che l'input # shaper dovrebbe sopprimere. Per shaper pi\u00f9 complessi, come # shaper di input EI a 2 e 3 gobbe, questo parametro pu\u00f2 essere # impostato in base a diverse considerazioni. Il valore predefinito # \u00e8 0, che disabilita la modellatura dell'input per l'asse Y. #shaper_type: mzv # Un tipo di input shaper da utilizzare per entrambi gli assi X e Y. # Gli shaper supportati sono zv, mzv, zvd, ei, 2hump_ei e # 3hump_ei. L'impostazione predefinita \u00e8 mzv input shaper. #shaper_type_x: #shaper_type_y: # Se shaper_type non \u00e8 impostato, questi due parametri possono # essere utilizzati per configurare diversi shaper di input per gli # assi X e Y. Sono supportati gli stessi valori del parametro # shaper_type. #damping_ratio_x: 0.1 #damping_ratio_y: 0.1 # Rapporti di smorzamento delle vibrazioni degli assi X e Y # utilizzati dagli shaper di input per migliorare la soppressione # delle vibrazioni. Il valore predefinito \u00e8 0,1, un buon valore per la # maggior parte delle stampanti. Nella maggior parte dei casi # questo parametro non richiede ottimizzazione e # non deve essere modificato. [adxl345] \u00b6 Supporto per accelerometri ADXL345. Questo supporto consente di interrogare le misurazioni dell'accelerometro dal sensore. Ci\u00f2 abilita un comando ACCELEROMETER_MEASURE (consultare G-Codes per ulteriori informazioni). Il nome del chip predefinito \u00e8 \"predefinito\", ma \u00e8 possibile specificare un nome esplicito (ad esempio, [adxl345 my_chip_name]). [adxl345] cs_pin: # The SPI enable pin for the sensor. This parameter must be provided. #spi_speed: 5000000 # The SPI speed (in hz) to use when communicating with the chip. # The default is 5000000. #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #axes_map: x, y, z # The accelerometer axis for each of the printer's X, Y, and Z axes. # This may be useful if the accelerometer is mounted in an # orientation that does not match the printer orientation. For # example, one could set this to \"y, x, z\" to swap the X and Y axes. # It is also possible to negate an axis if the accelerometer # direction is reversed (eg, \"x, z, -y\"). The default is \"x, y, z\". #rate: 3200 # Output data rate for ADXL345. ADXL345 supports the following data # rates: 3200, 1600, 800, 400, 200, 100, 50, and 25. Note that it is # not recommended to change this rate from the default 3200, and # rates below 800 will considerably affect the quality of resonance # measurements. [lis2dw] \u00b6 Support for LIS2DW accelerometers. [lis2dw] cs_pin: # The SPI enable pin for the sensor. This parameter must be provided. #spi_speed: 5000000 # The SPI speed (in hz) to use when communicating with the chip. # The default is 5000000. #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #axes_map: x, y, z # See the \"adxl345\" section for information on this parameter. [mpu9250] \u00b6 Supporto per accelerometri MPU-9250, MPU-9255, MPU-6515, MPU-6050 e MPU-6500 (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"mpu9250\"). [mpu9250 my_accelerometer] #i2c_address: # Default is 104 (0x68). If AD0 is high, it would be 0x69 instead. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: 400000 # See the \"common I2C settings\" section for a description of the # above parameters. The default \"i2c_speed\" is 400000. #axes_map: x, y, z # See the \"adxl345\" section for information on this parameter. [resonance_tester] \u00b6 Supporto per test di risonanza e calibrazione automatica del input shaper. Per utilizzare la maggior parte delle funzionalit\u00e0 di questo modulo, devono essere installate dipendenze software aggiuntive; fare riferimento a Measuring Resonances e al command reference per ulteriori informazioni. Per ulteriori informazioni sul parametro max_smoothing e sul suo utilizzo, vedere la sezione Max smoothing della guida alla misurazione delle risonanze. [resonance_tester] #probe_points: # Un elenco di coordinate X, Y, Z di punti (un punto per linea) in cui # testare le risonanze. Almeno un punto \u00e8 richiesto. Assicurati che tutti # i punti con un margine di sicurezza nel piano XY (~ pochi centimetri) # siano raggiungibili dalla testa di stampa. #accel_chip: # Un nome del chip dell'accelerometro da utilizzare per le misurazioni. # Se il chip adxl345 \u00e8 stato definito senza un nome esplicito, questo # parametro pu\u00f2 semplicemente fare riferimento ad esso come # \"accel_chip: adxl345\", altrimenti deve essere fornito anche un nome # esplicito, ad es. \"accel_chip: adxl345 mio_chip_nome\". \u00c8 necessario # impostare questo o i due parametri successivi. #accel_chip_x: #accel_chip_y: # Nomi dei chip dell'accelerometro da utilizzare per le misurazioni per # ciascuno degli assi. Pu\u00f2 essere utile, ad esempio, su una stampante con # piatto, se due accelerometri separati sono montati sul piatto (per l'asse Y) # e sulla testa di stampa (per l'asse X). Questi parametri hanno lo stesso # formato del parametro 'accel_chip'. # \u00c8 necessario fornire solo 'accel_chip' o questi due parametri. #max_smoothing: # Maximum input shaper smoothing to allow for each axis during shaper # auto-calibration (with 'SHAPER_CALIBRATE' command). By default no # maximum smoothing is specified. Refer to Measuring_Resonances guide # for more details on using this feature. #min_freq: 5 # Frequenza minima per testare le risonanze. L'impostazione \u00e8 5 Hz. #max_freq: 133.33 # Frequenza massima per testare le risonanze. L'impostazione \u00e8 133,33 Hz. #accel_per_hz: 75 # Questo parametro viene utilizzato per determinare quale accelerazione # utilizzare per testare una frequenza specifica: accel = accel_per_hz * freq. # Maggiore \u00e8 il valore, maggiore \u00e8 l'energia delle oscillazioni. Pu\u00f2 essere # impostato su un valore inferiore al valore predefinito se le risonanze # diventano troppo forti sulla stampante. Tuttavia, valori pi\u00f9 bassi rendono # le misurazioni delle risonanze ad alta frequenza meno precise. # Il valore predefinito \u00e8 75 (mm/sec). #hz_per_sec: 1 # Determina la velocit\u00e0 del test. Quando si testano tutte le frequenze # nell'intervallo [freq_min, freq_max], ogni secondo la frequenza aumenta # di hz_per_sec. Valori piccoli rallentano il test e valori grandi diminuiscono # la precisione del test. Il valore predefinito \u00e8 1,0 (Hz/sec == sec^-2). Helper per i file di configurazione \u00b6 [board_pins] \u00b6 Alias pin board (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"board_pins\"). Usalo per definire gli alias per i pin su un microcontrollore. [board_pins my_aliases] mcu: mcu # A comma separated list of micro-controllers that may use the # aliases. The default is to apply the aliases to the main \"mcu\". aliases: aliases_: # A comma separated list of \"name=value\" aliases to create for the # given micro-controller. For example, \"EXP1_1=PE6\" would create an # \"EXP1_1\" alias for the \"PE6\" pin. However, if \"value\" is enclosed # in \"<>\" then \"name\" is created as a reserved pin (for example, # \"EXP1_9=\" would reserve \"EXP1_9\"). Any number of options # starting with \"aliases_\" may be specified. [include] \u00b6 Supporto per includere i file. Uno pu\u00f2 includere un file di configurazione aggiuntivo dal file di configurazione della stampante principale. Possono essere utilizzati anche caratteri jolly (ad es. \"configs/*.cfg\"). [include my_other_config.cfg] [duplicate_pin_override] \u00b6 Questo strumento consente di definire pi\u00f9 volte un singolo pin del microcontrollore in un file di configurazione senza il normale controllo degli errori. Questo \u00e8 inteso per scopi diagnostici e di debug. Questa sezione non \u00e8 necessaria laddove Klipper supporta l'utilizzo dello stesso pin pi\u00f9 volte e l'utilizzo di questa sostituzione pu\u00f2 causare risultati confusi e imprevisti. [duplicate_pin_override] pins: # Un elenco di pin separato da virgole che possono essere utilizzati pi\u00f9 volte in # un file di configurazione senza normali controlli degli errori. Questo parametro deve essere # fornito. Hardware per probing del piatto \u00b6 [probe] \u00b6 Sonda di altezza Z. Si pu\u00f2 definire questa sezione per abilitare l'hardware di rilevamento dell'altezza Z. Quando questa sezione \u00e8 abilitata, i comandi estesi PROBE e QUERY_PROBE comandi g-code diventano disponibili. Inoltre, vedere la Guida alla calibrazione della sonda . La sezione probe crea anche un pin virtuale \"probe:z_virtual_endstop\". Si pu\u00f2 impostare stepper_z endstop_pin su questo pin virtuale su stampanti in stile cartesiano che utilizzano la sonda al posto di un endstop z. Se si utilizza \"probe:z_virtual_endstop\", non definire un position_endstop nella sezione di configurazione stepper_z. [probe] pin: # Pin di rilevamento della sonda. Se il pin si trova su un # microcontrollore diverso rispetto agli stepper Z, abilita # \"homing multi-mcu\". Questo parametro deve essere fornito. #deactivate_on_each_sample: True # Questo determina se Klipper deve eseguire la disattivazione # gcode tra ogni tentativo di esplorazione durante l'esecuzione di # una sequenza di probe multiple. L'impostazione predefinita \u00e8 True. #x_offset: 0.0 # La distanza (in mm) tra la sonda e l'ugello lungo l'asse x. # Il valore predefinito \u00e8 0. #y_offset: 0.0 # La distanza (in mm) tra la sonda e l'ugello lungo l'asse y. # Il valore predefinito \u00e8 0. z_offset: # La distanza (in mm) tra il piatto e l'ugello quando la sonda si attiva. # Questo parametro deve essere fornito. #speed: 5.0 # Velocit\u00e0 (in mm/s) dell'asse Z durante probing. # Il valore predefinito \u00e8 5 mm/s. #samples: 1 # Il numero di volte in cui sondare ciascun punto. I valori z sondati # verranno mediati. L'impostazione predefinita \u00e8 sondare 1 volta. #sample_retract_dist: 2.0 # La distanza (in mm) per sollevare la testa di stampa tra ciascun # campione (se si esegue il campionamento pi\u00f9 di una volta). # Il valore predefinito \u00e8 2 mm. #lift_speed: # Velocit\u00e0 (in mm/s) dell'asse Z durante il sollevamento della sonda # tra i campioni. L'impostazione predefinita prevede l'utilizzo dello # stesso valore del parametro 'speed'. #samples_result: average # Il metodo di calcolo durante il campionamento pi\u00f9 di una volta: # \"median\" o \"average\". L'impostazione predefinita \u00e8 average. #samples_tolerance: 0.100 # La distanza Z massima (in mm) che un campione pu\u00f2 differire da # altri campioni. Se questa tolleranza viene superata, viene segnalato # un errore o il tentativo viene riavviato # (vedere samples_tolerance_retries). Il valore predefinito \u00e8 0,100 mm. #samples_tolerance_retries: 0 # Il numero di tentativi per riprovare se viene trovato un campione che # supera samples_tolerance. In un nuovo tentativo, tutti i campioni # correnti vengono eliminati e il tentativo di sonda viene riavviato. # Se non si ottiene un insieme valido di campioni nel numero di tentativi # specificato, viene segnalato un errore. Il valore predefinito \u00e8 zero che # causa la segnalazione di un errore sul primo campione che supera # samples_tolerance. #activate_gcode: # Un elenco di comandi G-Code da eseguire prima di ogni tentativo di # esplorazione. Vedi docs/Command_Templates.md per il formato # G-Code. Questo pu\u00f2 essere utile se la sonda deve essere attivata in # qualche modo. Non impartire qui alcun comando che sposti la testa # di stampa (ad es. G1). L'impostazione predefinita \u00e8 di non eseguire # alcun comando G-Code speciale all'attivazione. #deactivate_gcode: # Un elenco di comandi G-Code da eseguire dopo il completamento di # ogni tentativo di esplorazione. Vedi docs/Command_Templates.md # per il formato G-Code. Non impartire qui alcun comando che sposti # la testina. L'impostazione predefinita \u00e8 di non eseguire alcun # comando G-Code speciale alla disattivazione. [bltouch] \u00b6 Sonda BLTouch. Si pu\u00f2 definire questa sezione (anzich\u00e9 una sezione sonda) per abilitare una sonda BLTouch. Per ulteriori informazioni, vedere BL-Touch guide e command reference .. Viene anche creato un pin virtuale \"probe:z_virtual_endstop\" (consultare la sezione \"probe\" per i dettagli). [bltouch] sensor_pin: # Pin connected to the BLTouch sensor pin. Most BLTouch devices # require a pullup on the sensor pin (prefix the pin name with \"^\"). # This parameter must be provided. control_pin: # Pin connected to the BLTouch control pin. This parameter must be # provided. #pin_move_time: 0.680 # The amount of time (in seconds) to wait for the BLTouch pin to # move up or down. The default is 0.680 seconds. #stow_on_each_sample: True # This determines if Klipper should command the pin to move up # between each probe attempt when performing a multiple probe # sequence. Read the directions in docs/BLTouch.md before setting # this to False. The default is True. #probe_with_touch_mode: False # If this is set to True then Klipper will probe with the device in # \"touch_mode\". The default is False (probing in \"pin_down\" mode). #pin_up_reports_not_triggered: True # Set if the BLTouch consistently reports the probe in a \"not # triggered\" state after a successful \"pin_up\" command. This should # be True for all genuine BLTouch devices. Read the directions in # docs/BLTouch.md before setting this to False. The default is True. #pin_up_touch_mode_reports_triggered: True # Set if the BLTouch consistently reports a \"triggered\" state after # the commands \"pin_up\" followed by \"touch_mode\". This should be # True for all genuine BLTouch devices. Read the directions in # docs/BLTouch.md before setting this to False. The default is True. #set_output_mode: # Request a specific sensor pin output mode on the BLTouch V3.0 (and # later). This setting should not be used on other types of probes. # Set to \"5V\" to request a sensor pin output of 5 Volts (only use if # the controller board needs 5V mode and is 5V tolerant on its input # signal line). Set to \"OD\" to request the sensor pin output use # open drain mode. The default is to not request an output mode. #x_offset: #y_offset: #z_offset: #speed: #lift_speed: #samples: #sample_retract_dist: #samples_result: #samples_tolerance: #samples_tolerance_retries: # See the \"probe\" section for information on these parameters. [smart_effector] \u00b6 Lo \"Smart Effector\" di Duet3d implementa una sonda Z utilizzando un sensore di forza. Si pu\u00f2 definire questa sezione invece di [probe] per abilitare le funzioni specifiche di Smart Effector. Ci\u00f2 consente anche a comandi di runtime di regolare i parametri di Smart Effector in fase di esecuzione. [smart_effector] pin: # Pin collegato al pin di uscita della sonda Z Smart Effector (pin 5). Si noti # che la resistenza di pullup sulla scheda generalmente non \u00e8 richiesta. # Tuttavia, se il pin di uscita \u00e8 collegato al pin della scheda con un resistore # di pullup, tale resistore deve essere di valore elevato (ad es. 10K Ohm o pi\u00f9). # Alcune schede hanno un resistore di pullup di basso valore sull'ingresso # della sonda Z, che probabilmente far\u00e0 risultare in uno stato di sonda sempre # attivato. In questo caso, collegare lo Smart Effector a un pin diverso sulla # scheda. Questo parametro \u00e8 obbligatorio. #control_pin: # Pin collegato al pin di ingresso di controllo Smart Effector (pin 7). Se fornito, # diventano disponibili i comandi di programmazione della sensibilit\u00e0 # di Smart Effector. #probe_accel: # Se impostato, limita l'accelerazione dei movimenti di tastatura (in mm/sec^2). # Un'improvvisa grande accelerazione all'inizio del movimento di esplorazione # pu\u00f2 causare l'attivazione spuria della sonda, specialmente se l'hotend \u00e8 pesante. # Per evitarlo, potrebbe essere necessario ridurre l'accelerazione dei movimenti # di tastatura tramite questo parametro. #recovery_time: 0.4 # Un ritardo tra i movimenti di spostamento e tastatura in secondi. Un # movimento veloce prima della tastatura pu\u00f2 causare l'attivazione spuria della # sonda. Ci\u00f2 pu\u00f2 causare errori \"Sonda attivata prima del movimento\" se non # \u00e8 impostato alcun ritardo. Il valore 0 disabilita il ritardo di ripristino. # Il valore predefinito \u00e8 0.4. #x_offset: #y_offset: # Dovrebbe essere lasciato non impostato (o impostato su 0). z_offset: # Altezza di attivazione della sonda. Inizia con -0.1 (mm) e regola in seguito # usando il comando `PROBE_CALIBRATE`. Questo parametro deve essere fornito. #speed: # Velocit\u00e0 (in mm/s) dell'asse Z durante la tastatura. Si consiglia di iniziare con la # velocit\u00e0 di tastatura di 20 mm/s e di regolarla secondo necessit\u00e0 per migliorare la # precisione e la ripetibilit\u00e0 dell'attivazione della sonda. #samples: #sample_retract_dist: #samples_result: #samples_tolerance: #samples_tolerance_retries: #activate_gcode: #deactivate_gcode: #deactivate_on_each_sample: # Vedere la sezione \"probe\" per ulteriori informazioni sui parametri di cui sopra. [axis_twist_compensation] \u00b6 Uno strumento per compensare letture imprecise della sonda dovute alla torsione nel portale X. Consultare la Guida alla compensazione della torsione dell'asse per informazioni pi\u00f9 dettagliate su sintomi, configurazione e impostazione. [axis_twist_compensation] #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5. calibrate_start_x: 20 # Defines the minimum X coordinate of the calibration # This should be the X coordinate that positions the nozzle at the starting # calibration position. This parameter must be provided. calibrate_end_x: 200 # Defines the maximum X coordinate of the calibration # This should be the X coordinate that positions the nozzle at the ending # calibration position. This parameter must be provided. calibrate_y: 112.5 # Defines the Y coordinate of the calibration # This should be the Y coordinate that positions the nozzle during the # calibration process. This parameter must be provided and is recommended to # be near the center of the bed Motori passo-passo ed estrusori aggiuntivi \u00b6 [stepper_z1] \u00b6 Assi multi-stepper. Su una stampante in stile cartesiano, lo stepper che controlla un dato asse pu\u00f2 avere blocchi di configurazione aggiuntivi che definiscono gli stepper che dovrebbero essere azionati insieme allo stepper primario. Si pu\u00f2 definire un numero qualsiasi di sezioni con un suffisso numerico che inizia da 1 (ad esempio, \"stepper_z1\", \"stepper_z2\", ecc.). [stepper_z1] #step_pin: #dir_pin: #enable_pin: #microsteps: #rotation_distance: # Vedere la sezione \"stepper\" per la definizione dei parametri di cui sopra. #endstop_pin: # Se viene definito un endstop_pin per lo stepper aggiuntivo, lo stepper # si fermer\u00e0 fino all'attivazione dell'endstop. In caso contrario, lo stepper # si fermer\u00e0 fino a quando non verr\u00e0 attivato il finecorsa sullo stepper # primario per l'asse. [extruder1] \u00b6 In una stampante multiestrusore aggiungere una sezione estrusore aggiuntiva per ogni estrusore aggiuntivo. Le sezioni aggiuntive dell'estrusore devono essere denominate \"extruder1\", \"extruder2\", \"extruder3\" e cos\u00ec via. Vedere la sezione \"extruder\" per una descrizione dei parametri disponibili. Vedere sample-multi-extruder.cfg per un esempio di configurazione. [extruder1] #step_pin: #dir_pin: #... # Vedere la sezione \"estrusore\" per i parametri per lo stepper e il riscaldatore # disponibili. #shared_heater: # Questa opzione \u00e8 obsoleta e non deve pi\u00f9 essere specificata. [dual_carriage] \u00b6 Support for cartesian and hybrid_corexy/z printers with dual carriages on a single axis. The carriage mode can be set via the SET_DUAL_CARRIAGE extended g-code command. For example, \"SET_DUAL_CARRIAGE CARRIAGE=1\" command will activate the carriage defined in this section (CARRIAGE=0 will return activation to the primary carriage). Dual carriage support is typically combined with extra extruders - the SET_DUAL_CARRIAGE command is often called at the same time as the ACTIVATE_EXTRUDER command. Be sure to park the carriages during deactivation. Note that during G28 homing, typically the primary carriage is homed first followed by the carriage defined in the [dual_carriage] config section. However, the [dual_carriage] carriage will be homed first if both carriages home in a positive direction and the [dual_carriage] carriage has a position_endstop greater than the primary carriage, or if both carriages home in a negative direction and the [dual_carriage] carriage has a position_endstop less than the primary carriage. Inoltre, \u00e8 possibile utilizzare i comandi \"SET_DUAL_CARRIAGE CARRIAGE=1 MODE=COPY\" o \"SET_DUAL_CARRIAGE CARRIAGE=1 MODE=MIRROR\" per attivare la modalit\u00e0 di copia o di mirroring del doppio carrello, nel qual caso seguir\u00e0 di conseguenza il movimento del carrello 0 . Questi comandi possono essere utilizzati per stampare due parti contemporaneamente: due parti identiche (in modalit\u00e0 COPIA) o parti specchiate (in modalit\u00e0 SPECCHIO). Tieni presente che le modalit\u00e0 COPY e MIRROR richiedono anche la configurazione appropriata dell'estrusore sul doppio carrello, che in genere pu\u00f2 essere ottenuta con \"SYNC_EXTRUDER_MOTION MOTION_QUEUE=extruder EXTRUDER= \" o un comando simile. Vedere sample-idex.cfg per un esempio di configurazione. [dual_carriage] axis: # The axis this extra carriage is on (either x or y). This parameter # must be provided. #safe_distance: # The minimum distance (in mm) to enforce between the dual and the primary # carriages. If a G-Code command is executed that will bring the carriages # closer than the specified limit, such a command will be rejected with an # error. If safe_distance is not provided, it will be inferred from # position_min and position_max for the dual and primary carriages. If set # to 0 (or safe_distance is unset and position_min and position_max are # identical for the primary and dual carraiges), the carriages proximity # checks will be disabled. #step_pin: #dir_pin: #enable_pin: #microsteps: #rotation_distance: #endstop_pin: #position_endstop: #position_min: #position_max: # See the \"stepper\" section for the definition of the above parameters. [extruder_stepper] \u00b6 Supporto per stepper aggiuntivi sincronizzati al movimento di un estrusore (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"extruder_stepper\"). Per ulteriori informazioni, vedere riferimento comando . [extruder_stepper my_extra_stepper] extruder: # L'estrusore con cui \u00e8 sincronizzato questo stepper. Se questo \u00e8 impostato su # una stringa vuota, lo stepper non verr\u00e0 sincronizzato con un # estrusore. Questo parametro deve essere fornito. #step_pin: #dir_pin: #enable_pin: #microsteps: #rotation_distance: # Vedere la sezione \"stepper\" per la definizione dei parametri sopra. # . [Stepper manuali] \u00b6 Stepper manuali (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"manual_stepper\"). Questi sono stepper controllati dal comando g-code MANUAL_STEPPER. Ad esempio: \"MANUAL_STEPPER STEPPER=my_stepper MOVE=10 SPEED=5\". Vedere il file G-Codes per una descrizione del comando MANUAL_STEPPER. Gli stepper non sono collegati alla normale cinematica della stampante. [manual_stepper my_stepper] #step_pin: #dir_pin: #enable_pin: #microsteps: #rotation_distance: # Vedere la sezione \"stepper\" per una descrizione di questi parametri. #velocity: # Impostare la velocit\u00e0 predefinita (in mm/s) per lo stepper. Questo # valore verr\u00e0 utilizzato se un comando MANUAL_STEPPER non specifica # un parametro SPEED. Il valore predefinito \u00e8 5 mm/s. #accel: # Imposta l'accelerazione predefinita (in mm/s^2) per lo stepper. # Un'accelerazione pari a zero non risulter\u00e0 in nessuna accelerazione. # Questo valore verr\u00e0 utilizzato se un comando MANUAL_STEPPER non # specifica un parametro ACCEL. Il valore predefinito \u00e8 zero. #endstop_pin: # Pin di rilevamento interruttore di fine corsa. Se specificato, \u00e8 possibile # eseguire \"movimenti di riferimento\" aggiungendo un parametro # STOP_ON_ENDSTOP ai comandi di movimento MANUAL_STEPPER. Riscaldatori e sensori personalizzati \u00b6 [verify_heater] \u00b6 Verifica riscaldatore e sensore di temperatura. La verifica del riscaldatore viene abilitata automaticamente per ogni riscaldatore configurato sulla stampante. Usa le sezioni di verifica_riscaldatore per modificare le impostazioni predefinite. [verify_heater heater_config_name] #max_error: 120 # Il massimo \"errore di temperatura cumulativo\" prima di generare un # errore. Valori pi\u00f9 piccoli comportano un controllo pi\u00f9 rigoroso e valori # pi\u00f9 grandi consentono pi\u00f9 tempo prima che venga segnalato un errore. # Nello specifico la temperatura viene osservata una volta al secondo e # se \u00e8 prossima alla temperatura target viene azzerato un \"contatore errori\" # interno; in caso contrario, se la temperatura \u00e8 inferiore all'intervallo target, # il contatore viene aumentato della quantit\u00e0 in cui la temperatura riportata # differisce da tale intervallo. Se il contatore supera questo \"errore_max\", # viene generato un errore. Il valore predefinito \u00e8 120. #check_gain_time: # Questo controlla la verifica del riscaldatore durante il riscaldamento # iniziale. Valori pi\u00f9 piccoli comportano un controllo pi\u00f9 rigoroso e valori # pi\u00f9 grandi consentono pi\u00f9 tempo prima che venga segnalato un errore. # In particolare, durante il riscaldamento iniziale, fintanto che il riscaldatore # aumenta di temperatura entro questo intervallo di tempo (specificato in # secondi), il \"contatore errori\" interno viene azzerato. Il valore predefinito # \u00e8 20 secondi per gli estrusori e 60 secondi per heater_bed. #hysteresis: 5 # La differenza di temperatura massima (in gradi Celsius) rispetto a una # temperatura target considerata nell'intervallo del target. Questo controlla # nell'intervallo max_error. \u00c8 raro personalizzare questo valore. # L'impostazione predefinita \u00e8 5. #heating_gain: 2 # La temperatura minima (in gradi Celsius) di cui il riscaldatore deve # aumentare durante il check_gain_time. \u00c8 raro personalizzare questo valore. # L'impostazione predefinita \u00e8 2. [homing_heaters] \u00b6 Strumento per disabilitare i riscaldatori durante l'homing o la probing di un asse. [homing_heaters] #steppers: # Un elenco separato da virgole di stepper che dovrebbero causare # la disattivazione dei riscaldatori. L'impostazione predefinita \u00e8 # disabilitare i riscaldatori per qualsiasi spostamento di homing/sonda. # Esempio tipico: stepper_z #heaters: # Un elenco separato da virgole di riscaldatori da disabilitare # durante i movimenti di homing/probing. L'impostazione # predefinita \u00e8 disabilitare tutti i riscaldatori. # Esempio tipico: estrusore, letto riscaldatore [thermistor] \u00b6 Termistori personalizzati (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"thermistor\"). \u00c8 possibile utilizzare un termistore personalizzato nel campo sensor_type di una sezione di configurazione del riscaldatore. (Ad esempio, se si definisce una sezione \"[thermistor my_thermistor]\", \u00e8 possibile utilizzare un \"sensor_type: my_thermistor\" quando si definisce un riscaldatore.) Assicurati di posizionare la sezione del termistore nel file di configurazione sopra il suo primo utilizzo in una sezione del riscaldatore . [thermistor my_thermistor] #temperature1: #resistance1: #temperature2: #resistance2: #temperature3: #resistance3: # Tre misure di resistenza (in Ohm) alle temperature date (in Celsius). # Le tre misurazioni verranno utilizzate per calcolare i coefficienti di # Steinhart-Hart per il termistore. Questi parametri devono essere # forniti quando si utilizza Steinhart-Hart per definire il termistore. #beta: # In alternativa, \u00e8 possibile definire temperatura1, resistenza1 e beta # per definire i parametri del termistore. Questo parametro deve # essere fornito quando si utilizza \"beta\" per definire il termistore. [adc_temperature] \u00b6 Sensori di temperatura ADC personalizzati (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"adc_temperature\"). Ci\u00f2 consente di definire un sensore di temperatura personalizzato che misura una tensione su un pin del convertitore da analogico a digitale (ADC) e utilizza l'interpolazione lineare tra una serie di misurazioni di temperatura/tensione (o temperatura/resistenza) configurate per determinare la temperatura. Il sensore risultante pu\u00f2 essere utilizzato come tipo_sensore in una sezione riscaldatore. (Ad esempio, se si definisce una sezione \"[adc_temperature my_sensor]\", \u00e8 possibile utilizzare un \"sensor_type: my_sensor\" quando si definisce un riscaldatore.) Assicurati di posizionare la sezione del sensore nel file di configurazione sopra il suo primo utilizzo in una sezione del riscaldatore. [adc_temperature my_sensor] #temperature1: #voltage1: #temperature2: #voltage2: #... # A set of temperatures (in Celsius) and voltages (in Volts) to use # as reference when converting a temperature. A heater section using # this sensor may also specify adc_voltage and voltage_offset # parameters to define the ADC voltage (see \"Common temperature # amplifiers\" section for details). At least two measurements must # be provided. #temperature1: #resistance1: #temperature2: #resistance2: #... # Alternatively one may specify a set of temperatures (in Celsius) # and resistance (in Ohms) to use as reference when converting a # temperature. A heater section using this sensor may also specify a # pullup_resistor parameter (see \"extruder\" section for details). At # least two measurements must be provided. [heater_generic] \u00b6 Riscaldatori generici (si pu\u00f2 definire un numero qualsiasi di sezioni con il prefisso \"riscaldatore_generico\"). Questi riscaldatori si comportano in modo simile ai riscaldatori standard (estrusori, piatti riscaldati). Utilizzare il comando SET_HEATER_TEMPERATURE (consultare G-Codes per i dettagli) per impostare la temperatura target. [heater_generic my_generic_heater] #gcode_id: # L'ID da utilizzare quando si riporta la temperatura nel comando M105. # Questo parametro deve essere fornito. #max_power: #sensor_type: #sensor_pin: #smooth_time: #control: #pid_Kp: #pid_Ki: #pid_Kd: #pwm_cycle_time: #min_temp: #max_temp: # Vedere la sezione \"extruder\" per la definizione dei parametri sopra. [temperature_sensor] \u00b6 Sensori di temperatura generici. \u00c8 possibile definire un numero qualsiasi di sensori di temperatura aggiuntivi che vengono riportati tramite il comando M105. [temperature_sensor my_sensor] #sensor_type: #sensor_pin: #min_temp: #max_temp: # Vedi la sezione \"extruder\" per la definizione dei parametri # sopra indicati. #gcode_id: # Vedi la sezione \"heater_generic\" per la definizione dei # parametri sopra indicati. Sensori di temperatura \u00b6 Klipper include definizioni per molti tipi di sensori di temperatura. Questi sensori possono essere utilizzati in qualsiasi sezione di configurazione che richieda un sensore di temperatura (come una sezione [extruder] o [heater_bed] ). Termistori comuni \u00b6 Termistori comuni. I seguenti parametri sono disponibili nelle sezioni del riscaldatore che utilizzano uno di questi sensori. sensor_type: # Uno di \"EPCOS 100K B57560G104F\", \"ATC Semitec 104GT-2\", # \"ATC Semitec 104NT-4-R025H42G\", \"Generic 3950\", # \"Honeywell 100K 135-104LAG-J01\", \"NTC 100K MGB18-104F39050L32\", # \"SliceEngineering 450\", o \"TDK NTCG104LH104JT1\" sensor_pin: # Pin di ingresso analogico collegato al termistore. # Questo parametro deve essere fornito. #pullup_resistor: 4700 # La resistenza (in ohm) del pullup collegato al termistore. # Il valore predefinito \u00e8 4700 ohm. #inline_resistor: 0 # La resistenza (in ohm) di un resistore aggiuntivo (non a variazione di # calore) posizionato in linea con il termistore. \u00c8 raro impostare questo. # Il valore predefinito \u00e8 0 ohm. Amplificatori di temperatura comuni \u00b6 Amplificatori di temperatura comuni. I seguenti parametri sono disponibili nelle sezioni del riscaldatore che utilizzano uno di questi sensori. sensor_type: # Uno tra \"PT100 INA826\", \"AD595\", \"AD597\", \"AD8494\", \"AD8495\", # \"AD8496\", o \"AD8497\". sensor_pin: # Pin di ingresso analogico collegato al sensore. Questo parametro # deve essere fornito. #adc_voltage: 5.0 # La tensione di confronto dell'ADC (in Volt). Il valore predefinito # \u00e8 5 volt. #voltage_offset: 0 # L'offset di tensione ADC (in Volt). Il valore predefinito \u00e8 0. Sensore PT1000 collegato direttamente \u00b6 Sensore PT1000 collegato direttamente. I seguenti parametri sono disponibili nelle sezioni del riscaldatore che utilizzano uno di questi sensori. sensor_type: PT1000 sensor_pin: # Pin di ingresso analogico collegato al sensore. Questo parametro # deve essere fornito. #pullup_resistor: 4700 # La resistenza (in ohm) del pullup collegato al sensore. Il valore # predefinito \u00e8 4700 ohm. Sensori di temperatura MAXxxxxx \u00b6 Sensori temperatura MAXxxxxx con interfaccia periferica seriale (SPI). I seguenti parametri sono disponibili nelle sezioni del riscaldatore che utilizzano uno di questi tipi di sensore. sensor_type: # Uno tra \"MAX6675\", \"MAX31855\", \"MAX31856\", o \"MAX31865\". sensor_pin: # Il pin mcu collegato al pin di selezione del chip del sensore. # Questo parametro deve essere fornito. #spi_speed: 4000000 # La velocit\u00e0 SPI (in hz) da utilizzare durante la comunicazione # con il chip. Il valore predefinito \u00e8 4000000. #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # Vedere la sezione \"impostazioni comuni SPI\" per una # descrizione dei parametri di cui sopra. #tc_type: K #tc_use_50Hz_filter: False #tc_averaging_count: 1 # I parametri di cui sopra controllano i parametri del sensore # dei chip MAX31856. I valori predefiniti per ciascun parametro # sono accanto al nome del parametro nell'elenco precedente. #rtd_nominal_r: 100 #rtd_reference_r: 430 #rtd_num_of_wires: 2 #rtd_use_50Hz_filter: False # I parametri di cui sopra controllano i parametri del sensore dei # chip MAX31865. I valori predefiniti per ciascun parametro sono # accanto al nome del parametro nell'elenco precedente. Sensore di temperatura BMP280/BME280/BME680 \u00b6 Sensori ambientali BMP280/BME280/BME680 con interfaccia I2C. Si noti che questi sensori non sono destinati all'uso con estrusori e letti riscaldanti, ma piuttosto per il monitoraggio della temperatura ambiente (C), della pressione (hPa), dell'umidit\u00e0 relativa (%)e di livello del gas per il BME680. Vedere sample-macros.cfg per una gcode_macro che pu\u00f2 essere utilizzata per riportare la pressione e l'umidit\u00e0 oltre alla temperatura. sensor_type: BME280 #i2c_address: # Default is 118 (0x76). Some BME280 sensors have an address of 119 # (0x77). #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. Sensore temperatura AHT10/AHT20/AHT21 \u00b6 Sensori ambientali con interfaccia a due fili (I2C) AHT10/AHT20/AHT21. Si noti che questi sensori non sono destinati all'uso con estrusori e letti riscaldanti, ma piuttosto per il monitoraggio della temperatura ambiente (C) e dell'umidit\u00e0 relativa. Vedi sample-macros.cfg per un gcode_macro che pu\u00f2 essere utilizzato per segnalare l'umidit\u00e0 oltre alla temperatura. sensor_type: AHT10 # Also use AHT10 for AHT20 and AHT21 sensors. #i2c_address: # Default is 56 (0x38). Some AHT10 sensors give the option to use # 57 (0x39) by moving a resistor. #i2c_mcu: #i2c_bus: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #aht10_report_time: # Interval in seconds between readings. Default is 30, minimum is 5 Sensore HTU21D \u00b6 Sensore ambientale con interfaccia a due fili (I2C) della famiglia HTU21D. Si noti che questo sensore non \u00e8 destinato all'uso con estrusori e letti riscaldanti, ma piuttosto per il monitoraggio della temperatura ambiente (C) e dell'umidit\u00e0 relativa(%). Vedere sample-macros.cfg per una gcode_macro che pu\u00f2 essere utilizzata per riportare l'umidit\u00e0 oltre alla temperatura. sensor_type: # Must be \"HTU21D\" , \"SI7013\", \"SI7020\", \"SI7021\" or \"SHT21\" #i2c_address: # Default is 64 (0x40). #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #htu21d_hold_master: # If the sensor can hold the I2C buf while reading. If True no other # bus communication can be performed while reading is in progress. # Default is False. #htu21d_resolution: # The resolution of temperature and humidity reading. # Valid values are: # 'TEMP14_HUM12' -> 14bit for Temp and 12bit for humidity # 'TEMP13_HUM10' -> 13bit for Temp and 10bit for humidity # 'TEMP12_HUM08' -> 12bit for Temp and 08bit for humidity # 'TEMP11_HUM11' -> 11bit for Temp and 11bit for humidity # Default is: \"TEMP11_HUM11\" #htu21d_report_time: # Interval in seconds between readings. Default is 30 Sensore di temperatura LM75 \u00b6 Sensori di temperatura (I2C) LM75/LM75A. Questi sensori hanno una gamma di -55~125 C, quindi sono utilizzabili ad es. monitoraggio della temperatura della camera. Possono anche funzionare come semplici controller per ventole/riscaldatori. sensor_type: LM75 #i2c_address: # Default is 72 (0x48). Normal range is 72-79 (0x48-0x4F) and the 3 # low bits of the address are configured via pins on the chip # (usually with jumpers or hard wired). #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #lm75_report_time: # Interval in seconds between readings. Default is 0.8, with minimum # 0.5. Sensore di temperatura integrato nel microcontrollore \u00b6 I microcontrollori atsam, atsamd e stm32 contengono un sensore di temperatura interno. \u00c8 possibile utilizzare il sensore \"temperature_mcu\" per monitorare queste temperature. sensor_type: temperature_mcu #sensor_mcu: mcu # Il microcontrollore da cui leggere. L'impostazione predefinita \u00e8 \"mcu\". #sensor_temperature1: #sensor_adc1: # Specificare i due parametri precedenti (una temperatura in gradi # Celsius e un valore ADC come float compreso tra 0,0 e 1,0) per # calibrare la temperatura del microcontrollore. Ci\u00f2 potrebbe # migliorare la precisione della temperatura riportata su alcuni chip. # Un modo tipico per ottenere queste informazioni di calibrazione # consiste nel rimuovere completamente l'alimentazione dalla # stampante per alcune ore (per assicurarsi che sia alla temperatura # ambiente), quindi accenderla e utilizzare il comando QUERY_ADC # per ottenere una misurazione ADC. Utilizzare un altro sensore di # temperatura sulla stampante per trovare la temperatura ambiente # corrispondente. L'impostazione predefinita consiste nell'utilizzare # i dati di calibrazione di fabbrica sul microcontrollore (se applicabile) # o i valori nominali dalle specifiche del microcontrollore. #sensor_temperature2: #sensor_adc2: # Se viene specificato sensor_temperature1/sensor_adc1, \u00e8 anche # possibile specificare i dati di calibrazione sensor_temperature2/sensor_adc2. # Ci\u00f2 potrebbe fornire informazioni calibrate sulla \"curva della # temperatura\". L'impostazione predefinita consiste nell'utilizzare i dati # di calibrazione di fabbrica sul microcontrollore (se applicabile) o i # valori nominali dalle specifiche del microcontrollore. Sensore di temperatura host \u00b6 Temperatura dalla macchina (es. Raspberry Pi) che esegue il software host. sensor_type: temperature_host #sensor_path: # il percorso del file di sistema della temperatura. L'impostazione # predefinita \u00e8 \"/sys/class/thermal/thermal_zone0/temp\" che \u00e8 il file di # sistema della temperatura su un computer Raspberry Pi. Sensore di temperatura DS18B20 \u00b6 DS18B20 \u00e8 un sensore di temperatura digitale a 1 filo (w1). Si noti che questo sensore non \u00e8 destinato all'uso con estrusori e letti riscaldanti, ma piuttosto per il monitoraggio della temperatura ambiente (C). Questi sensori hanno una portata fino a 125 C, quindi sono utilizzabili ad es. monitoraggio della temperatura della camera. Possono anche funzionare come semplici controller per ventole/riscaldatori. I sensori DS18B20 sono supportati solo su \"host mcu\", ad es. il Raspberry Pi. \u00c8 necessario installare il modulo del kernel Linux w1-gpio. sensor_type: DS18B20 serial_no: # Ogni dispositivo a 1 filo ha un numero di serie univoco utilizzato per # identificare il dispositivo, solitamente nel formato 28-031674b175ff. Questo # parametro deve essere fornito. I dispositivi collegati a 1 filo possono essere # elencati utilizzando il seguente comando Linux: ls /sys/bus/w1/devices/ #ds18_report_time: # Intervallo in secondi tra le letture. Il valore predefinito \u00e8 3.0, con un # minimo di 1.0 #sensor_mcu: # Il microcontrollore da cui leggere. Deve essere host_mcu Combined temperature sensor \u00b6 Combined temperature sensor is a virtual temperature sensor based on several other sensors. This sensor can be used with extruders, heater_generic and heater beds. sensor_type: temperature_combined #sensor_list: # Must be provided. List of sensors to combine to new \"virtual\" # sensor. # E.g. 'temperature_sensor sensor1,extruder,heater_bed' #combination_method: # Must be provided. Combination method used for the sensor. # Available options are 'max', 'min', 'mean'. #maximum_deviation: # Must be provided. Maximum permissible deviation between the sensors # to combine (e.g. 5 degrees). To disable it, use a large value (e.g. 999.9) Ventole \u00b6 [fan] \u00b6 Ventola di raffreddamento della stampa. [fan] pin: # Pin di output che controlla la ventola. Questo parametro deve essere fornito. #max_power: 1.0 # La potenza massima (espressa come un valore compreso tra 0.0 e 1.0) a # cui pu\u00f2 essere impostato il pin. Il valore 1.0 consente di impostare il pin # completamente abilitato per periodi prolungati, mentre un valore di 0.5 # consentirebbe di abilitare il pin per non pi\u00f9 della met\u00e0 del tempo. Questa # impostazione pu\u00f2 essere utilizzata per limitare la potenza totale (per # periodi prolungati) della ventola. Se questo valore \u00e8 inferiore a 1.0, le # richieste di velocit\u00e0 della ventola verranno ridimensionate tra zero e # max_power (ad esempio, se max_power \u00e8 0.9 e viene richiesta una # velocit\u00e0 della ventola dell'80%, la potenza della ventola verr\u00e0 impostata # su 72%). L'impostazione predefinita \u00e8 1.0. #shutdown_speed: 0 # La velocit\u00e0 della ventola desiderata (espressa come valore da 0.0 a # 1.0) se il software del microcontrollore entra in uno stato di errore. # Il valore predefinito \u00e8 0. #cycle_time: 0.010 # La quantit\u00e0 di tempo (in secondi) per ogni ciclo di alimentazione PWM # alla ventola. Si consiglia di essere pari o superiore a 10 millisecondi # quando si utilizza il PWM basato su software. # Il valore predefinito \u00e8 0,010 secondi. #hardware_pwm: False # Abilitare questa opzione per utilizzare PWM hardware anzich\u00e9 PWM # software. La maggior parte delle ventole non funziona bene con PWM # hardware, quindi non \u00e8 consigliabile abilitarlo a meno che non vi sia # un requisito elettrico per passare a velocit\u00e0 molto elevate. Quando # si utilizza l'hardware PWM, il tempo di ciclo effettivo \u00e8 vincolato # dall'implementazione e pu\u00f2 essere notevolmente diverso dal tempo # di ciclo richiesto. L'impostazione predefinita \u00e8 False. #kick_start_time: 0.100 # Tempo (in secondi) per far funzionare la ventola a piena velocit\u00e0 # quando la si abilita per la prima volta o la si aumenta di oltre il 50% # (aiuta a far girare la ventola). Il valore predefinito \u00e8 0,100 secondi. #off_below: 0.0 # La velocit\u00e0 minima in input che alimenter\u00e0 la ventola (espressa # come un valore da 0.0 a 1.0). Quando viene richiesta una velocit\u00e0 # inferiore a off_below la ventola verr\u00e0 invece spenta. Questa # impostazione pu\u00f2 essere utilizzata per prevenire lo stallo della # ventola e per garantire che i kick start siano efficaci. # Il valore predefinito \u00e8 0.0. # # Questa impostazione deve essere ricalibrata ogni volta che # max_power viene regolato. Per calibrare questa impostazione, # inizia con off_below impostato su 0.0 e la ventola gira. Abbassare # gradualmente la velocit\u00e0 della ventola per determinare la velocit\u00e0 # di ingresso pi\u00f9 bassa che aziona la ventola in modo affidabile senza # stalli. Impostare off_below al duty cycle corrispondente a questo # valore (ad esempio, 12% -> 0,12) o leggermente superiore. #tachometer_pin: # Pin di ingresso contagiri per il monitoraggio della velocit\u00e0 della # ventola. In genere \u00e8 richiesto un pullup. Questo parametro \u00e8 facoltativo. #tachometer_ppr: 2 # Quando viene specificato tachometer_pin, questo \u00e8 il numero di # impulsi per giro del segnale del tachimetro. Per una ventola BLDC # questo \u00e8 normalmente la met\u00e0 del numero di poli. # L'impostazione predefinita \u00e8 2. #tachometer_poll_interval: 0.0015 # Quando viene specificato tachometer_pin, questo \u00e8 il periodo di polling # del pin del contagiri, in secondi. Il valore predefinito \u00e8 0.0015, che \u00e8 # abbastanza veloce per le ventole al di sotto di 10000 RPM a 2 PPR. Deve # essere inferiore a 30/(tachometer_ppr*rpm), con un certo margine, # dove rpm \u00e8 la velocit\u00e0 massima (in RPM) della ventola. #enable_pin: # Pin opzionale per abilitare l'alimentazione alla ventola. Questo pu\u00f2 # essere utile per le ventole con ingressi PWM dedicati. Alcune di queste # ventole rimangono accese anche allo 0% di ingresso PWM. In tal caso, # il pin PWM pu\u00f2 essere utilizzato normalmente e ad es. un FET commutato # a terra (pin della ventola standard) pu\u00f2 essere utilizzato per controllare # l'alimentazione alla ventola. [heater_fan] \u00b6 Ventole di raffreddamento del riscaldatore (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"heater_fan\"). Una \"ventola riscaldatore\" \u00e8 una ventola che verr\u00e0 abilitata ogni volta che il riscaldatore associato \u00e8 attivo. Per impostazione predefinita, un heater_fan ha una velocit\u00e0 di spegnimento pari a max_power. [heater_fan heatbreak_cooling_fan] #pin: #max_power: #shutdown_speed: #cycle_time: #hardware_pwm: #kick_start_time: #off_below: #tachometer_pin: #tachometer_ppr: #tachometer_poll_interval: #enable_pin: # See the \"fan\" section for a description of the above parameters. #heater: extruder # Name of the config section defining the heater that this fan is # associated with. If a comma separated list of heater names is # provided here, then the fan will be enabled when any of the given # heaters are enabled. The default is \"extruder\". #heater_temp: 50.0 # A temperature (in Celsius) that the heater must drop below before # the fan is disabled. The default is 50 Celsius. #fan_speed: 1.0 # The fan speed (expressed as a value from 0.0 to 1.0) that the fan # will be set to when its associated heater is enabled. The default # is 1.0 [controller_fan] \u00b6 Ventola di raffreddamento del controller (\u00e8 possibile definire un numero qualsiasi di sezioni con il prefisso \"controller_fan\"). Una \"ventola del controller\" \u00e8 una ventola che verr\u00e0 abilitata ogni volta che il riscaldatore associato o il driver stepper associato \u00e8 attivo. La ventola si fermer\u00e0 ogni volta che viene raggiunto un idle_timeout per garantire che non si verifichi alcun surriscaldamento dopo la disattivazione di un componente osservato. [controller_fan my_controller_fan] #pin: #max_power: #shutdown_speed: #cycle_time: #hardware_pwm: #kick_start_time: #off_below: #tachometer_pin: #tachometer_ppr: #tachometer_poll_interval: #enable_pin: # Vedere la sezione \"fan\" per una descrizione dei parametri di cui sopra. #fan_speed: 1.0 # La velocit\u00e0 della ventola (espressa come un valore compreso tra 0.0 e # 1.0) a cui verr\u00e0 impostata la ventola quando \u00e8 attivo un riscaldatore # o un driver passo-passo. L'impostazione predefinita \u00e8 1.0 #idle_timeout: # La quantit\u00e0 di tempo (in secondi) dopo che un driver passo-passo o # un riscaldatore \u00e8 stato attivo per la quale la ventola deve essere tenuta # in funzione. L'impostazione predefinita \u00e8 30 secondi. #idle_speed: # La velocit\u00e0 della ventola (espressa come un valore compreso tra 0.0 # e 1.0) a cui verr\u00e0 impostata la ventola quando era attivo un riscaldatore # o un driver passo-passo e prima che venga raggiunto l'idle_timeout. # L'impostazione predefinita \u00e8 fan_speed. #heater: #stepper: # Nome della sezione di configurazione che definisce il riscaldatore/ # stepper a cui \u00e8 associata questa ventola. Se qui viene fornito un # elenco separato da virgole di nomi di riscaldatori/stepper, la ventola # sar\u00e0 abilitata quando uno qualsiasi dei riscaldatori/stepper indicati # \u00e8 abilitato. Il riscaldatore predefinito \u00e8 \"estrusore\", lo stepper # predefinito sono tutti. [temperature_fan] \u00b6 Ventole di raffreddamento attivate dalla temperatura (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"temperature_fan\"). Una \"ventola di temperatura\" \u00e8 una ventola che verr\u00e0 abilitata ogni volta che il sensore associato \u00e8 al di sopra di una temperatura impostata. Per impostazione predefinita, una ventola_temperatura ha una velocit\u00e0_di_arresto pari a potenza_massima. Per ulteriori informazioni, vedere command reference . [temperature_fan my_temp_fan] #pin: #max_power: #shutdown_speed: #cycle_time: #hardware_pwm: #kick_start_time: #off_below: #tachometer_pin: #tachometer_ppr: #tachometer_poll_interval: #enable_pin: # Vedere la sezione \"fan\" per una descrizione dei parametri di cui sopra. #sensor_type: #sensor_pin: #control: #max_delta: #min_temp: #max_temp: # Vedere la sezione \"extruder\" per una descrizione dei parametri di cui sopra. #pid_Kp: #pid_Ki: #pid_Kd: # Le impostazioni proporzionale (pid_Kp), integrale (pid_Ki) e derivata (pid_Kd) # per il sistema di controllo del feedback PID. Klipper valuta le impostazioni PID # con la seguente formula generale: fan_pwm = max_power - (Kp*e + Ki*integral(e) # - Kd*derivative(e)) / 255 Dove \"e\" \u00e8 \"target_temperature - measure_temperature\" # e \"fan_pwm\" \u00e8 la frequenza della ventola richiesta con 0.0 per spento e 1.0 al # massimo. I parametri pid_Kp, pid_Ki e pid_Kd devono essere forniti quando l# 'algoritmo di controllo PID \u00e8 abilitato. #pid_deriv_time: 2.0 # Un valore di tempo (in secondi) su cui le misurazioni della temperatura verranno # livellate quando si utilizza l'algoritmo di controllo PID. Ci\u00f2 pu\u00f2 ridurre l'impatto # del rumore di misurazione. Il valore predefinito \u00e8 2 secondi. #target_temp: 40.0 # Una temperatura (in Celsius) che sar\u00e0 la temperatura target. # L'impostazione predefinita \u00e8 40 gradi. #max_speed: 1.0 # La velocit\u00e0 della ventola (espressa come un valore compreso tra 0.0 e 1.0) a cui # verr\u00e0 impostata la ventola quando la temperatura del sensore supera il valore # impostato. L'impostazione predefinita \u00e8 1.0. #min_speed: 0.3 # La velocit\u00e0 minima della ventola (espressa come un valore compreso tra 0.0 e # 1.0) alla quale la ventola verr\u00e0 impostata per le ventole con temperatura PID. # Il valore predefinito \u00e8 0.3. #gcode_id: # Se impostata, la temperatura verr\u00e0 riportata nelle query M105 utilizzando l'id # fornito. L'impostazione predefinita \u00e8 di non riportare la temperatura tramite M105. [fan_generic] \u00b6 Ventola a controllo manuale (si pu\u00f2 definire un numero qualsiasi di sezioni con il prefisso \"fan_generic\"). La velocit\u00e0 di una ventola controllata manualmente viene impostata con SET_FAN_SPEED comando gcode . [fan_generic extruder_partfan] #pin: #max_power: #shutdown_speed: #cycle_time: #hardware_pwm: #kick_start_time: #off_below: #tachometer_pin: #tachometer_ppr: #tachometer_poll_interval: #enable_pin: # Vedere la sezione \"fan\" per una descrizione dei parametri di cui sopra. LEDs \u00b6 [led] \u00b6 Supporto per LED (e strisce LED) controllati tramite pin PWM del microcontrollore (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"led\"). Per ulteriori informazioni, vedere command reference . [led my_led] #red_pin: #green_pin: #blue_pin: #white_pin: # Il pin che controlla il colore del LED specificato. Deve essere fornito # almeno uno dei parametri sopra indicati. #cycle_time: 0.010 # La quantit\u00e0 di tempo (in secondi) per ciclo PWM. Si consiglia che sia # pari o superiore a 10 millisecondi quando si utilizza il PWM basato # su software. Il valore predefinito \u00e8 0,010 secondi. #hardware_pwm: False # Abilitare questa opzione per utilizzare PWM hardware anzich\u00e9 PWM # software. Quando si utilizza l'hardware PWM, il tempo di ciclo effettivo # \u00e8 vincolato dall'implementazione e pu\u00f2 essere notevolmente diverso # dal tempo di ciclo richiesto. L'impostazione predefinita \u00e8 Falso. #initial_RED: 0.0 #initial_GREEN: 0.0 #initial_BLUE: 0.0 #initial_WHITE: 0.0 # Imposta il colore iniziale del LED. Ciascun valore deve essere # compreso tra 0,0 e 1,0. Il valore predefinito per ogni colore \u00e8 0. [neopixel] \u00b6 Supporto LED Neopixel (aka WS2812) (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"neopixel\"). Per ulteriori informazioni, vedere riferimento comando . Si noti che l'implementazione di linux mcu non supporta attualmente i neopixel collegati direttamente. L'attuale design che utilizza l'interfaccia del kernel Linux non consente questo scenario perch\u00e9 l'interfaccia GPIO del kernel non \u00e8 sufficientemente veloce da fornire le frequenze di impulso richieste. [neopixel my_neopixel] pin: # Il pin collegato al neopixel. Questo parametro deve essere fornito. #chain_count: # Il numero di chip Neopixel che sono \"collegati a margherita\" al # pin fornito. Il valore predefinito \u00e8 1 (che indica che un solo # Neopixel \u00e8 collegato al pin). #color_order: GRB # Impostare l'ordine dei pixel richiesto dall'hardware del LED # (utilizzando una stringa contenente le lettere R, G, B, W con W # opzionale). In alternativa, questo pu\u00f2 essere un elenco separato # da virgole di pixel, uno per ogni LED nella catena. # L'impostazione predefinita \u00e8 GRB. #initial_RED: 0.0 #initial_GREEN: 0.0 #initial_BLUE: 0.0 #initial_WHITE: 0.0 # Vedere la sezione \"led\" per informazioni su questi parametri. [dotstar] \u00b6 Supporto LED Dotstar (conosciuti anche come APA102) (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"dotstar\"). Per ulteriori informazioni, vedere command reference . [dotstar my_dotstar] data_pin: # Il pin connesso alla data line del dotstar. Questo parametro # deve essere fornito. clock_pin: # Il pin connesso alla clock line del dotstar. Questo parametro # deve essere fornito. #chain_count: # Vedere la sezione \"neopixel\" per informazioni su questo parametro. #initial_RED: 0.0 #initial_GREEN: 0.0 #initial_BLUE: 0.0 # Vedere la sezione \"led\" per informazioni su questo parametro. [pca9533] \u00b6 PCA9533 Supporto LED. Il PCA9533 viene utilizzato sulla scheda mightyboard. [pca9533 my_pca9533] #i2c_address: 98 # The i2c address that the chip is using on the i2c bus. Use 98 for # the PCA9533/1, 99 for the PCA9533/2. The default is 98. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #initial_RED: 0.0 #initial_GREEN: 0.0 #initial_BLUE: 0.0 #initial_WHITE: 0.0 # See the \"led\" section for information on these parameters. [pca9632] \u00b6 Supporto LED PCA9632. Il PCA9632 viene utilizzato su FlashForge Dreamer. [pca9632 my_pca9632] #i2c_address: 98 # The i2c address that the chip is using on the i2c bus. This may be # 96, 97, 98, or 99. The default is 98. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #scl_pin: #sda_pin: # Alternatively, if the pca9632 is not connected to a hardware I2C # bus, then one may specify the \"clock\" (scl_pin) and \"data\" # (sda_pin) pins. The default is to use hardware I2C. #color_order: RGBW # Set the pixel order of the LED (using a string containing the # letters R, G, B, W). The default is RGBW. #initial_RED: 0.0 #initial_GREEN: 0.0 #initial_BLUE: 0.0 #initial_WHITE: 0.0 # See the \"led\" section for information on these parameters. Servocomandi aggiuntivi, pulsanti e altri pin \u00b6 [servo] \u00b6 Servo (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"servo\"). I servo possono essere controllati usando SET_SERVO comando g-code . Ad esempio: SET_SERVO SERVO=my_servo ANGLE=180 [servo my_servo] pin: # Pin di uscita PWM che controlla il servo. Questo parametro deve # essere fornito. #maximum_servo_angle: 180 # L'angolo massimo (in gradi) a cui questo servo pu\u00f2 essere impostato. # L'impostazione predefinita \u00e8 180 gradi. #minimum_pulse_width: 0.001 # La durata minima dell'impulso (in secondi). Questo dovrebbe # corrispondere a un angolo di 0 gradi. Il valore predefinito \u00e8 0.001 secondi. #maximum_pulse_width: 0.002 # La durata massima dell'impulso (in secondi). Questo dovrebbe # corrispondere a un angolo di maximum_servo_angle. Il valore # predefinito \u00e8 0.002 secondi. #initial_angle: # Angolo iniziale (in gradi) su cui impostare il servo. L'impostazione # predefinita \u00e8 di non inviare alcun segnale all'avvio. #initial_pulse_width: # Durata iniziale dell'impulso (in secondi) su cui impostare il servo. # (Questo \u00e8 valido solo se initial_angle non \u00e8 impostato.) # L'impostazione predefinita \u00e8 di non inviare alcun segnale all'avvio. [gcode_button] \u00b6 Esegui gcode quando un pulsante viene premuto o rilasciato (o quando un pin cambia stato). Puoi controllare lo stato del pulsante usando QUERY_BUTTON button=my_gcode_button . [gcode_button my_gcode_button] pin: # Il pin su cui \u00e8 collegato il pulsante. Questo parametro deve essere fornito. #analog_range: # Due resistenze separate da virgole (in Ohm) che specificano l'intervallo # di resistenza minimo e massimo per il pulsante. Se viene fornito # analog_range, il pin deve essere un pin con capacit\u00e0 analogica. # L'impostazione predefinita \u00e8 utilizzare digital gpio per il pulsante. #analog_pullup_resistor: # La resistenza di pullup (in Ohm) quando \u00e8 specificato analog_range. # Il valore predefinito \u00e8 4700 ohm. #press_gcode: # Un elenco di comandi G-Code da eseguire quando si preme il pulsante. # I modelli G-Code sono supportati. Questo parametro deve essere fornito. #release_gcode: # Un elenco di comandi G-Code da eseguire quando il pulsante viene # rilasciato. I modelli G-Code sono supportati. L'impostazione predefinita # \u00e8 di non eseguire alcun comando al rilascio di un pulsante. [output_pin] \u00b6 Pin di uscita configurabili in fase di run-time (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"output_pin\"). I pin configurati qui verranno impostati come pin di output e sar\u00e0 possibile modificarli in fase di esecuzione utilizzando il comando esteso \"SET_PIN PIN=my_pin VALUE=.1\" comandi g-code . [output_pin my_pin] pin: # Il pin da configurare come output. # Questo parametro deve essere fornito. #pwm: False # Impostare se il pin di uscita deve essere in grado di modulare la # larghezza di impulso PWM. Se questo \u00e8 True, i campi del valore # dovrebbero essere compresi tra 0 e 1; se \u00e8 False i campi del valore # devono essere 0 o 1. Il valore predefinito \u00e8 False. #static_value: # Se \u00e8 valorizzato, il pin viene assegnato a questo valore all'avvio e # il pin non pu\u00f2 essere modificato durante il runtime. Un pin statico # utilizza una ram leggermente inferiore nel microcontrollore. # L'impostazione predefinita prevede l'utilizzo della configurazione # di runtime dei pin. #value: # Il valore su cui impostare inizialmente il pin durante la # configurazione dell'MCU. Il valore predefinito \u00e8 0 (per bassa tensione). #shutdown_value: # Il valore su cui impostare il pin su un evento di arresto dell'MCU. # Il valore predefinito \u00e8 0 (per bassa tensione). #maximum_mcu_duration: # La durata massima di un valore di non spegnimento pu\u00f2 essere # determinato dall'MCU senza un riconoscimento da parte dell'host. # Se l'host non riesce a tenere il passo con un aggiornamento, l'MCU # si spegner\u00e0 e imposter\u00e0 tutti i pin sui rispettivi valori di spegnimento. # Default: 0 (disabilitato) I valori abituali sono circa 5 secondi. #cycle_time: 0.100 # La quantit\u00e0 di tempo (in secondi) per ciclo PWM. Si consiglia di # essere pari o superiore a 10 millisecondi quando si utilizza il PWM # basato su software. Il valore predefinito \u00e8 0.100 secondi per i pin pwm. #hardware_pwm: False # Abilitare questa opzione per utilizzare PWM hardware anzich\u00e9 PWM # software. Quando si utilizza l'hardware PWM, il tempo di ciclo effettivo # \u00e8 vincolato dall'implementazione e pu\u00f2 essere notevolmente diverso # dal tempo di ciclo richiesto. L'impostazione predefinita \u00e8 Falso. #scale: # Questo parametro pu\u00f2 essere utilizzato per modificare il modo in cui # i parametri 'value' e 'shutdown_value' vengono interpretati per i pin # pwm. Se fornito, il parametro 'value' deve essere compreso tra 0.0 e # 'scale'. Questo pu\u00f2 essere utile quando si configura un pin PWM che # controlla un riferimento di tensione stepper. La \"scala\" pu\u00f2 essere # impostata sull'amperaggio dello stepper equivalente se il PWM fosse # completamente abilitato, quindi il parametro \"value\" pu\u00f2 essere # specificato utilizzando l'amperaggio desiderato per lo stepper. # L'impostazione predefinita \u00e8 di non ridimensionare il parametro 'value'. [static_digital_output] \u00b6 Pin di uscita digitali configurati staticamente (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"static_digital_output\"). I pin configurati qui verranno impostati come uscita GPIO durante la configurazione dell'MCU. Non possono essere modificati in fase di esecuzione. [static_digital_output my_output_pins] pins: # Un elenco separato da virgole di pin da impostare come pin di # output GPIO. Il pin verr\u00e0 impostato su un livello alto a meno che il # nome del pin non sia preceduto da \"!\". Questo parametro deve # essere fornito. [multi_pin] \u00b6 Uscite a pin multipli (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"multi_pin\"). Un output multi_pin crea un alias pin interno che pu\u00f2 modificare pi\u00f9 pin di output ogni volta che viene impostato il pin alias. Ad esempio, si potrebbe definire un oggetto \"[multi_pin my_fan]\" contenente due pin e quindi impostare \"pin=multi_pin:my_fan\" nella sezione \"[fan]\" - ad ogni cambio di ventola entrambi i pin di output verrebbero aggiornati. Questi alias non possono essere utilizzati con i pin del motore passo-passo. [multi_pin my_multi_pin] pins: # Un elenco separato da virgole di pin associati a questo alias. # Questo parametro deve essere fornito. Configurazione del driver TMC per stepper \u00b6 Configurazione dei driver per motori passo-passo Trinamic in modalit\u00e0 UART/SPI. Ulteriori informazioni si trovano nella TMC Drivers guide e nel command reference . [tmc2130] \u00b6 Configurare un driver per motore passo-passo TMC2130 tramite bus SPI. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso \"tmc2130\" seguito dal nome della sezione di configurazione dello stepper corrispondente (ad esempio, \"[tmc2130 stepper_x]\"). [tmc2130 stepper_x] cs_pin: # The pin corresponding to the TMC2130 chip select line. This pin # will be set to low at the start of SPI messages and raised to high # after the message completes. This parameter must be provided. #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #chain_position: #chain_length: # These parameters configure an SPI daisy chain. The two parameters # define the stepper position in the chain and the total chain length. # Position 1 corresponds to the stepper that connects to the MOSI signal. # The default is to not use an SPI daisy chain. #interpolate: True # If true, enable step interpolation (the driver will internally # step at a rate of 256 micro-steps). This interpolation does # introduce a small systemic positional deviation - see # TMC_Drivers.md for details. The default is True. run_current: # The amount of current (in amps RMS) to configure the driver to use # during stepper movement. This parameter must be provided. #hold_current: # The amount of current (in amps RMS) to configure the driver to use # when the stepper is not moving. Setting a hold_current is not # recommended (see TMC_Drivers.md for details). The default is to # not reduce the current. #sense_resistor: 0.110 # The resistance (in ohms) of the motor sense resistor. The default # is 0.110 ohms. #stealthchop_threshold: 0 # The velocity (in mm/s) to set the \"stealthChop\" threshold to. When # set, \"stealthChop\" mode will be enabled if the stepper motor # velocity is below this value. The default is 0, which disables # \"stealthChop\" mode. #driver_MSLUT0: 2863314260 #driver_MSLUT1: 1251300522 #driver_MSLUT2: 608774441 #driver_MSLUT3: 269500962 #driver_MSLUT4: 4227858431 #driver_MSLUT5: 3048961917 #driver_MSLUT6: 1227445590 #driver_MSLUT7: 4211234 #driver_W0: 2 #driver_W1: 1 #driver_W2: 1 #driver_W3: 1 #driver_X1: 128 #driver_X2: 255 #driver_X3: 255 #driver_START_SIN: 0 #driver_START_SIN90: 247 # These fields control the Microstep Table registers directly. The optimal # wave table is specific to each motor and might vary with current. An # optimal configuration will have minimal print artifacts caused by # non-linear stepper movement. The values specified above are the default # values used by the driver. The value must be specified as a decimal integer # (hex form is not supported). In order to compute the wave table fields, # see the tmc2130 \"Calculation Sheet\" from the Trinamic website. #driver_IHOLDDELAY: 8 #driver_TPOWERDOWN: 0 #driver_TBL: 1 #driver_TOFF: 4 #driver_HEND: 7 #driver_HSTRT: 0 #driver_PWM_AUTOSCALE: True #driver_PWM_FREQ: 1 #driver_PWM_GRAD: 4 #driver_PWM_AMPL: 128 #driver_SGT: 0 # Set the given register during the configuration of the TMC2130 # chip. This may be used to set custom motor parameters. The # defaults for each parameter are next to the parameter name in the # above list. #diag0_pin: #diag1_pin: # The micro-controller pin attached to one of the DIAG lines of the # TMC2130 chip. Only a single diag pin should be specified. The pin # is \"active low\" and is thus normally prefaced with \"^!\". Setting # this creates a \"tmc2130_stepper_x:virtual_endstop\" virtual pin # which may be used as the stepper's endstop_pin. Doing this enables # \"sensorless homing\". (Be sure to also set driver_SGT to an # appropriate sensitivity value.) The default is to not enable # sensorless homing. [tmc2208] \u00b6 Configurare un driver per motore passo-passo TMC2208 (o TMC2224) tramite UART a filo singolo. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso \"tmc2208\" seguito dal nome della sezione di configurazione dello stepper corrispondente (ad esempio, \"[tmc2208 stepper_x]\"). [tmc2208 stepper_x] uart_pin: # The pin connected to the TMC2208 PDN_UART line. This parameter # must be provided. #tx_pin: # If using separate receive and transmit lines to communicate with # the driver then set uart_pin to the receive pin and tx_pin to the # transmit pin. The default is to use uart_pin for both reading and # writing. #select_pins: # A comma separated list of pins to set prior to accessing the # tmc2208 UART. This may be useful for configuring an analog mux for # UART communication. The default is to not configure any pins. #interpolate: True # If true, enable step interpolation (the driver will internally # step at a rate of 256 micro-steps). This interpolation does # introduce a small systemic positional deviation - see # TMC_Drivers.md for details. The default is True. run_current: # The amount of current (in amps RMS) to configure the driver to use # during stepper movement. This parameter must be provided. #hold_current: # The amount of current (in amps RMS) to configure the driver to use # when the stepper is not moving. Setting a hold_current is not # recommended (see TMC_Drivers.md for details). The default is to # not reduce the current. #sense_resistor: 0.110 # The resistance (in ohms) of the motor sense resistor. The default # is 0.110 ohms. #stealthchop_threshold: 0 # The velocity (in mm/s) to set the \"stealthChop\" threshold to. When # set, \"stealthChop\" mode will be enabled if the stepper motor # velocity is below this value. The default is 0, which disables # \"stealthChop\" mode. #driver_MULTISTEP_FILT: True #driver_IHOLDDELAY: 8 #driver_TPOWERDOWN: 20 #driver_TBL: 2 #driver_TOFF: 3 #driver_HEND: 0 #driver_HSTRT: 5 #driver_PWM_AUTOGRAD: True #driver_PWM_AUTOSCALE: True #driver_PWM_LIM: 12 #driver_PWM_REG: 8 #driver_PWM_FREQ: 1 #driver_PWM_GRAD: 14 #driver_PWM_OFS: 36 # Set the given register during the configuration of the TMC2208 # chip. This may be used to set custom motor parameters. The # defaults for each parameter are next to the parameter name in the # above list. [tmc2209] \u00b6 Configurare un driver per motore passo-passo TMC2209 tramite UART a filo singolo. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso \"tmc2209\" seguito dal nome della sezione di configurazione dello stepper corrispondente (ad esempio, \"[tmc2209 stepper_x]\"). [tmc2209 stepper_x] uart_pin: #tx_pin: #select_pins: #interpolate: True run_current: #hold_current: #sense_resistor: 0.110 #stealthchop_threshold: 0 # See the \"tmc2208\" section for the definition of these parameters. #uart_address: # The address of the TMC2209 chip for UART messages (an integer # between 0 and 3). This is typically used when multiple TMC2209 # chips are connected to the same UART pin. The default is zero. #driver_MULTISTEP_FILT: True #driver_IHOLDDELAY: 8 #driver_TPOWERDOWN: 20 #driver_TBL: 2 #driver_TOFF: 3 #driver_HEND: 0 #driver_HSTRT: 5 #driver_PWM_AUTOGRAD: True #driver_PWM_AUTOSCALE: True #driver_PWM_LIM: 12 #driver_PWM_REG: 8 #driver_PWM_FREQ: 1 #driver_PWM_GRAD: 14 #driver_PWM_OFS: 36 #driver_SGTHRS: 0 # Set the given register during the configuration of the TMC2209 # chip. This may be used to set custom motor parameters. The # defaults for each parameter are next to the parameter name in the # above list. #diag_pin: # The micro-controller pin attached to the DIAG line of the TMC2209 # chip. The pin is normally prefaced with \"^\" to enable a pullup. # Setting this creates a \"tmc2209_stepper_x:virtual_endstop\" virtual # pin which may be used as the stepper's endstop_pin. Doing this # enables \"sensorless homing\". (Be sure to also set driver_SGTHRS to # an appropriate sensitivity value.) The default is to not enable # sensorless homing. [tmc2660] \u00b6 Configurare un driver per motore passo-passo TMC2660 tramite bus SPI. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso tmc2660 seguito dal nome della sezione di configurazione dello stepper corrispondente (ad esempio, \"[tmc2660 stepper_x]\"). [tmc2660 stepper_x] cs_pin: # Il pin corrispondente al pin di selezione del chip TMC2660. Questo pin # verr\u00e0 impostato su basso all'inizio dei messaggi SPI e impostato su # alto al termine del trasferimento del messaggio. Questo parametro # deve essere fornito. #spi_speed: 4000000 # Frequenza bus SPI utilizzata per comunicare con il driver # passo-passo TMC2660. Il valore predefinito \u00e8 4000000. #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # Vedere la sezione \"impostazioni comuni SPI\" per una descrizione # dei parametri di cui sopra. #interpolate: True # Se true, abilita l'interpolazione del passo (il driver eseguir\u00e0 un passo # interno a una velocit\u00e0 di 256 micropassi). Funziona solo se microsteps # \u00e8 impostato su 16. L'interpolazione introduce una piccola deviazione # posizionale sistemica - vedere TMC_Drivers.md per i dettagli. # L'impostazione predefinita \u00e8 Vero. run_current: # La quantit\u00e0 di corrente (in ampere RMS) utilizzata dal driver durante # il movimento passo-passo. Questo parametro deve essere fornito. #sense_resistor: # La resistenza (in ohm) del resistore di rilevamento del motore. # Questo parametro deve essere fornito. #idle_current_percent: 100 # La percentuale di run_current a cui il driver stepper sar\u00e0 ridotto allo # scadere del timeout di inattivit\u00e0 (\u00e8 necessario impostare il timeout # utilizzando una sezione di configurazione [idle_timeout]). La corrente # verr\u00e0 nuovamente aumentata una volta che lo stepper dovr\u00e0 muoversi # di nuovo. Assicurati di impostarlo su un valore sufficientemente alto in # modo che gli stepper non perdano la loro posizione. C'\u00e8 anche un piccolo # ritardo fino a quando la corrente non viene nuovamente aumentata, # quindi tienine conto quando comandi mosse veloci mentre lo stepper \u00e8 # al minimo. Il valore predefinito \u00e8 100 (nessuna riduzione). #driver_TBL: 2 #driver_RNDTF: 0 #driver_HDEC: 0 #driver_CHM: 0 #driver_HEND: 3 #driver_HSTRT: 3 #driver_TOFF: 4 #driver_SEIMIN: 0 #driver_SEDN: 0 #driver_SEMAX: 0 #driver_SEUP: 0 #driver_SEMIN: 0 #driver_SFILT: 0 #driver_SGT: 0 #driver_SLPH: 0 #driver_SLPL: 0 #driver_DISS2G: 0 #driver_TS2G: 3 # Imposta il parametro indicato durante la configurazione del chip TMC2660. # Questo pu\u00f2 essere utilizzato per impostare parametri del driver personalizzati. # Le impostazioni predefinite per ogni parametro sono accanto al nome del # parametro nell'elenco sopra. Vedere la scheda tecnica del TMC2660 su cosa # fa ogni parametro e quali sono le restrizioni sulle combinazioni di parametri. # Prestare particolare attenzione al registro CHOPCONF, dove l'impostazione # di CHM su zero o uno comporter\u00e0 modifiche al layout (il primo bit di HDEC) # viene interpretato come MSB di HSTRT in questo caso). [tmc2240] \u00b6 Configure a TMC2240 stepper motor driver via SPI bus or UART. To use this feature, define a config section with a \"tmc2240\" prefix followed by the name of the corresponding stepper config section (for example, \"[tmc2240 stepper_x]\"). [tmc2240 stepper_x] cs_pin: # The pin corresponding to the TMC2240 chip select line. This pin # will be set to low at the start of SPI messages and raised to high # after the message completes. This parameter must be provided. #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #uart_pin: # The pin connected to the TMC2240 DIAG1/SW line. If this parameter # is provided UART communication is used rather then SPI. #chain_position: #chain_length: # These parameters configure an SPI daisy chain. The two parameters # define the stepper position in the chain and the total chain length. # Position 1 corresponds to the stepper that connects to the MOSI signal. # The default is to not use an SPI daisy chain. #interpolate: True # If true, enable step interpolation (the driver will internally # step at a rate of 256 micro-steps). The default is True. run_current: # The amount of current (in amps RMS) to configure the driver to use # during stepper movement. This parameter must be provided. #hold_current: # The amount of current (in amps RMS) to configure the driver to use # when the stepper is not moving. Setting a hold_current is not # recommended (see TMC_Drivers.md for details). The default is to # not reduce the current. #rref: 12000 # The resistance (in ohms) of the resistor between IREF and GND. The # default is 12000. #stealthchop_threshold: 0 # The velocity (in mm/s) to set the \"stealthChop\" threshold to. When # set, \"stealthChop\" mode will be enabled if the stepper motor # velocity is below this value. The default is 0, which disables # \"stealthChop\" mode. #driver_MSLUT0: 2863314260 #driver_MSLUT1: 1251300522 #driver_MSLUT2: 608774441 #driver_MSLUT3: 269500962 #driver_MSLUT4: 4227858431 #driver_MSLUT5: 3048961917 #driver_MSLUT6: 1227445590 #driver_MSLUT7: 4211234 #driver_W0: 2 #driver_W1: 1 #driver_W2: 1 #driver_W3: 1 #driver_X1: 128 #driver_X2: 255 #driver_X3: 255 #driver_START_SIN: 0 #driver_START_SIN90: 247 #driver_OFFSET_SIN90: 0 # These fields control the Microstep Table registers directly. The optimal # wave table is specific to each motor and might vary with current. An # optimal configuration will have minimal print artifacts caused by # non-linear stepper movement. The values specified above are the default # values used by the driver. The value must be specified as a decimal integer # (hex form is not supported). In order to compute the wave table fields, # see the tmc2130 \"Calculation Sheet\" from the Trinamic website. # Additionally, this driver also has the OFFSET_SIN90 field which can be used # to tune a motor with unbalanced coils. See the `Sine Wave Lookup Table` # section in the datasheet for information about this field and how to tune # it. #driver_MULTISTEP_FILT: True #driver_IHOLDDELAY: 6 #driver_IRUNDELAY: 4 #driver_TPOWERDOWN: 10 #driver_TBL: 2 #driver_TOFF: 3 #driver_HEND: 2 #driver_HSTRT: 5 #driver_FD3: 0 #driver_TPFD: 4 #driver_CHM: 0 #driver_VHIGHFS: 0 #driver_VHIGHCHM: 0 #driver_DISS2G: 0 #driver_DISS2VS: 0 #driver_PWM_AUTOSCALE: True #driver_PWM_AUTOGRAD: True #driver_PWM_FREQ: 0 #driver_FREEWHEEL: 0 #driver_PWM_GRAD: 0 #driver_PWM_OFS: 29 #driver_PWM_REG: 4 #driver_PWM_LIM: 12 #driver_SGT: 0 #driver_SEMIN: 0 #driver_SEUP: 0 #driver_SEMAX: 0 #driver_SEDN: 0 #driver_SEIMIN: 0 #driver_SFILT: 0 #driver_SG4_ANGLE_OFFSET: 1 # Set the given register during the configuration of the TMC2240 # chip. This may be used to set custom motor parameters. The # defaults for each parameter are next to the parameter name in the # above list. #diag0_pin: #diag1_pin: # The micro-controller pin attached to one of the DIAG lines of the # TMC2240 chip. Only a single diag pin should be specified. The pin # is \"active low\" and is thus normally prefaced with \"^!\". Setting # this creates a \"tmc2240_stepper_x:virtual_endstop\" virtual pin # which may be used as the stepper's endstop_pin. Doing this enables # \"sensorless homing\". (Be sure to also set driver_SGT to an # appropriate sensitivity value.) The default is to not enable # sensorless homing. [tmc5160] \u00b6 Configurare un driver per motore passo-passo TMC5160 tramite bus SPI. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso \"tmc5160\" seguito dal nome della sezione di configurazione dello stepper corrispondente (ad esempio, \"[tmc5160 stepper_x]\"). [tmc5160 stepper_x] cs_pin: # The pin corresponding to the TMC5160 chip select line. This pin # will be set to low at the start of SPI messages and raised to high # after the message completes. This parameter must be provided. #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #chain_position: #chain_length: # These parameters configure an SPI daisy chain. The two parameters # define the stepper position in the chain and the total chain length. # Position 1 corresponds to the stepper that connects to the MOSI signal. # The default is to not use an SPI daisy chain. #interpolate: True # If true, enable step interpolation (the driver will internally # step at a rate of 256 micro-steps). The default is True. run_current: # The amount of current (in amps RMS) to configure the driver to use # during stepper movement. This parameter must be provided. #hold_current: # The amount of current (in amps RMS) to configure the driver to use # when the stepper is not moving. Setting a hold_current is not # recommended (see TMC_Drivers.md for details). The default is to # not reduce the current. #sense_resistor: 0.075 # The resistance (in ohms) of the motor sense resistor. The default # is 0.075 ohms. #stealthchop_threshold: 0 # The velocity (in mm/s) to set the \"stealthChop\" threshold to. When # set, \"stealthChop\" mode will be enabled if the stepper motor # velocity is below this value. The default is 0, which disables # \"stealthChop\" mode. #driver_MSLUT0: 2863314260 #driver_MSLUT1: 1251300522 #driver_MSLUT2: 608774441 #driver_MSLUT3: 269500962 #driver_MSLUT4: 4227858431 #driver_MSLUT5: 3048961917 #driver_MSLUT6: 1227445590 #driver_MSLUT7: 4211234 #driver_W0: 2 #driver_W1: 1 #driver_W2: 1 #driver_W3: 1 #driver_X1: 128 #driver_X2: 255 #driver_X3: 255 #driver_START_SIN: 0 #driver_START_SIN90: 247 # These fields control the Microstep Table registers directly. The optimal # wave table is specific to each motor and might vary with current. An # optimal configuration will have minimal print artifacts caused by # non-linear stepper movement. The values specified above are the default # values used by the driver. The value must be specified as a decimal integer # (hex form is not supported). In order to compute the wave table fields, # see the tmc2130 \"Calculation Sheet\" from the Trinamic website. #driver_MULTISTEP_FILT: True #driver_IHOLDDELAY: 6 #driver_TPOWERDOWN: 10 #driver_TBL: 2 #driver_TOFF: 3 #driver_HEND: 2 #driver_HSTRT: 5 #driver_FD3: 0 #driver_TPFD: 4 #driver_CHM: 0 #driver_VHIGHFS: 0 #driver_VHIGHCHM: 0 #driver_DISS2G: 0 #driver_DISS2VS: 0 #driver_PWM_AUTOSCALE: True #driver_PWM_AUTOGRAD: True #driver_PWM_FREQ: 0 #driver_FREEWHEEL: 0 #driver_PWM_GRAD: 0 #driver_PWM_OFS: 30 #driver_PWM_REG: 4 #driver_PWM_LIM: 12 #driver_SGT: 0 #driver_SEMIN: 0 #driver_SEUP: 0 #driver_SEMAX: 0 #driver_SEDN: 0 #driver_SEIMIN: 0 #driver_SFILT: 0 #driver_DRVSTRENGTH: 0 #driver_BBMCLKS: 4 #driver_BBMTIME: 0 #driver_FILT_ISENSE: 0 # Set the given register during the configuration of the TMC5160 # chip. This may be used to set custom motor parameters. The # defaults for each parameter are next to the parameter name in the # above list. #diag0_pin: #diag1_pin: # The micro-controller pin attached to one of the DIAG lines of the # TMC5160 chip. Only a single diag pin should be specified. The pin # is \"active low\" and is thus normally prefaced with \"^!\". Setting # this creates a \"tmc5160_stepper_x:virtual_endstop\" virtual pin # which may be used as the stepper's endstop_pin. Doing this enables # \"sensorless homing\". (Be sure to also set driver_SGT to an # appropriate sensitivity value.) The default is to not enable # sensorless homing. Configurazione della corrente del motore passo-passo a run-time \u00b6 [ad5206] \u00b6 Digipot AD5206 configurati staticamente collegati tramite bus SPI (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"ad5206\"). [ad5206 my_digipot] enable_pin: # The pin corresponding to the AD5206 chip select line. This pin # will be set to low at the start of SPI messages and raised to high # after the message completes. This parameter must be provided. #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #channel_1: #channel_2: #channel_3: #channel_4: #channel_5: #channel_6: # The value to statically set the given AD5206 channel to. This is # typically set to a number between 0.0 and 1.0 with 1.0 being the # highest resistance and 0.0 being the lowest resistance. However, # the range may be changed with the 'scale' parameter (see below). # If a channel is not specified then it is left unconfigured. #scale: # This parameter can be used to alter how the 'channel_x' parameters # are interpreted. If provided, then the 'channel_x' parameters # should be between 0.0 and 'scale'. This may be useful when the # AD5206 is used to set stepper voltage references. The 'scale' can # be set to the equivalent stepper amperage if the AD5206 were at # its highest resistance, and then the 'channel_x' parameters can be # specified using the desired amperage value for the stepper. The # default is to not scale the 'channel_x' parameters. [mcp4451] \u00b6 Digipot MCP4451 configurato staticamente collegato tramite bus I2C (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"mcp4451\"). [mcp4451 my_digipot] i2c_address: # The i2c address that the chip is using on the i2c bus. This # parameter must be provided. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #wiper_0: #wiper_1: #wiper_2: #wiper_3: # The value to statically set the given MCP4451 \"wiper\" to. This is # typically set to a number between 0.0 and 1.0 with 1.0 being the # highest resistance and 0.0 being the lowest resistance. However, # the range may be changed with the 'scale' parameter (see below). # If a wiper is not specified then it is left unconfigured. #scale: # This parameter can be used to alter how the 'wiper_x' parameters # are interpreted. If provided, then the 'wiper_x' parameters should # be between 0.0 and 'scale'. This may be useful when the MCP4451 is # used to set stepper voltage references. The 'scale' can be set to # the equivalent stepper amperage if the MCP4451 were at its highest # resistance, and then the 'wiper_x' parameters can be specified # using the desired amperage value for the stepper. The default is # to not scale the 'wiper_x' parameters. [mcp4728] \u00b6 Convertitore digitale-analogico MCP4728 in configurazione statica collegato tramite bus I2C (\u00e8 possibile definire un numero qualsiasi di sezioni con prefisso \"mcp4728\"). [mcp4728 my_dac] #i2c_address: 96 # The i2c address that the chip is using on the i2c bus. The default # is 96. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #channel_a: #channel_b: #channel_c: #channel_d: # The value to statically set the given MCP4728 channel to. This is # typically set to a number between 0.0 and 1.0 with 1.0 being the # highest voltage (2.048V) and 0.0 being the lowest voltage. # However, the range may be changed with the 'scale' parameter (see # below). If a channel is not specified then it is left # unconfigured. #scale: # This parameter can be used to alter how the 'channel_x' parameters # are interpreted. If provided, then the 'channel_x' parameters # should be between 0.0 and 'scale'. This may be useful when the # MCP4728 is used to set stepper voltage references. The 'scale' can # be set to the equivalent stepper amperage if the MCP4728 were at # its highest voltage (2.048V), and then the 'channel_x' parameters # can be specified using the desired amperage value for the # stepper. The default is to not scale the 'channel_x' parameters. [mcp4018] \u00b6 Digipot MCP4018 configurato staticamente collegato tramite due pin gpio \"bit banging\" (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"mcp4018\"). [mcp4018 my_digipot] scl_pin: # Il pin \"clock\" SCL. Questo parametro deve essere fornito. sda_pin: # Il pin \"dati\" SDA. Questo parametro deve essere fornito. wiper: # Il valore su cui impostare staticamente il \"Wiper\" MCP4018 # specificato. Questo \u00e8 in genere impostato su un numero compreso # tra 0,0 e 1,0 con 1,0 come resistenza pi\u00f9 alta e 0,0 come resistenza # pi\u00f9 bassa. Tuttavia, l'intervallo pu\u00f2 essere modificato con il # parametro 'scale' (vedi sotto). Questo parametro deve essere fornito. #scale: # Questo parametro pu\u00f2 essere utilizzato per modificare il modo in # cui viene interpretato il parametro 'wiper'. Se fornito, il parametro # 'wiper' dovrebbe essere compreso tra 0.0 e 'scale'. Questo pu\u00f2 essere # utile quando l'MCP4018 viene utilizzato per impostare i riferimenti di # tensione stepper. La \"scala\" pu\u00f2 essere impostata sull'amperaggio # stepper equivalente se l'MCP4018 \u00e8 alla sua massima resistenza, # quindi \u00e8 possibile specificare il parametro \"wiper\" utilizzando il # valore di amperaggio desiderato per lo stepper. L'impostazione # predefinita \u00e8 di non ridimensionare il parametro 'wiper'. Supporto display \u00b6 [display] \u00b6 Supporto per un display collegato al microcontrollore. [display] lcd_type: # The type of LCD chip in use. This may be \"hd44780\", \"hd44780_spi\", # \"st7920\", \"emulated_st7920\", \"uc1701\", \"ssd1306\", or \"sh1106\". # See the display sections below for information on each type and # additional parameters they provide. This parameter must be # provided. #display_group: # The name of the display_data group to show on the display. This # controls the content of the screen (see the \"display_data\" section # for more information). The default is _default_20x4 for hd44780 # displays and _default_16x4 for other displays. #menu_timeout: # Timeout for menu. Being inactive this amount of seconds will # trigger menu exit or return to root menu when having autorun # enabled. The default is 0 seconds (disabled) #menu_root: # Name of the main menu section to show when clicking the encoder # on the home screen. The defaults is __main, and this shows the # the default menus as defined in klippy/extras/display/menu.cfg #menu_reverse_navigation: # When enabled it will reverse up and down directions for list # navigation. The default is False. This parameter is optional. #encoder_pins: # The pins connected to encoder. 2 pins must be provided when using # encoder. This parameter must be provided when using menu. #encoder_steps_per_detent: # How many steps the encoder emits per detent (\"click\"). If the # encoder takes two detents to move between entries or moves two # entries from one detent, try changing this. Allowed values are 2 # (half-stepping) or 4 (full-stepping). The default is 4. #click_pin: # The pin connected to 'enter' button or encoder 'click'. This # parameter must be provided when using menu. The presence of an # 'analog_range_click_pin' config parameter turns this parameter # from digital to analog. #back_pin: # The pin connected to 'back' button. This parameter is optional, # menu can be used without it. The presence of an # 'analog_range_back_pin' config parameter turns this parameter from # digital to analog. #up_pin: # The pin connected to 'up' button. This parameter must be provided # when using menu without encoder. The presence of an # 'analog_range_up_pin' config parameter turns this parameter from # digital to analog. #down_pin: # The pin connected to 'down' button. This parameter must be # provided when using menu without encoder. The presence of an # 'analog_range_down_pin' config parameter turns this parameter from # digital to analog. #kill_pin: # The pin connected to 'kill' button. This button will call # emergency stop. The presence of an 'analog_range_kill_pin' config # parameter turns this parameter from digital to analog. #analog_pullup_resistor: 4700 # The resistance (in ohms) of the pullup attached to the analog # button. The default is 4700 ohms. #analog_range_click_pin: # The resistance range for a 'enter' button. Range minimum and # maximum comma-separated values must be provided when using analog # button. #analog_range_back_pin: # The resistance range for a 'back' button. Range minimum and # maximum comma-separated values must be provided when using analog # button. #analog_range_up_pin: # The resistance range for a 'up' button. Range minimum and maximum # comma-separated values must be provided when using analog button. #analog_range_down_pin: # The resistance range for a 'down' button. Range minimum and # maximum comma-separated values must be provided when using analog # button. #analog_range_kill_pin: # The resistance range for a 'kill' button. Range minimum and # maximum comma-separated values must be provided when using analog # button. display hd44780 \u00b6 Informazioni sulla configurazione dei display hd44780 (utilizzati nei display di tipo \"RepRapDiscount 2004 Smart Controller\"). [display] lcd_type: hd44780 # Set to \"hd44780\" for hd44780 displays. rs_pin: e_pin: d4_pin: d5_pin: d6_pin: d7_pin: # The pins connected to an hd44780 type lcd. These parameters must # be provided. #hd44780_protocol_init: True # Perform 8-bit/4-bit protocol initialization on an hd44780 display. # This is necessary on real hd44780 devices. However, one may need # to disable this on some \"clone\" devices. The default is True. #line_length: # Set the number of characters per line for an hd44780 type lcd. # Possible values are 20 (default) and 16. The number of lines is # fixed to 4. ... display hd44780_spi \u00b6 Informazioni sulla configurazione di un display hd44780_spi - un display 20x04 controllato tramite uno \"shift register\" hardware (che viene utilizzato nelle stampanti basate su mightyboard). [display] lcd_type: hd44780_spi # Set to \"hd44780_spi\" for hd44780_spi displays. latch_pin: spi_software_sclk_pin: spi_software_mosi_pin: spi_software_miso_pin: # The pins connected to the shift register controlling the display. # The spi_software_miso_pin needs to be set to an unused pin of the # printer mainboard as the shift register does not have a MISO pin, # but the software spi implementation requires this pin to be # configured. #hd44780_protocol_init: True # Perform 8-bit/4-bit protocol initialization on an hd44780 display. # This is necessary on real hd44780 devices. However, one may need # to disable this on some \"clone\" devices. The default is True. #line_length: # Set the number of characters per line for an hd44780 type lcd. # Possible values are 20 (default) and 16. The number of lines is # fixed to 4. ... display st7920 \u00b6 Informazioni sulla configurazione dei display st7920 (utilizzati nei display di tipo \"RepRapDiscount 12864 Full Graphic Smart Controller\"). [display] lcd_type: st7920 # Set to \"st7920\" for st7920 displays. cs_pin: sclk_pin: sid_pin: # The pins connected to an st7920 type lcd. These parameters must be # provided. ... display emulazione emulated_st7920 \u00b6 Informazioni sulla configurazione di un display st7920 emulato, presenti in alcuni \"dispositivi touchscreen da 2,4 pollici\" e simili. [display] lcd_type: emulated_st7920 # Set to \"emulated_st7920\" for emulated_st7920 displays. en_pin: spi_software_sclk_pin: spi_software_mosi_pin: spi_software_miso_pin: # The pins connected to an emulated_st7920 type lcd. The en_pin # corresponds to the cs_pin of the st7920 type lcd, # spi_software_sclk_pin corresponds to sclk_pin and # spi_software_mosi_pin corresponds to sid_pin. The # spi_software_miso_pin needs to be set to an unused pin of the # printer mainboard as the st7920 as no MISO pin but the software # spi implementation requires this pin to be configured. ... display uc1701 \u00b6 Informazioni sulla configurazione dei display uc1701 (utilizzati nei display di tipo \"MKS Mini 12864\"). [display] lcd_type: uc1701 # Set to \"uc1701\" for uc1701 displays. cs_pin: a0_pin: # The pins connected to a uc1701 type lcd. These parameters must be # provided. #rst_pin: # The pin connected to the \"rst\" pin on the lcd. If it is not # specified then the hardware must have a pull-up on the # corresponding lcd line. #contrast: # The contrast to set. The value may range from 0 to 63 and the # default is 40. ... display ssd1306 e sh1106 \u00b6 Informazioni sulla configurazione dei display ssd1306 e sh1106. [display] lcd_type: # Set to either \"ssd1306\" or \"sh1106\" for the given display type. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # Optional parameters available for displays connected via an i2c # bus. See the \"common I2C settings\" section for a description of # the above parameters. #cs_pin: #dc_pin: #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # The pins connected to the lcd when in \"4-wire\" spi mode. See the # \"common SPI settings\" section for a description of the parameters # that start with \"spi_\". The default is to use i2c mode for the # display. #reset_pin: # A reset pin may be specified on the display. If it is not # specified then the hardware must have a pull-up on the # corresponding lcd line. #contrast: # The contrast to set. The value may range from 0 to 256 and the # default is 239. #vcomh: 0 # Set the Vcomh value on the display. This value is associated with # a \"smearing\" effect on some OLED displays. The value may range # from 0 to 63. Default is 0. #invert: False # TRUE inverts the pixels on certain OLED displays. The default is # False. #x_offset: 0 # Set the horizontal offset value on SH1106 displays. The default is # 0. ... [display_data] \u00b6 Supporto per la visualizzazione di dati personalizzati su uno schermo LCD. \u00c8 possibile creare un numero qualsiasi di gruppi di visualizzazione e un numero qualsiasi di elementi di dati in quei gruppi. Il display mostrer\u00e0 tutti gli elementi di dati per un determinato gruppo se l'opzione display_group nella sezione [display] \u00e8 impostata sul nome del gruppo specificato. Viene creato automaticamente un default set of display groups . \u00c8 possibile sostituire o estendere questi elementi display_data sovrascrivendo i valori predefiniti nel file di configurazione principale printer.cfg . [display_data my_group_name my_data_name] position: # Comma separated row and column of the display position that should # be used to display the information. This parameter must be # provided. text: # The text to show at the given position. This field is evaluated # using command templates (see docs/Command_Templates.md). This # parameter must be provided. [display_template] \u00b6 Visualizza il testo dei dati \"macro\" (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso display_template). Per informazioni sul template, vedere il documento template di comandi . Questa funzione consente di ridurre le definizioni ripetitive nelle sezioni display_data. Si pu\u00f2 usare la funzione incorporata render() nelle sezioni display_data per valutare un template. Per esempio, se si dovesse definire [display_template my_template] allora si potrebbe usare { render('my_template') } in una sezione display_data. Questa funzione pu\u00f2 essere utilizzata anche per aggiornamenti LED continui utilizzando il comando SET_LED_TEMPLATE . [display_template my_template_name] #param_: # One may specify any number of options with a \"param_\" prefix. The # given name will be assigned the given value (parsed as a Python # literal) and will be available during macro expansion. If the # parameter is passed in the call to render() then that value will # be used during macro expansion. For example, a config with # \"param_speed = 75\" might have a caller with # \"render('my_template_name', param_speed=80)\". Parameter names may # not use upper case characters. text: # The text to return when the this template is rendered. This field # is evaluated using command templates (see # docs/Command_Templates.md). This parameter must be provided. [display_glyph] \u00b6 Visualizza un glifo personalizzato sui display che lo supportano. Al nome dato verranno assegnati i dati di visualizzazione dati che possono quindi essere referenziati nei modelli di visualizzazione con il loro nome circondato da due simboli \"tilde\" per esempio ~my_display_glyph~ Vedere sample-glyphs.cfg per alcuni esempi. [display_glyph my_display_glyph] #data: # The display data, stored as 16 lines consisting of 16 bits (1 per # pixel) where '.' is a blank pixel and '*' is an on pixel (e.g., # \"****************\" to display a solid horizontal line). # Alternatively, one can use '0' for a blank pixel and '1' for an on # pixel. Put each display line into a separate config line. The # glyph must consist of exactly 16 lines with 16 bits each. This # parameter is optional. #hd44780_data: # Glyph to use on 20x4 hd44780 displays. The glyph must consist of # exactly 8 lines with 5 bits each. This parameter is optional. #hd44780_slot: # The hd44780 hardware index (0..7) to store the glyph at. If # multiple distinct images use the same slot then make sure to only # use one of those images in any given screen. This parameter is # required if hd44780_data is specified. [display my_extra_display] \u00b6 Se in printer.cfg \u00e8 stata definita una sezione primaria [display] come mostrato sopra, \u00e8 possibile definire pi\u00f9 display ausiliari. Si noti che i display ausiliari attualmente non supportano la funzionalit\u00e0 del menu, quindi non supportano le opzioni del \"menu\" o la configurazione dei pulsanti. [display my_extra_display] # Vedere la sezione \"display\" per i parametri disponibili. [menu] \u00b6 Menu display lcd personalizzabili. Viene creato automaticamente un default set of menus . \u00c8 possibile sostituire o estendere il menu sovrascrivendo le impostazioni predefinite nel file di configurazione principale printer.cfg . Consulta il command template document per informazioni sugli attributi di menu disponibili durante il rendering del modello. # Common parameters available for all menu config sections. #[menu __some_list __some_name] #type: disabled # Permanently disabled menu element, only required attribute is 'type'. # Allows you to easily disable/hide existing menu items. #[menu some_name] #type: # One of command, input, list, text: # command - basic menu element with various script triggers # input - same like 'command' but has value changing capabilities. # Press will start/stop edit mode. # list - it allows for menu items to be grouped together in a # scrollable list. Add to the list by creating menu # configurations using \"some_list\" as a prefix - for # example: [menu some_list some_item_in_the_list] # vsdlist - same as 'list' but will append files from virtual sdcard # (will be removed in the future) #name: # Name of menu item - evaluated as a template. #enable: # Template that evaluates to True or False. #index: # Position where an item needs to be inserted in list. By default # the item is added at the end. #[menu some_list] #type: list #name: #enable: # See above for a description of these parameters. #[menu some_list some_command] #type: command #name: #enable: # See above for a description of these parameters. #gcode: # Script to run on button click or long click. Evaluated as a # template. #[menu some_list some_input] #type: input #name: #enable: # See above for a description of these parameters. #input: # Initial value to use when editing - evaluated as a template. # Result must be float. #input_min: # Minimum value of range - evaluated as a template. Default -99999. #input_max: # Maximum value of range - evaluated as a template. Default 99999. #input_step: # Editing step - Must be a positive integer or float value. It has # internal fast rate step. When \"(input_max - input_min) / # input_step > 100\" then fast rate step is 10 * input_step else fast # rate step is same input_step. #realtime: # This attribute accepts static boolean value. When enabled then # gcode script is run after each value change. The default is False. #gcode: # Script to run on button click, long click or value change. # Evaluated as a template. The button click will trigger the edit # mode start or end. Sensori di filamento \u00b6 [filament_switch_sensor] \u00b6 Sensore del filamento a interruttore. Supporto per l'inserimento del filamento e il rilevamento dell'esaurimento tramite un sensore interruttore, come un interruttore di fine corsa. Per ulteriori informazioni, vedere command reference . [filament_switch_sensor my_sensor] #pause_on_runout: True # Se impostato su True, verr\u00e0 eseguita una PAUSA immediatamente # dopo il rilevamento di un'eccentricit\u00e0. Si noti che se pause_on_runout # \u00e8 False e runout_gcode viene omesso, il rilevamento dell'eccentricit\u00e0 # \u00e8 disabilitato. L'impostazione predefinita \u00e8 Vero. #runout_gcode: # Un elenco di comandi G-Code da eseguire dopo il rilevamento di # un'esaurimento del filamento. Vedi docs/Command_Templates.md # per il formato G-Code. Se pause_on_runout \u00e8 impostato su True, # questo codice G verr\u00e0 eseguito al termine della PAUSA. # L'impostazione predefinita \u00e8 di non eseguire alcun comando G-Code. #insert_gcode: # Un elenco di comandi G-Code da eseguire dopo il rilevamento # dell'inserimento di filamento. Vedi docs/Command_Templates.md # per il formato G-Code. L'impostazione predefinita non prevede # l'esecuzione di alcun comando G-Code, che disabilita il rilevamento # dell'inserimento. #event_delay: 3.0 # Il tempo minimo in secondi per ritardare tra gli eventi. Gli eventi # attivati durante questo periodo di tempo verranno ignorati # silenziosamente. L'impostazione predefinita \u00e8 3 secondi. #pause_delay: 0.5 # Il tempo di ritardo, in secondi, tra l'invio del comando pause e # l'esecuzione di runout_gcode. Potrebbe essere utile aumentare # questo ritardo se OctoPrint mostra uno strano comportamento # di pausa. Il valore predefinito \u00e8 0,5 secondi. #switch_pin: # Il pin su cui \u00e8 collegato l'interruttore. # Questo parametro deve essere fornito. [filament_motion_sensor] \u00b6 Sensore di movimento del filamento. Supporto per l'inserimento del filamento e il rilevamento dell'esaurimento mediante un codificatore che commuta il pin di uscita durante il movimento del filamento attraverso il sensore. Per ulteriori informazioni, vedere command reference . [filament_motion_sensor my_sensor] detection_length: 7.0 # La lunghezza minima di filamento tirato attraverso il sensore # per attivare un cambio di stato su switch_pin # Il default \u00e8 7 mm. extruder: # Nome della sezione extruder section con cui questo sensore \u00e8 associato. # Questo parametro deve essere fornito. switch_pin: #pause_on_runout: #runout_gcode: #insert_gcode: #event_delay: #pause_delay: # Vedere la sezione \"filament_switch_sensor\" per la descrizione dei # parametri riportati sopra. [tsl1401cl_filament_width_sensor] \u00b6 Sensore di larghezza del filamento basato su TSLl401CL. Consulta la guida per ulteriori informazioni. sl1401cl_filament_width_sensor] #pin: #diametro nominale del filamento predefinito: 1,75 (mm) # Differenza massima consentita del diametro del filamento in mm. #max_difference: 0.2 # La distanza dal sensore alla camera di fusione in mm. #measurement_delay: 100 [hall_filament_width_sensor] \u00b6 Sensore di larghezza del filamento ad effetto Hall (vedere Sensore di larghezza del filamento Hall ). [hall_filament_width_sensor] adc1: adc2: # Pin di ingresso analogico collegati al sensore. # Questi parametri devono essere forniti. #cal_dia1: 1.50 #cal_dia2: 2.00 # I valori di calibrazione (in mm) per i sensori. Il valore predefinito # \u00e8 1.50 per cal_dia1 e 2.00 per cal_dia2. #raw_dia1: 9500 #raw_dia2: 10500 # I valori di calibrazione grezzi per i sensori. Il valore predefinito \u00e8 # 9500 per raw_dia1 e 10500 per raw_dia2. #default_nominal_filament_diameter: 1.75 # Il diametro nominale del filamento. # Questo parametro deve essere fornito. #max_difference: 0.200 # Differenza massima consentita del diametro del filamento in # millimetri (mm). Se la differenza tra il diametro nominale del # filamento e l'uscita del sensore \u00e8 maggiore di +- max_difference, # il moltiplicatore di estrusione viene riportato a %100. # Il valore predefinito \u00e8 0,200. #measurement_delay: 70 # La distanza dal sensore alla camera di fusione/hot-end in # millimetri (mm). Il filamento tra il sensore e l'hot-end verr\u00e0 # trattato come default_nominal_filament_diameter. Il modulo # host funziona con la logica FIFO. Mantiene ogni valore e posizione # del sensore in un array e li riporta nella posizione corretta. # Questo parametro deve essere fornito. #enable: False # Sensore abilitato o disabilitato dopo l'accensione. L'impostazione predefinita \u00e8 disabilitare. #measurement_interval: 10 # La distanza approssimativa (in mm) tra le letture del sensore. # Il valore predefinito \u00e8 10 mm. #logging: False # Il log esterno al terminale e klipper.log pu\u00f2 essere # attivato|off tramite comando. #min_diameter: 1.0 # Diametro minimo per trigger filament_switch_sensor virtuale. #use_current_dia_while_delay: False # Utilizzare il diametro attuale invece del diametro nominale # mentre il ritardo di misurazione non \u00e8 trascorso. #pause_on_runout: #runout_gcode: #insert_gcode: #event_delay: #pause_delay: # Vedere la sezione \"filament_switch_sensor\" per una # descrizione dei parametri di cui sopra. Supporto hardware per specifica scheda \u00b6 [sx1509] \u00b6 Configurare un'espansione SX1509 da I2C a GPIO. A causa del ritardo dovuto alla comunicazione I2C, NON utilizzare i pin SX1509 come abilitazione stepper, pin step o dir o qualsiasi altro pin che richieda un bit banging veloce. Sono utilizzati al meglio come uscite digitali statiche o controllate da gcode o pin hardware-pwm per es. fan. Si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"sx1509\". Ogni espansione fornisce un set di 16 pin (da sx1509_my_sx1509:PIN_0 a sx1509_my_sx1509:PIN_15) che possono essere utilizzati nella configurazione della stampante. Per un esempio, vedere il file generic-duet2-duex.cfg . [sx1509 my_sx1509] i2c_address: # I2C address used by this expander. Depending on the hardware # jumpers this is one out of the following addresses: 62 63 112 # 113. This parameter must be provided. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. [samd_sercom] \u00b6 Configurazione SAMD SERCOM per specificare quali pin utilizzare su un determinato SERCOM. Si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"samd_sercom\". Ogni SERCOM deve essere configurato prima di utilizzarlo come periferica SPI o I2C. Posiziona questa sezione di configurazione sopra qualsiasi altra sezione che fa uso di bus SPI o I2C. [samd_sercom my_sercom] sercom: # Il nome del bus Sercom da configurare nel microcontrollore. I nomi # disponibili sono \"sercom0\", \"sercom1\", ecc. # Questo parametro deve essere fornito. tx_pin: # Pin MOSI per la comunicazione SPI o pin SDA (dati) per la # comunicazione I2C. Il pin deve avere una configurazione pinmux # valida per la specifica periferica SERCOM. # Questo parametro deve essere fornito. #rx_pin: # Pin MISO per la comunicazione SPI. Questo pin non viene utilizzato # per la comunicazione I2C (I2C utilizza tx_pin sia per l'invio che per la # ricezione). Il pin deve avere una configurazione pinmux valida per la # specifica periferica SERCOM. Questo parametro \u00e8 facoltativo. clk_pin: # Pin CLK per la comunicazione SPI o pin SCL (clock) per la # comunicazione I2C. Il pin deve avere una configurazione pinmux # valida per la specifica periferica SERCOM. Questo parametro deve # essere fornito. [adc_scaled] \u00b6 Scaling analogico di Duet2 Maestro tramite letture vref e vssa. La definizione di una sezione adc_scaled abilita pin adc virtuali (come \"my_name:PB0\") che vengono regolati automaticamente dai pin di monitoraggio vref e vssa della scheda. Assicurati di definire questa sezione di configurazione sopra qualsiasi sezione di configurazione che utilizza uno di questi pin virtuali. Per un esempio, vedere il file generic-duet2-maestro.cfg . [adc_scaled my_name] vref_pin: # The ADC pin to use for VREF monitoring. This parameter must be # provided. vssa_pin: # The ADC pin to use for VSSA monitoring. This parameter must be # provided. #smooth_time: 2.0 # A time value (in seconds) over which the vref and vssa # measurements will be smoothed to reduce the impact of measurement # noise. The default is 2 seconds. [replicape] \u00b6 Supporto per Replicape: vedere la guida beaglebone e il file generic-replicape.cfg per un esempio. # La sezione di configurazione \"replicape\" aggiunge i pin di abilitazione # dello stepper virtuale \"replicape: stepper_x_enable\" (per stepper X, Y, Z, # E e H) e i pin di uscita PWM \"replicape: power_x\" (per hotbed, e, h, fan0, # fan1 , fan2 e fan3) che possono quindi essere utilizzati altrove nel file # di configurazione. [replicape] revision: # La revisione dell'hardware di replicape. Attualmente \u00e8 supportata solo # la revisione \"B3\". Questo parametro deve essere fornito. #enable_pin: !gpio0_20 # Il pin di abilitazione globale dei replicape. L'impostazione predefinita # \u00e8 !gpio0_20 (aka P9_41). host_mcu: # Il nome della sezione mcu config che comunica con l'istanza mcu # \"linux process\" di Klipper. Questo parametro deve essere fornito. #standstill_power_down: False # Questo parametro controlla la linea CFG6_ENN su tutti i motori # passo-passo. True imposta le righe di abilitazione su \"open\". # L'impostazione predefinita \u00e8 Falso. #stepper_x_microstep_mode: #stepper_y_microstep_mode: #stepper_z_microstep_mode: #stepper_e_microstep_mode: #stepper_h_microstep_mode: # Questo parametro controlla i pin CFG1 e CFG2 del driver del motore # passo-passo specificato. Le opzioni disponibili sono: disabilita, 1, 2, # spread2, 4, 16, spread4, spread16, stealth4 e stealth16. L'impostazione # predefinita \u00e8 disabilitata. #stepper_x_current: #stepper_y_current: #stepper_z_current: #stepper_e_current: #stepper_h_current: # La corrente massima configurata (in Amp) del driver del motore # passo-passo. Questo parametro deve essere fornito se lo stepper non # \u00e8 in modalit\u00e0 disabilitazione. #stepper_x_chopper_off_time_high: #stepper_y_chopper_off_time_high: #stepper_z_chopper_off_time_high: #stepper_e_chopper_off_time_high: #stepper_h_chopper_off_time_high: # Questo parametro controlla il pin CFG0 del driver del motore # passo-passo (True imposta CFG0 alto, False lo imposta basso). # L'impostazione predefinita \u00e8 False. #stepper_x_chopper_hysteresis_high: #stepper_y_chopper_hysteresis_high: #stepper_z_chopper_hysteresis_high: #stepper_e_chopper_hysteresis_high: #stepper_h_chopper_hysteresis_high: # Questo parametro controlla il pin CFG4 del driver del motore # passo-passo (True imposta CFG4 alto, False lo imposta basso). # L'impostazione predefinita \u00e8 False. #stepper_x_chopper_blank_time_high: #stepper_y_chopper_blank_time_high: #stepper_z_chopper_blank_time_high: #stepper_e_chopper_blank_time_high: #stepper_h_chopper_blank_time_high: # Questo parametro controlla il pin CFG5 del driver del motore # passo-passo (True imposta CFG5 alto, False lo imposta basso). # L'impostazione predefinita \u00e8 True. Altri moduli personalizzati \u00b6 [palette2] \u00b6 Supporto multimateriale Palette 2: fornisce un'integrazione pi\u00f9 stretta supportando i dispositivi Palette 2 in modalit\u00e0 connessa. Questo modulo richiede anche [virtual_sdcard] e [pause_resume] per la piena funzionalit\u00e0. Se si utilizza questo modulo, non utilizzare il plug-in Palette 2 per Octoprint poich\u00e9 entreranno in conflitto e 1 non si inizializzer\u00e0 correttamente, probabilmente interrompendo la stampa. Se utilizzi Octoprint e esegui lo streaming di gcode sulla porta seriale invece di stampare da virtual_sd, rimuovere M1 e M0 da Pausa dei comandi in Impostazioni > Connessione seriale > Firmware e protocollo eviter\u00e0 la necessit\u00e0 per avviare la stampa sulla tavolozza 2 e riattivare la pausa in Octoprint per avviare la stampa. [palette2] serial: # The serial port to connect to the Palette 2. #baud: 115200 # The baud rate to use. The default is 115200. #feedrate_splice: 0.8 # The feedrate to use when splicing, default is 0.8 #feedrate_normal: 1.0 # The feedrate to use after splicing, default is 1.0 #auto_load_speed: 2 # Extrude feedrate when autoloading, default is 2 (mm/s) #auto_cancel_variation: 0.1 # Auto cancel print when ping variation is above this threshold [angle] \u00b6 Supporto per sensore magnetico Hall per la lettura delle misurazioni dell'angolo del motore passo-passo utilizzando i chip SPI a1333, as5047d o tle5012b. Le misurazioni sono disponibili tramite Server API e strumento di analisi del movimento . Vedere il Riferimento G-Code per i comandi disponibili. [angle my_angle_sensor] sensor_type: # The type of the magnetic hall sensor chip. Available choices are # \"a1333\", \"as5047d\", and \"tle5012b\". This parameter must be # specified. #sample_period: 0.000400 # The query period (in seconds) to use during measurements. The # default is 0.000400 (which is 2500 samples per second). #stepper: # The name of the stepper that the angle sensor is attached to (eg, # \"stepper_x\"). Setting this value enables an angle calibration # tool. To use this feature, the Python \"numpy\" package must be # installed. The default is to not enable angle calibration for the # angle sensor. cs_pin: # The SPI enable pin for the sensor. This parameter must be provided. #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. Parametri bus comuni \u00b6 Impostazioni SPI comuni \u00b6 I seguenti parametri sono generalmente disponibili per i dispositivi che utilizzano un bus SPI. #spi_speed: # La velocit\u00e0 SPI (in Hz) da utilizzare durante la comunicazione con il # dispositivo. L'impostazione predefinita dipende dal tipo di dispositivo. #spi_bus: # Se il microcontrollore supporta pi\u00f9 bus SPI, \u00e8 possibile specificare # qui il nome del bus del microcontrollore. L'impostazione predefinita # dipende dal tipo di microcontrollore. #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # Specificare i parametri di cui sopra per utilizzare \"SPI basato su # software\". Questa modalit\u00e0 non richiede il supporto hardware del # microcontrollore (in genere \u00e8 possibile utilizzare qualsiasi pin generico). # L'impostazione predefinita \u00e8 di non utilizzare \"spi software\". Impostazioni I2C comuni \u00b6 I seguenti parametri sono generalmente disponibili per i dispositivi che utilizzano un bus I2C. Tieni presente che l'attuale supporto del microcontrollore di Klipper per I2C generalmente non tollera il rumore di linea. Errori imprevisti sui cavi I2C potrebbero far s\u00ec che Klipper sollevi un errore di runtime. Il supporto di Klipper per il ripristino degli errori varia a seconda del tipo di microcontrollore. In genere si consiglia di utilizzare solo dispositivi I2C che si trovano sullo stesso circuito stampato del microcontrollore. La maggior parte delle implementazioni del microcontrollore Klipper supportano solo una i2c_speed di 100000 ( modalit\u00e0 standard , 100kbit/s). Il microcontrollore Klipper \"Linux\" supporta una velocit\u00e0 400000 ( modalit\u00e0 veloce , 400kbit/s), ma deve essere impostato nel sistema operativo e i2c_speed il parametro viene altrimenti ignorato. Il microcontrollore Klipper \"RP2040\" e la famiglia ATmega AVR supportano una velocit\u00e0 di 400000 tramite il parametro i2c_speed . Tutti gli altri microcontrollori Klipper utilizzano una velocit\u00e0 100000 e ignorano il parametro \"i2c_speed\". #i2c_address: # The i2c address of the device. This must specified as a decimal # number (not in hex). The default depends on the type of device. #i2c_mcu: # The name of the micro-controller that the chip is connected to. # The default is \"mcu\". #i2c_bus: # If the micro-controller supports multiple I2C busses then one may # specify the micro-controller bus name here. The default depends on # the type of micro-controller. #i2c_software_scl_pin: #i2c_software_sda_pin: # Specify these parameters to use micro-controller software based # I2C \"bit-banging\" support. The two parameters should the two pins # on the micro-controller to use for the scl and sda wires. The # default is to use hardware based I2C support as specified by the # i2c_bus parameter. #i2c_speed: # The I2C speed (in Hz) to use when communicating with the device. # The Klipper implementation on most micro-controllers is hard-coded # to 100000 and changing this value has no effect. The default is # 100000. Linux, RP2040 and ATmega support 400000.","title":"Riferimenti configurazione"},{"location":"Config_Reference.html#riferimenti-configurazione","text":"Questo documento \u00e8 un riferimento per le opzioni disponibili nel file di configurazione di Klipper. Le descrizioni in questo documento sono formattate in modo che sia possibile tagliarle e incollarle in un file di configurazione della stampante. Consulta il documento di installazione per informazioni sulla configurazione di Klipper e sulla scelta di un file di configurazione iniziale.","title":"Riferimenti configurazione"},{"location":"Config_Reference.html#configurazione-del-microcontrollore","text":"","title":"Configurazione del microcontrollore"},{"location":"Config_Reference.html#formato-dei-nomi-dei-pin-del-microcontrollore","text":"Molte opzioni di configurazione richiedono il nome di un pin del microcontrollore. Klipper usa i nomi hardware per questi pin, ad esempio \"PA4\". I nomi dei pin possono essere preceduti da ! per indicare che deve essere utilizzata una polarit\u00e0 inversa (ad esempio, trigger su basso anzich\u00e9 alto). I pin di input possono essere preceduti da ^ per indicare che un resistore di pull-up hardware deve essere abilitato per il pin. Se il microcontrollore supporta resistori pull-down, un pin di ingresso pu\u00f2 in alternativa essere preceduto da ~ . Nota, alcune sezioni di configurazione potrebbero \"creare\" pin aggiuntivi. Quando ci\u00f2 si verifica, la sezione di configurazione che definisce i pin deve essere elencata nel file di configurazione prima di qualsiasi sezione che utilizza tali pin.","title":"Formato dei nomi dei pin del microcontrollore"},{"location":"Config_Reference.html#mcu","text":"Configurazione del microcontrollore primario. [mcu] serial: # La porta seriale per la connessione all'MCU. In caso di dubbi (o se # cambia) vedere \"Dov'\u00e8 la mia porta seriale?\" sezione delle FAQ. # Questo parametro deve essere fornito quando si utilizza una # porta seriale. #baud: 250000 # La velocit\u00e0 di trasmissione da utilizzare. Il valore predefinito \u00e8 250000. #canbus_uuid: # Se si utilizza un dispositivo collegato a un bus CAN, questo imposta # l'identificatore univoco del chip a cui connettersi. Questo valore deve # essere fornito quando si utilizza il bus CAN per la comunicazione. #canbus_interface: # Se si utilizza un dispositivo collegato a un bus CAN, viene impostata # l'interfaccia di rete CAN da utilizzare. L'impostazione predefinita \u00e8 'can0'. #restart_method: # Questo controlla il meccanismo che l'host utilizzer\u00e0 per reimpostare # il microcontrollore. Le scelte sono \"arduino\", \"cheetah\", \"rpi_usb\" e # \"command\". Il metodo 'arduino' (attiva/disattiva DTR) \u00e8 comune su # schede Arduino e cloni. Il metodo 'cheetah' \u00e8 un metodo speciale # necessario per alcune schede Fysetc Cheetah. Il metodo \"rpi_usb\" # \u00e8 utile sulle schede Raspberry Pi con microcontrollori alimentati # tramite USB: disabilita brevemente l'alimentazione a tutte le porte # USB per eseguire un ripristino del microcontrollore. Il metodo # \"comando\" prevede l'invio di un comando Klipper al microcontrollore # in modo che possa reimpostarsi. L'impostazione predefinita \u00e8 # 'arduino' se il microcontrollore comunica su una porta seriale, # altrimenti 'comando'.","title":"[mcu]"},{"location":"Config_Reference.html#mcu-my_extra_mcu","text":"Microcontrollori aggiuntivi (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"mcu\"). Microcontrollori aggiuntivi introducono pin aggiuntivi che possono essere configurati come riscaldatori, stepper, ventole, ecc. Ad esempio, se viene introdotta una sezione \"[mcu extra_mcu]\", i pin come \"extra_mcu:ar9\" possono quindi essere utilizzati altrove nella configurazione (dove \"ar9\" \u00e8 un nome pin hardware o un nome alias sul dato mcu). [mcu my_extra_mcu] # Vedere la sezione \"mcu\" per i parametri di configurazione.","title":"[mcu my_extra_mcu]"},{"location":"Config_Reference.html#impostazioni-cinematiche-comuni","text":"","title":"Impostazioni cinematiche comuni"},{"location":"Config_Reference.html#printer","text":"La sezione printer controlla le impostazioni di alto livello della stampante. [printer] kinematics: # Il tipo di stampante in uso. Questa opzione pu\u00f2 essere una delle # seguenti: cartesian, corexy, corexz, hybrid_corexy, hybrid_corexz, # rotary_delta, delta, deltesian, polar, winch o nessuno. # Questo parametro deve essere specificato. max_velocity: # Velocit\u00e0 massima (in mm/s) della testa di stampa (relativa alla stampa). # Questo parametro deve essere specificato. max_accel: # Accelerazione massima (in mm/s^2) della testina (relativa alla stampa). # Questo parametro deve essere specificato. #max_accel_to_decel: # Una pseudo accelerazione (in mm/s^2) che controlla la velocit\u00e0 con cui # la testa di stampa pu\u00f2 passare dall'accelerazione alla decelerazione. Viene # utilizzato per ridurre la velocit\u00e0 massima di brevi movimenti a zig-zag # (e quindi ridurre le vibrazioni della stampante dovute a questi movimenti). # Il valore predefinito \u00e8 met\u00e0 di max_accel. #square_corner_velocity: 5.0 # La velocit\u00e0 massima (in mm/s) alla quale la testa di stampa pu\u00f2 viaggiare # su un angolo di 90 gradi. Un valore diverso da zero pu\u00f2 ridurre le variazioni # delle portate dell'estrusore consentendo variazioni istantanee della velocit\u00e0 # della testa utensile durante le curve. Questo valore configura l'algoritmo # interno di cornering della velocit\u00e0 centripeta; gli angoli con angoli maggiori # di 90 gradi avranno una velocit\u00e0 in curva maggiore mentre gli angoli con # angoli inferiori a 90 gradi avranno una velocit\u00e0 in curva inferiore. Se questo # \u00e8 impostato su zero, la testa utensile decelerer\u00e0 fino a zero ad ogni angolo. # Il valore predefinito \u00e8 5 mm/s.","title":"[printer]"},{"location":"Config_Reference.html#stepper","text":"Definizioni di motori passo-passo. Diversi tipi di stampante (come specificato dall'opzione \"cinematica\" nella sezione di configurazione [stampante]) richiedono nomi diversi per lo stepper (ad esempio, stepper_x vs stepper_a ). Di seguito sono riportate le definizioni comuni di stepper. Vedere il documento distanza di rotazione per informazioni sul calcolo del parametro rotation_distance . Consultare il documento Multi-MCU homing per informazioni sull'homing utilizzando pi\u00f9 microcontrollori. [stepper_x] step_pin: # Pin GPIO Step (attivato in alto) . Questo parametro deve essere fornito. dir_pin: # Pin GPIO di direzione (alto indica una direzione positiva). # Questo parametro deve essere fornito. enable_pin: # Pin GPIO di abilitazione (l'impostazione predefinita \u00e8 abilita alto; usa ! # per indicare abilita basso). Se questo parametro non viene fornito, il # driver del motore passo-passo deve essere sempre abilitato. rotation_distance: # Distanza (in mm) che l'asse percorre con una rotazione completa del # motore passo-passo (o viene specificata la marcia finale del rapporto di # trasmissione). Questo parametro deve essere fornito. microsteps: # Il numero di micropassi utilizzati dal driver del motore passo-passo. # Questo parametro deve essere fornito. #full_steps_per_rotation: 200 # Il numero di passi completi per una rotazione del motore passo-passo. # Impostarlo su 200 per un motore passo-passo da 1.8 gradi o su 400 per # un motore da 0.9 gradi. Il valore predefinito \u00e8 200. #gear_ratio: # Il rapporto di trasmissione se il motore passo-passo \u00e8 collegato all'asse # tramite un riduttore. Ad esempio, si pu\u00f2 specificare \"5:1\" se \u00e8 in uso un # riduttore 5 a 1. Se l'asse ha pi\u00f9 riduttori, \u00e8 possibile specificare un elenco # di rapporti di trasmissione separati da virgole (ad esempio, \"57:11, 2:1\"). # Se viene specificato gear_ratio, rotation_distance specifica la distanza # percorsa dall'asse per una rotazione completa dell'ingranaggio finale. # L'impostazione predefinita \u00e8 di non utilizzare un rapporto di trasmissione. #step_pulse_duration: # Il tempo minimo tra il fronte del segnale dell'impulso del passo e il # successivo fronte del segnale \"non passo\". Viene utilizzato anche per # impostare il tempo minimo tra un impulso di passo e un segnale di cambio # di direzione. L'impostazione predefinita \u00e8 0.000000100 (100ns) per gli # stepper TMC configurati in modalit\u00e0 UART o SPI e l'impostazione # predefinita \u00e8 0.000002 (che \u00e8 2us) per tutti gli altri stepper. endstop_pin: # Pin di rilevamento interruttore di fine corsa. Se questo pin di fine corsa # si trova su un mcu diverso dal motore passo-passo, abilita il # \"homing multi-mcu\". Questo parametro deve essere fornito per gli # stepper X, Y e Z su stampanti in stile cartesiano. #position_min: 0 # Distanza minima valida (in mm) alla quale l'utente pu\u00f2 comandare # il movimento dello stepper. Il valore predefinito \u00e8 0 mm. position_endstop: # Posizione del finecorsa (in mm). Questo parametro deve essere fornito # per gli stepper X, Y e Z su stampanti in stile cartesiano. position_max: # Distanza massima valida (in mm) alla quale l'utente pu\u00f2 comandare lo # spostamento dello stepper. Questo parametro deve essere fornito per # gli stepper X, Y e Z su stampanti in stile cartesiano. #homing_speed: 5.0 # Velocit\u00e0 massima (in mm/s) dello stepper durante l'homing. # Il valore predefinito \u00e8 5 mm/s. #homing_retract_dist: 5.0 # Distanza dall'arretramento (in mm) prima della corsa di riferimento # una seconda volta durante la corsa di riferimento. Impostalo a zero per # disabilitare la seconda casa. Il valore predefinito \u00e8 5 mm. #homing_retract_speed: # Velocit\u00e0 da utilizzare nella corsa di ritorno dopo l'homing nel caso in # cui questa dovesse essere diversa dalla velocit\u00e0 di homing, che \u00e8 # l'impostazione predefinita per questo parametro #second_homing_speed: # Velocit\u00e0 (in mm/s) dello stepper durante l'esecuzione del secondo # homing. L'impostazione predefinita \u00e8 homing_speed/2. #homing_positive_dir: # Se true, l'homing far\u00e0 muovere lo stepper in una direzione positiva # (allontanandosi da zero); se falso, home verso zero. \u00c8 meglio utilizzare # l'impostazione predefinita piuttosto che specificare questo parametro. # Il valore predefinito \u00e8 true se position_endstop \u00e8 vicino a position_max # false se vicino a position_min.","title":"[stepper]"},{"location":"Config_Reference.html#cinematica-cartesiana","text":"Vedere example-cartesian.cfg per un file di configurazione della cinematica cartesiana di esempio. Qui sono descritti solo i parametri specifici delle stampanti cartesiane - vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: cartesian max_z_velocity: # Imposta la velocit\u00e0 massima (in mm/s) di movimento lungo # l'asse z. Questa impostazione pu\u00f2 essere utilizzata per limitare # la velocit\u00e0 massima del motore passo-passo z. L'impostazione # predefinita \u00e8 utilizzare max_velocity per max_z_velocity. max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento # lungo l'asse z. Limita l'accelerazione del motore passo-passo z. # L'impostazione predefinita \u00e8 utilizzare max_accel per max_z_accel. # La sezione stepper_x viene utilizzata per descrivere lo stepper # che controlla l'asse X in un robot cartesiano. [stepper_x] # La sezione stepper_y viene utilizzata per descrivere lo stepper # che controlla l'asse Y in un robot cartesiano. [stepper_y] # La sezione stepper_z viene utilizzata per descrivere lo stepper # che controlla l'asse Z in un robot cartesiano. [stepper_z]","title":"Cinematica cartesiana"},{"location":"Config_Reference.html#cinematica-delta-lineare","text":"Vedere example-delta.cfg per un file di configurazione della cinematica delta lineare di esempio. Consultare la guida alla calibrazione delta per informazioni sulla calibrazione. Qui vengono descritti solo i parametri specifici per le stampanti delta lineari - vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: delta max_z_velocity: # Per le stampanti delta questo limita la velocit\u00e0 massima (in mm/s) dei # movimenti con movimento dell'asse z. Questa impostazione pu\u00f2 essere # utilizzata per ridurre la velocit\u00e0 massima dei movimenti su/gi\u00f9 (che # richiedono una velocit\u00e0 di incremento maggiore rispetto ad altri # movimenti su una stampante delta). L'impostazione predefinita \u00e8 # utilizzare max_velocity per max_z_velocity. #max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento lungo # l'asse z. L'impostazione pu\u00f2 essere utile se la stampante pu\u00f2 # raggiungere un'accelerazione maggiore sui movimenti XY rispetto ai # movimenti Z (ad esempio, quando si utilizza l'input shaper). # L'impostazione predefinita \u00e8 utilizzare max_accel per max_z_accel. #minimum_z_position: 0 # La posizione Z minima in cui l'utente pu\u00f2 comandare alla testa di # spostarsi. Il valore predefinito \u00e8 0. delta_radius: # Raggio (in mm) del cerchio orizzontale formato dalle tre torri ad # asse lineare. Questo parametro pu\u00f2 anche essere calcolato come: # delta_radius = smooth_rod_offset - effector_offset - carriage_offset # Questo parametro deve essere fornito. #print_radius: # Il raggio (in mm) delle coordinate XY della testa di stampa valide. # \u00c8 possibile utilizzare questa impostazione per personalizzare il # controllo dell'intervallo dei movimenti della testa. Se qui # viene specificato un valore elevato, potrebbe essere possibile # comandare la collisione della testa di stampa con una torre. # L'impostazione predefinita \u00e8 usare delta_radius per print_radius # (che normalmente impedirebbe una collisione con torri). # La sezione stepper_a descrive lo stepper che controlla la torre # anteriore sinistra (a 210 gradi). Questa sezione controlla anche i # parametri di homing (velocit\u00e0 di homing, homing retract_dist) # per tutte le torri. [stepper_a] position_endstop: # Distanza (in mm) tra l'ugello e il piatto quando l'ugello si trova al # centro dell'area di costruzione e si attiva il finecorsa. Questo # parametro deve essere fornito per stepper_a; per stepper_b e # stepper_c questo parametro \u00e8 predefinito sul valore specificato # per stepper_a. arm_length: # Lunghezza (in mm) dell'asta diagonale che collega questa torre # alla testa di stampa. Questo parametro deve essere fornito per # stepper_a; per stepper_b e stepper_c questo parametro \u00e8 predefinito sul valore specificato per stepper_a. #angle: # Questa opzione specifica l'angolo (in gradi) a cui si trova la torre. # Il valore predefinito \u00e8 210 per stepper_a, 330 per stepper_b e 90 # per stepper_c. # La sezione stepper_b descrive lo stepper che controlla la torre # anteriore destra (a 330 gradi). [stepper_b] # La sezione stepper_c descrive lo stepper che controlla la torre # posteriore (a 90 gradi). [stepper_c] # La sezione delta_calibrate abilita un comando G-code esteso # DELTA_CALIBRATE in grado di calibrare le posizioni e gli angoli # dei finecorsa della torre. [delta_calibrate] radius: # Raggio (in mm) dell'area che pu\u00f2 essere sondata. Questo \u00e8 # il raggio delle coordinate dell'ugello da sondare; se si utilizza # una sonda automatica con un offset XY, scegliere un raggio # sufficientemente piccolo in modo che la sonda si adatti sempre # al piatto. Questo parametro deve essere fornito. #speed: 50 # La velocit\u00e0 (in mm/s) degli spostamenti senza probing durante # la calibrazione. Il valore predefinito \u00e8 50. #horizontal_move_z: 5 # L'altezza (in mm) a cui la testa deve essere comandata di # spostarsi appena prima di avviare un'operazione di sonda. # L'impostazione predefinita \u00e8 5.","title":"Cinematica Delta lineare"},{"location":"Config_Reference.html#cinematica-deltesiana","text":"Vedere example-deltesian.cfg per un esempio di file di configurazione della cinematica deltesiana. Qui sono descritti solo i parametri specifici per le stampanti deltesiane - vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: deltesian max_z_velocity: # For deltesian printers, this limits the maximum velocity (in mm/s) of # moves with z axis movement. This setting can be used to reduce the # maximum speed of up/down moves (which require a higher step rate # than other moves on a deltesian printer). The default is to use # max_velocity for max_z_velocity. #max_z_accel: # This sets the maximum acceleration (in mm/s^2) of movement along # the z axis. Setting this may be useful if the printer can reach higher # acceleration on XY moves than Z moves (eg, when using input shaper). # The default is to use max_accel for max_z_accel. #minimum_z_position: 0 # The minimum Z position that the user may command the head to move # to. The default is 0. #min_angle: 5 # This represents the minimum angle (in degrees) relative to horizontal # that the deltesian arms are allowed to achieve. This parameter is # intended to restrict the arms from becoming completely horizontal, # which would risk accidental inversion of the XZ axis. The default is 5. #print_width: # The distance (in mm) of valid toolhead X coordinates. One may use # this setting to customize the range checking of toolhead moves. If # a large value is specified here then it may be possible to command # the toolhead into a collision with a tower. This setting usually # corresponds to bed width (in mm). #slow_ratio: 3 # The ratio used to limit velocity and acceleration on moves near the # extremes of the X axis. If vertical distance divided by horizontal # distance exceeds the value of slow_ratio, then velocity and # acceleration are limited to half their nominal values. If vertical # distance divided by horizontal distance exceeds twice the value of # the slow_ratio, then velocity and acceleration are limited to one # quarter of their nominal values. The default is 3. # The stepper_left section is used to describe the stepper controlling # the left tower. This section also controls the homing parameters # (homing_speed, homing_retract_dist) for all towers. [stepper_left] position_endstop: # Distance (in mm) between the nozzle and the bed when the nozzle is # in the center of the build area and the endstops are triggered. This # parameter must be provided for stepper_left; for stepper_right this # parameter defaults to the value specified for stepper_left. arm_length: # Length (in mm) of the diagonal rod that connects the tower carriage to # the print head. This parameter must be provided for stepper_left; for # stepper_right, this parameter defaults to the value specified for # stepper_left. arm_x_length: # Horizontal distance between the print head and the tower when the # printers is homed. This parameter must be provided for stepper_left; # for stepper_right, this parameter defaults to the value specified for # stepper_left. # The stepper_right section is used to describe the stepper controlling the # right tower. [stepper_right] # The stepper_y section is used to describe the stepper controlling # the Y axis in a deltesian robot. [stepper_y]","title":"Cinematica Deltesiana"},{"location":"Config_Reference.html#cinematica-corexy","text":"Vedere example-corexy.cfg per un file cinematico corexy (e h-bot) di esempio. Qui sono descritti solo i parametri specifici per le stampanti corexy - vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: corexy max_z_velocity: # Imposta la velocit\u00e0 massima (in mm/s) di movimento lungo l'asse z. # Questa impostazione pu\u00f2 essere utilizzata per limitare la velocit\u00e0 # massima del motore passo-passo z. L'impostazione predefinita \u00e8 # utilizzare max_velocity per max_z_velocity. max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento # lungo l'asse z. Limita l'accelerazione del motore passo-passo z. # L'impostazione predefinita \u00e8 utilizzare max_accel per max_z_accel. # La sezione stepper_x viene utilizzata per descrivere l'asse X e lo # stepper che controlla il movimento X+Y. [stepper_x] # La sezione stepper_y viene utilizzata per descrivere l'asse Y e lo # stepper che controlla il movimento X+Y. [stepper_y] # La sezione stepper_z viene utilizzata per descrivere l'asse Z [stepper_z]","title":"Cinematica CoreXY"},{"location":"Config_Reference.html#cinematica-corexz","text":"Vedere example-corexz.cfg per un file di configurazione della cinematica corexz di esempio. Qui sono descritti solo i parametri specifici per le stampanti corexz - vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: corexz max_z_velocity: # Imposta la velocit\u00e0 massima (in mm/s) di movimento lungo l'asse z. # L'impostazione predefinita \u00e8 utilizzare max_velocity per # max_z_velocity. max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento lungo # l'asse z. L'impostazione predefinita \u00e8 utilizzare max_accel per # max_z_accel. # La sezione stepper_x viene utilizzata per descrivere l'asse X e lo # stepper che controlla il movimento X+Z. [stepper_x] # La sezione stepper_y viene utilizzata per descrivere l'asse Y [stepper_y] # La sezione stepper_z viene utilizzata per descrivere l'asse Z e lo # stepper che controlla il movimento X+Z. [stepper_z]","title":"Cinematica CoreXZ"},{"location":"Config_Reference.html#cinematica-hybrid-corexy","text":"Vedere example-hybrid-corexy.cfg per un file di configurazione della cinematica corexy ibrida di esempio. Questa cinematica \u00e8 anche nota come cinematica Markforged. Qui vengono descritti solo i parametri specifici delle stampanti corexy ibride, vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: hybrid_corexy max_z_velocity: # Imposta la velocit\u00e0 massima (in mm/s) di movimento lungo # l'asse z. L'impostazione predefinita \u00e8 utilizzare max_velocity # per max_z_velocity. max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento # lungo l'asse z. L'impostazione predefinita \u00e8 utilizzare max_accel # per max_z_accel. # La sezione stepper_x viene utilizzata per descrivere l'asse X e lo # stepper che controlla il movimento X-Y. [stepper_x] # La sezione stepper_y viene utilizzata per descrivere lo stepper # che controlla l'asse Y. [stepper_y] # La sezione stepper_z viene utilizzata per descrivere lo stepper # che controlla l'asse Z. [stepper_z]","title":"Cinematica Hybrid-CoreXY"},{"location":"Config_Reference.html#cinematica-hybrid-corexz","text":"Vedere example-hybrid-corexz.cfg per un file di configurazione della cinematica corexz ibrido di esempio. Questa cinematica \u00e8 anche nota come cinematica Markforged. Qui vengono descritti solo i parametri specifici delle stampanti corexy ibride, vedere impostazioni cinematiche comuni per i parametri disponibili. [printer] kinematics: hybrid_corexz max_z_velocity: # Questo imposta la velocit\u00e0 massima (in mm/s) di movimento lungo # l'asse z. L'impostazione predefinita \u00e8 utilizzare max_velocity per # max_z_velocity. max_z_accel: # Imposta l'accelerazione massima (in mm/s^2) del movimento lungo # l'asse z. L'impostazione predefinita \u00e8 utilizzare max_accel per # max_z_accel. # La sezione stepper_x viene utilizzata per descrivere l'asse X e lo # stepper che controlla il movimento X-Z. [stepper_x] # La sezione stepper_y viene utilizzata per descrivere lo stepper che # controlla l'asse Y. [stepper_y] # La sezione stepper_z viene utilizzata per descrivere lo stepper che # controlla l'asse Z. [stepper_z]","title":"Cinematica Hybrid-CoreXZ"},{"location":"Config_Reference.html#cinematica-polare","text":"Vedere example-polar.cfg per un file di configurazione della cinematica polare di esempio. Qui sono descritti solo i parametri specifici per le stampanti polari - vedere impostazioni cinematiche comuni per i parametri disponibili. LA CINEMATICA POLARE \u00c8 UN LAVORO IN CORSO. \u00c8 noto che i movimenti intorno alla posizione 0, 0 non funzionano correttamente. [printer] kinematics: polar max_z_velocity: # Imposta la velocit\u00e0 massima (in mm/s) di movimento lungo l'asse z. # Questa impostazione pu\u00f2 essere utilizzata per limitare la velocit\u00e0 # massima del motore passo-passo z. L'impostazione predefinita \u00e8 # utilizzare max_velocity per max_z_velocity. max_z_accel: # Questo imposta l'accelerazione massima (in mm/s^2) del # movimento lungo l'asse z. Limita l'accelerazione del motore # passo-passo z. L'impostazione predefinita \u00e8 utilizzare max_accel # per max_z_accel. # La sezione stepper_bed viene utilizzata per descrivere lo stepper # che controlla il piatto [stepper_bed] gear_ratio: # \u00c8 necessario specificare un gear_ratio e rotation_distance # potrebbe non essere specificato. Ad esempio, se il piatto ha una # ruota a 80 denti azionata da uno stepper con una ruota a 16 # denti, si dovrebbe specificare un rapporto di trasmissione di \"80:16\". # Questo parametro deve essere fornito. # La sezione stepper_arm \u00e8 usata per descrivere lo stepper che # controlla il carrello sul braccio. [stepper_arm] # La sezione stepper_z viene utilizzata per descrivere lo stepper che # controlla l'asse Z. [stepper_z]","title":"Cinematica polare"},{"location":"Config_Reference.html#cinematica-delta-rotatoria","text":"Vedere example-rotary-delta.cfg per un esempio di file di configurazione della cinematica delta rotante. Qui vengono descritti solo i parametri specifici delle stampanti delta rotative - vedere impostazioni cinematiche comuni per i parametri disponibili. LA CINEMATICA DELTA ROTANTE \u00c8 UN LAVORO IN CORSO. Gli spostamenti di homing potrebbero scadere e alcuni controlli dei confini non vengono implementati. [printer] kinematics: rotary_delta max_z_velocity: # For delta printers this limits the maximum velocity (in mm/s) of # moves with z axis movement. This setting can be used to reduce the # maximum speed of up/down moves (which require a higher step rate # than other moves on a delta printer). The default is to use # max_velocity for max_z_velocity. #minimum_z_position: 0 # The minimum Z position that the user may command the head to move # to. The default is 0. shoulder_radius: # Radius (in mm) of the horizontal circle formed by the three # shoulder joints, minus the radius of the circle formed by the # effector joints. This parameter may also be calculated as: # shoulder_radius = (delta_f - delta_e) / sqrt(12) # This parameter must be provided. shoulder_height: # Distance (in mm) of the shoulder joints from the bed, minus the # effector toolhead height. This parameter must be provided. # The stepper_a section describes the stepper controlling the rear # right arm (at 30 degrees). This section also controls the homing # parameters (homing_speed, homing_retract_dist) for all arms. [stepper_a] gear_ratio: # A gear_ratio must be specified and rotation_distance may not be # specified. For example, if the arm has an 80 toothed pulley driven # by a pulley with 16 teeth, which is in turn connected to a 60 # toothed pulley driven by a stepper with a 16 toothed pulley, then # one would specify a gear ratio of \"80:16, 60:16\". This parameter # must be provided. position_endstop: # Distance (in mm) between the nozzle and the bed when the nozzle is # in the center of the build area and the endstop triggers. This # parameter must be provided for stepper_a; for stepper_b and # stepper_c this parameter defaults to the value specified for # stepper_a. upper_arm_length: # Length (in mm) of the arm connecting the \"shoulder joint\" to the # \"elbow joint\". This parameter must be provided for stepper_a; for # stepper_b and stepper_c this parameter defaults to the value # specified for stepper_a. lower_arm_length: # Length (in mm) of the arm connecting the \"elbow joint\" to the # \"effector joint\". This parameter must be provided for stepper_a; # for stepper_b and stepper_c this parameter defaults to the value # specified for stepper_a. #angle: # This option specifies the angle (in degrees) that the arm is at. # The default is 30 for stepper_a, 150 for stepper_b, and 270 for # stepper_c. # The stepper_b section describes the stepper controlling the rear # left arm (at 150 degrees). [stepper_b] # The stepper_c section describes the stepper controlling the front # arm (at 270 degrees). [stepper_c] # The delta_calibrate section enables a DELTA_CALIBRATE extended # g-code command that can calibrate the shoulder endstop positions. [delta_calibrate] radius: # Radius (in mm) of the area that may be probed. This is the radius # of nozzle coordinates to be probed; if using an automatic probe # with an XY offset then choose a radius small enough so that the # probe always fits over the bed. This parameter must be provided. #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5.","title":"Cinematica delta rotatoria"},{"location":"Config_Reference.html#cinematica-dellargano-a-fune","text":"Vedere example-winch.cfg per un esempio di file di configurazione della cinematica con verricello, cable winch. Qui sono descritti solo i parametri specifici per le stampanti cavo verricello - vedere impostazioni comuni cinematiche per i parametri disponibili. IL SUPPORTO DEL VERRICELLO \u00c8 SPERIMENTALE. L'homing non \u00e8 implementato nella cinematica del verricello. Per riportare la stampante alla posizione iniziale, inviare manualmente i comandi di movimento finch\u00e9 la testa utensile non si trova su 0, 0, 0, quindi emettere un comando \"G28\". [printer] kinematics: winch # The stepper_a section describes the stepper connected to the first # cable winch. A minimum of 3 and a maximum of 26 cable winches may be # defined (stepper_a to stepper_z) though it is common to define 4. [stepper_a] rotation_distance: # The rotation_distance is the nominal distance (in mm) the toolhead # moves towards the cable winch for each full rotation of the # stepper motor. This parameter must be provided. anchor_x: anchor_y: anchor_z: # The X, Y, and Z position of the cable winch in cartesian space. # These parameters must be provided.","title":"Cinematica dell'argano a fune"},{"location":"Config_Reference.html#nessuna-cinematica","text":"\u00c8 possibile definire una cinematica speciale \"none\" per disabilitare il supporto cinematico in Klipper. Questo pu\u00f2 essere utile per controllare dispositivi che non sono le tipiche stampanti 3D o per scopi di debug. [printer] kinematics: none max_velocity: 1 max_accel: 1 # \u00c8 necessario definire i parametri max_velocity e max_accel. I valori # non vengono utilizzati per la cinematica \"none\".","title":"Nessuna cinematica"},{"location":"Config_Reference.html#supporto-per-estrusore-e-piatto-riscaldato-comuni","text":"","title":"Supporto per estrusore e piatto riscaldato comuni"},{"location":"Config_Reference.html#extruder","text":"La sezione dell'estrusore viene utilizzata per descrivere i parametri del riscaldatore per l'hotend dell'ugello insieme allo stepper che controlla l'estrusore. Per ulteriori informazioni, vedere riferimento comando . Consultare la Guida all'avanzamento della pressione per informazioni sulla regolazione dell'anticipo della pressione. [extruder] step_pin: dir_pin: enable_pin: microsteps: rotation_distance: #full_steps_per_rotation: #gear_ratio: # Vedere la sezione \"stepper\" per una descrizione di quanto sopra # Se nessuno dei parametri precedenti \u00e8 specificato, nessuno stepper # sar\u00e0 associato all'hotend dell'ugello (sebbene un comando # SYNC_EXTRUDER_MOTION possa associarne uno in fase di esecuzione). nozzle_diameter: # Diametro dell'orifizio dell'ugello (in mm). Questo parametro deve essere fornito. filament_diameter:: # Il diametro nominale del filamento grezzo (in mm) quando # entra nell'estrusore. Questo parametro deve essere fornito. #max_extrude_cross_section: # Area massima (in mm^2) di una sezione trasversale dell'estrusione # (ad es. larghezza dell'estrusione moltiplicata per l'altezza dello strato). # Questa impostazione previene quantit\u00e0 eccessive di estrusione # durante spostamenti XY relativamente piccoli. # Se un movimento richiede una velocit\u00e0 di estrusione che supererebbe questo valore # causer\u00e0 la restituzione di un errore. L'impostazione predefinita # \u00e8: 4.0 * diametro_ugello^2 instantaneous_corner_velocity: 1.000 # La variazione di velocit\u00e0 istantanea massima (in mm/s) del # estrusore durante il collegamento di due movimenti. Il valore predefinito \u00e8 1 mm/s. #max_extrude_only_distance: 50.0 # Lunghezza massima (in mm di filamento grezzo) che pu\u00f2 avere un movimento # di retrazione o di sola estrusione. Se uno spostamento di retrazione # o di sola estrusione richiede una distanza maggiore di questo valore, # verr\u00e0 restituito un errore. Il valore predefinito \u00e8 50 mm. #max_extrude_only_velocity: #max_extrude_only_accel: # Velocit\u00e0 massima (in mm/s) e accelerazione (in mm/s^2) del # motore estrusore per retrazioni e movimenti di sola estrusione. # Queste impostazioni non hanno alcun impatto sui normali movimenti di stampa. # Se non specificati, vengono calcolati per corrispondere al limite che avrebbe # un movimento di stampa XY con una sezione trasversale di 4,0*diametro_ugello^2. #pressure_advance: 0.0 # La quantit\u00e0 di filamento grezzo da spingere nell'estrusore durante # accelerazione dell'estrusore. Una uguale quantit\u00e0 di filamento viene # retratta durante la decelerazione. Si misura in millimetri per # millimetro/secondo. Il valore predefinito \u00e8 0, che disabilita l'avanzamento della pressione. #pressure_advance_smooth_time: 0,040 # Un intervallo di tempo (in secondi) da utilizzare per calcolare la velocit\u00e0 media # dell'estrusore per l'avanzamento della pressione. Un valore maggiore si traduce # in movimenti pi\u00f9 fluidi dell'estrusore. Questo parametro non pu\u00f2 superare i 200 ms. # Questa impostazione si applica solo se pressure_advance \u00e8 diverso da zero. # Il valore predefinito \u00e8 0,040 (40 millisecondi). # # Le restanti variabili descrivono il riscaldatore dell'estrusore. heater_pin: # Pin di uscita PWM che controlla il riscaldatore. Questo parametro deve essere fornito. #max_power: 1.0 # La potenza massima (espressa come un valore compreso tra 0,0 e 1,0) a cui # pu\u00f2 essere impostato il riscaldatore_pin. Il valore 1.0 consente di impostare il pin # completamente abilitato per periodi prolungati, mentre un valore di 0,5 # consentirebbe di abilitare il pin per non pi\u00f9 della met\u00e0 del tempo. Questo # l'impostazione pu\u00f2 essere utilizzata per limitare la potenza totale # (per periodi prolungati) al riscaldatore. L'impostazione predefinita \u00e8 1.0. sensor_type: # Tipo di sensore - i termistori comuni sono \"EPCOS 100K B57560G104F\", # \"ATC Semitec 104GT-2\", \"ATC Semitec 104NT-4-R025H42G\", \"Generico # 3950\",\"Honeywell 100K 135-104LAG-J01\", \"NTC 100K MGB18-104F39050L32\", # \"SliceEngineering 450\" e \"TDK NTCG104LH104JT1\". Vedere la sezione # \"Sensori di temperatura\" per altri sensori. Questo parametro deve essere fornito. sensor_pin: # Pin di ingresso analogico collegato al sensore. Questo parametro deve essere fornito. #pullup_resistor: 4700 # La resistenza (in ohm) del pullup collegato al termistore. Questo parametro # \u00e8 valido solo quando il sensore \u00e8 un termistore. Il valore predefinito \u00e8 4700 ohm. #smooth_time: 1.0 # Un valore di tempo (in secondi) durante il quale le misurazioni della # temperatura verranno uniformate per ridurre l'impatto del rumore # di misurazione. Il valore predefinito \u00e8 1 secondo. control: # Algoritmo di controllo (pid o filigrana). Questo parametro deve # essere fornito. pid_Kp: pid_Ki: pid_Kd: # Il proporzionale (pid_Kp), l'integrale (pid_Ki) e la derivata # (pid_Kd) impostazioni per il sistema di controllo del feedback PID. Klipper # valuta le impostazioni PID con la seguente formula generale: # riscaldatore_pwm = (Kp*errore + Ki*integrale(errore) - Kd*derivato(errore)) / 255 # Dove \"errore\" \u00e8 \"temperatura_richiesta - temperatura_misurata\" # e \"heater_pwm\" \u00e8 la velocit\u00e0 di riscaldamento richiesta con 0,0 completamente # off e 1.0 completamente on. Prendi in considerazione l'utilizzo di PID_CALIBRATE # comando per ottenere questi parametri. pid_Kp, pid_Ki e pid_Kd # i parametri devono essere forniti per i riscaldatori PID. #delta_max: 2.0 # Sui riscaldatori controllati questo \u00e8 il numero di gradi in # Celsius al di sopra della temperatura target prima di disattivare il riscaldatore # cos\u00ec come il numero di gradi sotto il target prima # riattivare il riscaldatore. L'impostazione predefinita \u00e8 2 gradi Celsius. #pwm_cycle_time: 0,100 # Tempo in secondi per ogni ciclo PWM software del riscaldatore. # non \u00e8 consigliabile impostarlo a meno che non ci sia necessario come # requisito accendere il riscaldatore pi\u00f9 velocemente di 10 volte al secondo. # Il valore predefinito \u00e8 0,100 secondi. #min_extrude_temp: 170 # La temperatura minima (in gradi Celsius) alla quale possono essere # impartiti comandi all'estrusore. L'impostazione predefinita \u00e8 170 gradi Celsius. min_temp: max_temp: # L'intervallo massimo di temperature valide (in gradi Celsius) in cui # il riscaldatore deve rimanere all'interno. Questo controlla una funzione di sicurezza # implementata nel codice del microcontrollore , la temperatura # non cadr\u00e0 mai al di fuori di questo intervallo, altrimenti il microcontrollore # entrer\u00e0 in uno stato di arresto. Questo controllo pu\u00f2 aiutare a rilevarne alcuni # guasti hardware del riscaldatore e del sensore. Imposta questo intervallo solo in modo ampio # abbastanza in modo che temperature ragionevoli non si traducano in un errore. # Questi parametri devono essere forniti.","title":"[extruder]"},{"location":"Config_Reference.html#heater_bed","text":"La sezione heater_bed descrive un piatto riscaldato. Utilizza le stesse impostazioni del riscaldatore descritte nella sezione \"extruder\". [heater_bed] heater_pin: sensor_type: sensor_pin: control: min_temp: max_temp: # Vedere la sezione \"extruder\" per una descrizione dei parametri sopra.","title":"[heater_bed]"},{"location":"Config_Reference.html#supporto-livellamento-del-piatto","text":"","title":"Supporto livellamento del piatto"},{"location":"Config_Reference.html#bed_mesh","text":"Mesh Bed Leveling. Si pu\u00f2 definire una sezione di configurazione bed_mesh per abilitare trasformazioni di spostamento che sfalsano l'asse z in base a una mesh generata da punti sondati. Quando si utilizza una sonda per la posizione di riferimento sull'asse z, si consiglia di definire una sezione safe_z_home in printer.cfg per la posizione di riferimento verso il centro dell'area di stampa. Per ulteriori informazioni, vedere la bed mesh guide e riferimento del comando . Esempi visivi: rectangular bed, probe_count = 3, 3: x---x---x (max_point) | x---x---x | (min_point) x---x---x round bed, round_probe_count = 5, bed_radius = r: x (0, r) end / x---x---x \\ (-r, 0) x---x---x---x---x (r, 0) \\ x---x---x / x (0, -r) start [bed_mesh] #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5. #mesh_radius: # Defines the radius of the mesh to probe for round beds. Note that # the radius is relative to the coordinate specified by the # mesh_origin option. This parameter must be provided for round beds # and omitted for rectangular beds. #mesh_origin: # Defines the center X, Y coordinate of the mesh for round beds. This # coordinate is relative to the probe's location. It may be useful # to adjust the mesh_origin in an effort to maximize the size of the # mesh radius. Default is 0, 0. This parameter must be omitted for # rectangular beds. #mesh_min: # Defines the minimum X, Y coordinate of the mesh for rectangular # beds. This coordinate is relative to the probe's location. This # will be the first point probed, nearest to the origin. This # parameter must be provided for rectangular beds. #mesh_max: # Defines the maximum X, Y coordinate of the mesh for rectangular # beds. Adheres to the same principle as mesh_min, however this will # be the furthest point probed from the bed's origin. This parameter # must be provided for rectangular beds. #probe_count: 3, 3 # For rectangular beds, this is a comma separate pair of integer # values X, Y defining the number of points to probe along each # axis. A single value is also valid, in which case that value will # be applied to both axes. Default is 3, 3. #round_probe_count: 5 # For round beds, this integer value defines the maximum number of # points to probe along each axis. This value must be an odd number. # Default is 5. #fade_start: 1.0 # The gcode z position in which to start phasing out z-adjustment # when fade is enabled. Default is 1.0. #fade_end: 0.0 # The gcode z position in which phasing out completes. When set to a # value below fade_start, fade is disabled. It should be noted that # fade may add unwanted scaling along the z-axis of a print. If a # user wishes to enable fade, a value of 10.0 is recommended. # Default is 0.0, which disables fade. #fade_target: # The z position in which fade should converge. When this value is # set to a non-zero value it must be within the range of z-values in # the mesh. Users that wish to converge to the z homing position # should set this to 0. Default is the average z value of the mesh. #split_delta_z: .025 # The amount of Z difference (in mm) along a move that will trigger # a split. Default is .025. #move_check_distance: 5.0 # The distance (in mm) along a move to check for split_delta_z. # This is also the minimum length that a move can be split. Default # is 5.0. #mesh_pps: 2, 2 # A comma separated pair of integers X, Y defining the number of # points per segment to interpolate in the mesh along each axis. A # \"segment\" can be defined as the space between each probed point. # The user may enter a single value which will be applied to both # axes. Default is 2, 2. #algorithm: lagrange # The interpolation algorithm to use. May be either \"lagrange\" or # \"bicubic\". This option will not affect 3x3 grids, which are forced # to use lagrange sampling. Default is lagrange. #bicubic_tension: .2 # When using the bicubic algorithm the tension parameter above may # be applied to change the amount of slope interpolated. Larger # numbers will increase the amount of slope, which results in more # curvature in the mesh. Default is .2. #zero_reference_position: # An optional X,Y coordinate that specifies the location on the bed # where Z = 0. When this option is specified the mesh will be offset # so that zero Z adjustment occurs at this location. The default is # no zero reference. #relative_reference_index: # **DEPRECATED, use the \"zero_reference_position\" option** # The legacy option superceded by the \"zero reference position\". # Rather than a coordinate this option takes an integer \"index\" that # refers to the location of one of the generated points. It is recommended # to use the \"zero_reference_position\" instead of this option for new # configurations. The default is no relative reference index. #faulty_region_1_min: #faulty_region_1_max: # Optional points that define a faulty region. See docs/Bed_Mesh.md # for details on faulty regions. Up to 99 faulty regions may be added. # By default no faulty regions are set.","title":"[bed_mesh]"},{"location":"Config_Reference.html#bed_tilt","text":"Compensazione dell'inclinazione del piatto. Si pu\u00f2 definire una sezione di configurazione bed_tilt per abilitare le trasformazioni di movimento che tengono conto di un piatto inclinato. Nota che bed_mesh e bed_tilt sono incompatibili; entrambi non possono essere definiti. Per ulteriori informazioni, vedere riferimento comando . [bed_tilt] #x_adjust: 0 # The amount to add to each move's Z height for each mm on the X # axis. The default is 0. #y_adjust: 0 # The amount to add to each move's Z height for each mm on the Y # axis. The default is 0. #z_adjust: 0 # The amount to add to the Z height when the nozzle is nominally at # 0, 0. The default is 0. # The remaining parameters control a BED_TILT_CALIBRATE extended # g-code command that may be used to calibrate appropriate x and y # adjustment parameters. #points: # A list of X, Y coordinates (one per line; subsequent lines # indented) that should be probed during a BED_TILT_CALIBRATE # command. Specify coordinates of the nozzle and be sure the probe # is above the bed at the given nozzle coordinates. The default is # to not enable the command. #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5.","title":"[bed_tilt]"},{"location":"Config_Reference.html#bed_screws","text":"Strumento per aiutare a regolare le viti di livellamento del letto. Si pu\u00f2 definire una sezione di configurazione [bed_screws] per abilitare un comando g-code BED_SCREWS_ADJUST. Per ulteriori informazioni, vedere la guida al livellamento e il riferimento al comando . [bed_screws] #screw1: # The X, Y coordinate of the first bed leveling screw. This is a # position to command the nozzle to that is directly above the bed # screw (or as close as possible while still being above the bed). # This parameter must be provided. #screw1_name: # An arbitrary name for the given screw. This name is displayed when # the helper script runs. The default is to use a name based upon # the screw XY location. #screw1_fine_adjust: # An X, Y coordinate to command the nozzle to so that one can fine # tune the bed leveling screw. The default is to not perform fine # adjustments on the bed screw. #screw2: #screw2_name: #screw2_fine_adjust: #... # Additional bed leveling screws. At least three screws must be # defined. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # when moving from one screw location to the next. The default is 5. #probe_height: 0 # The height of the probe (in mm) after adjusting for the thermal # expansion of bed and nozzle. The default is zero. #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #probe_speed: 5 # The speed (in mm/s) when moving from a horizontal_move_z position # to a probe_height position. The default is 5.","title":"[bed_screws]"},{"location":"Config_Reference.html#screws_tilt_adjust","text":"Strumento per aiutare a regolare l'inclinazione delle viti del piatto utilizzando la sonda Z. Si pu\u00f2 definire una sezione di configurazione Screws_tilt_adjust per abilitare un comando g-code SCREWS_TILT_CALCULATE. Per ulteriori informazioni, vedere la guida al livellamento e riferimento al comando . [screws_tilt_adjust] #screw1: # The (X, Y) coordinate of the first bed leveling screw. This is a # position to command the nozzle to so that the probe is directly # above the bed screw (or as close as possible while still being # above the bed). This is the base screw used in calculations. This # parameter must be provided. #screw1_name: # An arbitrary name for the given screw. This name is displayed when # the helper script runs. The default is to use a name based upon # the screw XY location. #screw2: #screw2_name: #... # Additional bed leveling screws. At least two screws must be # defined. #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5. #screw_thread: CW-M3 # The type of screw used for bed leveling, M3, M4, or M5, and the # rotation direction of the knob that is used to level the bed. # Accepted values: CW-M3, CCW-M3, CW-M4, CCW-M4, CW-M5, CCW-M5. # Default value is CW-M3 which most printers use. A clockwise # rotation of the knob decreases the gap between the nozzle and the # bed. Conversely, a counter-clockwise rotation increases the gap.","title":"[screws_tilt_adjust]"},{"location":"Config_Reference.html#z_tilt","text":"Regolazione multipla dell'inclinazione dello stepper Z. Questa funzione consente la regolazione indipendente di pi\u00f9 stepper z (vedere la sezione \"stepper_z1\") per regolare l'inclinazione. Se questa sezione \u00e8 presente, diventa disponibile un comando G-Code esteso Z_TILT_ADJUST. [z_tilt] #z_positions: # Un elenco di coordinate X, Y (una per riga; le righe successive # identate) che descrivono la posizione di ciascun \"pivot point\" # del piattotto. Il \"pivot point\" \u00e8 il punto in cui il piatto si attacca # al dato stepper Z. Viene descritto utilizzando le coordinate dell'ugello # (la posizione X, Y dell'ugello se potesse spostarsi direttamente sopra # il punto). La prima voce corrisponde a stepper_z, la seconda a # stepper_z1, la terza a stepper_z2, ecc. # Questo parametro deve essere fornito. #points: # Un elenco di coordinate X, Y (una per riga; righe successive identate) # che devono essere rilevate durante un comando Z_TILT_ADJUST. # Specificare le coordinate dell'ugello e assicurarsi che la sonda sia # sopra il piatto alle coordinate dell'ugello date. # Questo parametro deve essere fornito. #speed: 50 # La velocit\u00e0 (in mm/s) degli spostamenti senza probing durante # la calibrazione. Il valore predefinito \u00e8 50. #horizontal_move_z: 5 # L'altezza (in mm) a cui la testa deve essere comandata per spostarsi # appena prima di avviare un'operazione di probing. # L'impostazione predefinita \u00e8 5. #retries: 0 # Numero di volte per riprovare se i punti rilevati non sono all'interno # della tolleranza. #retry_tolerance: 0 # Se i tentativi sono abilitati, riprovare se i punti sondati pi\u00f9 grande e # pi\u00f9 piccolo differiscono pi\u00f9 di retry_tolerance. Nota che l'unit\u00e0 di # modifica pi\u00f9 piccola qui sarebbe un singolo passaggio. # Tuttavia, se stai sondando pi\u00f9 punti rispetto agli stepper, # probabilmente avrai un valore minimo fisso per l'intervallo di punti # sondati che puoi apprendere osservando l'output del comando.","title":"[z_tilt]"},{"location":"Config_Reference.html#quad_gantry_level","text":"Livellamento del gantly mediante 4 motori Z controllati in modo indipendente. Corregge gli effetti della parabola iperbolica (patatine fritte) sul portale mobile che \u00e8 pi\u00f9 flessibile. ATTENZIONE: l'utilizzo su un letto mobile pu\u00f2 portare a risultati indesiderati. Se questa sezione \u00e8 presente, diventa disponibile un comando G-Code esteso QUAD_GANTRY_LEVEL. Questa routine presuppone la seguente configurazione del motore Z: ---------------- |Z1 Z2| | --------- | | | | | | | | | | x-------- | |Z Z3| ---------------- Dove x \u00e8 il punto 0, 0 sul piatto [quad_gantry_level] #gantry_corners: # A newline separated list of X, Y coordinates describing the two # opposing corners of the gantry. The first entry corresponds to Z, # the second to Z2. This parameter must be provided. #points: # A newline separated list of four X, Y points that should be probed # during a QUAD_GANTRY_LEVEL command. Order of the locations is # important, and should correspond to Z, Z1, Z2, and Z3 location in # order. This parameter must be provided. For maximum accuracy, # ensure your probe offsets are configured. #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5. #max_adjust: 4 # Safety limit if an adjustment greater than this value is requested # quad_gantry_level will abort. #retries: 0 # Number of times to retry if the probed points aren't within # tolerance. #retry_tolerance: 0 # If retries are enabled then retry if largest and smallest probed # points differ more than retry_tolerance.","title":"[quad_gantry_level]"},{"location":"Config_Reference.html#skew_correction","text":"Correzione dell'inclinazione della stampante. \u00c8 possibile utilizzare il software per correggere l'inclinazione della stampante su 3 piani, xy, xz, yz. Questo viene fatto stampando un modello di calibrazione lungo un piano e misurando tre lunghezze. A causa della natura della correzione dell'inclinazione, queste lunghezze vengono impostate tramite gcode. Per i dettagli, vedere Correzione inclinazione e Command Reference . [skew_correction]","title":"[skew_correction]"},{"location":"Config_Reference.html#z_thermal_adjust","text":"Regolazione della posizione Z della testa di stampa in funzione della temperatura. Compensare il movimento verticale della testina utensile causato dall'espansione termica del telaio della stampante in tempo reale utilizzando un sensore di temperatura (tipicamente accoppiato a una sezione verticale del telaio). Vedi anche: comandi g-code estesi . [z_thermal_adjust] #temp_coeff: # Il coefficiente di dilatazione della temperatura, in mm/degC. Ad esempio, un # temp_coeff di 0,01 mm/degC sposter\u00e0 l'asse Z verso il basso di 0,01 mm per ogni # grado Celsius di auemnto del sensore di temperatura . Il valore predefinito \u00e8 # 0,0 mm/degC, che non applica alcuna regolazione. #smooth_time: # Finestra di smoothing applicata al sensore di temperatura, in secondi. Pu\u00f2 # ridurre il rumore del motore da piccole correzioni eccessive in risposta al # rumore del sensore. Il valore predefinito \u00e8 2,0 secondi. #z_adjust_off_above: # Disattiva le regolazioni al di sopra di questa altezza Z [mm]. L'ultima correzione # calcolata rimarr\u00e0 applicata finch\u00e9 la testa utensile non si sposter\u00e0 nuovamente # al di sotto dell'altezza Z specificata. # Il valore predefinito \u00e8 99999999,0 mm (sempre attivo). #max_z_adjustment: # Massima regolazione assoluta applicabile all'asse Z [mm]. Il valore predefinito # \u00e8 99999999,0 mm (illimitato). #sensor_type: #sensor_pin: #min_temp: #max_temp: # Configurazione del sensore di temperatura. Vedere la sezione \"extruder\" per # la definizione dei parametri di cui sopra. #gcode_id: # Vedere la sezione \"heater_generic\" per la definizione di questo parametro.","title":"[z_thermal_adjust]"},{"location":"Config_Reference.html#homing-personalizzato","text":"","title":"Homing personalizzato"},{"location":"Config_Reference.html#safe_z_home","text":"Homing Z sicuro. Si pu\u00f2 utilizzare questo meccanismo per posizionare l'asse Z su una specifica coordinata X, Y. Ci\u00f2 \u00e8 utile se la testa portautensili, ad esempio, deve spostarsi al centro del letto prima che Z possa essere riposizionato. [safe_z_home] home_xy_position: # Una coordinata X, Y (ad es. 100, 100) dove deve essere eseguita # homing Z. Questo parametro deve essere fornito. #speed: 50.0 # Velocit\u00e0 alla quale la testa di stampa viene spostata sulla # coordinata Z sicura. Il valore predefinito \u00e8 50 mm/s #z_hop: # Distanza (in mm) per sollevare l'asse Z prima dell'homing. # Questo si applica a qualsiasi comando di homing, anche se non # si trova sull'asse Z. Se l'asse Z \u00e8 gi\u00e0 azzerato e la posizione Z # corrente \u00e8 inferiore a z_hop, questo sollever\u00e0 la testa a un'altezza # di z_hop. Se l'asse Z non \u00e8 gi\u00e0 azzerato la testina viene sollevata # di z_hop. L'impostazione predefinita \u00e8 di non implementare Z hop. #z_hop_speed: 15.0 # Velocit\u00e0 (in mm/s) alla quale l'asse Z viene sollevato prima # del homing. Il valore predefinito \u00e8 15 mm/s. #move_to_previous: False # Quando \u00e8 impostato su True, gli assi X e Y vengono ripristinati alle # posizioni precedenti dopo l'homing dell'asse Z. # L'impostazione predefinita \u00e8 False.","title":"[safe_z_home]"},{"location":"Config_Reference.html#homing_override","text":"Homing Override. Si pu\u00f2 utilizzare questo meccanismo per eseguire una serie di comandi g-code al posto di un G28 che si trova nel normale input di g-code. Questo pu\u00f2 essere utile su stampanti che richiedono una procedura specifica per l'home della macchina. [homing_override] gcode: # Un elenco di comandi G-Code da eseguire al posto dei comandi # G28 trovati nel normale input di G-Code. # Vedi docs/Command_Templates.md per il formato G-Code. # Se un G28 \u00e8 contenuto in questo elenco di comandi, invocher\u00e0 # la normale procedura di homing per la stampante. I comandi # qui elencati devono eseguire l'home di tutti gli assi. # Questo parametro deve essere fornito. #axes: xyz # Gli assi da sovrascrivere. Ad esempio, se questo \u00e8 impostato # su \"z\", lo script di override verr\u00e0 eseguito solo quando l'asse z # \u00e8 azzerato (ad esempio, tramite un comando \"G28\" o \"G28 Z0\"). # Nota, lo script di sovrascrittura dovrebbe comunque ospitare # tutti gli assi. L'impostazione predefinita \u00e8 \"xyz\" che fa s\u00ec che lo # script di override venga eseguito al posto di tutti i comandi G28. #set_position_x: #set_position_y: #set_position_z: # Se specificato, la stampante presumer\u00e0 che l'asse si trovi # nella posizione specificata prima di eseguire i comandi g-code # precedenti. L'impostazione di questa opzione disabilita i # controlli di riferimento per quell'asse. Questo pu\u00f2 essere utile # se la testa deve muoversi prima di invocare il normale # meccanismo G28 per un asse. L'impostazione predefinita \u00e8 # di non forzare una posizione per un asse.","title":"[homing_override]"},{"location":"Config_Reference.html#endstop_phase","text":"Finecorsa regolati in fase stepper. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso \"endstop_phase\" seguito dal nome della corrispondente sezione di configurazione dello stepper (ad esempio, \"[endstop_phase stepper_z]\"). Questa funzione pu\u00f2 migliorare la precisione degli interruttori di fine corsa. Aggiungi una semplice dichiarazione \"[endstop_phase]\" per abilitare il comando ENDSTOP_PHASE_CALIBRATE. Per ulteriori informazioni, vedere la endstop phases guide e command reference . [endstop_phase stepper_z] #endstop_accuracy: # Imposta la precisione prevista (in mm) del finecorsa. Questo rappresenta # la distanza massima di errore che il finecorsa pu\u00f2 attivare (ad es. se un # finecorsa pu\u00f2 occasionalmente attivarsi 100um in anticipo o fino a 100um in ritardo # quindi impostalo su 0,200 per 200 um). L'impostazione predefinita \u00e8 # 4*distanza_rotazione/passi_completi_per_rotazione. #trigger_phase: # Questo specifica la fase del driver del motore passo-passo da aspettarsi # quando si raggiunge il finecorsa. \u00c8 composto da due numeri separati # da un '/' - la fase e il numero totale di # fasi (ad es. \"7/64\"). Impostare questo valore solo se si \u00e8 sicuri che il # driver del motore passo-passo viene ripristinato ogni volta che viene ripristinato l'mcu. Se questo # non \u00e8 impostato, la prima fase verr\u00e0 rilevata al primo home # e quella fase sar\u00e0 utilizzata su tutte le abitazioni successive. #endstop_align_zero: False # Se true, la posizione_endstop dell'asse sar\u00e0 effettivamente # modificato in modo che la posizione zero dell'asse avvenga a passo pieno # sul motore. (Se utilizzato sull'asse Z e la stampa # l'altezza del livello \u00e8 un multiplo di una distanza di un passo intero, allora ogni # layer si eseguir\u00e0 in un step completo.) L'impostazione predefinita \u00e8 False.","title":"[endstop_phase]"},{"location":"Config_Reference.html#macro-ed-eventi-g-code","text":"","title":"Macro ed eventi G-Code"},{"location":"Config_Reference.html#gcode_macro","text":"Macro G-Code (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"gcode_macro\"). Per ulteriori informazioni, consulta la Guida ai modelli di comando . [gcode_macro my_cmd] #gcode: # Un elenco di comandi G-Code da eseguire al posto di \"my_cmd\". # Vedi docs/Command_Templates.md per il formato G-Code. # Questo parametro deve essere fornito. #variable_: # Si pu\u00f2 specificare un numero qualsiasi di opzioni con un prefisso # \"variable_\". Al nome della variabile data verr\u00e0 assegnato il valore dato # (analizzato come un valore letterale Python) e sar\u00e0 disponibile durante # l'espansione della macro. Ad esempio, una configurazione con # \"variable_fan_speed = 75\" potrebbe avere comandi gcode contenenti # \"M106 S{ fan_speed * 255 }\". Le variabili possono essere modificate in # fase di esecuzione utilizzando il comando SET_GCODE_VARIABLE # (consultare docs/Command_Templates.md per i dettagli). # I nomi delle variabili potrebbero non utilizzare caratteri maiuscoli. #rename_existing: # Questa opzione far\u00e0 s\u00ec che la macro ignori un comando G-Code # esistente e fornisca la definizione precedente del comando tramite # il nome fornito qui. Questo pu\u00f2 essere usato per sovrascrivere i # comandi G-Code integrati. Prestare attenzione quando si ignorano # i comandi poich\u00e9 possono causare risultati complessi e imprevisti. # L'impostazione predefinita \u00e8 di non sovrascrivere un comando # G-Code esistente. #description: G-Code macro # Ci\u00f2 aggiunger\u00e0 una breve descrizione utilizzata al comando HELP # o durante l'utilizzo della funzione di completamento automatico. # Predefinito \"G-Code macro\"","title":"[gcode_macro]"},{"location":"Config_Reference.html#delayed_gcode","text":"Esegui un gcode con un ritardo impostato. Per ulteriori informazioni, consulta la Guida template dei comandi e riferimento al comando . [delayed_gcode my_delayed_gcode] gcode: # A list of G-Code commands to execute when the delay duration has # elapsed. G-Code templates are supported. This parameter must be # provided. #initial_duration: 0.0 # The duration of the initial delay (in seconds). If set to a # non-zero value the delayed_gcode will execute the specified number # of seconds after the printer enters the \"ready\" state. This can be # useful for initialization procedures or a repeating delayed_gcode. # If set to 0 the delayed_gcode will not execute on startup. # Default is 0.","title":"[delayed_gcode]"},{"location":"Config_Reference.html#save_variables","text":"Supporta il salvataggio delle variabili su disco in modo che vengano mantenute durante i riavvii. Per ulteriori informazioni, vedere template dei comandi e G-Code reference . [save_variables] filename: # Richiesto: fornire un nome file che verrebbe utilizzato per salvare # le variabili su disco, ad es. ~/variables.cfg","title":"[save_variables]"},{"location":"Config_Reference.html#idle_timeout","text":"Timeout di inattivit\u00e0. Viene automaticamente abilitato un timeout di inattivit\u00e0: aggiungi una sezione di configurazione di idle_timeout esplicita per modificare le impostazioni predefinite. [idle_timeout] #gcode: # Un elenco di comandi G-Code da eseguire in un timeout di # inattivit\u00e0. Vedi docs/Command Templates.md per il formato # G-Code. L'impostazione predefinita \u00e8 # eseguire \"TURN_OFF HEATERS\" e \"M84\". #timeout: 600 # Tempo di inattivit\u00e0 (in secondi) da attendere prima di eseguire # i comandi G-Code sopra. Il valore predefinito \u00e8 600 secondi.","title":"[idle_timeout]"},{"location":"Config_Reference.html#funzionalita-opzionali-g-code","text":"","title":"Funzionalit\u00e0 opzionali G-Code"},{"location":"Config_Reference.html#virtual_sdcard","text":"Una scheda SD virtuale pu\u00f2 essere utile se la macchina host non \u00e8 abbastanza veloce per eseguire bene OctoPrint. Consente al software host Klipper di stampare direttamente i file gcode archiviati in una directory sull'host utilizzando i comandi G-Code standard (ad esempio, M24). [virtual_sdcard] path: # Il percorso della directory locale sulla macchina host per cercare # i file di Gcode. Questa \u00e8 una directory di sola lettura (le scritture # di file sdcard non sono supportate). Si pu\u00f2 indicare questo alla # directory di caricamento di OctoPrint # (generalmente ~/.octoprint/uploads/ ). # Questo parametro deve essere fornito. #on_error_gcode: # Un elenco di comandi G-Code da eseguire quando viene segnalato # un errore.","title":"[virtual_sdcard]"},{"location":"Config_Reference.html#sdcard_loop","text":"Alcune stampanti con funzionalit\u00e0 di pulizia del piatto, come un espulsore di parti o una stampante a nastro, possono trovare impiego nelle sezioni di loop del file sdcard. (Ad esempio, per stampare la stessa parte pi\u00f9 e pi\u00f9 volte, o ripetere la sezione a di una parte per una catena o un altro motivo ripetuto). Consulta il command reference per i comandi supportati. Vedere il file sample-macros.cfg per una macro M808 G-Code compatibile con Marlin. [sdcard_loop]","title":"[sdcard_loop]"},{"location":"Config_Reference.html#force_move","text":"Supporta lo spostamento manuale dei motori passo-passo per scopi diagnostici. Nota, l'utilizzo di questa funzione potrebbe mettere la stampante in uno stato non valido - vedere il command reference per dettagli importanti. [force_move] #enable_force_move: False # Impostare su True per abilitare FORCE_MOVE e SET_KINEMATIC_POSITION # i comandi G-Code estesi. L'impostazione predefinita \u00e8 False.","title":"[force_move]"},{"location":"Config_Reference.html#pause_resume","text":"Funzionalit\u00e0 di Pause/Resume con supporto di acquisizione e ripristino della posizione. Per ulteriori informazioni, vedere riferimento comando . [pause_resume] #recover_velocity: 50. # Quando si abilita pause_resume, la velocit\u00e0 con cui tornare alla # posizione catturata (in mm/s). Il valore predefinito \u00e8 50,0 mm/s.","title":"[pause_resume]"},{"location":"Config_Reference.html#firmware_retraction","text":"Retrazione del filamento del firmware. Ci\u00f2 abilita i comandi GCODE G10 (ritiro) e G11 (non ritirati) emessi da molti slicer. I parametri seguenti forniscono le impostazioni predefinite di avvio, sebbene i valori possano essere regolati tramite il [comando] SET_RETRACTION (G-Codes.md#firmware_retraction)), consentendo l'impostazione e l'ottimizzazione del filamento a runtime. [firmware_retraction] #retract_length: 0 # La lunghezza del filamento (in mm) da ritrarre quando G10 # \u00e8 attivato e da ritrarre quando G11 \u00e8 attivato (ma vedere # unretract_extra_length di seguito). I# l valore predefinito \u00e8 0 mm. #retract_speed: 20 # La velocit\u00e0 di retrazione, in mm/s. # Il valore predefinito \u00e8 20 mm/s. #unretract_extra_length: 0 # La lunghezza (in mm) del filamento *aggiuntivo* da # sommare quando non si ritrae. #unretract_speed: 10 # La velocit\u00e0 di srotolamento, in mm/s. # Il valore predefinito \u00e8 10 mm/s.","title":"[firmware_retraction]"},{"location":"Config_Reference.html#gcode_arcs","text":"Supporto per i comandi Gcode arc (G2/G3). [gcode_arcs] #resolution: 1.0 # Un arco sar\u00e0 diviso in segmenti. La lunghezza di ciascun segmento # sar\u00e0 uguale alla risoluzione in mm impostata sopra. Valori pi\u00f9 bassi # produrranno un arco pi\u00f9 fine, ma anche pi\u00f9 lavoro per la tua macchina. # Archi pi\u00f9 piccoli del valore configurato diventer\u00e0 linee rette. # L'impostazione predefinita \u00e8 # 1mm.","title":"[gcode_arcs]"},{"location":"Config_Reference.html#respond","text":"Abilita i comandi estesi \"M118\" e \"RESPOND\" commands . [respond] #default_type: echo # Imposta il prefisso predefinito dell'output \"M118\" e \"RESPOND\" su uno dei seguenti: # echo: \"echo: \" (Questa \u00e8 l'impostazione predefinita) # command: \"// \" # error: \"!! \" #default_prefix: echo: # Imposta direttamente il prefisso predefinito. Se presente # questo valore sovrascriver\u00e0 il \"default_type\".","title":"[respond]"},{"location":"Config_Reference.html#exclude_object","text":"Abilita il supporto per escludere o cancellare singoli oggetti durante il processo di stampa. Per ulteriori informazioni, vedere la guida escludi oggetti e riferimento ai comandi . Vedere il file sample-macros.cfg per una macro G-Code M486 compatibile con Marlin/RepRapFirmware. [exclude_object]","title":"[exclude_object]"},{"location":"Config_Reference.html#compensazione-della-risonanza","text":"","title":"Compensazione della risonanza"},{"location":"Config_Reference.html#input_shaper","text":"Abilita compensazione della risonanza . Vedere anche il command reference . [input_shaper] #shaper_freq_x: 0 # Una frequenza (in Hz) dell'input shaper per l'asse X. Questa \u00e8 # solitamente una frequenza di risonanza dell'asse X che l'input # shaper dovrebbe sopprimere. Per shaper pi\u00f9 complessi, come # shaper di input EI a 2 e 3 gobbe, questo parametro pu\u00f2 essere # impostato in base a diverse considerazioni. # Il valore predefinito \u00e8 0, che disabilita la modellatura dell'input # per l'asse X. #shaper_freq_y: 0 # Una frequenza (in Hz) dell'input shaper per l'asse Y. Questa \u00e8 # solitamente una frequenza di risonanza dell'asse Y che l'input # shaper dovrebbe sopprimere. Per shaper pi\u00f9 complessi, come # shaper di input EI a 2 e 3 gobbe, questo parametro pu\u00f2 essere # impostato in base a diverse considerazioni. Il valore predefinito # \u00e8 0, che disabilita la modellatura dell'input per l'asse Y. #shaper_type: mzv # Un tipo di input shaper da utilizzare per entrambi gli assi X e Y. # Gli shaper supportati sono zv, mzv, zvd, ei, 2hump_ei e # 3hump_ei. L'impostazione predefinita \u00e8 mzv input shaper. #shaper_type_x: #shaper_type_y: # Se shaper_type non \u00e8 impostato, questi due parametri possono # essere utilizzati per configurare diversi shaper di input per gli # assi X e Y. Sono supportati gli stessi valori del parametro # shaper_type. #damping_ratio_x: 0.1 #damping_ratio_y: 0.1 # Rapporti di smorzamento delle vibrazioni degli assi X e Y # utilizzati dagli shaper di input per migliorare la soppressione # delle vibrazioni. Il valore predefinito \u00e8 0,1, un buon valore per la # maggior parte delle stampanti. Nella maggior parte dei casi # questo parametro non richiede ottimizzazione e # non deve essere modificato.","title":"[input_shaper]"},{"location":"Config_Reference.html#adxl345","text":"Supporto per accelerometri ADXL345. Questo supporto consente di interrogare le misurazioni dell'accelerometro dal sensore. Ci\u00f2 abilita un comando ACCELEROMETER_MEASURE (consultare G-Codes per ulteriori informazioni). Il nome del chip predefinito \u00e8 \"predefinito\", ma \u00e8 possibile specificare un nome esplicito (ad esempio, [adxl345 my_chip_name]). [adxl345] cs_pin: # The SPI enable pin for the sensor. This parameter must be provided. #spi_speed: 5000000 # The SPI speed (in hz) to use when communicating with the chip. # The default is 5000000. #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #axes_map: x, y, z # The accelerometer axis for each of the printer's X, Y, and Z axes. # This may be useful if the accelerometer is mounted in an # orientation that does not match the printer orientation. For # example, one could set this to \"y, x, z\" to swap the X and Y axes. # It is also possible to negate an axis if the accelerometer # direction is reversed (eg, \"x, z, -y\"). The default is \"x, y, z\". #rate: 3200 # Output data rate for ADXL345. ADXL345 supports the following data # rates: 3200, 1600, 800, 400, 200, 100, 50, and 25. Note that it is # not recommended to change this rate from the default 3200, and # rates below 800 will considerably affect the quality of resonance # measurements.","title":"[adxl345]"},{"location":"Config_Reference.html#lis2dw","text":"Support for LIS2DW accelerometers. [lis2dw] cs_pin: # The SPI enable pin for the sensor. This parameter must be provided. #spi_speed: 5000000 # The SPI speed (in hz) to use when communicating with the chip. # The default is 5000000. #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #axes_map: x, y, z # See the \"adxl345\" section for information on this parameter.","title":"[lis2dw]"},{"location":"Config_Reference.html#mpu9250","text":"Supporto per accelerometri MPU-9250, MPU-9255, MPU-6515, MPU-6050 e MPU-6500 (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"mpu9250\"). [mpu9250 my_accelerometer] #i2c_address: # Default is 104 (0x68). If AD0 is high, it would be 0x69 instead. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: 400000 # See the \"common I2C settings\" section for a description of the # above parameters. The default \"i2c_speed\" is 400000. #axes_map: x, y, z # See the \"adxl345\" section for information on this parameter.","title":"[mpu9250]"},{"location":"Config_Reference.html#resonance_tester","text":"Supporto per test di risonanza e calibrazione automatica del input shaper. Per utilizzare la maggior parte delle funzionalit\u00e0 di questo modulo, devono essere installate dipendenze software aggiuntive; fare riferimento a Measuring Resonances e al command reference per ulteriori informazioni. Per ulteriori informazioni sul parametro max_smoothing e sul suo utilizzo, vedere la sezione Max smoothing della guida alla misurazione delle risonanze. [resonance_tester] #probe_points: # Un elenco di coordinate X, Y, Z di punti (un punto per linea) in cui # testare le risonanze. Almeno un punto \u00e8 richiesto. Assicurati che tutti # i punti con un margine di sicurezza nel piano XY (~ pochi centimetri) # siano raggiungibili dalla testa di stampa. #accel_chip: # Un nome del chip dell'accelerometro da utilizzare per le misurazioni. # Se il chip adxl345 \u00e8 stato definito senza un nome esplicito, questo # parametro pu\u00f2 semplicemente fare riferimento ad esso come # \"accel_chip: adxl345\", altrimenti deve essere fornito anche un nome # esplicito, ad es. \"accel_chip: adxl345 mio_chip_nome\". \u00c8 necessario # impostare questo o i due parametri successivi. #accel_chip_x: #accel_chip_y: # Nomi dei chip dell'accelerometro da utilizzare per le misurazioni per # ciascuno degli assi. Pu\u00f2 essere utile, ad esempio, su una stampante con # piatto, se due accelerometri separati sono montati sul piatto (per l'asse Y) # e sulla testa di stampa (per l'asse X). Questi parametri hanno lo stesso # formato del parametro 'accel_chip'. # \u00c8 necessario fornire solo 'accel_chip' o questi due parametri. #max_smoothing: # Maximum input shaper smoothing to allow for each axis during shaper # auto-calibration (with 'SHAPER_CALIBRATE' command). By default no # maximum smoothing is specified. Refer to Measuring_Resonances guide # for more details on using this feature. #min_freq: 5 # Frequenza minima per testare le risonanze. L'impostazione \u00e8 5 Hz. #max_freq: 133.33 # Frequenza massima per testare le risonanze. L'impostazione \u00e8 133,33 Hz. #accel_per_hz: 75 # Questo parametro viene utilizzato per determinare quale accelerazione # utilizzare per testare una frequenza specifica: accel = accel_per_hz * freq. # Maggiore \u00e8 il valore, maggiore \u00e8 l'energia delle oscillazioni. Pu\u00f2 essere # impostato su un valore inferiore al valore predefinito se le risonanze # diventano troppo forti sulla stampante. Tuttavia, valori pi\u00f9 bassi rendono # le misurazioni delle risonanze ad alta frequenza meno precise. # Il valore predefinito \u00e8 75 (mm/sec). #hz_per_sec: 1 # Determina la velocit\u00e0 del test. Quando si testano tutte le frequenze # nell'intervallo [freq_min, freq_max], ogni secondo la frequenza aumenta # di hz_per_sec. Valori piccoli rallentano il test e valori grandi diminuiscono # la precisione del test. Il valore predefinito \u00e8 1,0 (Hz/sec == sec^-2).","title":"[resonance_tester]"},{"location":"Config_Reference.html#helper-per-i-file-di-configurazione","text":"","title":"Helper per i file di configurazione"},{"location":"Config_Reference.html#board_pins","text":"Alias pin board (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"board_pins\"). Usalo per definire gli alias per i pin su un microcontrollore. [board_pins my_aliases] mcu: mcu # A comma separated list of micro-controllers that may use the # aliases. The default is to apply the aliases to the main \"mcu\". aliases: aliases_: # A comma separated list of \"name=value\" aliases to create for the # given micro-controller. For example, \"EXP1_1=PE6\" would create an # \"EXP1_1\" alias for the \"PE6\" pin. However, if \"value\" is enclosed # in \"<>\" then \"name\" is created as a reserved pin (for example, # \"EXP1_9=\" would reserve \"EXP1_9\"). Any number of options # starting with \"aliases_\" may be specified.","title":"[board_pins]"},{"location":"Config_Reference.html#include","text":"Supporto per includere i file. Uno pu\u00f2 includere un file di configurazione aggiuntivo dal file di configurazione della stampante principale. Possono essere utilizzati anche caratteri jolly (ad es. \"configs/*.cfg\"). [include my_other_config.cfg]","title":"[include]"},{"location":"Config_Reference.html#duplicate_pin_override","text":"Questo strumento consente di definire pi\u00f9 volte un singolo pin del microcontrollore in un file di configurazione senza il normale controllo degli errori. Questo \u00e8 inteso per scopi diagnostici e di debug. Questa sezione non \u00e8 necessaria laddove Klipper supporta l'utilizzo dello stesso pin pi\u00f9 volte e l'utilizzo di questa sostituzione pu\u00f2 causare risultati confusi e imprevisti. [duplicate_pin_override] pins: # Un elenco di pin separato da virgole che possono essere utilizzati pi\u00f9 volte in # un file di configurazione senza normali controlli degli errori. Questo parametro deve essere # fornito.","title":"[duplicate_pin_override]"},{"location":"Config_Reference.html#hardware-per-probing-del-piatto","text":"","title":"Hardware per probing del piatto"},{"location":"Config_Reference.html#probe","text":"Sonda di altezza Z. Si pu\u00f2 definire questa sezione per abilitare l'hardware di rilevamento dell'altezza Z. Quando questa sezione \u00e8 abilitata, i comandi estesi PROBE e QUERY_PROBE comandi g-code diventano disponibili. Inoltre, vedere la Guida alla calibrazione della sonda . La sezione probe crea anche un pin virtuale \"probe:z_virtual_endstop\". Si pu\u00f2 impostare stepper_z endstop_pin su questo pin virtuale su stampanti in stile cartesiano che utilizzano la sonda al posto di un endstop z. Se si utilizza \"probe:z_virtual_endstop\", non definire un position_endstop nella sezione di configurazione stepper_z. [probe] pin: # Pin di rilevamento della sonda. Se il pin si trova su un # microcontrollore diverso rispetto agli stepper Z, abilita # \"homing multi-mcu\". Questo parametro deve essere fornito. #deactivate_on_each_sample: True # Questo determina se Klipper deve eseguire la disattivazione # gcode tra ogni tentativo di esplorazione durante l'esecuzione di # una sequenza di probe multiple. L'impostazione predefinita \u00e8 True. #x_offset: 0.0 # La distanza (in mm) tra la sonda e l'ugello lungo l'asse x. # Il valore predefinito \u00e8 0. #y_offset: 0.0 # La distanza (in mm) tra la sonda e l'ugello lungo l'asse y. # Il valore predefinito \u00e8 0. z_offset: # La distanza (in mm) tra il piatto e l'ugello quando la sonda si attiva. # Questo parametro deve essere fornito. #speed: 5.0 # Velocit\u00e0 (in mm/s) dell'asse Z durante probing. # Il valore predefinito \u00e8 5 mm/s. #samples: 1 # Il numero di volte in cui sondare ciascun punto. I valori z sondati # verranno mediati. L'impostazione predefinita \u00e8 sondare 1 volta. #sample_retract_dist: 2.0 # La distanza (in mm) per sollevare la testa di stampa tra ciascun # campione (se si esegue il campionamento pi\u00f9 di una volta). # Il valore predefinito \u00e8 2 mm. #lift_speed: # Velocit\u00e0 (in mm/s) dell'asse Z durante il sollevamento della sonda # tra i campioni. L'impostazione predefinita prevede l'utilizzo dello # stesso valore del parametro 'speed'. #samples_result: average # Il metodo di calcolo durante il campionamento pi\u00f9 di una volta: # \"median\" o \"average\". L'impostazione predefinita \u00e8 average. #samples_tolerance: 0.100 # La distanza Z massima (in mm) che un campione pu\u00f2 differire da # altri campioni. Se questa tolleranza viene superata, viene segnalato # un errore o il tentativo viene riavviato # (vedere samples_tolerance_retries). Il valore predefinito \u00e8 0,100 mm. #samples_tolerance_retries: 0 # Il numero di tentativi per riprovare se viene trovato un campione che # supera samples_tolerance. In un nuovo tentativo, tutti i campioni # correnti vengono eliminati e il tentativo di sonda viene riavviato. # Se non si ottiene un insieme valido di campioni nel numero di tentativi # specificato, viene segnalato un errore. Il valore predefinito \u00e8 zero che # causa la segnalazione di un errore sul primo campione che supera # samples_tolerance. #activate_gcode: # Un elenco di comandi G-Code da eseguire prima di ogni tentativo di # esplorazione. Vedi docs/Command_Templates.md per il formato # G-Code. Questo pu\u00f2 essere utile se la sonda deve essere attivata in # qualche modo. Non impartire qui alcun comando che sposti la testa # di stampa (ad es. G1). L'impostazione predefinita \u00e8 di non eseguire # alcun comando G-Code speciale all'attivazione. #deactivate_gcode: # Un elenco di comandi G-Code da eseguire dopo il completamento di # ogni tentativo di esplorazione. Vedi docs/Command_Templates.md # per il formato G-Code. Non impartire qui alcun comando che sposti # la testina. L'impostazione predefinita \u00e8 di non eseguire alcun # comando G-Code speciale alla disattivazione.","title":"[probe]"},{"location":"Config_Reference.html#bltouch","text":"Sonda BLTouch. Si pu\u00f2 definire questa sezione (anzich\u00e9 una sezione sonda) per abilitare una sonda BLTouch. Per ulteriori informazioni, vedere BL-Touch guide e command reference .. Viene anche creato un pin virtuale \"probe:z_virtual_endstop\" (consultare la sezione \"probe\" per i dettagli). [bltouch] sensor_pin: # Pin connected to the BLTouch sensor pin. Most BLTouch devices # require a pullup on the sensor pin (prefix the pin name with \"^\"). # This parameter must be provided. control_pin: # Pin connected to the BLTouch control pin. This parameter must be # provided. #pin_move_time: 0.680 # The amount of time (in seconds) to wait for the BLTouch pin to # move up or down. The default is 0.680 seconds. #stow_on_each_sample: True # This determines if Klipper should command the pin to move up # between each probe attempt when performing a multiple probe # sequence. Read the directions in docs/BLTouch.md before setting # this to False. The default is True. #probe_with_touch_mode: False # If this is set to True then Klipper will probe with the device in # \"touch_mode\". The default is False (probing in \"pin_down\" mode). #pin_up_reports_not_triggered: True # Set if the BLTouch consistently reports the probe in a \"not # triggered\" state after a successful \"pin_up\" command. This should # be True for all genuine BLTouch devices. Read the directions in # docs/BLTouch.md before setting this to False. The default is True. #pin_up_touch_mode_reports_triggered: True # Set if the BLTouch consistently reports a \"triggered\" state after # the commands \"pin_up\" followed by \"touch_mode\". This should be # True for all genuine BLTouch devices. Read the directions in # docs/BLTouch.md before setting this to False. The default is True. #set_output_mode: # Request a specific sensor pin output mode on the BLTouch V3.0 (and # later). This setting should not be used on other types of probes. # Set to \"5V\" to request a sensor pin output of 5 Volts (only use if # the controller board needs 5V mode and is 5V tolerant on its input # signal line). Set to \"OD\" to request the sensor pin output use # open drain mode. The default is to not request an output mode. #x_offset: #y_offset: #z_offset: #speed: #lift_speed: #samples: #sample_retract_dist: #samples_result: #samples_tolerance: #samples_tolerance_retries: # See the \"probe\" section for information on these parameters.","title":"[bltouch]"},{"location":"Config_Reference.html#smart_effector","text":"Lo \"Smart Effector\" di Duet3d implementa una sonda Z utilizzando un sensore di forza. Si pu\u00f2 definire questa sezione invece di [probe] per abilitare le funzioni specifiche di Smart Effector. Ci\u00f2 consente anche a comandi di runtime di regolare i parametri di Smart Effector in fase di esecuzione. [smart_effector] pin: # Pin collegato al pin di uscita della sonda Z Smart Effector (pin 5). Si noti # che la resistenza di pullup sulla scheda generalmente non \u00e8 richiesta. # Tuttavia, se il pin di uscita \u00e8 collegato al pin della scheda con un resistore # di pullup, tale resistore deve essere di valore elevato (ad es. 10K Ohm o pi\u00f9). # Alcune schede hanno un resistore di pullup di basso valore sull'ingresso # della sonda Z, che probabilmente far\u00e0 risultare in uno stato di sonda sempre # attivato. In questo caso, collegare lo Smart Effector a un pin diverso sulla # scheda. Questo parametro \u00e8 obbligatorio. #control_pin: # Pin collegato al pin di ingresso di controllo Smart Effector (pin 7). Se fornito, # diventano disponibili i comandi di programmazione della sensibilit\u00e0 # di Smart Effector. #probe_accel: # Se impostato, limita l'accelerazione dei movimenti di tastatura (in mm/sec^2). # Un'improvvisa grande accelerazione all'inizio del movimento di esplorazione # pu\u00f2 causare l'attivazione spuria della sonda, specialmente se l'hotend \u00e8 pesante. # Per evitarlo, potrebbe essere necessario ridurre l'accelerazione dei movimenti # di tastatura tramite questo parametro. #recovery_time: 0.4 # Un ritardo tra i movimenti di spostamento e tastatura in secondi. Un # movimento veloce prima della tastatura pu\u00f2 causare l'attivazione spuria della # sonda. Ci\u00f2 pu\u00f2 causare errori \"Sonda attivata prima del movimento\" se non # \u00e8 impostato alcun ritardo. Il valore 0 disabilita il ritardo di ripristino. # Il valore predefinito \u00e8 0.4. #x_offset: #y_offset: # Dovrebbe essere lasciato non impostato (o impostato su 0). z_offset: # Altezza di attivazione della sonda. Inizia con -0.1 (mm) e regola in seguito # usando il comando `PROBE_CALIBRATE`. Questo parametro deve essere fornito. #speed: # Velocit\u00e0 (in mm/s) dell'asse Z durante la tastatura. Si consiglia di iniziare con la # velocit\u00e0 di tastatura di 20 mm/s e di regolarla secondo necessit\u00e0 per migliorare la # precisione e la ripetibilit\u00e0 dell'attivazione della sonda. #samples: #sample_retract_dist: #samples_result: #samples_tolerance: #samples_tolerance_retries: #activate_gcode: #deactivate_gcode: #deactivate_on_each_sample: # Vedere la sezione \"probe\" per ulteriori informazioni sui parametri di cui sopra.","title":"[smart_effector]"},{"location":"Config_Reference.html#axis_twist_compensation","text":"Uno strumento per compensare letture imprecise della sonda dovute alla torsione nel portale X. Consultare la Guida alla compensazione della torsione dell'asse per informazioni pi\u00f9 dettagliate su sintomi, configurazione e impostazione. [axis_twist_compensation] #speed: 50 # The speed (in mm/s) of non-probing moves during the calibration. # The default is 50. #horizontal_move_z: 5 # The height (in mm) that the head should be commanded to move to # just prior to starting a probe operation. The default is 5. calibrate_start_x: 20 # Defines the minimum X coordinate of the calibration # This should be the X coordinate that positions the nozzle at the starting # calibration position. This parameter must be provided. calibrate_end_x: 200 # Defines the maximum X coordinate of the calibration # This should be the X coordinate that positions the nozzle at the ending # calibration position. This parameter must be provided. calibrate_y: 112.5 # Defines the Y coordinate of the calibration # This should be the Y coordinate that positions the nozzle during the # calibration process. This parameter must be provided and is recommended to # be near the center of the bed","title":"[axis_twist_compensation]"},{"location":"Config_Reference.html#motori-passo-passo-ed-estrusori-aggiuntivi","text":"","title":"Motori passo-passo ed estrusori aggiuntivi"},{"location":"Config_Reference.html#stepper_z1","text":"Assi multi-stepper. Su una stampante in stile cartesiano, lo stepper che controlla un dato asse pu\u00f2 avere blocchi di configurazione aggiuntivi che definiscono gli stepper che dovrebbero essere azionati insieme allo stepper primario. Si pu\u00f2 definire un numero qualsiasi di sezioni con un suffisso numerico che inizia da 1 (ad esempio, \"stepper_z1\", \"stepper_z2\", ecc.). [stepper_z1] #step_pin: #dir_pin: #enable_pin: #microsteps: #rotation_distance: # Vedere la sezione \"stepper\" per la definizione dei parametri di cui sopra. #endstop_pin: # Se viene definito un endstop_pin per lo stepper aggiuntivo, lo stepper # si fermer\u00e0 fino all'attivazione dell'endstop. In caso contrario, lo stepper # si fermer\u00e0 fino a quando non verr\u00e0 attivato il finecorsa sullo stepper # primario per l'asse.","title":"[stepper_z1]"},{"location":"Config_Reference.html#extruder1","text":"In una stampante multiestrusore aggiungere una sezione estrusore aggiuntiva per ogni estrusore aggiuntivo. Le sezioni aggiuntive dell'estrusore devono essere denominate \"extruder1\", \"extruder2\", \"extruder3\" e cos\u00ec via. Vedere la sezione \"extruder\" per una descrizione dei parametri disponibili. Vedere sample-multi-extruder.cfg per un esempio di configurazione. [extruder1] #step_pin: #dir_pin: #... # Vedere la sezione \"estrusore\" per i parametri per lo stepper e il riscaldatore # disponibili. #shared_heater: # Questa opzione \u00e8 obsoleta e non deve pi\u00f9 essere specificata.","title":"[extruder1]"},{"location":"Config_Reference.html#dual_carriage","text":"Support for cartesian and hybrid_corexy/z printers with dual carriages on a single axis. The carriage mode can be set via the SET_DUAL_CARRIAGE extended g-code command. For example, \"SET_DUAL_CARRIAGE CARRIAGE=1\" command will activate the carriage defined in this section (CARRIAGE=0 will return activation to the primary carriage). Dual carriage support is typically combined with extra extruders - the SET_DUAL_CARRIAGE command is often called at the same time as the ACTIVATE_EXTRUDER command. Be sure to park the carriages during deactivation. Note that during G28 homing, typically the primary carriage is homed first followed by the carriage defined in the [dual_carriage] config section. However, the [dual_carriage] carriage will be homed first if both carriages home in a positive direction and the [dual_carriage] carriage has a position_endstop greater than the primary carriage, or if both carriages home in a negative direction and the [dual_carriage] carriage has a position_endstop less than the primary carriage. Inoltre, \u00e8 possibile utilizzare i comandi \"SET_DUAL_CARRIAGE CARRIAGE=1 MODE=COPY\" o \"SET_DUAL_CARRIAGE CARRIAGE=1 MODE=MIRROR\" per attivare la modalit\u00e0 di copia o di mirroring del doppio carrello, nel qual caso seguir\u00e0 di conseguenza il movimento del carrello 0 . Questi comandi possono essere utilizzati per stampare due parti contemporaneamente: due parti identiche (in modalit\u00e0 COPIA) o parti specchiate (in modalit\u00e0 SPECCHIO). Tieni presente che le modalit\u00e0 COPY e MIRROR richiedono anche la configurazione appropriata dell'estrusore sul doppio carrello, che in genere pu\u00f2 essere ottenuta con \"SYNC_EXTRUDER_MOTION MOTION_QUEUE=extruder EXTRUDER= \" o un comando simile. Vedere sample-idex.cfg per un esempio di configurazione. [dual_carriage] axis: # The axis this extra carriage is on (either x or y). This parameter # must be provided. #safe_distance: # The minimum distance (in mm) to enforce between the dual and the primary # carriages. If a G-Code command is executed that will bring the carriages # closer than the specified limit, such a command will be rejected with an # error. If safe_distance is not provided, it will be inferred from # position_min and position_max for the dual and primary carriages. If set # to 0 (or safe_distance is unset and position_min and position_max are # identical for the primary and dual carraiges), the carriages proximity # checks will be disabled. #step_pin: #dir_pin: #enable_pin: #microsteps: #rotation_distance: #endstop_pin: #position_endstop: #position_min: #position_max: # See the \"stepper\" section for the definition of the above parameters.","title":"[dual_carriage]"},{"location":"Config_Reference.html#extruder_stepper","text":"Supporto per stepper aggiuntivi sincronizzati al movimento di un estrusore (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"extruder_stepper\"). Per ulteriori informazioni, vedere riferimento comando . [extruder_stepper my_extra_stepper] extruder: # L'estrusore con cui \u00e8 sincronizzato questo stepper. Se questo \u00e8 impostato su # una stringa vuota, lo stepper non verr\u00e0 sincronizzato con un # estrusore. Questo parametro deve essere fornito. #step_pin: #dir_pin: #enable_pin: #microsteps: #rotation_distance: # Vedere la sezione \"stepper\" per la definizione dei parametri sopra. # .","title":"[extruder_stepper]"},{"location":"Config_Reference.html#stepper-manuali","text":"Stepper manuali (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"manual_stepper\"). Questi sono stepper controllati dal comando g-code MANUAL_STEPPER. Ad esempio: \"MANUAL_STEPPER STEPPER=my_stepper MOVE=10 SPEED=5\". Vedere il file G-Codes per una descrizione del comando MANUAL_STEPPER. Gli stepper non sono collegati alla normale cinematica della stampante. [manual_stepper my_stepper] #step_pin: #dir_pin: #enable_pin: #microsteps: #rotation_distance: # Vedere la sezione \"stepper\" per una descrizione di questi parametri. #velocity: # Impostare la velocit\u00e0 predefinita (in mm/s) per lo stepper. Questo # valore verr\u00e0 utilizzato se un comando MANUAL_STEPPER non specifica # un parametro SPEED. Il valore predefinito \u00e8 5 mm/s. #accel: # Imposta l'accelerazione predefinita (in mm/s^2) per lo stepper. # Un'accelerazione pari a zero non risulter\u00e0 in nessuna accelerazione. # Questo valore verr\u00e0 utilizzato se un comando MANUAL_STEPPER non # specifica un parametro ACCEL. Il valore predefinito \u00e8 zero. #endstop_pin: # Pin di rilevamento interruttore di fine corsa. Se specificato, \u00e8 possibile # eseguire \"movimenti di riferimento\" aggiungendo un parametro # STOP_ON_ENDSTOP ai comandi di movimento MANUAL_STEPPER.","title":"[Stepper manuali]"},{"location":"Config_Reference.html#riscaldatori-e-sensori-personalizzati","text":"","title":"Riscaldatori e sensori personalizzati"},{"location":"Config_Reference.html#verify_heater","text":"Verifica riscaldatore e sensore di temperatura. La verifica del riscaldatore viene abilitata automaticamente per ogni riscaldatore configurato sulla stampante. Usa le sezioni di verifica_riscaldatore per modificare le impostazioni predefinite. [verify_heater heater_config_name] #max_error: 120 # Il massimo \"errore di temperatura cumulativo\" prima di generare un # errore. Valori pi\u00f9 piccoli comportano un controllo pi\u00f9 rigoroso e valori # pi\u00f9 grandi consentono pi\u00f9 tempo prima che venga segnalato un errore. # Nello specifico la temperatura viene osservata una volta al secondo e # se \u00e8 prossima alla temperatura target viene azzerato un \"contatore errori\" # interno; in caso contrario, se la temperatura \u00e8 inferiore all'intervallo target, # il contatore viene aumentato della quantit\u00e0 in cui la temperatura riportata # differisce da tale intervallo. Se il contatore supera questo \"errore_max\", # viene generato un errore. Il valore predefinito \u00e8 120. #check_gain_time: # Questo controlla la verifica del riscaldatore durante il riscaldamento # iniziale. Valori pi\u00f9 piccoli comportano un controllo pi\u00f9 rigoroso e valori # pi\u00f9 grandi consentono pi\u00f9 tempo prima che venga segnalato un errore. # In particolare, durante il riscaldamento iniziale, fintanto che il riscaldatore # aumenta di temperatura entro questo intervallo di tempo (specificato in # secondi), il \"contatore errori\" interno viene azzerato. Il valore predefinito # \u00e8 20 secondi per gli estrusori e 60 secondi per heater_bed. #hysteresis: 5 # La differenza di temperatura massima (in gradi Celsius) rispetto a una # temperatura target considerata nell'intervallo del target. Questo controlla # nell'intervallo max_error. \u00c8 raro personalizzare questo valore. # L'impostazione predefinita \u00e8 5. #heating_gain: 2 # La temperatura minima (in gradi Celsius) di cui il riscaldatore deve # aumentare durante il check_gain_time. \u00c8 raro personalizzare questo valore. # L'impostazione predefinita \u00e8 2.","title":"[verify_heater]"},{"location":"Config_Reference.html#homing_heaters","text":"Strumento per disabilitare i riscaldatori durante l'homing o la probing di un asse. [homing_heaters] #steppers: # Un elenco separato da virgole di stepper che dovrebbero causare # la disattivazione dei riscaldatori. L'impostazione predefinita \u00e8 # disabilitare i riscaldatori per qualsiasi spostamento di homing/sonda. # Esempio tipico: stepper_z #heaters: # Un elenco separato da virgole di riscaldatori da disabilitare # durante i movimenti di homing/probing. L'impostazione # predefinita \u00e8 disabilitare tutti i riscaldatori. # Esempio tipico: estrusore, letto riscaldatore","title":"[homing_heaters]"},{"location":"Config_Reference.html#thermistor","text":"Termistori personalizzati (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"thermistor\"). \u00c8 possibile utilizzare un termistore personalizzato nel campo sensor_type di una sezione di configurazione del riscaldatore. (Ad esempio, se si definisce una sezione \"[thermistor my_thermistor]\", \u00e8 possibile utilizzare un \"sensor_type: my_thermistor\" quando si definisce un riscaldatore.) Assicurati di posizionare la sezione del termistore nel file di configurazione sopra il suo primo utilizzo in una sezione del riscaldatore . [thermistor my_thermistor] #temperature1: #resistance1: #temperature2: #resistance2: #temperature3: #resistance3: # Tre misure di resistenza (in Ohm) alle temperature date (in Celsius). # Le tre misurazioni verranno utilizzate per calcolare i coefficienti di # Steinhart-Hart per il termistore. Questi parametri devono essere # forniti quando si utilizza Steinhart-Hart per definire il termistore. #beta: # In alternativa, \u00e8 possibile definire temperatura1, resistenza1 e beta # per definire i parametri del termistore. Questo parametro deve # essere fornito quando si utilizza \"beta\" per definire il termistore.","title":"[thermistor]"},{"location":"Config_Reference.html#adc_temperature","text":"Sensori di temperatura ADC personalizzati (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"adc_temperature\"). Ci\u00f2 consente di definire un sensore di temperatura personalizzato che misura una tensione su un pin del convertitore da analogico a digitale (ADC) e utilizza l'interpolazione lineare tra una serie di misurazioni di temperatura/tensione (o temperatura/resistenza) configurate per determinare la temperatura. Il sensore risultante pu\u00f2 essere utilizzato come tipo_sensore in una sezione riscaldatore. (Ad esempio, se si definisce una sezione \"[adc_temperature my_sensor]\", \u00e8 possibile utilizzare un \"sensor_type: my_sensor\" quando si definisce un riscaldatore.) Assicurati di posizionare la sezione del sensore nel file di configurazione sopra il suo primo utilizzo in una sezione del riscaldatore. [adc_temperature my_sensor] #temperature1: #voltage1: #temperature2: #voltage2: #... # A set of temperatures (in Celsius) and voltages (in Volts) to use # as reference when converting a temperature. A heater section using # this sensor may also specify adc_voltage and voltage_offset # parameters to define the ADC voltage (see \"Common temperature # amplifiers\" section for details). At least two measurements must # be provided. #temperature1: #resistance1: #temperature2: #resistance2: #... # Alternatively one may specify a set of temperatures (in Celsius) # and resistance (in Ohms) to use as reference when converting a # temperature. A heater section using this sensor may also specify a # pullup_resistor parameter (see \"extruder\" section for details). At # least two measurements must be provided.","title":"[adc_temperature]"},{"location":"Config_Reference.html#heater_generic","text":"Riscaldatori generici (si pu\u00f2 definire un numero qualsiasi di sezioni con il prefisso \"riscaldatore_generico\"). Questi riscaldatori si comportano in modo simile ai riscaldatori standard (estrusori, piatti riscaldati). Utilizzare il comando SET_HEATER_TEMPERATURE (consultare G-Codes per i dettagli) per impostare la temperatura target. [heater_generic my_generic_heater] #gcode_id: # L'ID da utilizzare quando si riporta la temperatura nel comando M105. # Questo parametro deve essere fornito. #max_power: #sensor_type: #sensor_pin: #smooth_time: #control: #pid_Kp: #pid_Ki: #pid_Kd: #pwm_cycle_time: #min_temp: #max_temp: # Vedere la sezione \"extruder\" per la definizione dei parametri sopra.","title":"[heater_generic]"},{"location":"Config_Reference.html#temperature_sensor","text":"Sensori di temperatura generici. \u00c8 possibile definire un numero qualsiasi di sensori di temperatura aggiuntivi che vengono riportati tramite il comando M105. [temperature_sensor my_sensor] #sensor_type: #sensor_pin: #min_temp: #max_temp: # Vedi la sezione \"extruder\" per la definizione dei parametri # sopra indicati. #gcode_id: # Vedi la sezione \"heater_generic\" per la definizione dei # parametri sopra indicati.","title":"[temperature_sensor]"},{"location":"Config_Reference.html#sensori-di-temperatura","text":"Klipper include definizioni per molti tipi di sensori di temperatura. Questi sensori possono essere utilizzati in qualsiasi sezione di configurazione che richieda un sensore di temperatura (come una sezione [extruder] o [heater_bed] ).","title":"Sensori di temperatura"},{"location":"Config_Reference.html#termistori-comuni","text":"Termistori comuni. I seguenti parametri sono disponibili nelle sezioni del riscaldatore che utilizzano uno di questi sensori. sensor_type: # Uno di \"EPCOS 100K B57560G104F\", \"ATC Semitec 104GT-2\", # \"ATC Semitec 104NT-4-R025H42G\", \"Generic 3950\", # \"Honeywell 100K 135-104LAG-J01\", \"NTC 100K MGB18-104F39050L32\", # \"SliceEngineering 450\", o \"TDK NTCG104LH104JT1\" sensor_pin: # Pin di ingresso analogico collegato al termistore. # Questo parametro deve essere fornito. #pullup_resistor: 4700 # La resistenza (in ohm) del pullup collegato al termistore. # Il valore predefinito \u00e8 4700 ohm. #inline_resistor: 0 # La resistenza (in ohm) di un resistore aggiuntivo (non a variazione di # calore) posizionato in linea con il termistore. \u00c8 raro impostare questo. # Il valore predefinito \u00e8 0 ohm.","title":"Termistori comuni"},{"location":"Config_Reference.html#amplificatori-di-temperatura-comuni","text":"Amplificatori di temperatura comuni. I seguenti parametri sono disponibili nelle sezioni del riscaldatore che utilizzano uno di questi sensori. sensor_type: # Uno tra \"PT100 INA826\", \"AD595\", \"AD597\", \"AD8494\", \"AD8495\", # \"AD8496\", o \"AD8497\". sensor_pin: # Pin di ingresso analogico collegato al sensore. Questo parametro # deve essere fornito. #adc_voltage: 5.0 # La tensione di confronto dell'ADC (in Volt). Il valore predefinito # \u00e8 5 volt. #voltage_offset: 0 # L'offset di tensione ADC (in Volt). Il valore predefinito \u00e8 0.","title":"Amplificatori di temperatura comuni"},{"location":"Config_Reference.html#sensore-pt1000-collegato-direttamente","text":"Sensore PT1000 collegato direttamente. I seguenti parametri sono disponibili nelle sezioni del riscaldatore che utilizzano uno di questi sensori. sensor_type: PT1000 sensor_pin: # Pin di ingresso analogico collegato al sensore. Questo parametro # deve essere fornito. #pullup_resistor: 4700 # La resistenza (in ohm) del pullup collegato al sensore. Il valore # predefinito \u00e8 4700 ohm.","title":"Sensore PT1000 collegato direttamente"},{"location":"Config_Reference.html#sensori-di-temperatura-maxxxxxx","text":"Sensori temperatura MAXxxxxx con interfaccia periferica seriale (SPI). I seguenti parametri sono disponibili nelle sezioni del riscaldatore che utilizzano uno di questi tipi di sensore. sensor_type: # Uno tra \"MAX6675\", \"MAX31855\", \"MAX31856\", o \"MAX31865\". sensor_pin: # Il pin mcu collegato al pin di selezione del chip del sensore. # Questo parametro deve essere fornito. #spi_speed: 4000000 # La velocit\u00e0 SPI (in hz) da utilizzare durante la comunicazione # con il chip. Il valore predefinito \u00e8 4000000. #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # Vedere la sezione \"impostazioni comuni SPI\" per una # descrizione dei parametri di cui sopra. #tc_type: K #tc_use_50Hz_filter: False #tc_averaging_count: 1 # I parametri di cui sopra controllano i parametri del sensore # dei chip MAX31856. I valori predefiniti per ciascun parametro # sono accanto al nome del parametro nell'elenco precedente. #rtd_nominal_r: 100 #rtd_reference_r: 430 #rtd_num_of_wires: 2 #rtd_use_50Hz_filter: False # I parametri di cui sopra controllano i parametri del sensore dei # chip MAX31865. I valori predefiniti per ciascun parametro sono # accanto al nome del parametro nell'elenco precedente.","title":"Sensori di temperatura MAXxxxxx"},{"location":"Config_Reference.html#sensore-di-temperatura-bmp280bme280bme680","text":"Sensori ambientali BMP280/BME280/BME680 con interfaccia I2C. Si noti che questi sensori non sono destinati all'uso con estrusori e letti riscaldanti, ma piuttosto per il monitoraggio della temperatura ambiente (C), della pressione (hPa), dell'umidit\u00e0 relativa (%)e di livello del gas per il BME680. Vedere sample-macros.cfg per una gcode_macro che pu\u00f2 essere utilizzata per riportare la pressione e l'umidit\u00e0 oltre alla temperatura. sensor_type: BME280 #i2c_address: # Default is 118 (0x76). Some BME280 sensors have an address of 119 # (0x77). #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters.","title":"Sensore di temperatura BMP280/BME280/BME680"},{"location":"Config_Reference.html#sensore-temperatura-aht10aht20aht21","text":"Sensori ambientali con interfaccia a due fili (I2C) AHT10/AHT20/AHT21. Si noti che questi sensori non sono destinati all'uso con estrusori e letti riscaldanti, ma piuttosto per il monitoraggio della temperatura ambiente (C) e dell'umidit\u00e0 relativa. Vedi sample-macros.cfg per un gcode_macro che pu\u00f2 essere utilizzato per segnalare l'umidit\u00e0 oltre alla temperatura. sensor_type: AHT10 # Also use AHT10 for AHT20 and AHT21 sensors. #i2c_address: # Default is 56 (0x38). Some AHT10 sensors give the option to use # 57 (0x39) by moving a resistor. #i2c_mcu: #i2c_bus: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #aht10_report_time: # Interval in seconds between readings. Default is 30, minimum is 5","title":"Sensore temperatura AHT10/AHT20/AHT21"},{"location":"Config_Reference.html#sensore-htu21d","text":"Sensore ambientale con interfaccia a due fili (I2C) della famiglia HTU21D. Si noti che questo sensore non \u00e8 destinato all'uso con estrusori e letti riscaldanti, ma piuttosto per il monitoraggio della temperatura ambiente (C) e dell'umidit\u00e0 relativa(%). Vedere sample-macros.cfg per una gcode_macro che pu\u00f2 essere utilizzata per riportare l'umidit\u00e0 oltre alla temperatura. sensor_type: # Must be \"HTU21D\" , \"SI7013\", \"SI7020\", \"SI7021\" or \"SHT21\" #i2c_address: # Default is 64 (0x40). #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #htu21d_hold_master: # If the sensor can hold the I2C buf while reading. If True no other # bus communication can be performed while reading is in progress. # Default is False. #htu21d_resolution: # The resolution of temperature and humidity reading. # Valid values are: # 'TEMP14_HUM12' -> 14bit for Temp and 12bit for humidity # 'TEMP13_HUM10' -> 13bit for Temp and 10bit for humidity # 'TEMP12_HUM08' -> 12bit for Temp and 08bit for humidity # 'TEMP11_HUM11' -> 11bit for Temp and 11bit for humidity # Default is: \"TEMP11_HUM11\" #htu21d_report_time: # Interval in seconds between readings. Default is 30","title":"Sensore HTU21D"},{"location":"Config_Reference.html#sensore-di-temperatura-lm75","text":"Sensori di temperatura (I2C) LM75/LM75A. Questi sensori hanno una gamma di -55~125 C, quindi sono utilizzabili ad es. monitoraggio della temperatura della camera. Possono anche funzionare come semplici controller per ventole/riscaldatori. sensor_type: LM75 #i2c_address: # Default is 72 (0x48). Normal range is 72-79 (0x48-0x4F) and the 3 # low bits of the address are configured via pins on the chip # (usually with jumpers or hard wired). #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #lm75_report_time: # Interval in seconds between readings. Default is 0.8, with minimum # 0.5.","title":"Sensore di temperatura LM75"},{"location":"Config_Reference.html#sensore-di-temperatura-integrato-nel-microcontrollore","text":"I microcontrollori atsam, atsamd e stm32 contengono un sensore di temperatura interno. \u00c8 possibile utilizzare il sensore \"temperature_mcu\" per monitorare queste temperature. sensor_type: temperature_mcu #sensor_mcu: mcu # Il microcontrollore da cui leggere. L'impostazione predefinita \u00e8 \"mcu\". #sensor_temperature1: #sensor_adc1: # Specificare i due parametri precedenti (una temperatura in gradi # Celsius e un valore ADC come float compreso tra 0,0 e 1,0) per # calibrare la temperatura del microcontrollore. Ci\u00f2 potrebbe # migliorare la precisione della temperatura riportata su alcuni chip. # Un modo tipico per ottenere queste informazioni di calibrazione # consiste nel rimuovere completamente l'alimentazione dalla # stampante per alcune ore (per assicurarsi che sia alla temperatura # ambiente), quindi accenderla e utilizzare il comando QUERY_ADC # per ottenere una misurazione ADC. Utilizzare un altro sensore di # temperatura sulla stampante per trovare la temperatura ambiente # corrispondente. L'impostazione predefinita consiste nell'utilizzare # i dati di calibrazione di fabbrica sul microcontrollore (se applicabile) # o i valori nominali dalle specifiche del microcontrollore. #sensor_temperature2: #sensor_adc2: # Se viene specificato sensor_temperature1/sensor_adc1, \u00e8 anche # possibile specificare i dati di calibrazione sensor_temperature2/sensor_adc2. # Ci\u00f2 potrebbe fornire informazioni calibrate sulla \"curva della # temperatura\". L'impostazione predefinita consiste nell'utilizzare i dati # di calibrazione di fabbrica sul microcontrollore (se applicabile) o i # valori nominali dalle specifiche del microcontrollore.","title":"Sensore di temperatura integrato nel microcontrollore"},{"location":"Config_Reference.html#sensore-di-temperatura-host","text":"Temperatura dalla macchina (es. Raspberry Pi) che esegue il software host. sensor_type: temperature_host #sensor_path: # il percorso del file di sistema della temperatura. L'impostazione # predefinita \u00e8 \"/sys/class/thermal/thermal_zone0/temp\" che \u00e8 il file di # sistema della temperatura su un computer Raspberry Pi.","title":"Sensore di temperatura host"},{"location":"Config_Reference.html#sensore-di-temperatura-ds18b20","text":"DS18B20 \u00e8 un sensore di temperatura digitale a 1 filo (w1). Si noti che questo sensore non \u00e8 destinato all'uso con estrusori e letti riscaldanti, ma piuttosto per il monitoraggio della temperatura ambiente (C). Questi sensori hanno una portata fino a 125 C, quindi sono utilizzabili ad es. monitoraggio della temperatura della camera. Possono anche funzionare come semplici controller per ventole/riscaldatori. I sensori DS18B20 sono supportati solo su \"host mcu\", ad es. il Raspberry Pi. \u00c8 necessario installare il modulo del kernel Linux w1-gpio. sensor_type: DS18B20 serial_no: # Ogni dispositivo a 1 filo ha un numero di serie univoco utilizzato per # identificare il dispositivo, solitamente nel formato 28-031674b175ff. Questo # parametro deve essere fornito. I dispositivi collegati a 1 filo possono essere # elencati utilizzando il seguente comando Linux: ls /sys/bus/w1/devices/ #ds18_report_time: # Intervallo in secondi tra le letture. Il valore predefinito \u00e8 3.0, con un # minimo di 1.0 #sensor_mcu: # Il microcontrollore da cui leggere. Deve essere host_mcu","title":"Sensore di temperatura DS18B20"},{"location":"Config_Reference.html#combined-temperature-sensor","text":"Combined temperature sensor is a virtual temperature sensor based on several other sensors. This sensor can be used with extruders, heater_generic and heater beds. sensor_type: temperature_combined #sensor_list: # Must be provided. List of sensors to combine to new \"virtual\" # sensor. # E.g. 'temperature_sensor sensor1,extruder,heater_bed' #combination_method: # Must be provided. Combination method used for the sensor. # Available options are 'max', 'min', 'mean'. #maximum_deviation: # Must be provided. Maximum permissible deviation between the sensors # to combine (e.g. 5 degrees). To disable it, use a large value (e.g. 999.9)","title":"Combined temperature sensor"},{"location":"Config_Reference.html#ventole","text":"","title":"Ventole"},{"location":"Config_Reference.html#fan","text":"Ventola di raffreddamento della stampa. [fan] pin: # Pin di output che controlla la ventola. Questo parametro deve essere fornito. #max_power: 1.0 # La potenza massima (espressa come un valore compreso tra 0.0 e 1.0) a # cui pu\u00f2 essere impostato il pin. Il valore 1.0 consente di impostare il pin # completamente abilitato per periodi prolungati, mentre un valore di 0.5 # consentirebbe di abilitare il pin per non pi\u00f9 della met\u00e0 del tempo. Questa # impostazione pu\u00f2 essere utilizzata per limitare la potenza totale (per # periodi prolungati) della ventola. Se questo valore \u00e8 inferiore a 1.0, le # richieste di velocit\u00e0 della ventola verranno ridimensionate tra zero e # max_power (ad esempio, se max_power \u00e8 0.9 e viene richiesta una # velocit\u00e0 della ventola dell'80%, la potenza della ventola verr\u00e0 impostata # su 72%). L'impostazione predefinita \u00e8 1.0. #shutdown_speed: 0 # La velocit\u00e0 della ventola desiderata (espressa come valore da 0.0 a # 1.0) se il software del microcontrollore entra in uno stato di errore. # Il valore predefinito \u00e8 0. #cycle_time: 0.010 # La quantit\u00e0 di tempo (in secondi) per ogni ciclo di alimentazione PWM # alla ventola. Si consiglia di essere pari o superiore a 10 millisecondi # quando si utilizza il PWM basato su software. # Il valore predefinito \u00e8 0,010 secondi. #hardware_pwm: False # Abilitare questa opzione per utilizzare PWM hardware anzich\u00e9 PWM # software. La maggior parte delle ventole non funziona bene con PWM # hardware, quindi non \u00e8 consigliabile abilitarlo a meno che non vi sia # un requisito elettrico per passare a velocit\u00e0 molto elevate. Quando # si utilizza l'hardware PWM, il tempo di ciclo effettivo \u00e8 vincolato # dall'implementazione e pu\u00f2 essere notevolmente diverso dal tempo # di ciclo richiesto. L'impostazione predefinita \u00e8 False. #kick_start_time: 0.100 # Tempo (in secondi) per far funzionare la ventola a piena velocit\u00e0 # quando la si abilita per la prima volta o la si aumenta di oltre il 50% # (aiuta a far girare la ventola). Il valore predefinito \u00e8 0,100 secondi. #off_below: 0.0 # La velocit\u00e0 minima in input che alimenter\u00e0 la ventola (espressa # come un valore da 0.0 a 1.0). Quando viene richiesta una velocit\u00e0 # inferiore a off_below la ventola verr\u00e0 invece spenta. Questa # impostazione pu\u00f2 essere utilizzata per prevenire lo stallo della # ventola e per garantire che i kick start siano efficaci. # Il valore predefinito \u00e8 0.0. # # Questa impostazione deve essere ricalibrata ogni volta che # max_power viene regolato. Per calibrare questa impostazione, # inizia con off_below impostato su 0.0 e la ventola gira. Abbassare # gradualmente la velocit\u00e0 della ventola per determinare la velocit\u00e0 # di ingresso pi\u00f9 bassa che aziona la ventola in modo affidabile senza # stalli. Impostare off_below al duty cycle corrispondente a questo # valore (ad esempio, 12% -> 0,12) o leggermente superiore. #tachometer_pin: # Pin di ingresso contagiri per il monitoraggio della velocit\u00e0 della # ventola. In genere \u00e8 richiesto un pullup. Questo parametro \u00e8 facoltativo. #tachometer_ppr: 2 # Quando viene specificato tachometer_pin, questo \u00e8 il numero di # impulsi per giro del segnale del tachimetro. Per una ventola BLDC # questo \u00e8 normalmente la met\u00e0 del numero di poli. # L'impostazione predefinita \u00e8 2. #tachometer_poll_interval: 0.0015 # Quando viene specificato tachometer_pin, questo \u00e8 il periodo di polling # del pin del contagiri, in secondi. Il valore predefinito \u00e8 0.0015, che \u00e8 # abbastanza veloce per le ventole al di sotto di 10000 RPM a 2 PPR. Deve # essere inferiore a 30/(tachometer_ppr*rpm), con un certo margine, # dove rpm \u00e8 la velocit\u00e0 massima (in RPM) della ventola. #enable_pin: # Pin opzionale per abilitare l'alimentazione alla ventola. Questo pu\u00f2 # essere utile per le ventole con ingressi PWM dedicati. Alcune di queste # ventole rimangono accese anche allo 0% di ingresso PWM. In tal caso, # il pin PWM pu\u00f2 essere utilizzato normalmente e ad es. un FET commutato # a terra (pin della ventola standard) pu\u00f2 essere utilizzato per controllare # l'alimentazione alla ventola.","title":"[fan]"},{"location":"Config_Reference.html#heater_fan","text":"Ventole di raffreddamento del riscaldatore (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"heater_fan\"). Una \"ventola riscaldatore\" \u00e8 una ventola che verr\u00e0 abilitata ogni volta che il riscaldatore associato \u00e8 attivo. Per impostazione predefinita, un heater_fan ha una velocit\u00e0 di spegnimento pari a max_power. [heater_fan heatbreak_cooling_fan] #pin: #max_power: #shutdown_speed: #cycle_time: #hardware_pwm: #kick_start_time: #off_below: #tachometer_pin: #tachometer_ppr: #tachometer_poll_interval: #enable_pin: # See the \"fan\" section for a description of the above parameters. #heater: extruder # Name of the config section defining the heater that this fan is # associated with. If a comma separated list of heater names is # provided here, then the fan will be enabled when any of the given # heaters are enabled. The default is \"extruder\". #heater_temp: 50.0 # A temperature (in Celsius) that the heater must drop below before # the fan is disabled. The default is 50 Celsius. #fan_speed: 1.0 # The fan speed (expressed as a value from 0.0 to 1.0) that the fan # will be set to when its associated heater is enabled. The default # is 1.0","title":"[heater_fan]"},{"location":"Config_Reference.html#controller_fan","text":"Ventola di raffreddamento del controller (\u00e8 possibile definire un numero qualsiasi di sezioni con il prefisso \"controller_fan\"). Una \"ventola del controller\" \u00e8 una ventola che verr\u00e0 abilitata ogni volta che il riscaldatore associato o il driver stepper associato \u00e8 attivo. La ventola si fermer\u00e0 ogni volta che viene raggiunto un idle_timeout per garantire che non si verifichi alcun surriscaldamento dopo la disattivazione di un componente osservato. [controller_fan my_controller_fan] #pin: #max_power: #shutdown_speed: #cycle_time: #hardware_pwm: #kick_start_time: #off_below: #tachometer_pin: #tachometer_ppr: #tachometer_poll_interval: #enable_pin: # Vedere la sezione \"fan\" per una descrizione dei parametri di cui sopra. #fan_speed: 1.0 # La velocit\u00e0 della ventola (espressa come un valore compreso tra 0.0 e # 1.0) a cui verr\u00e0 impostata la ventola quando \u00e8 attivo un riscaldatore # o un driver passo-passo. L'impostazione predefinita \u00e8 1.0 #idle_timeout: # La quantit\u00e0 di tempo (in secondi) dopo che un driver passo-passo o # un riscaldatore \u00e8 stato attivo per la quale la ventola deve essere tenuta # in funzione. L'impostazione predefinita \u00e8 30 secondi. #idle_speed: # La velocit\u00e0 della ventola (espressa come un valore compreso tra 0.0 # e 1.0) a cui verr\u00e0 impostata la ventola quando era attivo un riscaldatore # o un driver passo-passo e prima che venga raggiunto l'idle_timeout. # L'impostazione predefinita \u00e8 fan_speed. #heater: #stepper: # Nome della sezione di configurazione che definisce il riscaldatore/ # stepper a cui \u00e8 associata questa ventola. Se qui viene fornito un # elenco separato da virgole di nomi di riscaldatori/stepper, la ventola # sar\u00e0 abilitata quando uno qualsiasi dei riscaldatori/stepper indicati # \u00e8 abilitato. Il riscaldatore predefinito \u00e8 \"estrusore\", lo stepper # predefinito sono tutti.","title":"[controller_fan]"},{"location":"Config_Reference.html#temperature_fan","text":"Ventole di raffreddamento attivate dalla temperatura (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"temperature_fan\"). Una \"ventola di temperatura\" \u00e8 una ventola che verr\u00e0 abilitata ogni volta che il sensore associato \u00e8 al di sopra di una temperatura impostata. Per impostazione predefinita, una ventola_temperatura ha una velocit\u00e0_di_arresto pari a potenza_massima. Per ulteriori informazioni, vedere command reference . [temperature_fan my_temp_fan] #pin: #max_power: #shutdown_speed: #cycle_time: #hardware_pwm: #kick_start_time: #off_below: #tachometer_pin: #tachometer_ppr: #tachometer_poll_interval: #enable_pin: # Vedere la sezione \"fan\" per una descrizione dei parametri di cui sopra. #sensor_type: #sensor_pin: #control: #max_delta: #min_temp: #max_temp: # Vedere la sezione \"extruder\" per una descrizione dei parametri di cui sopra. #pid_Kp: #pid_Ki: #pid_Kd: # Le impostazioni proporzionale (pid_Kp), integrale (pid_Ki) e derivata (pid_Kd) # per il sistema di controllo del feedback PID. Klipper valuta le impostazioni PID # con la seguente formula generale: fan_pwm = max_power - (Kp*e + Ki*integral(e) # - Kd*derivative(e)) / 255 Dove \"e\" \u00e8 \"target_temperature - measure_temperature\" # e \"fan_pwm\" \u00e8 la frequenza della ventola richiesta con 0.0 per spento e 1.0 al # massimo. I parametri pid_Kp, pid_Ki e pid_Kd devono essere forniti quando l# 'algoritmo di controllo PID \u00e8 abilitato. #pid_deriv_time: 2.0 # Un valore di tempo (in secondi) su cui le misurazioni della temperatura verranno # livellate quando si utilizza l'algoritmo di controllo PID. Ci\u00f2 pu\u00f2 ridurre l'impatto # del rumore di misurazione. Il valore predefinito \u00e8 2 secondi. #target_temp: 40.0 # Una temperatura (in Celsius) che sar\u00e0 la temperatura target. # L'impostazione predefinita \u00e8 40 gradi. #max_speed: 1.0 # La velocit\u00e0 della ventola (espressa come un valore compreso tra 0.0 e 1.0) a cui # verr\u00e0 impostata la ventola quando la temperatura del sensore supera il valore # impostato. L'impostazione predefinita \u00e8 1.0. #min_speed: 0.3 # La velocit\u00e0 minima della ventola (espressa come un valore compreso tra 0.0 e # 1.0) alla quale la ventola verr\u00e0 impostata per le ventole con temperatura PID. # Il valore predefinito \u00e8 0.3. #gcode_id: # Se impostata, la temperatura verr\u00e0 riportata nelle query M105 utilizzando l'id # fornito. L'impostazione predefinita \u00e8 di non riportare la temperatura tramite M105.","title":"[temperature_fan]"},{"location":"Config_Reference.html#fan_generic","text":"Ventola a controllo manuale (si pu\u00f2 definire un numero qualsiasi di sezioni con il prefisso \"fan_generic\"). La velocit\u00e0 di una ventola controllata manualmente viene impostata con SET_FAN_SPEED comando gcode . [fan_generic extruder_partfan] #pin: #max_power: #shutdown_speed: #cycle_time: #hardware_pwm: #kick_start_time: #off_below: #tachometer_pin: #tachometer_ppr: #tachometer_poll_interval: #enable_pin: # Vedere la sezione \"fan\" per una descrizione dei parametri di cui sopra.","title":"[fan_generic]"},{"location":"Config_Reference.html#leds","text":"","title":"LEDs"},{"location":"Config_Reference.html#led","text":"Supporto per LED (e strisce LED) controllati tramite pin PWM del microcontrollore (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"led\"). Per ulteriori informazioni, vedere command reference . [led my_led] #red_pin: #green_pin: #blue_pin: #white_pin: # Il pin che controlla il colore del LED specificato. Deve essere fornito # almeno uno dei parametri sopra indicati. #cycle_time: 0.010 # La quantit\u00e0 di tempo (in secondi) per ciclo PWM. Si consiglia che sia # pari o superiore a 10 millisecondi quando si utilizza il PWM basato # su software. Il valore predefinito \u00e8 0,010 secondi. #hardware_pwm: False # Abilitare questa opzione per utilizzare PWM hardware anzich\u00e9 PWM # software. Quando si utilizza l'hardware PWM, il tempo di ciclo effettivo # \u00e8 vincolato dall'implementazione e pu\u00f2 essere notevolmente diverso # dal tempo di ciclo richiesto. L'impostazione predefinita \u00e8 Falso. #initial_RED: 0.0 #initial_GREEN: 0.0 #initial_BLUE: 0.0 #initial_WHITE: 0.0 # Imposta il colore iniziale del LED. Ciascun valore deve essere # compreso tra 0,0 e 1,0. Il valore predefinito per ogni colore \u00e8 0.","title":"[led]"},{"location":"Config_Reference.html#neopixel","text":"Supporto LED Neopixel (aka WS2812) (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"neopixel\"). Per ulteriori informazioni, vedere riferimento comando . Si noti che l'implementazione di linux mcu non supporta attualmente i neopixel collegati direttamente. L'attuale design che utilizza l'interfaccia del kernel Linux non consente questo scenario perch\u00e9 l'interfaccia GPIO del kernel non \u00e8 sufficientemente veloce da fornire le frequenze di impulso richieste. [neopixel my_neopixel] pin: # Il pin collegato al neopixel. Questo parametro deve essere fornito. #chain_count: # Il numero di chip Neopixel che sono \"collegati a margherita\" al # pin fornito. Il valore predefinito \u00e8 1 (che indica che un solo # Neopixel \u00e8 collegato al pin). #color_order: GRB # Impostare l'ordine dei pixel richiesto dall'hardware del LED # (utilizzando una stringa contenente le lettere R, G, B, W con W # opzionale). In alternativa, questo pu\u00f2 essere un elenco separato # da virgole di pixel, uno per ogni LED nella catena. # L'impostazione predefinita \u00e8 GRB. #initial_RED: 0.0 #initial_GREEN: 0.0 #initial_BLUE: 0.0 #initial_WHITE: 0.0 # Vedere la sezione \"led\" per informazioni su questi parametri.","title":"[neopixel]"},{"location":"Config_Reference.html#dotstar","text":"Supporto LED Dotstar (conosciuti anche come APA102) (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"dotstar\"). Per ulteriori informazioni, vedere command reference . [dotstar my_dotstar] data_pin: # Il pin connesso alla data line del dotstar. Questo parametro # deve essere fornito. clock_pin: # Il pin connesso alla clock line del dotstar. Questo parametro # deve essere fornito. #chain_count: # Vedere la sezione \"neopixel\" per informazioni su questo parametro. #initial_RED: 0.0 #initial_GREEN: 0.0 #initial_BLUE: 0.0 # Vedere la sezione \"led\" per informazioni su questo parametro.","title":"[dotstar]"},{"location":"Config_Reference.html#pca9533","text":"PCA9533 Supporto LED. Il PCA9533 viene utilizzato sulla scheda mightyboard. [pca9533 my_pca9533] #i2c_address: 98 # The i2c address that the chip is using on the i2c bus. Use 98 for # the PCA9533/1, 99 for the PCA9533/2. The default is 98. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #initial_RED: 0.0 #initial_GREEN: 0.0 #initial_BLUE: 0.0 #initial_WHITE: 0.0 # See the \"led\" section for information on these parameters.","title":"[pca9533]"},{"location":"Config_Reference.html#pca9632","text":"Supporto LED PCA9632. Il PCA9632 viene utilizzato su FlashForge Dreamer. [pca9632 my_pca9632] #i2c_address: 98 # The i2c address that the chip is using on the i2c bus. This may be # 96, 97, 98, or 99. The default is 98. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #scl_pin: #sda_pin: # Alternatively, if the pca9632 is not connected to a hardware I2C # bus, then one may specify the \"clock\" (scl_pin) and \"data\" # (sda_pin) pins. The default is to use hardware I2C. #color_order: RGBW # Set the pixel order of the LED (using a string containing the # letters R, G, B, W). The default is RGBW. #initial_RED: 0.0 #initial_GREEN: 0.0 #initial_BLUE: 0.0 #initial_WHITE: 0.0 # See the \"led\" section for information on these parameters.","title":"[pca9632]"},{"location":"Config_Reference.html#servocomandi-aggiuntivi-pulsanti-e-altri-pin","text":"","title":"Servocomandi aggiuntivi, pulsanti e altri pin"},{"location":"Config_Reference.html#servo","text":"Servo (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"servo\"). I servo possono essere controllati usando SET_SERVO comando g-code . Ad esempio: SET_SERVO SERVO=my_servo ANGLE=180 [servo my_servo] pin: # Pin di uscita PWM che controlla il servo. Questo parametro deve # essere fornito. #maximum_servo_angle: 180 # L'angolo massimo (in gradi) a cui questo servo pu\u00f2 essere impostato. # L'impostazione predefinita \u00e8 180 gradi. #minimum_pulse_width: 0.001 # La durata minima dell'impulso (in secondi). Questo dovrebbe # corrispondere a un angolo di 0 gradi. Il valore predefinito \u00e8 0.001 secondi. #maximum_pulse_width: 0.002 # La durata massima dell'impulso (in secondi). Questo dovrebbe # corrispondere a un angolo di maximum_servo_angle. Il valore # predefinito \u00e8 0.002 secondi. #initial_angle: # Angolo iniziale (in gradi) su cui impostare il servo. L'impostazione # predefinita \u00e8 di non inviare alcun segnale all'avvio. #initial_pulse_width: # Durata iniziale dell'impulso (in secondi) su cui impostare il servo. # (Questo \u00e8 valido solo se initial_angle non \u00e8 impostato.) # L'impostazione predefinita \u00e8 di non inviare alcun segnale all'avvio.","title":"[servo]"},{"location":"Config_Reference.html#gcode_button","text":"Esegui gcode quando un pulsante viene premuto o rilasciato (o quando un pin cambia stato). Puoi controllare lo stato del pulsante usando QUERY_BUTTON button=my_gcode_button . [gcode_button my_gcode_button] pin: # Il pin su cui \u00e8 collegato il pulsante. Questo parametro deve essere fornito. #analog_range: # Due resistenze separate da virgole (in Ohm) che specificano l'intervallo # di resistenza minimo e massimo per il pulsante. Se viene fornito # analog_range, il pin deve essere un pin con capacit\u00e0 analogica. # L'impostazione predefinita \u00e8 utilizzare digital gpio per il pulsante. #analog_pullup_resistor: # La resistenza di pullup (in Ohm) quando \u00e8 specificato analog_range. # Il valore predefinito \u00e8 4700 ohm. #press_gcode: # Un elenco di comandi G-Code da eseguire quando si preme il pulsante. # I modelli G-Code sono supportati. Questo parametro deve essere fornito. #release_gcode: # Un elenco di comandi G-Code da eseguire quando il pulsante viene # rilasciato. I modelli G-Code sono supportati. L'impostazione predefinita # \u00e8 di non eseguire alcun comando al rilascio di un pulsante.","title":"[gcode_button]"},{"location":"Config_Reference.html#output_pin","text":"Pin di uscita configurabili in fase di run-time (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"output_pin\"). I pin configurati qui verranno impostati come pin di output e sar\u00e0 possibile modificarli in fase di esecuzione utilizzando il comando esteso \"SET_PIN PIN=my_pin VALUE=.1\" comandi g-code . [output_pin my_pin] pin: # Il pin da configurare come output. # Questo parametro deve essere fornito. #pwm: False # Impostare se il pin di uscita deve essere in grado di modulare la # larghezza di impulso PWM. Se questo \u00e8 True, i campi del valore # dovrebbero essere compresi tra 0 e 1; se \u00e8 False i campi del valore # devono essere 0 o 1. Il valore predefinito \u00e8 False. #static_value: # Se \u00e8 valorizzato, il pin viene assegnato a questo valore all'avvio e # il pin non pu\u00f2 essere modificato durante il runtime. Un pin statico # utilizza una ram leggermente inferiore nel microcontrollore. # L'impostazione predefinita prevede l'utilizzo della configurazione # di runtime dei pin. #value: # Il valore su cui impostare inizialmente il pin durante la # configurazione dell'MCU. Il valore predefinito \u00e8 0 (per bassa tensione). #shutdown_value: # Il valore su cui impostare il pin su un evento di arresto dell'MCU. # Il valore predefinito \u00e8 0 (per bassa tensione). #maximum_mcu_duration: # La durata massima di un valore di non spegnimento pu\u00f2 essere # determinato dall'MCU senza un riconoscimento da parte dell'host. # Se l'host non riesce a tenere il passo con un aggiornamento, l'MCU # si spegner\u00e0 e imposter\u00e0 tutti i pin sui rispettivi valori di spegnimento. # Default: 0 (disabilitato) I valori abituali sono circa 5 secondi. #cycle_time: 0.100 # La quantit\u00e0 di tempo (in secondi) per ciclo PWM. Si consiglia di # essere pari o superiore a 10 millisecondi quando si utilizza il PWM # basato su software. Il valore predefinito \u00e8 0.100 secondi per i pin pwm. #hardware_pwm: False # Abilitare questa opzione per utilizzare PWM hardware anzich\u00e9 PWM # software. Quando si utilizza l'hardware PWM, il tempo di ciclo effettivo # \u00e8 vincolato dall'implementazione e pu\u00f2 essere notevolmente diverso # dal tempo di ciclo richiesto. L'impostazione predefinita \u00e8 Falso. #scale: # Questo parametro pu\u00f2 essere utilizzato per modificare il modo in cui # i parametri 'value' e 'shutdown_value' vengono interpretati per i pin # pwm. Se fornito, il parametro 'value' deve essere compreso tra 0.0 e # 'scale'. Questo pu\u00f2 essere utile quando si configura un pin PWM che # controlla un riferimento di tensione stepper. La \"scala\" pu\u00f2 essere # impostata sull'amperaggio dello stepper equivalente se il PWM fosse # completamente abilitato, quindi il parametro \"value\" pu\u00f2 essere # specificato utilizzando l'amperaggio desiderato per lo stepper. # L'impostazione predefinita \u00e8 di non ridimensionare il parametro 'value'.","title":"[output_pin]"},{"location":"Config_Reference.html#static_digital_output","text":"Pin di uscita digitali configurati staticamente (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso \"static_digital_output\"). I pin configurati qui verranno impostati come uscita GPIO durante la configurazione dell'MCU. Non possono essere modificati in fase di esecuzione. [static_digital_output my_output_pins] pins: # Un elenco separato da virgole di pin da impostare come pin di # output GPIO. Il pin verr\u00e0 impostato su un livello alto a meno che il # nome del pin non sia preceduto da \"!\". Questo parametro deve # essere fornito.","title":"[static_digital_output]"},{"location":"Config_Reference.html#multi_pin","text":"Uscite a pin multipli (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"multi_pin\"). Un output multi_pin crea un alias pin interno che pu\u00f2 modificare pi\u00f9 pin di output ogni volta che viene impostato il pin alias. Ad esempio, si potrebbe definire un oggetto \"[multi_pin my_fan]\" contenente due pin e quindi impostare \"pin=multi_pin:my_fan\" nella sezione \"[fan]\" - ad ogni cambio di ventola entrambi i pin di output verrebbero aggiornati. Questi alias non possono essere utilizzati con i pin del motore passo-passo. [multi_pin my_multi_pin] pins: # Un elenco separato da virgole di pin associati a questo alias. # Questo parametro deve essere fornito.","title":"[multi_pin]"},{"location":"Config_Reference.html#configurazione-del-driver-tmc-per-stepper","text":"Configurazione dei driver per motori passo-passo Trinamic in modalit\u00e0 UART/SPI. Ulteriori informazioni si trovano nella TMC Drivers guide e nel command reference .","title":"Configurazione del driver TMC per stepper"},{"location":"Config_Reference.html#tmc2130","text":"Configurare un driver per motore passo-passo TMC2130 tramite bus SPI. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso \"tmc2130\" seguito dal nome della sezione di configurazione dello stepper corrispondente (ad esempio, \"[tmc2130 stepper_x]\"). [tmc2130 stepper_x] cs_pin: # The pin corresponding to the TMC2130 chip select line. This pin # will be set to low at the start of SPI messages and raised to high # after the message completes. This parameter must be provided. #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #chain_position: #chain_length: # These parameters configure an SPI daisy chain. The two parameters # define the stepper position in the chain and the total chain length. # Position 1 corresponds to the stepper that connects to the MOSI signal. # The default is to not use an SPI daisy chain. #interpolate: True # If true, enable step interpolation (the driver will internally # step at a rate of 256 micro-steps). This interpolation does # introduce a small systemic positional deviation - see # TMC_Drivers.md for details. The default is True. run_current: # The amount of current (in amps RMS) to configure the driver to use # during stepper movement. This parameter must be provided. #hold_current: # The amount of current (in amps RMS) to configure the driver to use # when the stepper is not moving. Setting a hold_current is not # recommended (see TMC_Drivers.md for details). The default is to # not reduce the current. #sense_resistor: 0.110 # The resistance (in ohms) of the motor sense resistor. The default # is 0.110 ohms. #stealthchop_threshold: 0 # The velocity (in mm/s) to set the \"stealthChop\" threshold to. When # set, \"stealthChop\" mode will be enabled if the stepper motor # velocity is below this value. The default is 0, which disables # \"stealthChop\" mode. #driver_MSLUT0: 2863314260 #driver_MSLUT1: 1251300522 #driver_MSLUT2: 608774441 #driver_MSLUT3: 269500962 #driver_MSLUT4: 4227858431 #driver_MSLUT5: 3048961917 #driver_MSLUT6: 1227445590 #driver_MSLUT7: 4211234 #driver_W0: 2 #driver_W1: 1 #driver_W2: 1 #driver_W3: 1 #driver_X1: 128 #driver_X2: 255 #driver_X3: 255 #driver_START_SIN: 0 #driver_START_SIN90: 247 # These fields control the Microstep Table registers directly. The optimal # wave table is specific to each motor and might vary with current. An # optimal configuration will have minimal print artifacts caused by # non-linear stepper movement. The values specified above are the default # values used by the driver. The value must be specified as a decimal integer # (hex form is not supported). In order to compute the wave table fields, # see the tmc2130 \"Calculation Sheet\" from the Trinamic website. #driver_IHOLDDELAY: 8 #driver_TPOWERDOWN: 0 #driver_TBL: 1 #driver_TOFF: 4 #driver_HEND: 7 #driver_HSTRT: 0 #driver_PWM_AUTOSCALE: True #driver_PWM_FREQ: 1 #driver_PWM_GRAD: 4 #driver_PWM_AMPL: 128 #driver_SGT: 0 # Set the given register during the configuration of the TMC2130 # chip. This may be used to set custom motor parameters. The # defaults for each parameter are next to the parameter name in the # above list. #diag0_pin: #diag1_pin: # The micro-controller pin attached to one of the DIAG lines of the # TMC2130 chip. Only a single diag pin should be specified. The pin # is \"active low\" and is thus normally prefaced with \"^!\". Setting # this creates a \"tmc2130_stepper_x:virtual_endstop\" virtual pin # which may be used as the stepper's endstop_pin. Doing this enables # \"sensorless homing\". (Be sure to also set driver_SGT to an # appropriate sensitivity value.) The default is to not enable # sensorless homing.","title":"[tmc2130]"},{"location":"Config_Reference.html#tmc2208","text":"Configurare un driver per motore passo-passo TMC2208 (o TMC2224) tramite UART a filo singolo. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso \"tmc2208\" seguito dal nome della sezione di configurazione dello stepper corrispondente (ad esempio, \"[tmc2208 stepper_x]\"). [tmc2208 stepper_x] uart_pin: # The pin connected to the TMC2208 PDN_UART line. This parameter # must be provided. #tx_pin: # If using separate receive and transmit lines to communicate with # the driver then set uart_pin to the receive pin and tx_pin to the # transmit pin. The default is to use uart_pin for both reading and # writing. #select_pins: # A comma separated list of pins to set prior to accessing the # tmc2208 UART. This may be useful for configuring an analog mux for # UART communication. The default is to not configure any pins. #interpolate: True # If true, enable step interpolation (the driver will internally # step at a rate of 256 micro-steps). This interpolation does # introduce a small systemic positional deviation - see # TMC_Drivers.md for details. The default is True. run_current: # The amount of current (in amps RMS) to configure the driver to use # during stepper movement. This parameter must be provided. #hold_current: # The amount of current (in amps RMS) to configure the driver to use # when the stepper is not moving. Setting a hold_current is not # recommended (see TMC_Drivers.md for details). The default is to # not reduce the current. #sense_resistor: 0.110 # The resistance (in ohms) of the motor sense resistor. The default # is 0.110 ohms. #stealthchop_threshold: 0 # The velocity (in mm/s) to set the \"stealthChop\" threshold to. When # set, \"stealthChop\" mode will be enabled if the stepper motor # velocity is below this value. The default is 0, which disables # \"stealthChop\" mode. #driver_MULTISTEP_FILT: True #driver_IHOLDDELAY: 8 #driver_TPOWERDOWN: 20 #driver_TBL: 2 #driver_TOFF: 3 #driver_HEND: 0 #driver_HSTRT: 5 #driver_PWM_AUTOGRAD: True #driver_PWM_AUTOSCALE: True #driver_PWM_LIM: 12 #driver_PWM_REG: 8 #driver_PWM_FREQ: 1 #driver_PWM_GRAD: 14 #driver_PWM_OFS: 36 # Set the given register during the configuration of the TMC2208 # chip. This may be used to set custom motor parameters. The # defaults for each parameter are next to the parameter name in the # above list.","title":"[tmc2208]"},{"location":"Config_Reference.html#tmc2209","text":"Configurare un driver per motore passo-passo TMC2209 tramite UART a filo singolo. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso \"tmc2209\" seguito dal nome della sezione di configurazione dello stepper corrispondente (ad esempio, \"[tmc2209 stepper_x]\"). [tmc2209 stepper_x] uart_pin: #tx_pin: #select_pins: #interpolate: True run_current: #hold_current: #sense_resistor: 0.110 #stealthchop_threshold: 0 # See the \"tmc2208\" section for the definition of these parameters. #uart_address: # The address of the TMC2209 chip for UART messages (an integer # between 0 and 3). This is typically used when multiple TMC2209 # chips are connected to the same UART pin. The default is zero. #driver_MULTISTEP_FILT: True #driver_IHOLDDELAY: 8 #driver_TPOWERDOWN: 20 #driver_TBL: 2 #driver_TOFF: 3 #driver_HEND: 0 #driver_HSTRT: 5 #driver_PWM_AUTOGRAD: True #driver_PWM_AUTOSCALE: True #driver_PWM_LIM: 12 #driver_PWM_REG: 8 #driver_PWM_FREQ: 1 #driver_PWM_GRAD: 14 #driver_PWM_OFS: 36 #driver_SGTHRS: 0 # Set the given register during the configuration of the TMC2209 # chip. This may be used to set custom motor parameters. The # defaults for each parameter are next to the parameter name in the # above list. #diag_pin: # The micro-controller pin attached to the DIAG line of the TMC2209 # chip. The pin is normally prefaced with \"^\" to enable a pullup. # Setting this creates a \"tmc2209_stepper_x:virtual_endstop\" virtual # pin which may be used as the stepper's endstop_pin. Doing this # enables \"sensorless homing\". (Be sure to also set driver_SGTHRS to # an appropriate sensitivity value.) The default is to not enable # sensorless homing.","title":"[tmc2209]"},{"location":"Config_Reference.html#tmc2660","text":"Configurare un driver per motore passo-passo TMC2660 tramite bus SPI. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso tmc2660 seguito dal nome della sezione di configurazione dello stepper corrispondente (ad esempio, \"[tmc2660 stepper_x]\"). [tmc2660 stepper_x] cs_pin: # Il pin corrispondente al pin di selezione del chip TMC2660. Questo pin # verr\u00e0 impostato su basso all'inizio dei messaggi SPI e impostato su # alto al termine del trasferimento del messaggio. Questo parametro # deve essere fornito. #spi_speed: 4000000 # Frequenza bus SPI utilizzata per comunicare con il driver # passo-passo TMC2660. Il valore predefinito \u00e8 4000000. #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # Vedere la sezione \"impostazioni comuni SPI\" per una descrizione # dei parametri di cui sopra. #interpolate: True # Se true, abilita l'interpolazione del passo (il driver eseguir\u00e0 un passo # interno a una velocit\u00e0 di 256 micropassi). Funziona solo se microsteps # \u00e8 impostato su 16. L'interpolazione introduce una piccola deviazione # posizionale sistemica - vedere TMC_Drivers.md per i dettagli. # L'impostazione predefinita \u00e8 Vero. run_current: # La quantit\u00e0 di corrente (in ampere RMS) utilizzata dal driver durante # il movimento passo-passo. Questo parametro deve essere fornito. #sense_resistor: # La resistenza (in ohm) del resistore di rilevamento del motore. # Questo parametro deve essere fornito. #idle_current_percent: 100 # La percentuale di run_current a cui il driver stepper sar\u00e0 ridotto allo # scadere del timeout di inattivit\u00e0 (\u00e8 necessario impostare il timeout # utilizzando una sezione di configurazione [idle_timeout]). La corrente # verr\u00e0 nuovamente aumentata una volta che lo stepper dovr\u00e0 muoversi # di nuovo. Assicurati di impostarlo su un valore sufficientemente alto in # modo che gli stepper non perdano la loro posizione. C'\u00e8 anche un piccolo # ritardo fino a quando la corrente non viene nuovamente aumentata, # quindi tienine conto quando comandi mosse veloci mentre lo stepper \u00e8 # al minimo. Il valore predefinito \u00e8 100 (nessuna riduzione). #driver_TBL: 2 #driver_RNDTF: 0 #driver_HDEC: 0 #driver_CHM: 0 #driver_HEND: 3 #driver_HSTRT: 3 #driver_TOFF: 4 #driver_SEIMIN: 0 #driver_SEDN: 0 #driver_SEMAX: 0 #driver_SEUP: 0 #driver_SEMIN: 0 #driver_SFILT: 0 #driver_SGT: 0 #driver_SLPH: 0 #driver_SLPL: 0 #driver_DISS2G: 0 #driver_TS2G: 3 # Imposta il parametro indicato durante la configurazione del chip TMC2660. # Questo pu\u00f2 essere utilizzato per impostare parametri del driver personalizzati. # Le impostazioni predefinite per ogni parametro sono accanto al nome del # parametro nell'elenco sopra. Vedere la scheda tecnica del TMC2660 su cosa # fa ogni parametro e quali sono le restrizioni sulle combinazioni di parametri. # Prestare particolare attenzione al registro CHOPCONF, dove l'impostazione # di CHM su zero o uno comporter\u00e0 modifiche al layout (il primo bit di HDEC) # viene interpretato come MSB di HSTRT in questo caso).","title":"[tmc2660]"},{"location":"Config_Reference.html#tmc2240","text":"Configure a TMC2240 stepper motor driver via SPI bus or UART. To use this feature, define a config section with a \"tmc2240\" prefix followed by the name of the corresponding stepper config section (for example, \"[tmc2240 stepper_x]\"). [tmc2240 stepper_x] cs_pin: # The pin corresponding to the TMC2240 chip select line. This pin # will be set to low at the start of SPI messages and raised to high # after the message completes. This parameter must be provided. #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #uart_pin: # The pin connected to the TMC2240 DIAG1/SW line. If this parameter # is provided UART communication is used rather then SPI. #chain_position: #chain_length: # These parameters configure an SPI daisy chain. The two parameters # define the stepper position in the chain and the total chain length. # Position 1 corresponds to the stepper that connects to the MOSI signal. # The default is to not use an SPI daisy chain. #interpolate: True # If true, enable step interpolation (the driver will internally # step at a rate of 256 micro-steps). The default is True. run_current: # The amount of current (in amps RMS) to configure the driver to use # during stepper movement. This parameter must be provided. #hold_current: # The amount of current (in amps RMS) to configure the driver to use # when the stepper is not moving. Setting a hold_current is not # recommended (see TMC_Drivers.md for details). The default is to # not reduce the current. #rref: 12000 # The resistance (in ohms) of the resistor between IREF and GND. The # default is 12000. #stealthchop_threshold: 0 # The velocity (in mm/s) to set the \"stealthChop\" threshold to. When # set, \"stealthChop\" mode will be enabled if the stepper motor # velocity is below this value. The default is 0, which disables # \"stealthChop\" mode. #driver_MSLUT0: 2863314260 #driver_MSLUT1: 1251300522 #driver_MSLUT2: 608774441 #driver_MSLUT3: 269500962 #driver_MSLUT4: 4227858431 #driver_MSLUT5: 3048961917 #driver_MSLUT6: 1227445590 #driver_MSLUT7: 4211234 #driver_W0: 2 #driver_W1: 1 #driver_W2: 1 #driver_W3: 1 #driver_X1: 128 #driver_X2: 255 #driver_X3: 255 #driver_START_SIN: 0 #driver_START_SIN90: 247 #driver_OFFSET_SIN90: 0 # These fields control the Microstep Table registers directly. The optimal # wave table is specific to each motor and might vary with current. An # optimal configuration will have minimal print artifacts caused by # non-linear stepper movement. The values specified above are the default # values used by the driver. The value must be specified as a decimal integer # (hex form is not supported). In order to compute the wave table fields, # see the tmc2130 \"Calculation Sheet\" from the Trinamic website. # Additionally, this driver also has the OFFSET_SIN90 field which can be used # to tune a motor with unbalanced coils. See the `Sine Wave Lookup Table` # section in the datasheet for information about this field and how to tune # it. #driver_MULTISTEP_FILT: True #driver_IHOLDDELAY: 6 #driver_IRUNDELAY: 4 #driver_TPOWERDOWN: 10 #driver_TBL: 2 #driver_TOFF: 3 #driver_HEND: 2 #driver_HSTRT: 5 #driver_FD3: 0 #driver_TPFD: 4 #driver_CHM: 0 #driver_VHIGHFS: 0 #driver_VHIGHCHM: 0 #driver_DISS2G: 0 #driver_DISS2VS: 0 #driver_PWM_AUTOSCALE: True #driver_PWM_AUTOGRAD: True #driver_PWM_FREQ: 0 #driver_FREEWHEEL: 0 #driver_PWM_GRAD: 0 #driver_PWM_OFS: 29 #driver_PWM_REG: 4 #driver_PWM_LIM: 12 #driver_SGT: 0 #driver_SEMIN: 0 #driver_SEUP: 0 #driver_SEMAX: 0 #driver_SEDN: 0 #driver_SEIMIN: 0 #driver_SFILT: 0 #driver_SG4_ANGLE_OFFSET: 1 # Set the given register during the configuration of the TMC2240 # chip. This may be used to set custom motor parameters. The # defaults for each parameter are next to the parameter name in the # above list. #diag0_pin: #diag1_pin: # The micro-controller pin attached to one of the DIAG lines of the # TMC2240 chip. Only a single diag pin should be specified. The pin # is \"active low\" and is thus normally prefaced with \"^!\". Setting # this creates a \"tmc2240_stepper_x:virtual_endstop\" virtual pin # which may be used as the stepper's endstop_pin. Doing this enables # \"sensorless homing\". (Be sure to also set driver_SGT to an # appropriate sensitivity value.) The default is to not enable # sensorless homing.","title":"[tmc2240]"},{"location":"Config_Reference.html#tmc5160","text":"Configurare un driver per motore passo-passo TMC5160 tramite bus SPI. Per utilizzare questa funzione, definire una sezione di configurazione con un prefisso \"tmc5160\" seguito dal nome della sezione di configurazione dello stepper corrispondente (ad esempio, \"[tmc5160 stepper_x]\"). [tmc5160 stepper_x] cs_pin: # The pin corresponding to the TMC5160 chip select line. This pin # will be set to low at the start of SPI messages and raised to high # after the message completes. This parameter must be provided. #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #chain_position: #chain_length: # These parameters configure an SPI daisy chain. The two parameters # define the stepper position in the chain and the total chain length. # Position 1 corresponds to the stepper that connects to the MOSI signal. # The default is to not use an SPI daisy chain. #interpolate: True # If true, enable step interpolation (the driver will internally # step at a rate of 256 micro-steps). The default is True. run_current: # The amount of current (in amps RMS) to configure the driver to use # during stepper movement. This parameter must be provided. #hold_current: # The amount of current (in amps RMS) to configure the driver to use # when the stepper is not moving. Setting a hold_current is not # recommended (see TMC_Drivers.md for details). The default is to # not reduce the current. #sense_resistor: 0.075 # The resistance (in ohms) of the motor sense resistor. The default # is 0.075 ohms. #stealthchop_threshold: 0 # The velocity (in mm/s) to set the \"stealthChop\" threshold to. When # set, \"stealthChop\" mode will be enabled if the stepper motor # velocity is below this value. The default is 0, which disables # \"stealthChop\" mode. #driver_MSLUT0: 2863314260 #driver_MSLUT1: 1251300522 #driver_MSLUT2: 608774441 #driver_MSLUT3: 269500962 #driver_MSLUT4: 4227858431 #driver_MSLUT5: 3048961917 #driver_MSLUT6: 1227445590 #driver_MSLUT7: 4211234 #driver_W0: 2 #driver_W1: 1 #driver_W2: 1 #driver_W3: 1 #driver_X1: 128 #driver_X2: 255 #driver_X3: 255 #driver_START_SIN: 0 #driver_START_SIN90: 247 # These fields control the Microstep Table registers directly. The optimal # wave table is specific to each motor and might vary with current. An # optimal configuration will have minimal print artifacts caused by # non-linear stepper movement. The values specified above are the default # values used by the driver. The value must be specified as a decimal integer # (hex form is not supported). In order to compute the wave table fields, # see the tmc2130 \"Calculation Sheet\" from the Trinamic website. #driver_MULTISTEP_FILT: True #driver_IHOLDDELAY: 6 #driver_TPOWERDOWN: 10 #driver_TBL: 2 #driver_TOFF: 3 #driver_HEND: 2 #driver_HSTRT: 5 #driver_FD3: 0 #driver_TPFD: 4 #driver_CHM: 0 #driver_VHIGHFS: 0 #driver_VHIGHCHM: 0 #driver_DISS2G: 0 #driver_DISS2VS: 0 #driver_PWM_AUTOSCALE: True #driver_PWM_AUTOGRAD: True #driver_PWM_FREQ: 0 #driver_FREEWHEEL: 0 #driver_PWM_GRAD: 0 #driver_PWM_OFS: 30 #driver_PWM_REG: 4 #driver_PWM_LIM: 12 #driver_SGT: 0 #driver_SEMIN: 0 #driver_SEUP: 0 #driver_SEMAX: 0 #driver_SEDN: 0 #driver_SEIMIN: 0 #driver_SFILT: 0 #driver_DRVSTRENGTH: 0 #driver_BBMCLKS: 4 #driver_BBMTIME: 0 #driver_FILT_ISENSE: 0 # Set the given register during the configuration of the TMC5160 # chip. This may be used to set custom motor parameters. The # defaults for each parameter are next to the parameter name in the # above list. #diag0_pin: #diag1_pin: # The micro-controller pin attached to one of the DIAG lines of the # TMC5160 chip. Only a single diag pin should be specified. The pin # is \"active low\" and is thus normally prefaced with \"^!\". Setting # this creates a \"tmc5160_stepper_x:virtual_endstop\" virtual pin # which may be used as the stepper's endstop_pin. Doing this enables # \"sensorless homing\". (Be sure to also set driver_SGT to an # appropriate sensitivity value.) The default is to not enable # sensorless homing.","title":"[tmc5160]"},{"location":"Config_Reference.html#configurazione-della-corrente-del-motore-passo-passo-a-run-time","text":"","title":"Configurazione della corrente del motore passo-passo a run-time"},{"location":"Config_Reference.html#ad5206","text":"Digipot AD5206 configurati staticamente collegati tramite bus SPI (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"ad5206\"). [ad5206 my_digipot] enable_pin: # The pin corresponding to the AD5206 chip select line. This pin # will be set to low at the start of SPI messages and raised to high # after the message completes. This parameter must be provided. #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters. #channel_1: #channel_2: #channel_3: #channel_4: #channel_5: #channel_6: # The value to statically set the given AD5206 channel to. This is # typically set to a number between 0.0 and 1.0 with 1.0 being the # highest resistance and 0.0 being the lowest resistance. However, # the range may be changed with the 'scale' parameter (see below). # If a channel is not specified then it is left unconfigured. #scale: # This parameter can be used to alter how the 'channel_x' parameters # are interpreted. If provided, then the 'channel_x' parameters # should be between 0.0 and 'scale'. This may be useful when the # AD5206 is used to set stepper voltage references. The 'scale' can # be set to the equivalent stepper amperage if the AD5206 were at # its highest resistance, and then the 'channel_x' parameters can be # specified using the desired amperage value for the stepper. The # default is to not scale the 'channel_x' parameters.","title":"[ad5206]"},{"location":"Config_Reference.html#mcp4451","text":"Digipot MCP4451 configurato staticamente collegato tramite bus I2C (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"mcp4451\"). [mcp4451 my_digipot] i2c_address: # The i2c address that the chip is using on the i2c bus. This # parameter must be provided. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #wiper_0: #wiper_1: #wiper_2: #wiper_3: # The value to statically set the given MCP4451 \"wiper\" to. This is # typically set to a number between 0.0 and 1.0 with 1.0 being the # highest resistance and 0.0 being the lowest resistance. However, # the range may be changed with the 'scale' parameter (see below). # If a wiper is not specified then it is left unconfigured. #scale: # This parameter can be used to alter how the 'wiper_x' parameters # are interpreted. If provided, then the 'wiper_x' parameters should # be between 0.0 and 'scale'. This may be useful when the MCP4451 is # used to set stepper voltage references. The 'scale' can be set to # the equivalent stepper amperage if the MCP4451 were at its highest # resistance, and then the 'wiper_x' parameters can be specified # using the desired amperage value for the stepper. The default is # to not scale the 'wiper_x' parameters.","title":"[mcp4451]"},{"location":"Config_Reference.html#mcp4728","text":"Convertitore digitale-analogico MCP4728 in configurazione statica collegato tramite bus I2C (\u00e8 possibile definire un numero qualsiasi di sezioni con prefisso \"mcp4728\"). [mcp4728 my_dac] #i2c_address: 96 # The i2c address that the chip is using on the i2c bus. The default # is 96. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters. #channel_a: #channel_b: #channel_c: #channel_d: # The value to statically set the given MCP4728 channel to. This is # typically set to a number between 0.0 and 1.0 with 1.0 being the # highest voltage (2.048V) and 0.0 being the lowest voltage. # However, the range may be changed with the 'scale' parameter (see # below). If a channel is not specified then it is left # unconfigured. #scale: # This parameter can be used to alter how the 'channel_x' parameters # are interpreted. If provided, then the 'channel_x' parameters # should be between 0.0 and 'scale'. This may be useful when the # MCP4728 is used to set stepper voltage references. The 'scale' can # be set to the equivalent stepper amperage if the MCP4728 were at # its highest voltage (2.048V), and then the 'channel_x' parameters # can be specified using the desired amperage value for the # stepper. The default is to not scale the 'channel_x' parameters.","title":"[mcp4728]"},{"location":"Config_Reference.html#mcp4018","text":"Digipot MCP4018 configurato staticamente collegato tramite due pin gpio \"bit banging\" (si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"mcp4018\"). [mcp4018 my_digipot] scl_pin: # Il pin \"clock\" SCL. Questo parametro deve essere fornito. sda_pin: # Il pin \"dati\" SDA. Questo parametro deve essere fornito. wiper: # Il valore su cui impostare staticamente il \"Wiper\" MCP4018 # specificato. Questo \u00e8 in genere impostato su un numero compreso # tra 0,0 e 1,0 con 1,0 come resistenza pi\u00f9 alta e 0,0 come resistenza # pi\u00f9 bassa. Tuttavia, l'intervallo pu\u00f2 essere modificato con il # parametro 'scale' (vedi sotto). Questo parametro deve essere fornito. #scale: # Questo parametro pu\u00f2 essere utilizzato per modificare il modo in # cui viene interpretato il parametro 'wiper'. Se fornito, il parametro # 'wiper' dovrebbe essere compreso tra 0.0 e 'scale'. Questo pu\u00f2 essere # utile quando l'MCP4018 viene utilizzato per impostare i riferimenti di # tensione stepper. La \"scala\" pu\u00f2 essere impostata sull'amperaggio # stepper equivalente se l'MCP4018 \u00e8 alla sua massima resistenza, # quindi \u00e8 possibile specificare il parametro \"wiper\" utilizzando il # valore di amperaggio desiderato per lo stepper. L'impostazione # predefinita \u00e8 di non ridimensionare il parametro 'wiper'.","title":"[mcp4018]"},{"location":"Config_Reference.html#supporto-display","text":"","title":"Supporto display"},{"location":"Config_Reference.html#display","text":"Supporto per un display collegato al microcontrollore. [display] lcd_type: # The type of LCD chip in use. This may be \"hd44780\", \"hd44780_spi\", # \"st7920\", \"emulated_st7920\", \"uc1701\", \"ssd1306\", or \"sh1106\". # See the display sections below for information on each type and # additional parameters they provide. This parameter must be # provided. #display_group: # The name of the display_data group to show on the display. This # controls the content of the screen (see the \"display_data\" section # for more information). The default is _default_20x4 for hd44780 # displays and _default_16x4 for other displays. #menu_timeout: # Timeout for menu. Being inactive this amount of seconds will # trigger menu exit or return to root menu when having autorun # enabled. The default is 0 seconds (disabled) #menu_root: # Name of the main menu section to show when clicking the encoder # on the home screen. The defaults is __main, and this shows the # the default menus as defined in klippy/extras/display/menu.cfg #menu_reverse_navigation: # When enabled it will reverse up and down directions for list # navigation. The default is False. This parameter is optional. #encoder_pins: # The pins connected to encoder. 2 pins must be provided when using # encoder. This parameter must be provided when using menu. #encoder_steps_per_detent: # How many steps the encoder emits per detent (\"click\"). If the # encoder takes two detents to move between entries or moves two # entries from one detent, try changing this. Allowed values are 2 # (half-stepping) or 4 (full-stepping). The default is 4. #click_pin: # The pin connected to 'enter' button or encoder 'click'. This # parameter must be provided when using menu. The presence of an # 'analog_range_click_pin' config parameter turns this parameter # from digital to analog. #back_pin: # The pin connected to 'back' button. This parameter is optional, # menu can be used without it. The presence of an # 'analog_range_back_pin' config parameter turns this parameter from # digital to analog. #up_pin: # The pin connected to 'up' button. This parameter must be provided # when using menu without encoder. The presence of an # 'analog_range_up_pin' config parameter turns this parameter from # digital to analog. #down_pin: # The pin connected to 'down' button. This parameter must be # provided when using menu without encoder. The presence of an # 'analog_range_down_pin' config parameter turns this parameter from # digital to analog. #kill_pin: # The pin connected to 'kill' button. This button will call # emergency stop. The presence of an 'analog_range_kill_pin' config # parameter turns this parameter from digital to analog. #analog_pullup_resistor: 4700 # The resistance (in ohms) of the pullup attached to the analog # button. The default is 4700 ohms. #analog_range_click_pin: # The resistance range for a 'enter' button. Range minimum and # maximum comma-separated values must be provided when using analog # button. #analog_range_back_pin: # The resistance range for a 'back' button. Range minimum and # maximum comma-separated values must be provided when using analog # button. #analog_range_up_pin: # The resistance range for a 'up' button. Range minimum and maximum # comma-separated values must be provided when using analog button. #analog_range_down_pin: # The resistance range for a 'down' button. Range minimum and # maximum comma-separated values must be provided when using analog # button. #analog_range_kill_pin: # The resistance range for a 'kill' button. Range minimum and # maximum comma-separated values must be provided when using analog # button.","title":"[display]"},{"location":"Config_Reference.html#display-hd44780","text":"Informazioni sulla configurazione dei display hd44780 (utilizzati nei display di tipo \"RepRapDiscount 2004 Smart Controller\"). [display] lcd_type: hd44780 # Set to \"hd44780\" for hd44780 displays. rs_pin: e_pin: d4_pin: d5_pin: d6_pin: d7_pin: # The pins connected to an hd44780 type lcd. These parameters must # be provided. #hd44780_protocol_init: True # Perform 8-bit/4-bit protocol initialization on an hd44780 display. # This is necessary on real hd44780 devices. However, one may need # to disable this on some \"clone\" devices. The default is True. #line_length: # Set the number of characters per line for an hd44780 type lcd. # Possible values are 20 (default) and 16. The number of lines is # fixed to 4. ...","title":"display hd44780"},{"location":"Config_Reference.html#display-hd44780_spi","text":"Informazioni sulla configurazione di un display hd44780_spi - un display 20x04 controllato tramite uno \"shift register\" hardware (che viene utilizzato nelle stampanti basate su mightyboard). [display] lcd_type: hd44780_spi # Set to \"hd44780_spi\" for hd44780_spi displays. latch_pin: spi_software_sclk_pin: spi_software_mosi_pin: spi_software_miso_pin: # The pins connected to the shift register controlling the display. # The spi_software_miso_pin needs to be set to an unused pin of the # printer mainboard as the shift register does not have a MISO pin, # but the software spi implementation requires this pin to be # configured. #hd44780_protocol_init: True # Perform 8-bit/4-bit protocol initialization on an hd44780 display. # This is necessary on real hd44780 devices. However, one may need # to disable this on some \"clone\" devices. The default is True. #line_length: # Set the number of characters per line for an hd44780 type lcd. # Possible values are 20 (default) and 16. The number of lines is # fixed to 4. ...","title":"display hd44780_spi"},{"location":"Config_Reference.html#display-st7920","text":"Informazioni sulla configurazione dei display st7920 (utilizzati nei display di tipo \"RepRapDiscount 12864 Full Graphic Smart Controller\"). [display] lcd_type: st7920 # Set to \"st7920\" for st7920 displays. cs_pin: sclk_pin: sid_pin: # The pins connected to an st7920 type lcd. These parameters must be # provided. ...","title":"display st7920"},{"location":"Config_Reference.html#display-emulazione-emulated_st7920","text":"Informazioni sulla configurazione di un display st7920 emulato, presenti in alcuni \"dispositivi touchscreen da 2,4 pollici\" e simili. [display] lcd_type: emulated_st7920 # Set to \"emulated_st7920\" for emulated_st7920 displays. en_pin: spi_software_sclk_pin: spi_software_mosi_pin: spi_software_miso_pin: # The pins connected to an emulated_st7920 type lcd. The en_pin # corresponds to the cs_pin of the st7920 type lcd, # spi_software_sclk_pin corresponds to sclk_pin and # spi_software_mosi_pin corresponds to sid_pin. The # spi_software_miso_pin needs to be set to an unused pin of the # printer mainboard as the st7920 as no MISO pin but the software # spi implementation requires this pin to be configured. ...","title":"display emulazione emulated_st7920"},{"location":"Config_Reference.html#display-uc1701","text":"Informazioni sulla configurazione dei display uc1701 (utilizzati nei display di tipo \"MKS Mini 12864\"). [display] lcd_type: uc1701 # Set to \"uc1701\" for uc1701 displays. cs_pin: a0_pin: # The pins connected to a uc1701 type lcd. These parameters must be # provided. #rst_pin: # The pin connected to the \"rst\" pin on the lcd. If it is not # specified then the hardware must have a pull-up on the # corresponding lcd line. #contrast: # The contrast to set. The value may range from 0 to 63 and the # default is 40. ...","title":"display uc1701"},{"location":"Config_Reference.html#display-ssd1306-e-sh1106","text":"Informazioni sulla configurazione dei display ssd1306 e sh1106. [display] lcd_type: # Set to either \"ssd1306\" or \"sh1106\" for the given display type. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # Optional parameters available for displays connected via an i2c # bus. See the \"common I2C settings\" section for a description of # the above parameters. #cs_pin: #dc_pin: #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # The pins connected to the lcd when in \"4-wire\" spi mode. See the # \"common SPI settings\" section for a description of the parameters # that start with \"spi_\". The default is to use i2c mode for the # display. #reset_pin: # A reset pin may be specified on the display. If it is not # specified then the hardware must have a pull-up on the # corresponding lcd line. #contrast: # The contrast to set. The value may range from 0 to 256 and the # default is 239. #vcomh: 0 # Set the Vcomh value on the display. This value is associated with # a \"smearing\" effect on some OLED displays. The value may range # from 0 to 63. Default is 0. #invert: False # TRUE inverts the pixels on certain OLED displays. The default is # False. #x_offset: 0 # Set the horizontal offset value on SH1106 displays. The default is # 0. ...","title":"display ssd1306 e sh1106"},{"location":"Config_Reference.html#display_data","text":"Supporto per la visualizzazione di dati personalizzati su uno schermo LCD. \u00c8 possibile creare un numero qualsiasi di gruppi di visualizzazione e un numero qualsiasi di elementi di dati in quei gruppi. Il display mostrer\u00e0 tutti gli elementi di dati per un determinato gruppo se l'opzione display_group nella sezione [display] \u00e8 impostata sul nome del gruppo specificato. Viene creato automaticamente un default set of display groups . \u00c8 possibile sostituire o estendere questi elementi display_data sovrascrivendo i valori predefiniti nel file di configurazione principale printer.cfg . [display_data my_group_name my_data_name] position: # Comma separated row and column of the display position that should # be used to display the information. This parameter must be # provided. text: # The text to show at the given position. This field is evaluated # using command templates (see docs/Command_Templates.md). This # parameter must be provided.","title":"[display_data]"},{"location":"Config_Reference.html#display_template","text":"Visualizza il testo dei dati \"macro\" (\u00e8 possibile definire un numero qualsiasi di sezioni con un prefisso display_template). Per informazioni sul template, vedere il documento template di comandi . Questa funzione consente di ridurre le definizioni ripetitive nelle sezioni display_data. Si pu\u00f2 usare la funzione incorporata render() nelle sezioni display_data per valutare un template. Per esempio, se si dovesse definire [display_template my_template] allora si potrebbe usare { render('my_template') } in una sezione display_data. Questa funzione pu\u00f2 essere utilizzata anche per aggiornamenti LED continui utilizzando il comando SET_LED_TEMPLATE . [display_template my_template_name] #param_: # One may specify any number of options with a \"param_\" prefix. The # given name will be assigned the given value (parsed as a Python # literal) and will be available during macro expansion. If the # parameter is passed in the call to render() then that value will # be used during macro expansion. For example, a config with # \"param_speed = 75\" might have a caller with # \"render('my_template_name', param_speed=80)\". Parameter names may # not use upper case characters. text: # The text to return when the this template is rendered. This field # is evaluated using command templates (see # docs/Command_Templates.md). This parameter must be provided.","title":"[display_template]"},{"location":"Config_Reference.html#display_glyph","text":"Visualizza un glifo personalizzato sui display che lo supportano. Al nome dato verranno assegnati i dati di visualizzazione dati che possono quindi essere referenziati nei modelli di visualizzazione con il loro nome circondato da due simboli \"tilde\" per esempio ~my_display_glyph~ Vedere sample-glyphs.cfg per alcuni esempi. [display_glyph my_display_glyph] #data: # The display data, stored as 16 lines consisting of 16 bits (1 per # pixel) where '.' is a blank pixel and '*' is an on pixel (e.g., # \"****************\" to display a solid horizontal line). # Alternatively, one can use '0' for a blank pixel and '1' for an on # pixel. Put each display line into a separate config line. The # glyph must consist of exactly 16 lines with 16 bits each. This # parameter is optional. #hd44780_data: # Glyph to use on 20x4 hd44780 displays. The glyph must consist of # exactly 8 lines with 5 bits each. This parameter is optional. #hd44780_slot: # The hd44780 hardware index (0..7) to store the glyph at. If # multiple distinct images use the same slot then make sure to only # use one of those images in any given screen. This parameter is # required if hd44780_data is specified.","title":"[display_glyph]"},{"location":"Config_Reference.html#display-my_extra_display","text":"Se in printer.cfg \u00e8 stata definita una sezione primaria [display] come mostrato sopra, \u00e8 possibile definire pi\u00f9 display ausiliari. Si noti che i display ausiliari attualmente non supportano la funzionalit\u00e0 del menu, quindi non supportano le opzioni del \"menu\" o la configurazione dei pulsanti. [display my_extra_display] # Vedere la sezione \"display\" per i parametri disponibili.","title":"[display my_extra_display]"},{"location":"Config_Reference.html#menu","text":"Menu display lcd personalizzabili. Viene creato automaticamente un default set of menus . \u00c8 possibile sostituire o estendere il menu sovrascrivendo le impostazioni predefinite nel file di configurazione principale printer.cfg . Consulta il command template document per informazioni sugli attributi di menu disponibili durante il rendering del modello. # Common parameters available for all menu config sections. #[menu __some_list __some_name] #type: disabled # Permanently disabled menu element, only required attribute is 'type'. # Allows you to easily disable/hide existing menu items. #[menu some_name] #type: # One of command, input, list, text: # command - basic menu element with various script triggers # input - same like 'command' but has value changing capabilities. # Press will start/stop edit mode. # list - it allows for menu items to be grouped together in a # scrollable list. Add to the list by creating menu # configurations using \"some_list\" as a prefix - for # example: [menu some_list some_item_in_the_list] # vsdlist - same as 'list' but will append files from virtual sdcard # (will be removed in the future) #name: # Name of menu item - evaluated as a template. #enable: # Template that evaluates to True or False. #index: # Position where an item needs to be inserted in list. By default # the item is added at the end. #[menu some_list] #type: list #name: #enable: # See above for a description of these parameters. #[menu some_list some_command] #type: command #name: #enable: # See above for a description of these parameters. #gcode: # Script to run on button click or long click. Evaluated as a # template. #[menu some_list some_input] #type: input #name: #enable: # See above for a description of these parameters. #input: # Initial value to use when editing - evaluated as a template. # Result must be float. #input_min: # Minimum value of range - evaluated as a template. Default -99999. #input_max: # Maximum value of range - evaluated as a template. Default 99999. #input_step: # Editing step - Must be a positive integer or float value. It has # internal fast rate step. When \"(input_max - input_min) / # input_step > 100\" then fast rate step is 10 * input_step else fast # rate step is same input_step. #realtime: # This attribute accepts static boolean value. When enabled then # gcode script is run after each value change. The default is False. #gcode: # Script to run on button click, long click or value change. # Evaluated as a template. The button click will trigger the edit # mode start or end.","title":"[menu]"},{"location":"Config_Reference.html#sensori-di-filamento","text":"","title":"Sensori di filamento"},{"location":"Config_Reference.html#filament_switch_sensor","text":"Sensore del filamento a interruttore. Supporto per l'inserimento del filamento e il rilevamento dell'esaurimento tramite un sensore interruttore, come un interruttore di fine corsa. Per ulteriori informazioni, vedere command reference . [filament_switch_sensor my_sensor] #pause_on_runout: True # Se impostato su True, verr\u00e0 eseguita una PAUSA immediatamente # dopo il rilevamento di un'eccentricit\u00e0. Si noti che se pause_on_runout # \u00e8 False e runout_gcode viene omesso, il rilevamento dell'eccentricit\u00e0 # \u00e8 disabilitato. L'impostazione predefinita \u00e8 Vero. #runout_gcode: # Un elenco di comandi G-Code da eseguire dopo il rilevamento di # un'esaurimento del filamento. Vedi docs/Command_Templates.md # per il formato G-Code. Se pause_on_runout \u00e8 impostato su True, # questo codice G verr\u00e0 eseguito al termine della PAUSA. # L'impostazione predefinita \u00e8 di non eseguire alcun comando G-Code. #insert_gcode: # Un elenco di comandi G-Code da eseguire dopo il rilevamento # dell'inserimento di filamento. Vedi docs/Command_Templates.md # per il formato G-Code. L'impostazione predefinita non prevede # l'esecuzione di alcun comando G-Code, che disabilita il rilevamento # dell'inserimento. #event_delay: 3.0 # Il tempo minimo in secondi per ritardare tra gli eventi. Gli eventi # attivati durante questo periodo di tempo verranno ignorati # silenziosamente. L'impostazione predefinita \u00e8 3 secondi. #pause_delay: 0.5 # Il tempo di ritardo, in secondi, tra l'invio del comando pause e # l'esecuzione di runout_gcode. Potrebbe essere utile aumentare # questo ritardo se OctoPrint mostra uno strano comportamento # di pausa. Il valore predefinito \u00e8 0,5 secondi. #switch_pin: # Il pin su cui \u00e8 collegato l'interruttore. # Questo parametro deve essere fornito.","title":"[filament_switch_sensor]"},{"location":"Config_Reference.html#filament_motion_sensor","text":"Sensore di movimento del filamento. Supporto per l'inserimento del filamento e il rilevamento dell'esaurimento mediante un codificatore che commuta il pin di uscita durante il movimento del filamento attraverso il sensore. Per ulteriori informazioni, vedere command reference . [filament_motion_sensor my_sensor] detection_length: 7.0 # La lunghezza minima di filamento tirato attraverso il sensore # per attivare un cambio di stato su switch_pin # Il default \u00e8 7 mm. extruder: # Nome della sezione extruder section con cui questo sensore \u00e8 associato. # Questo parametro deve essere fornito. switch_pin: #pause_on_runout: #runout_gcode: #insert_gcode: #event_delay: #pause_delay: # Vedere la sezione \"filament_switch_sensor\" per la descrizione dei # parametri riportati sopra.","title":"[filament_motion_sensor]"},{"location":"Config_Reference.html#tsl1401cl_filament_width_sensor","text":"Sensore di larghezza del filamento basato su TSLl401CL. Consulta la guida per ulteriori informazioni. sl1401cl_filament_width_sensor] #pin: #diametro nominale del filamento predefinito: 1,75 (mm) # Differenza massima consentita del diametro del filamento in mm. #max_difference: 0.2 # La distanza dal sensore alla camera di fusione in mm. #measurement_delay: 100","title":"[tsl1401cl_filament_width_sensor]"},{"location":"Config_Reference.html#hall_filament_width_sensor","text":"Sensore di larghezza del filamento ad effetto Hall (vedere Sensore di larghezza del filamento Hall ). [hall_filament_width_sensor] adc1: adc2: # Pin di ingresso analogico collegati al sensore. # Questi parametri devono essere forniti. #cal_dia1: 1.50 #cal_dia2: 2.00 # I valori di calibrazione (in mm) per i sensori. Il valore predefinito # \u00e8 1.50 per cal_dia1 e 2.00 per cal_dia2. #raw_dia1: 9500 #raw_dia2: 10500 # I valori di calibrazione grezzi per i sensori. Il valore predefinito \u00e8 # 9500 per raw_dia1 e 10500 per raw_dia2. #default_nominal_filament_diameter: 1.75 # Il diametro nominale del filamento. # Questo parametro deve essere fornito. #max_difference: 0.200 # Differenza massima consentita del diametro del filamento in # millimetri (mm). Se la differenza tra il diametro nominale del # filamento e l'uscita del sensore \u00e8 maggiore di +- max_difference, # il moltiplicatore di estrusione viene riportato a %100. # Il valore predefinito \u00e8 0,200. #measurement_delay: 70 # La distanza dal sensore alla camera di fusione/hot-end in # millimetri (mm). Il filamento tra il sensore e l'hot-end verr\u00e0 # trattato come default_nominal_filament_diameter. Il modulo # host funziona con la logica FIFO. Mantiene ogni valore e posizione # del sensore in un array e li riporta nella posizione corretta. # Questo parametro deve essere fornito. #enable: False # Sensore abilitato o disabilitato dopo l'accensione. L'impostazione predefinita \u00e8 disabilitare. #measurement_interval: 10 # La distanza approssimativa (in mm) tra le letture del sensore. # Il valore predefinito \u00e8 10 mm. #logging: False # Il log esterno al terminale e klipper.log pu\u00f2 essere # attivato|off tramite comando. #min_diameter: 1.0 # Diametro minimo per trigger filament_switch_sensor virtuale. #use_current_dia_while_delay: False # Utilizzare il diametro attuale invece del diametro nominale # mentre il ritardo di misurazione non \u00e8 trascorso. #pause_on_runout: #runout_gcode: #insert_gcode: #event_delay: #pause_delay: # Vedere la sezione \"filament_switch_sensor\" per una # descrizione dei parametri di cui sopra.","title":"[hall_filament_width_sensor]"},{"location":"Config_Reference.html#supporto-hardware-per-specifica-scheda","text":"","title":"Supporto hardware per specifica scheda"},{"location":"Config_Reference.html#sx1509","text":"Configurare un'espansione SX1509 da I2C a GPIO. A causa del ritardo dovuto alla comunicazione I2C, NON utilizzare i pin SX1509 come abilitazione stepper, pin step o dir o qualsiasi altro pin che richieda un bit banging veloce. Sono utilizzati al meglio come uscite digitali statiche o controllate da gcode o pin hardware-pwm per es. fan. Si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"sx1509\". Ogni espansione fornisce un set di 16 pin (da sx1509_my_sx1509:PIN_0 a sx1509_my_sx1509:PIN_15) che possono essere utilizzati nella configurazione della stampante. Per un esempio, vedere il file generic-duet2-duex.cfg . [sx1509 my_sx1509] i2c_address: # I2C address used by this expander. Depending on the hardware # jumpers this is one out of the following addresses: 62 63 112 # 113. This parameter must be provided. #i2c_mcu: #i2c_bus: #i2c_software_scl_pin: #i2c_software_sda_pin: #i2c_speed: # See the \"common I2C settings\" section for a description of the # above parameters.","title":"[sx1509]"},{"location":"Config_Reference.html#samd_sercom","text":"Configurazione SAMD SERCOM per specificare quali pin utilizzare su un determinato SERCOM. Si pu\u00f2 definire un numero qualsiasi di sezioni con un prefisso \"samd_sercom\". Ogni SERCOM deve essere configurato prima di utilizzarlo come periferica SPI o I2C. Posiziona questa sezione di configurazione sopra qualsiasi altra sezione che fa uso di bus SPI o I2C. [samd_sercom my_sercom] sercom: # Il nome del bus Sercom da configurare nel microcontrollore. I nomi # disponibili sono \"sercom0\", \"sercom1\", ecc. # Questo parametro deve essere fornito. tx_pin: # Pin MOSI per la comunicazione SPI o pin SDA (dati) per la # comunicazione I2C. Il pin deve avere una configurazione pinmux # valida per la specifica periferica SERCOM. # Questo parametro deve essere fornito. #rx_pin: # Pin MISO per la comunicazione SPI. Questo pin non viene utilizzato # per la comunicazione I2C (I2C utilizza tx_pin sia per l'invio che per la # ricezione). Il pin deve avere una configurazione pinmux valida per la # specifica periferica SERCOM. Questo parametro \u00e8 facoltativo. clk_pin: # Pin CLK per la comunicazione SPI o pin SCL (clock) per la # comunicazione I2C. Il pin deve avere una configurazione pinmux # valida per la specifica periferica SERCOM. Questo parametro deve # essere fornito.","title":"[samd_sercom]"},{"location":"Config_Reference.html#adc_scaled","text":"Scaling analogico di Duet2 Maestro tramite letture vref e vssa. La definizione di una sezione adc_scaled abilita pin adc virtuali (come \"my_name:PB0\") che vengono regolati automaticamente dai pin di monitoraggio vref e vssa della scheda. Assicurati di definire questa sezione di configurazione sopra qualsiasi sezione di configurazione che utilizza uno di questi pin virtuali. Per un esempio, vedere il file generic-duet2-maestro.cfg . [adc_scaled my_name] vref_pin: # The ADC pin to use for VREF monitoring. This parameter must be # provided. vssa_pin: # The ADC pin to use for VSSA monitoring. This parameter must be # provided. #smooth_time: 2.0 # A time value (in seconds) over which the vref and vssa # measurements will be smoothed to reduce the impact of measurement # noise. The default is 2 seconds.","title":"[adc_scaled]"},{"location":"Config_Reference.html#replicape","text":"Supporto per Replicape: vedere la guida beaglebone e il file generic-replicape.cfg per un esempio. # La sezione di configurazione \"replicape\" aggiunge i pin di abilitazione # dello stepper virtuale \"replicape: stepper_x_enable\" (per stepper X, Y, Z, # E e H) e i pin di uscita PWM \"replicape: power_x\" (per hotbed, e, h, fan0, # fan1 , fan2 e fan3) che possono quindi essere utilizzati altrove nel file # di configurazione. [replicape] revision: # La revisione dell'hardware di replicape. Attualmente \u00e8 supportata solo # la revisione \"B3\". Questo parametro deve essere fornito. #enable_pin: !gpio0_20 # Il pin di abilitazione globale dei replicape. L'impostazione predefinita # \u00e8 !gpio0_20 (aka P9_41). host_mcu: # Il nome della sezione mcu config che comunica con l'istanza mcu # \"linux process\" di Klipper. Questo parametro deve essere fornito. #standstill_power_down: False # Questo parametro controlla la linea CFG6_ENN su tutti i motori # passo-passo. True imposta le righe di abilitazione su \"open\". # L'impostazione predefinita \u00e8 Falso. #stepper_x_microstep_mode: #stepper_y_microstep_mode: #stepper_z_microstep_mode: #stepper_e_microstep_mode: #stepper_h_microstep_mode: # Questo parametro controlla i pin CFG1 e CFG2 del driver del motore # passo-passo specificato. Le opzioni disponibili sono: disabilita, 1, 2, # spread2, 4, 16, spread4, spread16, stealth4 e stealth16. L'impostazione # predefinita \u00e8 disabilitata. #stepper_x_current: #stepper_y_current: #stepper_z_current: #stepper_e_current: #stepper_h_current: # La corrente massima configurata (in Amp) del driver del motore # passo-passo. Questo parametro deve essere fornito se lo stepper non # \u00e8 in modalit\u00e0 disabilitazione. #stepper_x_chopper_off_time_high: #stepper_y_chopper_off_time_high: #stepper_z_chopper_off_time_high: #stepper_e_chopper_off_time_high: #stepper_h_chopper_off_time_high: # Questo parametro controlla il pin CFG0 del driver del motore # passo-passo (True imposta CFG0 alto, False lo imposta basso). # L'impostazione predefinita \u00e8 False. #stepper_x_chopper_hysteresis_high: #stepper_y_chopper_hysteresis_high: #stepper_z_chopper_hysteresis_high: #stepper_e_chopper_hysteresis_high: #stepper_h_chopper_hysteresis_high: # Questo parametro controlla il pin CFG4 del driver del motore # passo-passo (True imposta CFG4 alto, False lo imposta basso). # L'impostazione predefinita \u00e8 False. #stepper_x_chopper_blank_time_high: #stepper_y_chopper_blank_time_high: #stepper_z_chopper_blank_time_high: #stepper_e_chopper_blank_time_high: #stepper_h_chopper_blank_time_high: # Questo parametro controlla il pin CFG5 del driver del motore # passo-passo (True imposta CFG5 alto, False lo imposta basso). # L'impostazione predefinita \u00e8 True.","title":"[replicape]"},{"location":"Config_Reference.html#altri-moduli-personalizzati","text":"","title":"Altri moduli personalizzati"},{"location":"Config_Reference.html#palette2","text":"Supporto multimateriale Palette 2: fornisce un'integrazione pi\u00f9 stretta supportando i dispositivi Palette 2 in modalit\u00e0 connessa. Questo modulo richiede anche [virtual_sdcard] e [pause_resume] per la piena funzionalit\u00e0. Se si utilizza questo modulo, non utilizzare il plug-in Palette 2 per Octoprint poich\u00e9 entreranno in conflitto e 1 non si inizializzer\u00e0 correttamente, probabilmente interrompendo la stampa. Se utilizzi Octoprint e esegui lo streaming di gcode sulla porta seriale invece di stampare da virtual_sd, rimuovere M1 e M0 da Pausa dei comandi in Impostazioni > Connessione seriale > Firmware e protocollo eviter\u00e0 la necessit\u00e0 per avviare la stampa sulla tavolozza 2 e riattivare la pausa in Octoprint per avviare la stampa. [palette2] serial: # The serial port to connect to the Palette 2. #baud: 115200 # The baud rate to use. The default is 115200. #feedrate_splice: 0.8 # The feedrate to use when splicing, default is 0.8 #feedrate_normal: 1.0 # The feedrate to use after splicing, default is 1.0 #auto_load_speed: 2 # Extrude feedrate when autoloading, default is 2 (mm/s) #auto_cancel_variation: 0.1 # Auto cancel print when ping variation is above this threshold","title":"[palette2]"},{"location":"Config_Reference.html#angle","text":"Supporto per sensore magnetico Hall per la lettura delle misurazioni dell'angolo del motore passo-passo utilizzando i chip SPI a1333, as5047d o tle5012b. Le misurazioni sono disponibili tramite Server API e strumento di analisi del movimento . Vedere il Riferimento G-Code per i comandi disponibili. [angle my_angle_sensor] sensor_type: # The type of the magnetic hall sensor chip. Available choices are # \"a1333\", \"as5047d\", and \"tle5012b\". This parameter must be # specified. #sample_period: 0.000400 # The query period (in seconds) to use during measurements. The # default is 0.000400 (which is 2500 samples per second). #stepper: # The name of the stepper that the angle sensor is attached to (eg, # \"stepper_x\"). Setting this value enables an angle calibration # tool. To use this feature, the Python \"numpy\" package must be # installed. The default is to not enable angle calibration for the # angle sensor. cs_pin: # The SPI enable pin for the sensor. This parameter must be provided. #spi_speed: #spi_bus: #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # See the \"common SPI settings\" section for a description of the # above parameters.","title":"[angle]"},{"location":"Config_Reference.html#parametri-bus-comuni","text":"","title":"Parametri bus comuni"},{"location":"Config_Reference.html#impostazioni-spi-comuni","text":"I seguenti parametri sono generalmente disponibili per i dispositivi che utilizzano un bus SPI. #spi_speed: # La velocit\u00e0 SPI (in Hz) da utilizzare durante la comunicazione con il # dispositivo. L'impostazione predefinita dipende dal tipo di dispositivo. #spi_bus: # Se il microcontrollore supporta pi\u00f9 bus SPI, \u00e8 possibile specificare # qui il nome del bus del microcontrollore. L'impostazione predefinita # dipende dal tipo di microcontrollore. #spi_software_sclk_pin: #spi_software_mosi_pin: #spi_software_miso_pin: # Specificare i parametri di cui sopra per utilizzare \"SPI basato su # software\". Questa modalit\u00e0 non richiede il supporto hardware del # microcontrollore (in genere \u00e8 possibile utilizzare qualsiasi pin generico). # L'impostazione predefinita \u00e8 di non utilizzare \"spi software\".","title":"Impostazioni SPI comuni"},{"location":"Config_Reference.html#impostazioni-i2c-comuni","text":"I seguenti parametri sono generalmente disponibili per i dispositivi che utilizzano un bus I2C. Tieni presente che l'attuale supporto del microcontrollore di Klipper per I2C generalmente non tollera il rumore di linea. Errori imprevisti sui cavi I2C potrebbero far s\u00ec che Klipper sollevi un errore di runtime. Il supporto di Klipper per il ripristino degli errori varia a seconda del tipo di microcontrollore. In genere si consiglia di utilizzare solo dispositivi I2C che si trovano sullo stesso circuito stampato del microcontrollore. La maggior parte delle implementazioni del microcontrollore Klipper supportano solo una i2c_speed di 100000 ( modalit\u00e0 standard , 100kbit/s). Il microcontrollore Klipper \"Linux\" supporta una velocit\u00e0 400000 ( modalit\u00e0 veloce , 400kbit/s), ma deve essere impostato nel sistema operativo e i2c_speed il parametro viene altrimenti ignorato. Il microcontrollore Klipper \"RP2040\" e la famiglia ATmega AVR supportano una velocit\u00e0 di 400000 tramite il parametro i2c_speed . Tutti gli altri microcontrollori Klipper utilizzano una velocit\u00e0 100000 e ignorano il parametro \"i2c_speed\". #i2c_address: # The i2c address of the device. This must specified as a decimal # number (not in hex). The default depends on the type of device. #i2c_mcu: # The name of the micro-controller that the chip is connected to. # The default is \"mcu\". #i2c_bus: # If the micro-controller supports multiple I2C busses then one may # specify the micro-controller bus name here. The default depends on # the type of micro-controller. #i2c_software_scl_pin: #i2c_software_sda_pin: # Specify these parameters to use micro-controller software based # I2C \"bit-banging\" support. The two parameters should the two pins # on the micro-controller to use for the scl and sda wires. The # default is to use hardware based I2C support as specified by the # i2c_bus parameter. #i2c_speed: # The I2C speed (in Hz) to use when communicating with the device. # The Klipper implementation on most micro-controllers is hard-coded # to 100000 and changing this value has no effect. The default is # 100000. Linux, RP2040 and ATmega support 400000.","title":"Impostazioni I2C comuni"},{"location":"Config_checks.html","text":"Controlli della configurazione \u00b6 Questo documento fornisce una lista di step per confermare le impostazioni dei pin nel file printer.cfg di Klipper. \u00c8 una buona idea eseguire questi passi dopo aver seguito i passi nel documento di installazione . In alcuni passaggi di questa guida, potrebbe essere necessario modificare il file di configurazione di Klipper. Assicuratevi di dare il comando RESTART, dopo ogni modifica al file di configurazione, per accertarsi che le modifiche abbiano effetto(scrivere \"restart\" nella scheda del terminale di Octoprint e cliccare su INVIA). E' anche consigliabile utilizzare il comando STATUS, dopo ogni RESTART, per verificare che il file di configurazione sia stato caricato correttamente. Verifica delle temperature \u00b6 Inizia verificando che le temperature siano riportate correttamente. Naviga nella sezione della temperatura nell'interfaccia utente. Verifica che la temperatura del nozzle e del letto (se possibile) sono presenti e non aumentino. Nel caso aumentino, togli corrente alla stampante. Se le temperature non sono accurate, ricontrolla le impostazioni del nozzle e del letto chiamate \"sensor_type\" e \"sensor_pin\". Verifica M112 \u00b6 Naviga nella console dei comandi e invia un comando M112 nel terminale. Questo comando chiede a Klipper di andare in uno stato di spegnimento. Ci\u00f2 causer\u00e0 un errore, che potr\u00e0 essere risolto con l'esecuzione di un comando \"FIRMWARE_RESTART\" nella console. Anche octoprint richieder\u00e0 una riconessione. Poi vai nella sezione delle temperature e verifica che esse continuino ad aggiornarsi e non incrementino. Se le temperature incrementano togliere immediatamente corrente alla stampante. Verifica i riscaldatori \u00b6 Navigate to the temperature graph section and type in 50 followed by enter in the extruder/tool temperature box. The extruder temperature in the graph should start to increase (within about 30 seconds or so). Then go to the extruder temperature drop-down box and select \"Off\". After several minutes the temperature should start to return to its initial room temperature value. If the temperature does not increase then verify the \"heater_pin\" setting in the config. Se la stampante ha il piatto riscaldato, eseguire nuovamente il test indicato in precedenza ma per il piatto. Verifica il pin di abilitazione del motore passo-passo \u00b6 Verifica che gli assi della stampante possano muoversi liberamente (I motori sono disabilitati). In caso contrario, inviare un comando M84 per disabilitare i motori. Se un asse qualunque non si potesse muovere liberamente, verificare la configurazione stepper \"enable_pin\" per gli assi in questione.Nella maggior parte dei driver per motori passo-passo, il pin di abilitazione del motore \u00e8 \"attivo basso\" e pertanto il pin di abilitazione deve essere preceduto da un \"!\" (ad esempio, \"enable_pin: !PA1\"). Verifica i finecorsa \u00b6 Manually move all the printer axes so that none of them are in contact with an endstop. Send a QUERY_ENDSTOPS command via the command console. It should respond with the current state of all of the configured endstops and they should all report a state of \"open\". For each of the endstops, rerun the QUERY_ENDSTOPS command while manually triggering the endstop. The QUERY_ENDSTOPS command should report the endstop as \"TRIGGERED\". If the endstop appears inverted (it reports \"open\" when triggered and vice-versa) then add a \"!\" to the pin definition (for example, \"endstop_pin: ^PA2\"), or remove the \"!\" if there is already one present. Se il segnale del finecorsa non cambia , pu\u00f2 significare che il fine corsa \u00e8 collegato a un pin diverso. Tuttavia, potrebbe essere necessaria una modifica all'impostazione pullup del pin (il '^' all'inizio del istruzione \"endstop_pin\".La maggior parte delle stampanti utilizzano un resistore pullup e l'istruzione '^' dovrebbe essere presente). Verifica dei motori passo-passo \u00b6 Use the STEPPER_BUZZ command to verify the connectivity of each stepper motor. Start by manually positioning the given axis to a midway point and then run STEPPER_BUZZ STEPPER=stepper_x in the command console. The STEPPER_BUZZ command will cause the given stepper to move one millimeter in a positive direction and then it will return to its starting position. (If the endstop is defined at position_endstop=0 then at the start of each movement the stepper will move away from the endstop.) It will perform this oscillation ten times. Se il motore passo-passo non si muove , verifica le impostazioni \"enable_pin\" e \"step_pin\" sul driver. Se il motore passo-passo si muove ma non torna nella sua posizione originale, verificare l'impostazione \"dir_pin\". Se il motore passo-passo oscilla in una direzione errata, generalmente sta a significare che \u00e8 necessario invertire il \"dir_pin\" del l'asse. Questo viene fatto aggiungendo un istruzione '!' alla \"dir_pin\" nel file di configurazione della stampante (o rimuovendolo se ne esiste gi\u00e0 presente). Se il motore passo-passo si muove di pi\u00f9 o di meno di un millimetro, verificare l'impostazione \"rotation_distance\". Eseguire il test sopra descritto per ogni motore passo-passo definito nel file di configurazione. (Impostare il parametro STEPPER del comando STEPPER_BUZZ sul nome della sezione di configurazione da testare.) Se non \u00e8 presente il filamento nell'estrusore, \u00e8 possibile utilizzare STEPPER_BUZZ per verificare la connessione del motore dell'estrusore (usare STEPPER=estrusore). In caso contrario, \u00e8 meglio testare il motore dell'estrusore per conto suo (vedere la sezione successiva). Dopo aver verificato tutti i finecorsa e aver verificato tutti i motori passo-passo, \u00e8 necessario testare il sistema di homing. Scrivere un comando G28 per portare a home tutti gli assi. Rimuovere l'alimentazione dalla stampante se l'istruzione non funziona correttamente. Se necessario, ripetere i passaggi di verifica del finecorsa e del motore passo-passo. Verifica il motore dell'estrusore \u00b6 To test the extruder motor it will be necessary to heat the extruder to a printing temperature. Navigate to the temperature graph section and select a target temperature from the temperature drop-down box (or manually enter an appropriate temperature). Wait for the printer to reach the desired temperature. Then navigate to the command console and click the \"Extrude\" button. Verify that the extruder motor turns in the correct direction. If it does not, see the troubleshooting tips in the previous section to confirm the \"enable_pin\", \"step_pin\", and \"dir_pin\" settings for the extruder. Calibrare le impostazioni del PID \u00b6 Klipper supporta il sistema controllo PID per iriscaldatori dell'estrusore e del piatto. Per utilizzare questo sistema di controllo, \u00e8 necessario calibrare le impostazioni PID su ciascuna stampante (le impostazioni PID presenti in altri firmware o nei file di configurazione di esempio spesso funzionano male). To calibrate the extruder, navigate to the command console and run the PID_CALIBRATE command. For example: PID_CALIBRATE HEATER=extruder TARGET=170 Al termine del test di ottimizzazione, eseguire l'istruzione SAVE_CONFIG per aggiornare il file printer.cfg con le nuove impostazioni PID. Se la stampante ha un piatto riscaldato ed \u00e8 dotato di azionamento con funzione PWM (Pulse Width Modulation), si consiglia di utilizzare il controllo PID anche per il piatto. (Quando il riscaldatore del piatto \u00e8 controllato utilizzando l'algoritmo PID, potrebbe accendersi e spegnersi dieci volte al secondo, il che potrebbe non essere adatto per i riscaldatori che utilizzano un rel\u00e8 elettromeccanico.) Un tipico comando per calibrazione PID del piatto \u00e8: PID_CALIBRATE HEATER=heater_bed TARGET= 60 Passi sucessivi \u00b6 Questa guida ha lo scopo di aiutare la verifica delle impostazioni di base riferite ai pin presenti nel file di configurazione di Klipper. Assicurati di leggere la guida bed leveling . Consulta anche il documento Slicers per informazioni sulla configurazione di un software slicer con Klipper. Dopo aver verificato che la stampa di base funziona, \u00e8 una buona prassi procedere con la calibrazione avanzamento pressione . Potrebbe essere necessario eseguire altri tipi di calibrazione di dettaglio in riferimento alla stampante: sono disponibili numerose guide online per questo scopo (ad esempio, eseguire una ricerca sul Web per \"calibrazione della stampante 3d\"). Ad esempio, se si verifica l'effetto chiamato risonanza, \u00e8 possibile provare a seguire la calibrazione tramite l'istruzione compensazione della risonanza .","title":"Controlli della configurazione"},{"location":"Config_checks.html#controlli-della-configurazione","text":"Questo documento fornisce una lista di step per confermare le impostazioni dei pin nel file printer.cfg di Klipper. \u00c8 una buona idea eseguire questi passi dopo aver seguito i passi nel documento di installazione . In alcuni passaggi di questa guida, potrebbe essere necessario modificare il file di configurazione di Klipper. Assicuratevi di dare il comando RESTART, dopo ogni modifica al file di configurazione, per accertarsi che le modifiche abbiano effetto(scrivere \"restart\" nella scheda del terminale di Octoprint e cliccare su INVIA). E' anche consigliabile utilizzare il comando STATUS, dopo ogni RESTART, per verificare che il file di configurazione sia stato caricato correttamente.","title":"Controlli della configurazione"},{"location":"Config_checks.html#verifica-delle-temperature","text":"Inizia verificando che le temperature siano riportate correttamente. Naviga nella sezione della temperatura nell'interfaccia utente. Verifica che la temperatura del nozzle e del letto (se possibile) sono presenti e non aumentino. Nel caso aumentino, togli corrente alla stampante. Se le temperature non sono accurate, ricontrolla le impostazioni del nozzle e del letto chiamate \"sensor_type\" e \"sensor_pin\".","title":"Verifica delle temperature"},{"location":"Config_checks.html#verifica-m112","text":"Naviga nella console dei comandi e invia un comando M112 nel terminale. Questo comando chiede a Klipper di andare in uno stato di spegnimento. Ci\u00f2 causer\u00e0 un errore, che potr\u00e0 essere risolto con l'esecuzione di un comando \"FIRMWARE_RESTART\" nella console. Anche octoprint richieder\u00e0 una riconessione. Poi vai nella sezione delle temperature e verifica che esse continuino ad aggiornarsi e non incrementino. Se le temperature incrementano togliere immediatamente corrente alla stampante.","title":"Verifica M112"},{"location":"Config_checks.html#verifica-i-riscaldatori","text":"Navigate to the temperature graph section and type in 50 followed by enter in the extruder/tool temperature box. The extruder temperature in the graph should start to increase (within about 30 seconds or so). Then go to the extruder temperature drop-down box and select \"Off\". After several minutes the temperature should start to return to its initial room temperature value. If the temperature does not increase then verify the \"heater_pin\" setting in the config. Se la stampante ha il piatto riscaldato, eseguire nuovamente il test indicato in precedenza ma per il piatto.","title":"Verifica i riscaldatori"},{"location":"Config_checks.html#verifica-il-pin-di-abilitazione-del-motore-passo-passo","text":"Verifica che gli assi della stampante possano muoversi liberamente (I motori sono disabilitati). In caso contrario, inviare un comando M84 per disabilitare i motori. Se un asse qualunque non si potesse muovere liberamente, verificare la configurazione stepper \"enable_pin\" per gli assi in questione.Nella maggior parte dei driver per motori passo-passo, il pin di abilitazione del motore \u00e8 \"attivo basso\" e pertanto il pin di abilitazione deve essere preceduto da un \"!\" (ad esempio, \"enable_pin: !PA1\").","title":"Verifica il pin di abilitazione del motore passo-passo"},{"location":"Config_checks.html#verifica-i-finecorsa","text":"Manually move all the printer axes so that none of them are in contact with an endstop. Send a QUERY_ENDSTOPS command via the command console. It should respond with the current state of all of the configured endstops and they should all report a state of \"open\". For each of the endstops, rerun the QUERY_ENDSTOPS command while manually triggering the endstop. The QUERY_ENDSTOPS command should report the endstop as \"TRIGGERED\". If the endstop appears inverted (it reports \"open\" when triggered and vice-versa) then add a \"!\" to the pin definition (for example, \"endstop_pin: ^PA2\"), or remove the \"!\" if there is already one present. Se il segnale del finecorsa non cambia , pu\u00f2 significare che il fine corsa \u00e8 collegato a un pin diverso. Tuttavia, potrebbe essere necessaria una modifica all'impostazione pullup del pin (il '^' all'inizio del istruzione \"endstop_pin\".La maggior parte delle stampanti utilizzano un resistore pullup e l'istruzione '^' dovrebbe essere presente).","title":"Verifica i finecorsa"},{"location":"Config_checks.html#verifica-dei-motori-passo-passo","text":"Use the STEPPER_BUZZ command to verify the connectivity of each stepper motor. Start by manually positioning the given axis to a midway point and then run STEPPER_BUZZ STEPPER=stepper_x in the command console. The STEPPER_BUZZ command will cause the given stepper to move one millimeter in a positive direction and then it will return to its starting position. (If the endstop is defined at position_endstop=0 then at the start of each movement the stepper will move away from the endstop.) It will perform this oscillation ten times. Se il motore passo-passo non si muove , verifica le impostazioni \"enable_pin\" e \"step_pin\" sul driver. Se il motore passo-passo si muove ma non torna nella sua posizione originale, verificare l'impostazione \"dir_pin\". Se il motore passo-passo oscilla in una direzione errata, generalmente sta a significare che \u00e8 necessario invertire il \"dir_pin\" del l'asse. Questo viene fatto aggiungendo un istruzione '!' alla \"dir_pin\" nel file di configurazione della stampante (o rimuovendolo se ne esiste gi\u00e0 presente). Se il motore passo-passo si muove di pi\u00f9 o di meno di un millimetro, verificare l'impostazione \"rotation_distance\". Eseguire il test sopra descritto per ogni motore passo-passo definito nel file di configurazione. (Impostare il parametro STEPPER del comando STEPPER_BUZZ sul nome della sezione di configurazione da testare.) Se non \u00e8 presente il filamento nell'estrusore, \u00e8 possibile utilizzare STEPPER_BUZZ per verificare la connessione del motore dell'estrusore (usare STEPPER=estrusore). In caso contrario, \u00e8 meglio testare il motore dell'estrusore per conto suo (vedere la sezione successiva). Dopo aver verificato tutti i finecorsa e aver verificato tutti i motori passo-passo, \u00e8 necessario testare il sistema di homing. Scrivere un comando G28 per portare a home tutti gli assi. Rimuovere l'alimentazione dalla stampante se l'istruzione non funziona correttamente. Se necessario, ripetere i passaggi di verifica del finecorsa e del motore passo-passo.","title":"Verifica dei motori passo-passo"},{"location":"Config_checks.html#verifica-il-motore-dellestrusore","text":"To test the extruder motor it will be necessary to heat the extruder to a printing temperature. Navigate to the temperature graph section and select a target temperature from the temperature drop-down box (or manually enter an appropriate temperature). Wait for the printer to reach the desired temperature. Then navigate to the command console and click the \"Extrude\" button. Verify that the extruder motor turns in the correct direction. If it does not, see the troubleshooting tips in the previous section to confirm the \"enable_pin\", \"step_pin\", and \"dir_pin\" settings for the extruder.","title":"Verifica il motore dell'estrusore"},{"location":"Config_checks.html#calibrare-le-impostazioni-del-pid","text":"Klipper supporta il sistema controllo PID per iriscaldatori dell'estrusore e del piatto. Per utilizzare questo sistema di controllo, \u00e8 necessario calibrare le impostazioni PID su ciascuna stampante (le impostazioni PID presenti in altri firmware o nei file di configurazione di esempio spesso funzionano male). To calibrate the extruder, navigate to the command console and run the PID_CALIBRATE command. For example: PID_CALIBRATE HEATER=extruder TARGET=170 Al termine del test di ottimizzazione, eseguire l'istruzione SAVE_CONFIG per aggiornare il file printer.cfg con le nuove impostazioni PID. Se la stampante ha un piatto riscaldato ed \u00e8 dotato di azionamento con funzione PWM (Pulse Width Modulation), si consiglia di utilizzare il controllo PID anche per il piatto. (Quando il riscaldatore del piatto \u00e8 controllato utilizzando l'algoritmo PID, potrebbe accendersi e spegnersi dieci volte al secondo, il che potrebbe non essere adatto per i riscaldatori che utilizzano un rel\u00e8 elettromeccanico.) Un tipico comando per calibrazione PID del piatto \u00e8: PID_CALIBRATE HEATER=heater_bed TARGET= 60","title":"Calibrare le impostazioni del PID"},{"location":"Config_checks.html#passi-sucessivi","text":"Questa guida ha lo scopo di aiutare la verifica delle impostazioni di base riferite ai pin presenti nel file di configurazione di Klipper. Assicurati di leggere la guida bed leveling . Consulta anche il documento Slicers per informazioni sulla configurazione di un software slicer con Klipper. Dopo aver verificato che la stampa di base funziona, \u00e8 una buona prassi procedere con la calibrazione avanzamento pressione . Potrebbe essere necessario eseguire altri tipi di calibrazione di dettaglio in riferimento alla stampante: sono disponibili numerose guide online per questo scopo (ad esempio, eseguire una ricerca sul Web per \"calibrazione della stampante 3d\"). Ad esempio, se si verifica l'effetto chiamato risonanza, \u00e8 possibile provare a seguire la calibrazione tramite l'istruzione compensazione della risonanza .","title":"Passi sucessivi"},{"location":"Contact.html","text":"Contatti \u00b6 Questo documento fornisce informazioni di contatto per Klipper. Forum della comunit\u00e0 Chat Discord Ho una domanda su Klipper Ho una richiesta per una funzionalit\u00e0 Aiuto! Non funziona! I found a bug in the Klipper software Sto apportando modifiche che vorrei includere in Klipper Klipper github Forum della Comunit\u00e0 \u00b6 C'\u00e8 un server Klipper Community Discourse server per discussioni su Klipper. Chat Discord \u00b6 C'\u00e8 un serve Discord dedicato a Klipper a: https://discord.klipper3d.org . Questo server \u00e8 gestito da una comunit\u00e0 di appassionati di Klipper dediti alle discussioni su Klipper. Consente agli utenti di chattare con altri utenti in tempo reale. Ho una domanda su Klipper \u00b6 Molte domande che riceviamo hanno gi\u00e0 una risposta nella Klipper documentation . Per favore assicurati di leggere la documentazione e di seguire le indicazioni fornite. \u00c8 anche possibile cercare domande simili nel Klipper Community Forum . Se sei interessato a condividere le tue conoscenze ed esperienze con altri utenti di Klipper, puoi unirti al Klipper Community Forum o Klipper Discord Chat . Entrambe sono comunit\u00e0 in cui gli utenti di Klipper possono discutere di Klipper con altri utenti. Molte domande che riceviamo sono domande generiche sulla stampa 3D che non sono specifiche di Klipper. Se hai una domanda generica o stai riscontrando problemi di stampa generici, probabilmente otterrai una risposta migliore chiedendo in un forum generale sulla stampa 3D o in un forum dedicato all'hardware della tua stampante. Ho una richiesta per una funzionalit\u00e0 \u00b6 Tutte le nuove funzionalit\u00e0 richiedono qualcuno interessato e in grado di implementare tale funzionalit\u00e0. Se sei interessato ad aiutare a implementare o testare una nuova funzionalit\u00e0, puoi cercare gli sviluppi coinvolti nel Klipper Community Forum . C'\u00e8 anche Klipper Discord Chat per le discussioni tra i collaboratori. Aiuto! Non funziona! \u00b6 Sfortunatamente, riceviamo molte pi\u00f9 richieste di aiuto di quante potremmo eventualmente rispondere. La maggior parte delle segnalazioni di problemi che vediamo vengono infine rintracciate in: Piccoli nell'hardware, o Non seguendo tutti i passaggi descritti nella documentazione di Klipper. In caso di problemi, ti consigliamo di leggere attentamente la Klipper documentation e di verificare che tutti i passaggi siano stati seguiti. Se si verifica un problema di stampa, si consiglia di ispezionare attentamente l'hardware della stampante (tutti i giunti, i cavi, le viti, ecc.) e verificare che non vi siano anomalie. Scopriamo che la maggior parte dei problemi di stampa non sono correlati al software Klipper. Se trovi un problema con l'hardware della stampante, probabilmente otterrai una risposta migliore cercando in un forum generale di stampa 3D o in un forum dedicato all'hardware della tua stampante. \u00c8 anche possibile cercare problemi simili in Klipper Community Forum . Se sei interessato a condividere le tue conoscenze ed esperienze con altri utenti di Klipper, puoi unirti al Klipper Community Forum o Klipper Discord Chat . Entrambe sono comunit\u00e0 in cui gli utenti di Klipper possono discutere di Klipper con altri utenti. Ho trovato un bug nel software Klipper \u00b6 Klipper \u00e8 un progetto open-source ed apprezziamo quando i collaboratori diagnosticano errori nel software. I problemi devono essere segnalati nel Klipper Community Forum . Ci sono informazioni importanti che saranno necessarie per correggere un bug. Per favore segui questi passaggi: Assicurati di eseguire codice non modificato da https://github.com/Klipper3d/klipper . Se il codice \u00e8 stato modificato o \u00e8 stato ottenuto da un'altra fonte, \u00e8 necessario riprodurre il problema sul codice non modificato da https://github.com/Klipper3d/klipper prima della segnalazione. Se possibile, eseguire un comando M112 immediatamente dopo che si \u00e8 verificato l'evento indesiderato. Ci\u00f2 fa s\u00ec che Klipper entri in uno \"shutdown state\" e causer\u00e0 la scrittura di ulteriori informazioni di debug nel file di registro. Ottieni il log file di Klipper dell'evento. Il file di registro \u00e8 stato progettato per rispondere alle domande pi\u00f9 comuni degli sviluppatori di Klipper sul software e sul suo ambiente (versione del software, tipo di hardware, configurazione, tempistica degli eventi e centinaia di altre domande). Il log file di Klipper si trova in /tmp/klippy.log sul computer \"host\" di Klipper (il Raspberry Pi). Un comando o utility \"scp\" o \"sftp\" \u00e8 necessario per copiare questo file di registro sul computer desktop. L'utilit\u00e0 \"scp\" viene fornita di serie con i desktop Linux e MacOS. Ci sono utilit\u00e0 scp disponibili gratuitamente per altri desktop (ad es. WinSCP). Se si utilizza un'interfaccia grafica scp che non pu\u00f2 copiare direttamente /tmp/klippy.log , fare clic ripetutamente su .. o cartella principale fino ad arrivare alla directory principale, fare clic sulla cartella tmp , quindi seleziona il file klippy.log . Copia il lof file sul desktop in modo che possa essere allegato a una segnalazione di problema. Non modificare in alcun modo il log file; non editare o ritagliare il log file. Solo il file di log completo non modificato fornisce le informazioni necessarie. \u00c8 una buona idea comprimere il file di registro con zip o gzip. Apri un nuovo topic sul Klipper Community Forum e fornisci una descrizione chiara del problema. Altri contributori di Klipper dovranno capire quali passi sono stati compiuti, quale era il risultato desiderato e quale risultato si \u00e8 effettivamente verificato. Il file di registro compresso di Klipper dovrebbe essere allegato a quel topic. Sto apportando modifiche che vorrei includere in Klipper \u00b6 Klipper \u00e8 un software open-source e apprezziamo i nuovi contributi. I nuovi contributi (sia per il codice che per la documentazione) vengono inviati tramite Github Pull Requests. Vedere [ CONTRIBUTING document per informazioni importanti. Ci sono diversi documenti per sviluppatori . Se hai domande sul codice, puoi anche chiedere nel Klipper Community Forum o nella Klipper Community Discord . Klipper github \u00b6 Klipper github pu\u00f2 essere utilizzato dai contributori per condividere lo stato del loro lavoro per migliorare Klipper. Ci si aspetta che la persona che apre un ticket github stia lavorando attivamente all'attivit\u00e0 specificata e sar\u00e0 quella che eseguir\u00e0 tutto il lavoro necessario per realizzarla. Il github di Klipper non viene utilizzato per richieste, n\u00e9 per segnalare bug, n\u00e9 per porre domande. Usa invece il Klipper Community Forum o la Klipper Community Discord .","title":"Contatti"},{"location":"Contact.html#contatti","text":"Questo documento fornisce informazioni di contatto per Klipper. Forum della comunit\u00e0 Chat Discord Ho una domanda su Klipper Ho una richiesta per una funzionalit\u00e0 Aiuto! Non funziona! I found a bug in the Klipper software Sto apportando modifiche che vorrei includere in Klipper Klipper github","title":"Contatti"},{"location":"Contact.html#forum-della-comunita","text":"C'\u00e8 un server Klipper Community Discourse server per discussioni su Klipper.","title":"Forum della Comunit\u00e0"},{"location":"Contact.html#chat-discord","text":"C'\u00e8 un serve Discord dedicato a Klipper a: https://discord.klipper3d.org . Questo server \u00e8 gestito da una comunit\u00e0 di appassionati di Klipper dediti alle discussioni su Klipper. Consente agli utenti di chattare con altri utenti in tempo reale.","title":"Chat Discord"},{"location":"Contact.html#ho-una-domanda-su-klipper","text":"Molte domande che riceviamo hanno gi\u00e0 una risposta nella Klipper documentation . Per favore assicurati di leggere la documentazione e di seguire le indicazioni fornite. \u00c8 anche possibile cercare domande simili nel Klipper Community Forum . Se sei interessato a condividere le tue conoscenze ed esperienze con altri utenti di Klipper, puoi unirti al Klipper Community Forum o Klipper Discord Chat . Entrambe sono comunit\u00e0 in cui gli utenti di Klipper possono discutere di Klipper con altri utenti. Molte domande che riceviamo sono domande generiche sulla stampa 3D che non sono specifiche di Klipper. Se hai una domanda generica o stai riscontrando problemi di stampa generici, probabilmente otterrai una risposta migliore chiedendo in un forum generale sulla stampa 3D o in un forum dedicato all'hardware della tua stampante.","title":"Ho una domanda su Klipper"},{"location":"Contact.html#ho-una-richiesta-per-una-funzionalita","text":"Tutte le nuove funzionalit\u00e0 richiedono qualcuno interessato e in grado di implementare tale funzionalit\u00e0. Se sei interessato ad aiutare a implementare o testare una nuova funzionalit\u00e0, puoi cercare gli sviluppi coinvolti nel Klipper Community Forum . C'\u00e8 anche Klipper Discord Chat per le discussioni tra i collaboratori.","title":"Ho una richiesta per una funzionalit\u00e0"},{"location":"Contact.html#aiuto-non-funziona","text":"Sfortunatamente, riceviamo molte pi\u00f9 richieste di aiuto di quante potremmo eventualmente rispondere. La maggior parte delle segnalazioni di problemi che vediamo vengono infine rintracciate in: Piccoli nell'hardware, o Non seguendo tutti i passaggi descritti nella documentazione di Klipper. In caso di problemi, ti consigliamo di leggere attentamente la Klipper documentation e di verificare che tutti i passaggi siano stati seguiti. Se si verifica un problema di stampa, si consiglia di ispezionare attentamente l'hardware della stampante (tutti i giunti, i cavi, le viti, ecc.) e verificare che non vi siano anomalie. Scopriamo che la maggior parte dei problemi di stampa non sono correlati al software Klipper. Se trovi un problema con l'hardware della stampante, probabilmente otterrai una risposta migliore cercando in un forum generale di stampa 3D o in un forum dedicato all'hardware della tua stampante. \u00c8 anche possibile cercare problemi simili in Klipper Community Forum . Se sei interessato a condividere le tue conoscenze ed esperienze con altri utenti di Klipper, puoi unirti al Klipper Community Forum o Klipper Discord Chat . Entrambe sono comunit\u00e0 in cui gli utenti di Klipper possono discutere di Klipper con altri utenti.","title":"Aiuto! Non funziona!"},{"location":"Contact.html#ho-trovato-un-bug-nel-software-klipper","text":"Klipper \u00e8 un progetto open-source ed apprezziamo quando i collaboratori diagnosticano errori nel software. I problemi devono essere segnalati nel Klipper Community Forum . Ci sono informazioni importanti che saranno necessarie per correggere un bug. Per favore segui questi passaggi: Assicurati di eseguire codice non modificato da https://github.com/Klipper3d/klipper . Se il codice \u00e8 stato modificato o \u00e8 stato ottenuto da un'altra fonte, \u00e8 necessario riprodurre il problema sul codice non modificato da https://github.com/Klipper3d/klipper prima della segnalazione. Se possibile, eseguire un comando M112 immediatamente dopo che si \u00e8 verificato l'evento indesiderato. Ci\u00f2 fa s\u00ec che Klipper entri in uno \"shutdown state\" e causer\u00e0 la scrittura di ulteriori informazioni di debug nel file di registro. Ottieni il log file di Klipper dell'evento. Il file di registro \u00e8 stato progettato per rispondere alle domande pi\u00f9 comuni degli sviluppatori di Klipper sul software e sul suo ambiente (versione del software, tipo di hardware, configurazione, tempistica degli eventi e centinaia di altre domande). Il log file di Klipper si trova in /tmp/klippy.log sul computer \"host\" di Klipper (il Raspberry Pi). Un comando o utility \"scp\" o \"sftp\" \u00e8 necessario per copiare questo file di registro sul computer desktop. L'utilit\u00e0 \"scp\" viene fornita di serie con i desktop Linux e MacOS. Ci sono utilit\u00e0 scp disponibili gratuitamente per altri desktop (ad es. WinSCP). Se si utilizza un'interfaccia grafica scp che non pu\u00f2 copiare direttamente /tmp/klippy.log , fare clic ripetutamente su .. o cartella principale fino ad arrivare alla directory principale, fare clic sulla cartella tmp , quindi seleziona il file klippy.log . Copia il lof file sul desktop in modo che possa essere allegato a una segnalazione di problema. Non modificare in alcun modo il log file; non editare o ritagliare il log file. Solo il file di log completo non modificato fornisce le informazioni necessarie. \u00c8 una buona idea comprimere il file di registro con zip o gzip. Apri un nuovo topic sul Klipper Community Forum e fornisci una descrizione chiara del problema. Altri contributori di Klipper dovranno capire quali passi sono stati compiuti, quale era il risultato desiderato e quale risultato si \u00e8 effettivamente verificato. Il file di registro compresso di Klipper dovrebbe essere allegato a quel topic.","title":"Ho trovato un bug nel software Klipper"},{"location":"Contact.html#sto-apportando-modifiche-che-vorrei-includere-in-klipper","text":"Klipper \u00e8 un software open-source e apprezziamo i nuovi contributi. I nuovi contributi (sia per il codice che per la documentazione) vengono inviati tramite Github Pull Requests. Vedere [ CONTRIBUTING document per informazioni importanti. Ci sono diversi documenti per sviluppatori . Se hai domande sul codice, puoi anche chiedere nel Klipper Community Forum o nella Klipper Community Discord .","title":"Sto apportando modifiche che vorrei includere in Klipper"},{"location":"Contact.html#klipper-github","text":"Klipper github pu\u00f2 essere utilizzato dai contributori per condividere lo stato del loro lavoro per migliorare Klipper. Ci si aspetta che la persona che apre un ticket github stia lavorando attivamente all'attivit\u00e0 specificata e sar\u00e0 quella che eseguir\u00e0 tutto il lavoro necessario per realizzarla. Il github di Klipper non viene utilizzato per richieste, n\u00e9 per segnalare bug, n\u00e9 per porre domande. Usa invece il Klipper Community Forum o la Klipper Community Discord .","title":"Klipper github"},{"location":"Debugging.html","text":"Debugging \u00b6 Questo documento descrive alcuni degli strumenti di debug di Klipper. Esecuzione dei test di regressione \u00b6 Il repository principale di Klipper GitHub utilizza \"github actions\" per eseguire una serie di test di regressione. Pu\u00f2 essere utile eseguire alcuni di questi test in locale. Il sorgente \"controllo spazi bianchi\" pu\u00f2 essere eseguito con: ./scripts/check_whitespace.sh La suite di test di regressione Klippy richiede \"dizionari di dati\" da molte piattaforme. Il modo pi\u00f9 semplice per ottenerli \u00e8 scaricarli da github . Una volta scaricati i dizionari di dati, utilizzare quanto segue per eseguire la suite di regressione: tar xfz klipper-dict-20??????.tar.gz ~/klippy-env/bin/python ~/klipper/scripts/test_klippy.py -d dict/ ~/klipper/test/klippy/*.test Invio manuale di comandi al microcontrollore \u00b6 Normalmente, il processo host klippy.py verrebbe utilizzato per tradurre i comandi gcode in comandi del microcontrollore Klipper. Tuttavia, \u00e8 anche possibile inviare manualmente questi comandi MCU (funzioni contrassegnate con la macro DECL_COMMAND() nel codice sorgente di Klipper). Per farlo, esegui: ~/klippy-env/bin/python ./klippy/console.py /tmp/pseudoserial Vedere il comando \"HELP\" all'interno dello strumento per ulteriori informazioni sulla sua funzionalit\u00e0. Sono disponibili alcune opzioni della riga di comando. Per ulteriori informazioni esegui: ~/klippy-env/bin/python ./klippy/console.py --help Traduzione di file gcode in comandi del microcontrollore \u00b6 Il codice host Klippy pu\u00f2 essere eseguito in modalit\u00e0 batch per produrre i comandi del microcontrollore di basso livello associati a un file gcode. L'ispezione di questi comandi di basso livello \u00e8 utile quando si cerca di comprendere le azioni dell'hardware di basso livello. Pu\u00f2 anche essere utile confrontare la differenza nei comandi del microcontrollore dopo una modifica del codice. Per eseguire Klippy in questa modalit\u00e0 batch, \u00e8 necessario un passaggio per generare il \"dizionario dati\" del microcontrollore. Questo viene fatto compilando il codice del microcontrollore per ottenere il file out/klipper.dict : make menuconfig make Una volta fatto quanto sopra \u00e8 possibile eseguire Klipper in modalit\u00e0 batch (vedi installazione per i passaggi necessari per costruire l'ambiente virtuale python e un file printer.cfg): ~/klippy-env/bin/python ./klippy/klippy.py ~/printer.cfg -i test.gcode -o test.serial -v -d out/klipper.dict Quanto sopra produrr\u00e0 un file test.serial con output seriale binario. Questo output pu\u00f2 essere tradotto in testo leggibile con: ~/klippy-env/bin/python ./klippy/parsedump.py out/klipper.dict test.serial > test.txt Il file risultante test.txt contiene un elenco leggibile di comandi del microcontrollore. La modalit\u00e0 batch disabilita alcuni comandi di risposta/richiesta per funzionare. Di conseguenza, ci saranno alcune differenze tra i comandi effettivi e l'output sopra. I dati generati sono utili per il test e l'ispezione; non \u00e8 utile per l'invio a un vero microcontrollore. Analisi del movimento e registrazione dei dati \u00b6 Klipper supporta la registrazione della cronologia dei movimenti interni, che pu\u00f2 essere analizzata in seguito. Per utilizzare questa funzione, Klipper deve essere avviato con Server API abilitato. La registrazione dei dati \u00e8 abilitata con lo strumento data_logger.py . Per esempio: ~/klipper/scripts/motan/data_logger.py /tmp/klippy_uds mylog Questo comando si collegher\u00e0 al Klipper API Server, sottoscriver\u00e0 le informazioni sullo stato e sul movimento e registrer\u00e0 i risultati. Vengono generati due file: un file di dati compresso e un file di indice (ad esempio, mylog.json.gz e mylog.index.gz ). Dopo aver avviato la registrazione, \u00e8 possibile completare le stampe e altre azioni: la registrazione continuer\u00e0 in background. Al termine della registrazione, premi ctrl-c per uscire dallo strumento data_logger.py . I file risultanti possono essere letti e rappresentati graficamente utilizzando lo strumento motan_graph.py . Per generare grafici su un Raspberry Pi, \u00e8 necessario un passaggio per installare il pacchetto \"matplotlib\": sudo apt-get update sudo apt-get install python-matplotlib Tuttavia, potrebbe essere pi\u00f9 conveniente copiare i file di dati su una macchina di classe desktop insieme al codice Python nella directory scripts/motan/ . Gli script di analisi del movimento dovrebbero essere eseguiti su qualsiasi macchina con una versione recente di Python e Matplotlib installata. I grafici possono essere generati con un comando come il seguente: ~/klipper/scripts/motan/motan_graph.py mylog -o mygraph.png One can use the -g option to specify the datasets to graph (it takes a Python literal containing a list of lists). For example: ~/klipper/scripts/motan/motan_graph.py mylog -g '[[\"trapq(toolhead,velocity)\"], [\"trapq(toolhead,accel)\"]]' L'elenco dei set di dati disponibili pu\u00f2 essere trovato usando l'opzione -l , ad esempio: ~/klipper/scripts/motan/motan_graph.py -l \u00c8 anche possibile specificare le opzioni di stampa matplotlib per ogni set di dati: ~/klipper/scripts/motan/motan_graph.py mylog -g '[[\"trapq(toolhead,velocity)?color=red&alpha=0.4\"]]' Sono disponibili molte opzioni di matplotlib; alcuni esempi sono \"color\", \"label\", \"alpha\" e \"linestyle\". Lo strumento motan_graph.py supporta molte altre opzioni della riga di comando: usa l'opzione --help per vedere un elenco. Pu\u00f2 anche essere conveniente visualizzare/modificare lo stesso script motan_graph.py . I log di dati grezzi prodotti dallo strumento data_logger.py seguono il formato descritto in Server API . Pu\u00f2 essere utile ispezionare i dati con un comando Unix come il seguente: gunzip < mylog.json.gz | tr '\\03' '\\n' | less Generare di grafici di carico \u00b6 Il file di registro di Klippy (/tmp/klippy.log) memorizza le statistiche sulla larghezza di banda, sul carico del microcontrollore e sul carico del buffer dell'host. Pu\u00f2 essere utile rappresentare graficamente queste statistiche dopo una stampa. Per generare un grafico, \u00e8 necessario un passaggio una tantum per installare il pacchetto \"matplotlib\": sudo apt-get update sudo apt-get install python-matplotlib Quindi i grafici possono essere prodotti con: ~/klipper/scripts/graphstats.py /tmp/klippy.log -o loadgraph.png Si pu\u00f2 quindi visualizzare il file loadgraph.png risultante. Possono essere prodotti diversi grafici. Per ulteriori informazioni esegui: ~/klipper/scripts/graphstats.py --help Estrazione di informazioni dal file klippy.log \u00b6 Anche il file di registro di Klippy (/tmp/klippy.log) contiene informazioni di debug. Esiste uno script logextract.py che pu\u00f2 essere utile quando si analizza l'arresto di un microcontrollore o un problema simile. In genere viene eseguito con qualcosa come: mkdir work_directory cd work_directory cp /tmp/klippy.log . ~/klipper/scripts/logextract.py ./klippy.log Lo script estrarr\u00e0 il file di configurazione della stampante ed estrarr\u00e0 le informazioni di arresto dell'MCU. I dump delle informazioni da un arresto dell'MCU (se presente) verranno riordinati in base al timestamp per facilitare la diagnosi degli scenari di causa ed effetto. Test con simulavr \u00b6 Lo strumento simulavr consente di simulare un microcontrollore Atmel ATmega. Questa sezione descrive come eseguire test di file gcode tramite simulavr. Si consiglia di eseguirlo su una macchina di classe desktop (non un Raspberry Pi) poich\u00e9 richiede una CPU significativa per funzionare in modo efficiente. Per utilizzare simulavr, scarica il pacchetto simulavr e compila con il supporto python. Nota che il sistema di build potrebbe aver bisogno di alcuni pacchetti (come swig) installati per costruire il modulo python. git clone git://git.savannah.nongnu.org/simulavr.git cd simulavr make python make build Assicurati che un file come ./build/pysimulavr/_pysimulavr.*.so sia presente dopo la compilazione di cui sopra: ls ./build/pysimulavr/_pysimulavr.*.so Questo comando dovrebbe segnalare un file specifico (ad esempio ./build/pysimulavr/_pysimulavr.cpython-39-x86_64-linux-gnu.so ) e non un errore. Se utilizzi un sistema basato su Debian (Debian, Ubuntu, ecc.) puoi installare i seguenti pacchetti e generare file *.deb per l'installazione di simulavr a livello di sistema: sudo apt update sudo apt install g++ make cmake swig rst2pdf help2man texinfo make cfgclean python debian sudo dpkg -i build/debian/python3-simulavr*.deb Per compilare Klipper per l'uso in simulavr, eseguire: cd /path/to/klipper make menuconfig e compilare il software del microcontrollore per un AVR atmega644p e selezionare il supporto per l'emulazione del software SIMULAVR. Quindi si pu\u00f2 compilare Klipper (eseguire make ) e quindi avviare la simulazione con: PYTHONPATH=/path/to/simulavr/build/pysimulavr/ ./scripts/avrsim.py out/klipper.elf Nota che se hai installato python3-simulavr a livello di sistema, non \u00e8 necessario impostare PYTHONPATH e puoi semplicemente eseguire il simulatore come ./scripts/avrsim.py out/klipper.elf Quindi, con simulavr in esecuzione in un'altra finestra, \u00e8 possibile eseguire quanto segue per leggere gcode da un file (ad es. \"test.gcode\"), elaborarlo con Klippy e inviarlo a Klipper in esecuzione in simulavr (vedere installazione per i passaggi necessari per costruire l'ambiente virtuale Python): ~/klippy-env/bin/python ./klippy/klippy.py config/generic-simulavr.cfg -i test.gcode -v Utilizzo di simulavr con gtkwave \u00b6 Una caratteristica utile di simulavr \u00e8 la sua capacit\u00e0 di creare file di generazione di onde di segnale con l'esatta sincronizzazione degli eventi. Per fare ci\u00f2, segui le istruzioni sopra, ma esegui avrsim.py con una riga di comando come la seguente: PYTHONPATH=/path/to/simulavr/src/python/ ./scripts/avrsim.py out/klipper.elf -t PORTA.PORT,PORTC.PORT Quanto sopra creerebbe un file avrsim.vcd con informazioni su ogni modifica ai GPIO su PORTA e PORTB. Questo potrebbe quindi essere visualizzato usando gtkwave con: gtkwave avrsim.vcd","title":"Debugging"},{"location":"Debugging.html#debugging","text":"Questo documento descrive alcuni degli strumenti di debug di Klipper.","title":"Debugging"},{"location":"Debugging.html#esecuzione-dei-test-di-regressione","text":"Il repository principale di Klipper GitHub utilizza \"github actions\" per eseguire una serie di test di regressione. Pu\u00f2 essere utile eseguire alcuni di questi test in locale. Il sorgente \"controllo spazi bianchi\" pu\u00f2 essere eseguito con: ./scripts/check_whitespace.sh La suite di test di regressione Klippy richiede \"dizionari di dati\" da molte piattaforme. Il modo pi\u00f9 semplice per ottenerli \u00e8 scaricarli da github . Una volta scaricati i dizionari di dati, utilizzare quanto segue per eseguire la suite di regressione: tar xfz klipper-dict-20??????.tar.gz ~/klippy-env/bin/python ~/klipper/scripts/test_klippy.py -d dict/ ~/klipper/test/klippy/*.test","title":"Esecuzione dei test di regressione"},{"location":"Debugging.html#invio-manuale-di-comandi-al-microcontrollore","text":"Normalmente, il processo host klippy.py verrebbe utilizzato per tradurre i comandi gcode in comandi del microcontrollore Klipper. Tuttavia, \u00e8 anche possibile inviare manualmente questi comandi MCU (funzioni contrassegnate con la macro DECL_COMMAND() nel codice sorgente di Klipper). Per farlo, esegui: ~/klippy-env/bin/python ./klippy/console.py /tmp/pseudoserial Vedere il comando \"HELP\" all'interno dello strumento per ulteriori informazioni sulla sua funzionalit\u00e0. Sono disponibili alcune opzioni della riga di comando. Per ulteriori informazioni esegui: ~/klippy-env/bin/python ./klippy/console.py --help","title":"Invio manuale di comandi al microcontrollore"},{"location":"Debugging.html#traduzione-di-file-gcode-in-comandi-del-microcontrollore","text":"Il codice host Klippy pu\u00f2 essere eseguito in modalit\u00e0 batch per produrre i comandi del microcontrollore di basso livello associati a un file gcode. L'ispezione di questi comandi di basso livello \u00e8 utile quando si cerca di comprendere le azioni dell'hardware di basso livello. Pu\u00f2 anche essere utile confrontare la differenza nei comandi del microcontrollore dopo una modifica del codice. Per eseguire Klippy in questa modalit\u00e0 batch, \u00e8 necessario un passaggio per generare il \"dizionario dati\" del microcontrollore. Questo viene fatto compilando il codice del microcontrollore per ottenere il file out/klipper.dict : make menuconfig make Una volta fatto quanto sopra \u00e8 possibile eseguire Klipper in modalit\u00e0 batch (vedi installazione per i passaggi necessari per costruire l'ambiente virtuale python e un file printer.cfg): ~/klippy-env/bin/python ./klippy/klippy.py ~/printer.cfg -i test.gcode -o test.serial -v -d out/klipper.dict Quanto sopra produrr\u00e0 un file test.serial con output seriale binario. Questo output pu\u00f2 essere tradotto in testo leggibile con: ~/klippy-env/bin/python ./klippy/parsedump.py out/klipper.dict test.serial > test.txt Il file risultante test.txt contiene un elenco leggibile di comandi del microcontrollore. La modalit\u00e0 batch disabilita alcuni comandi di risposta/richiesta per funzionare. Di conseguenza, ci saranno alcune differenze tra i comandi effettivi e l'output sopra. I dati generati sono utili per il test e l'ispezione; non \u00e8 utile per l'invio a un vero microcontrollore.","title":"Traduzione di file gcode in comandi del microcontrollore"},{"location":"Debugging.html#analisi-del-movimento-e-registrazione-dei-dati","text":"Klipper supporta la registrazione della cronologia dei movimenti interni, che pu\u00f2 essere analizzata in seguito. Per utilizzare questa funzione, Klipper deve essere avviato con Server API abilitato. La registrazione dei dati \u00e8 abilitata con lo strumento data_logger.py . Per esempio: ~/klipper/scripts/motan/data_logger.py /tmp/klippy_uds mylog Questo comando si collegher\u00e0 al Klipper API Server, sottoscriver\u00e0 le informazioni sullo stato e sul movimento e registrer\u00e0 i risultati. Vengono generati due file: un file di dati compresso e un file di indice (ad esempio, mylog.json.gz e mylog.index.gz ). Dopo aver avviato la registrazione, \u00e8 possibile completare le stampe e altre azioni: la registrazione continuer\u00e0 in background. Al termine della registrazione, premi ctrl-c per uscire dallo strumento data_logger.py . I file risultanti possono essere letti e rappresentati graficamente utilizzando lo strumento motan_graph.py . Per generare grafici su un Raspberry Pi, \u00e8 necessario un passaggio per installare il pacchetto \"matplotlib\": sudo apt-get update sudo apt-get install python-matplotlib Tuttavia, potrebbe essere pi\u00f9 conveniente copiare i file di dati su una macchina di classe desktop insieme al codice Python nella directory scripts/motan/ . Gli script di analisi del movimento dovrebbero essere eseguiti su qualsiasi macchina con una versione recente di Python e Matplotlib installata. I grafici possono essere generati con un comando come il seguente: ~/klipper/scripts/motan/motan_graph.py mylog -o mygraph.png One can use the -g option to specify the datasets to graph (it takes a Python literal containing a list of lists). For example: ~/klipper/scripts/motan/motan_graph.py mylog -g '[[\"trapq(toolhead,velocity)\"], [\"trapq(toolhead,accel)\"]]' L'elenco dei set di dati disponibili pu\u00f2 essere trovato usando l'opzione -l , ad esempio: ~/klipper/scripts/motan/motan_graph.py -l \u00c8 anche possibile specificare le opzioni di stampa matplotlib per ogni set di dati: ~/klipper/scripts/motan/motan_graph.py mylog -g '[[\"trapq(toolhead,velocity)?color=red&alpha=0.4\"]]' Sono disponibili molte opzioni di matplotlib; alcuni esempi sono \"color\", \"label\", \"alpha\" e \"linestyle\". Lo strumento motan_graph.py supporta molte altre opzioni della riga di comando: usa l'opzione --help per vedere un elenco. Pu\u00f2 anche essere conveniente visualizzare/modificare lo stesso script motan_graph.py . I log di dati grezzi prodotti dallo strumento data_logger.py seguono il formato descritto in Server API . Pu\u00f2 essere utile ispezionare i dati con un comando Unix come il seguente: gunzip < mylog.json.gz | tr '\\03' '\\n' | less","title":"Analisi del movimento e registrazione dei dati"},{"location":"Debugging.html#generare-di-grafici-di-carico","text":"Il file di registro di Klippy (/tmp/klippy.log) memorizza le statistiche sulla larghezza di banda, sul carico del microcontrollore e sul carico del buffer dell'host. Pu\u00f2 essere utile rappresentare graficamente queste statistiche dopo una stampa. Per generare un grafico, \u00e8 necessario un passaggio una tantum per installare il pacchetto \"matplotlib\": sudo apt-get update sudo apt-get install python-matplotlib Quindi i grafici possono essere prodotti con: ~/klipper/scripts/graphstats.py /tmp/klippy.log -o loadgraph.png Si pu\u00f2 quindi visualizzare il file loadgraph.png risultante. Possono essere prodotti diversi grafici. Per ulteriori informazioni esegui: ~/klipper/scripts/graphstats.py --help","title":"Generare di grafici di carico"},{"location":"Debugging.html#estrazione-di-informazioni-dal-file-klippylog","text":"Anche il file di registro di Klippy (/tmp/klippy.log) contiene informazioni di debug. Esiste uno script logextract.py che pu\u00f2 essere utile quando si analizza l'arresto di un microcontrollore o un problema simile. In genere viene eseguito con qualcosa come: mkdir work_directory cd work_directory cp /tmp/klippy.log . ~/klipper/scripts/logextract.py ./klippy.log Lo script estrarr\u00e0 il file di configurazione della stampante ed estrarr\u00e0 le informazioni di arresto dell'MCU. I dump delle informazioni da un arresto dell'MCU (se presente) verranno riordinati in base al timestamp per facilitare la diagnosi degli scenari di causa ed effetto.","title":"Estrazione di informazioni dal file klippy.log"},{"location":"Debugging.html#test-con-simulavr","text":"Lo strumento simulavr consente di simulare un microcontrollore Atmel ATmega. Questa sezione descrive come eseguire test di file gcode tramite simulavr. Si consiglia di eseguirlo su una macchina di classe desktop (non un Raspberry Pi) poich\u00e9 richiede una CPU significativa per funzionare in modo efficiente. Per utilizzare simulavr, scarica il pacchetto simulavr e compila con il supporto python. Nota che il sistema di build potrebbe aver bisogno di alcuni pacchetti (come swig) installati per costruire il modulo python. git clone git://git.savannah.nongnu.org/simulavr.git cd simulavr make python make build Assicurati che un file come ./build/pysimulavr/_pysimulavr.*.so sia presente dopo la compilazione di cui sopra: ls ./build/pysimulavr/_pysimulavr.*.so Questo comando dovrebbe segnalare un file specifico (ad esempio ./build/pysimulavr/_pysimulavr.cpython-39-x86_64-linux-gnu.so ) e non un errore. Se utilizzi un sistema basato su Debian (Debian, Ubuntu, ecc.) puoi installare i seguenti pacchetti e generare file *.deb per l'installazione di simulavr a livello di sistema: sudo apt update sudo apt install g++ make cmake swig rst2pdf help2man texinfo make cfgclean python debian sudo dpkg -i build/debian/python3-simulavr*.deb Per compilare Klipper per l'uso in simulavr, eseguire: cd /path/to/klipper make menuconfig e compilare il software del microcontrollore per un AVR atmega644p e selezionare il supporto per l'emulazione del software SIMULAVR. Quindi si pu\u00f2 compilare Klipper (eseguire make ) e quindi avviare la simulazione con: PYTHONPATH=/path/to/simulavr/build/pysimulavr/ ./scripts/avrsim.py out/klipper.elf Nota che se hai installato python3-simulavr a livello di sistema, non \u00e8 necessario impostare PYTHONPATH e puoi semplicemente eseguire il simulatore come ./scripts/avrsim.py out/klipper.elf Quindi, con simulavr in esecuzione in un'altra finestra, \u00e8 possibile eseguire quanto segue per leggere gcode da un file (ad es. \"test.gcode\"), elaborarlo con Klippy e inviarlo a Klipper in esecuzione in simulavr (vedere installazione per i passaggi necessari per costruire l'ambiente virtuale Python): ~/klippy-env/bin/python ./klippy/klippy.py config/generic-simulavr.cfg -i test.gcode -v","title":"Test con simulavr"},{"location":"Debugging.html#utilizzo-di-simulavr-con-gtkwave","text":"Una caratteristica utile di simulavr \u00e8 la sua capacit\u00e0 di creare file di generazione di onde di segnale con l'esatta sincronizzazione degli eventi. Per fare ci\u00f2, segui le istruzioni sopra, ma esegui avrsim.py con una riga di comando come la seguente: PYTHONPATH=/path/to/simulavr/src/python/ ./scripts/avrsim.py out/klipper.elf -t PORTA.PORT,PORTC.PORT Quanto sopra creerebbe un file avrsim.vcd con informazioni su ogni modifica ai GPIO su PORTA e PORTB. Questo potrebbe quindi essere visualizzato usando gtkwave con: gtkwave avrsim.vcd","title":"Utilizzo di simulavr con gtkwave"},{"location":"Delta_Calibrate.html","text":"Calibrazione delta \u00b6 Questo documento descrive il sistema di calibrazione automatica di Klipper per stampanti \"delta\". La calibrazione delta implica la ricerca delle posizioni dei finecorsa della torre, degli angoli della torre, del raggio delta e delle lunghezze del braccio delta. Queste impostazioni controllano il movimento della stampante su una stampante delta. Ognuno di questi parametri ha un impatto non evidente e non lineare ed \u00e8 difficile calibrarli manualmente. Al contrario, il codice di calibrazione del software pu\u00f2 fornire risultati eccellenti in pochi minuti di tempo. Non \u00e8 necessario alcun hardware di rilevamento speciale. In definitiva, la calibrazione delta dipende dalla precisione degli interruttori di fine corsa della torre. Se si utilizzano i driver per motori passo-passo Trinamic, considerare l'abilitazione del rilevamento fase endstop per migliorare la precisione di tali interruttori. Sonda automatica vs manuale \u00b6 Klipper supporta la calibrazione dei parametri delta tramite un metodo di sonda manuale o tramite una sonda Z automatica. Numerosi kit di stampanti delta sono dotati di sonde Z automatiche che non sono sufficientemente accurate (in particolare, piccole differenze nella lunghezza del braccio possono causare l'inclinazione dell'effettore che pu\u00f2 distorcere una sonda automatica). Se si utilizza una sonda automatica, prima calibrare la sonda e quindi verificare la presenza di un bias posizione sonda . Se la sonda automatica ha una polarizzazione superiore a 25 micron (0,025 mm), utilizzare invece la sonda manuale. Il probing manuale richiede solo pochi minuti ed elimina l'errore introdotto dalla sonda. Se si utilizza una sonda montata sul lato dell'hotend (ovvero ha un offset X o Y), tenere presente che l'esecuzione della calibrazione delta invalider\u00e0 i risultati della calibrazione della sonda. Questi tipi di sonde sono raramente adatti per l'uso su un delta (poich\u00e9 una minore inclinazione dell'effettore risulter\u00e0 in una distorsione della posizione della sonda). Se si utilizza comunque la sonda, assicurarsi di eseguire nuovamente la calibrazione della sonda dopo qualsiasi calibrazione delta. Calibrazione delta di base \u00b6 Klipper ha un comando DELTA_CALIBRATE che pu\u00f2 eseguire la calibrazione delta di base. Questo comando sonda sette diversi punti sul letto e calcola nuovi valori per gli angoli della torre, i punti terminali della torre e il raggio delta. Per eseguire questa calibrazione devono essere forniti i parametri delta iniziali (lunghezze dei bracci, raggio e posizioni dei finecorsa) e devono avere una precisione di pochi millimetri. La maggior parte dei kit della stampante delta fornisce questi parametri: configurare la stampante con queste impostazioni predefinite iniziali e quindi eseguire il comando DELTA_CALIBRATE come descritto di seguito. Se non sono disponibili impostazioni predefinite, cercare online una guida alla calibrazione delta che possa fornire un punto di partenza di base. Durante il processo di calibrazione delta potrebbe essere necessario che la stampante sondi al di sotto di quello che altrimenti sarebbe considerato il piano del piatto. \u00c8 tipico consentire ci\u00f2 durante la calibrazione aggiornando la configurazione in modo che minimum_z_position=-5 della stampante. (Una volta completata la calibrazione, \u00e8 possibile rimuovere questa impostazione dalla configurazione.) Ci sono due modi per eseguire la procedura: probing manuale ( DELTA_CALIBRATE METHOD=manual ) e automatica ( DELTA_CALIBRATE ). Il metodo di rilevamento manuale sposter\u00e0 la testa vicino al piatto e quindi attender\u00e0 che l'utente segua i passaggi descritti in \"test della carta\" per determinare la distanza effettiva tra l'ugello e letto nel luogo indicato. Per eseguire la misura di base, assicurati che la configurazione abbia una sezione [delta_calibrate] definita e quindi esegui lo strumento: G28 DELTA_CALIBRATE METHOD=manual Dopo aver sondato i sette punti verranno calcolati i nuovi parametri delta. Salva e applica questi parametri eseguendo: SAVE_CONFIG La calibrazione di base dovrebbe fornire parametri delta sufficientemente accurati per la stampa di base. Se si tratta di una nuova stampante, questo \u00e8 un buon momento per stampare alcuni oggetti di base e verificarne la funzionalit\u00e0 generale. Calibrazione delta migliorata \u00b6 La calibrazione delta di base generalmente fa un buon lavoro nel calcolo dei parametri delta in modo tale che l'ugello sia alla distanza corretta dal letto. Tuttavia, non tenta di calibrare la precisione dimensionale X e Y. \u00c8 una buona idea eseguire una calibrazione delta avanzata per verificare l'accuratezza dimensionale. Questa procedura di calibrazione richiede la stampa di un oggetto di prova e la misurazione di parti di tale oggetto di prova con un calibro digitale. Prima di eseguire una calibrazione delta avanzata, \u00e8 necessario eseguire la calibrazione delta di base (tramite il comando DELTA_CALIBRATE) e salvare i risultati (tramite il comando SAVE_CONFIG). Assicurati che non siano state apportate modifiche degne di nota alla configurazione della stampante n\u00e9 all'hardware dall'ultima esecuzione di una calibrazione delta di base (se non sei sicuro, esegui nuovamente la calibrazione delta di base , incluso SAVE_CONFIG, appena prima della stampa l'oggetto di prova descritto di seguito.) Usa uno slicer per generare il G-code dal file docs/prints/calibrate_size.stl . Estrudere l'oggetto a bassa velocit\u00e0 (ad es. 40 mm/s). Se possibile, usa una plastica rigida (come il PLA) per l'oggetto. L'oggetto ha un diametro di 140 mm. Se questo \u00e8 troppo grande per la stampante, \u00e8 possibile ridimensionarlo (ma assicurati di ridimensionare uniformemente entrambi gli assi X e Y). Se la stampante supporta stampe significativamente pi\u00f9 grandi, \u00e8 anche possibile aumentare le dimensioni di questo oggetto. Un formato pi\u00f9 grande pu\u00f2 migliorare la precisione della misurazione, ma una buona adesione di stampa \u00e8 pi\u00f9 importante di un formato di stampa pi\u00f9 grande. Stampa l'oggetto di prova e attendi che si raffreddi completamente. I comandi descritti di seguito devono essere eseguiti con le stesse impostazioni della stampante utilizzate per stampare l'oggetto di calibrazione (non eseguire DELTA_CALIBRATE tra la stampa e la misurazione, o fare qualcosa che altrimenti modificherebbe la configurazione della stampante). Se possibile, esegui le misurazioni descritte di seguito mentre l'oggetto \u00e8 ancora attaccato al piano di stampa, ma non preoccuparti se la parte si stacca dal letto: cerca solo di evitare di piegare l'oggetto durante l'esecuzione delle misurazioni. Inizia misurando la distanza tra il pilastro centrale e il pilastro accanto all'etichetta \"A\" (che dovrebbe anche puntare verso la torre \"A\"). Quindi procedere in senso antiorario e misurare le distanze tra il pilastro centrale e gli altri pilastri (distanza dal centro al pilastro attraverso l'etichetta C, distanza dal centro al pilastro con l'etichetta B, ecc.). Inserisci questi parametri in Klipper con un elenco separato da virgole di numeri in virgola mobile: DELTA_ANALYZE CENTER_DISTS=,,,,, Fornisci i valori senza spazi tra di loro. Quindi misurare la distanza tra il montante A e il montante di fronte all'etichetta C. Quindi andare in senso antiorario e misurare la distanza tra il pilastro di fronte a C e il pilastro B, la distanza tra il pilastro B e il pilastro di fronte a A, e cos\u00ec via. Inserisci questi parametri in Klipper: DELTA_ANALYZE OUTER_DISTS=,,,,, A questo punto va bene rimuovere l'oggetto dal letto. Le misure finali sono dei pilastri stessi. Misurare la dimensione del pilastro centrale lungo il raggio A, poi il raggio B e poi il raggio C. Inseriscili in Klipper: DELTA_ANALYZE CENTER_PILLAR_WIDTHS=,, Le misure finali sono dei pilastri esterni. Inizia misurando la distanza del pilastro A lungo la linea da A al pilastro di fronte a C. Quindi andare in senso antiorario e misurare i restanti pilastri esterni (pilastro di fronte a C lungo la linea a B, pilastro B lungo la linea a pilastro di fronte ad A, ecc.). E inseriscili in Klipper: DELTA_ANALYZE OUTER_PILLAR_WIDTHS=,,,,, Se l'oggetto \u00e8 stato ridimensionato a una dimensione inferiore o superiore, fornire il fattore di scala utilizzato durante il taglio dell'oggetto: DELTA_ANALYZE SCALE=1.0 (Un valore di scala di 2,0 significherebbe che l'oggetto \u00e8 il doppio della sua dimensione originale, 0,5 sarebbe la met\u00e0 della sua dimensione originale.) Infine, esegui la calibrazione delta avanzata eseguendo: DELTA_ANALYZE CALIBRATE=extended Il completamento di questo comando pu\u00f2 richiedere diversi minuti. Dopo il completamento, calcoler\u00e0 i parametri delta aggiornati (raggio delta, angoli della torre, posizioni dei finecorsa e lunghezze dei bracci). Utilizzare il comando SAVE_CONFIG per salvare e applicare le impostazioni: SAVE_CONFIG Il comando SAVE_CONFIG salver\u00e0 sia i parametri delta aggiornati che le informazioni dalle misurazioni della distanza. Anche i futuri comandi DELTA_CALIBRATE utilizzeranno queste informazioni sulla distanza. Non tentare di reinserire le misurazioni grezze della distanza dopo aver eseguito SAVE_CONFIG, poich\u00e9 questo comando modifica la configurazione della stampante e le misurazioni grezze non vengono pi\u00f9 applicate. Note aggiuntive \u00b6 Se la stampante delta ha una buona precisione dimensionale, la distanza tra due pilastri qualsiasi dovrebbe essere di circa 74 mm e la larghezza di ogni pilastro dovrebbe essere di circa 9 mm. (In particolare, l'obiettivo \u00e8 che la distanza tra due pilastri qualsiasi meno la larghezza di uno dei pilastri sia esattamente 65 mm.) In caso di imprecisione dimensionale nella parte, la routine DELTA_ANALYZE calcoler\u00e0 nuovi parametri delta utilizzando entrambe le misurazioni della distanza e le misurazioni dell'altezza precedenti dall'ultimo comando DELTA_CALIBRATE. DELTA_ANALYZE pu\u00f2 produrre parametri delta sorprendenti. Ad esempio, pu\u00f2 suggerire lunghezze dei bracci che non corrispondono alle lunghezze effettive dei bracci della stampante. Nonostante ci\u00f2, i test hanno dimostrato che DELTA_ANALYZE produce spesso risultati superiori. Si ritiene che i parametri delta calcolati siano in grado di tenere conto di lievi errori in altre parti dell'hardware. Ad esempio, piccole differenze nella lunghezza del braccio possono comportare un'inclinazione dell'effettore e parte di tale inclinazione pu\u00f2 essere spiegata regolando i parametri della lunghezza del braccio. Utilizzo della mesh del piatto su un delta \u00b6 \u00c8 possibile utilizzare bed mesh su un delta. Tuttavia, \u00e8 importante ottenere una buona calibrazione delta prima di abilitare una mesh del letto. L'esecuzione della mesh del letto con una scarsa calibrazione delta comporter\u00e0 risultati confusi e scarsi. Si noti che l'esecuzione della calibrazione delta invalider\u00e0 qualsiasi mesh del piatto precedentemente ottenuto. Dopo aver eseguito una nuova calibrazione delta, assicurati di eseguire nuovamente BED_MESH_CALIBRATE.","title":"Calibrazione delta"},{"location":"Delta_Calibrate.html#calibrazione-delta","text":"Questo documento descrive il sistema di calibrazione automatica di Klipper per stampanti \"delta\". La calibrazione delta implica la ricerca delle posizioni dei finecorsa della torre, degli angoli della torre, del raggio delta e delle lunghezze del braccio delta. Queste impostazioni controllano il movimento della stampante su una stampante delta. Ognuno di questi parametri ha un impatto non evidente e non lineare ed \u00e8 difficile calibrarli manualmente. Al contrario, il codice di calibrazione del software pu\u00f2 fornire risultati eccellenti in pochi minuti di tempo. Non \u00e8 necessario alcun hardware di rilevamento speciale. In definitiva, la calibrazione delta dipende dalla precisione degli interruttori di fine corsa della torre. Se si utilizzano i driver per motori passo-passo Trinamic, considerare l'abilitazione del rilevamento fase endstop per migliorare la precisione di tali interruttori.","title":"Calibrazione delta"},{"location":"Delta_Calibrate.html#sonda-automatica-vs-manuale","text":"Klipper supporta la calibrazione dei parametri delta tramite un metodo di sonda manuale o tramite una sonda Z automatica. Numerosi kit di stampanti delta sono dotati di sonde Z automatiche che non sono sufficientemente accurate (in particolare, piccole differenze nella lunghezza del braccio possono causare l'inclinazione dell'effettore che pu\u00f2 distorcere una sonda automatica). Se si utilizza una sonda automatica, prima calibrare la sonda e quindi verificare la presenza di un bias posizione sonda . Se la sonda automatica ha una polarizzazione superiore a 25 micron (0,025 mm), utilizzare invece la sonda manuale. Il probing manuale richiede solo pochi minuti ed elimina l'errore introdotto dalla sonda. Se si utilizza una sonda montata sul lato dell'hotend (ovvero ha un offset X o Y), tenere presente che l'esecuzione della calibrazione delta invalider\u00e0 i risultati della calibrazione della sonda. Questi tipi di sonde sono raramente adatti per l'uso su un delta (poich\u00e9 una minore inclinazione dell'effettore risulter\u00e0 in una distorsione della posizione della sonda). Se si utilizza comunque la sonda, assicurarsi di eseguire nuovamente la calibrazione della sonda dopo qualsiasi calibrazione delta.","title":"Sonda automatica vs manuale"},{"location":"Delta_Calibrate.html#calibrazione-delta-di-base","text":"Klipper ha un comando DELTA_CALIBRATE che pu\u00f2 eseguire la calibrazione delta di base. Questo comando sonda sette diversi punti sul letto e calcola nuovi valori per gli angoli della torre, i punti terminali della torre e il raggio delta. Per eseguire questa calibrazione devono essere forniti i parametri delta iniziali (lunghezze dei bracci, raggio e posizioni dei finecorsa) e devono avere una precisione di pochi millimetri. La maggior parte dei kit della stampante delta fornisce questi parametri: configurare la stampante con queste impostazioni predefinite iniziali e quindi eseguire il comando DELTA_CALIBRATE come descritto di seguito. Se non sono disponibili impostazioni predefinite, cercare online una guida alla calibrazione delta che possa fornire un punto di partenza di base. Durante il processo di calibrazione delta potrebbe essere necessario che la stampante sondi al di sotto di quello che altrimenti sarebbe considerato il piano del piatto. \u00c8 tipico consentire ci\u00f2 durante la calibrazione aggiornando la configurazione in modo che minimum_z_position=-5 della stampante. (Una volta completata la calibrazione, \u00e8 possibile rimuovere questa impostazione dalla configurazione.) Ci sono due modi per eseguire la procedura: probing manuale ( DELTA_CALIBRATE METHOD=manual ) e automatica ( DELTA_CALIBRATE ). Il metodo di rilevamento manuale sposter\u00e0 la testa vicino al piatto e quindi attender\u00e0 che l'utente segua i passaggi descritti in \"test della carta\" per determinare la distanza effettiva tra l'ugello e letto nel luogo indicato. Per eseguire la misura di base, assicurati che la configurazione abbia una sezione [delta_calibrate] definita e quindi esegui lo strumento: G28 DELTA_CALIBRATE METHOD=manual Dopo aver sondato i sette punti verranno calcolati i nuovi parametri delta. Salva e applica questi parametri eseguendo: SAVE_CONFIG La calibrazione di base dovrebbe fornire parametri delta sufficientemente accurati per la stampa di base. Se si tratta di una nuova stampante, questo \u00e8 un buon momento per stampare alcuni oggetti di base e verificarne la funzionalit\u00e0 generale.","title":"Calibrazione delta di base"},{"location":"Delta_Calibrate.html#calibrazione-delta-migliorata","text":"La calibrazione delta di base generalmente fa un buon lavoro nel calcolo dei parametri delta in modo tale che l'ugello sia alla distanza corretta dal letto. Tuttavia, non tenta di calibrare la precisione dimensionale X e Y. \u00c8 una buona idea eseguire una calibrazione delta avanzata per verificare l'accuratezza dimensionale. Questa procedura di calibrazione richiede la stampa di un oggetto di prova e la misurazione di parti di tale oggetto di prova con un calibro digitale. Prima di eseguire una calibrazione delta avanzata, \u00e8 necessario eseguire la calibrazione delta di base (tramite il comando DELTA_CALIBRATE) e salvare i risultati (tramite il comando SAVE_CONFIG). Assicurati che non siano state apportate modifiche degne di nota alla configurazione della stampante n\u00e9 all'hardware dall'ultima esecuzione di una calibrazione delta di base (se non sei sicuro, esegui nuovamente la calibrazione delta di base , incluso SAVE_CONFIG, appena prima della stampa l'oggetto di prova descritto di seguito.) Usa uno slicer per generare il G-code dal file docs/prints/calibrate_size.stl . Estrudere l'oggetto a bassa velocit\u00e0 (ad es. 40 mm/s). Se possibile, usa una plastica rigida (come il PLA) per l'oggetto. L'oggetto ha un diametro di 140 mm. Se questo \u00e8 troppo grande per la stampante, \u00e8 possibile ridimensionarlo (ma assicurati di ridimensionare uniformemente entrambi gli assi X e Y). Se la stampante supporta stampe significativamente pi\u00f9 grandi, \u00e8 anche possibile aumentare le dimensioni di questo oggetto. Un formato pi\u00f9 grande pu\u00f2 migliorare la precisione della misurazione, ma una buona adesione di stampa \u00e8 pi\u00f9 importante di un formato di stampa pi\u00f9 grande. Stampa l'oggetto di prova e attendi che si raffreddi completamente. I comandi descritti di seguito devono essere eseguiti con le stesse impostazioni della stampante utilizzate per stampare l'oggetto di calibrazione (non eseguire DELTA_CALIBRATE tra la stampa e la misurazione, o fare qualcosa che altrimenti modificherebbe la configurazione della stampante). Se possibile, esegui le misurazioni descritte di seguito mentre l'oggetto \u00e8 ancora attaccato al piano di stampa, ma non preoccuparti se la parte si stacca dal letto: cerca solo di evitare di piegare l'oggetto durante l'esecuzione delle misurazioni. Inizia misurando la distanza tra il pilastro centrale e il pilastro accanto all'etichetta \"A\" (che dovrebbe anche puntare verso la torre \"A\"). Quindi procedere in senso antiorario e misurare le distanze tra il pilastro centrale e gli altri pilastri (distanza dal centro al pilastro attraverso l'etichetta C, distanza dal centro al pilastro con l'etichetta B, ecc.). Inserisci questi parametri in Klipper con un elenco separato da virgole di numeri in virgola mobile: DELTA_ANALYZE CENTER_DISTS=,,,,, Fornisci i valori senza spazi tra di loro. Quindi misurare la distanza tra il montante A e il montante di fronte all'etichetta C. Quindi andare in senso antiorario e misurare la distanza tra il pilastro di fronte a C e il pilastro B, la distanza tra il pilastro B e il pilastro di fronte a A, e cos\u00ec via. Inserisci questi parametri in Klipper: DELTA_ANALYZE OUTER_DISTS=,,,,, A questo punto va bene rimuovere l'oggetto dal letto. Le misure finali sono dei pilastri stessi. Misurare la dimensione del pilastro centrale lungo il raggio A, poi il raggio B e poi il raggio C. Inseriscili in Klipper: DELTA_ANALYZE CENTER_PILLAR_WIDTHS=,, Le misure finali sono dei pilastri esterni. Inizia misurando la distanza del pilastro A lungo la linea da A al pilastro di fronte a C. Quindi andare in senso antiorario e misurare i restanti pilastri esterni (pilastro di fronte a C lungo la linea a B, pilastro B lungo la linea a pilastro di fronte ad A, ecc.). E inseriscili in Klipper: DELTA_ANALYZE OUTER_PILLAR_WIDTHS=,,,,, Se l'oggetto \u00e8 stato ridimensionato a una dimensione inferiore o superiore, fornire il fattore di scala utilizzato durante il taglio dell'oggetto: DELTA_ANALYZE SCALE=1.0 (Un valore di scala di 2,0 significherebbe che l'oggetto \u00e8 il doppio della sua dimensione originale, 0,5 sarebbe la met\u00e0 della sua dimensione originale.) Infine, esegui la calibrazione delta avanzata eseguendo: DELTA_ANALYZE CALIBRATE=extended Il completamento di questo comando pu\u00f2 richiedere diversi minuti. Dopo il completamento, calcoler\u00e0 i parametri delta aggiornati (raggio delta, angoli della torre, posizioni dei finecorsa e lunghezze dei bracci). Utilizzare il comando SAVE_CONFIG per salvare e applicare le impostazioni: SAVE_CONFIG Il comando SAVE_CONFIG salver\u00e0 sia i parametri delta aggiornati che le informazioni dalle misurazioni della distanza. Anche i futuri comandi DELTA_CALIBRATE utilizzeranno queste informazioni sulla distanza. Non tentare di reinserire le misurazioni grezze della distanza dopo aver eseguito SAVE_CONFIG, poich\u00e9 questo comando modifica la configurazione della stampante e le misurazioni grezze non vengono pi\u00f9 applicate.","title":"Calibrazione delta migliorata"},{"location":"Delta_Calibrate.html#note-aggiuntive","text":"Se la stampante delta ha una buona precisione dimensionale, la distanza tra due pilastri qualsiasi dovrebbe essere di circa 74 mm e la larghezza di ogni pilastro dovrebbe essere di circa 9 mm. (In particolare, l'obiettivo \u00e8 che la distanza tra due pilastri qualsiasi meno la larghezza di uno dei pilastri sia esattamente 65 mm.) In caso di imprecisione dimensionale nella parte, la routine DELTA_ANALYZE calcoler\u00e0 nuovi parametri delta utilizzando entrambe le misurazioni della distanza e le misurazioni dell'altezza precedenti dall'ultimo comando DELTA_CALIBRATE. DELTA_ANALYZE pu\u00f2 produrre parametri delta sorprendenti. Ad esempio, pu\u00f2 suggerire lunghezze dei bracci che non corrispondono alle lunghezze effettive dei bracci della stampante. Nonostante ci\u00f2, i test hanno dimostrato che DELTA_ANALYZE produce spesso risultati superiori. Si ritiene che i parametri delta calcolati siano in grado di tenere conto di lievi errori in altre parti dell'hardware. Ad esempio, piccole differenze nella lunghezza del braccio possono comportare un'inclinazione dell'effettore e parte di tale inclinazione pu\u00f2 essere spiegata regolando i parametri della lunghezza del braccio.","title":"Note aggiuntive"},{"location":"Delta_Calibrate.html#utilizzo-della-mesh-del-piatto-su-un-delta","text":"\u00c8 possibile utilizzare bed mesh su un delta. Tuttavia, \u00e8 importante ottenere una buona calibrazione delta prima di abilitare una mesh del letto. L'esecuzione della mesh del letto con una scarsa calibrazione delta comporter\u00e0 risultati confusi e scarsi. Si noti che l'esecuzione della calibrazione delta invalider\u00e0 qualsiasi mesh del piatto precedentemente ottenuto. Dopo aver eseguito una nuova calibrazione delta, assicurati di eseguire nuovamente BED_MESH_CALIBRATE.","title":"Utilizzo della mesh del piatto su un delta"},{"location":"Endstop_Phase.html","text":"Fase di fine corsa \u00b6 Questo documento descrive il sistema di finecorsa di Klipper regolato sulla fase degli stepper. Questa funzionalit\u00e0 pu\u00f2 migliorare la precisione degli interruttori di fine corsa tradizionali. \u00c8 particolarmente utile quando si utilizza un driver per motori passo-passo Trinamic con configurazione runtime. Un tipico interruttore di fine corsa ha una precisione di circa 100 micron. (Ogni volta l'interruttore pu\u00f2 attivarsi leggermente prima o leggermente dopo.) Sebbene si tratti di un errore relativamente piccolo, pu\u00f2 causare artefatti indesiderati. In particolare, questa deviazione di posizione pu\u00f2 essere evidente quando si stampa il primo strato di un oggetto. Al contrario, i tipici motori passo-passo possono ottenere una precisione significativamente maggiore. Il meccanismo di fine corsa con regolazione della fase pu\u00f2 utilizzare la precisione dei motori passo-passo per migliorare la precisione degli interruttori di fine corsa. Un motore passo-passo si muove ciclicamente attraverso una serie di fasi fino a completare quattro \"passi completi\". Quindi, un motore passo-passo che utilizza 16 micro-passi avrebbe 64 fasi e quando si muove in direzione positiva passerebbe in rassegna le fasi: 0, 1, 2, ... 61, 62, 63, 0, 1, 2, ecc. Fondamentalmente, quando il motore passo-passo si trova in una posizione particolare su una guida lineare, dovrebbe essere sempre nella stessa fase passo-passo. Pertanto, quando un carrello fa scattare l'interruttore di fine corsa, lo stepper che controlla quel carrello dovrebbe essere sempre nella stessa fase del motore passo-passo. Il sistema di fase finecorsa di Klipper combina la fase del motore con l'attivazione del finecorsa per migliorare la precisione. Per utilizzare questa funzionalit\u00e0 \u00e8 necessario essere in grado di identificare la fase del motore passo-passo. Se si utilizzano i driver Trinamic TMC2130, TMC2208, TMC2224 o TMC2660 in modalit\u00e0 di configurazione runtime (cio\u00e8 non in modalit\u00e0 stand-alone), Klipper pu\u00f2 interrogare la fase stepper dal driver. (\u00c8 anche possibile utilizzare questo sistema su driver stepper tradizionali se \u00e8 possibile ripristinare in modo affidabile i driver stepper - vedere sotto per i dettagli.) Taratura fasi dei finecorsa \u00b6 Se si utilizzano driver Trinamic per motori passo-passo in configurazione runtime, \u00e8 possibile calibrare le fasi di fine corsa utilizzando il comando ENDSTOP_PHASE_CALIBRATE. Inizia aggiungendo quanto segue al file di configurazione: [endstop_phase] Quindi RIAVVIARE la stampante ed eseguire un comando G28 seguito da un comando ENDSTOP_PHASE_CALIBRATE . Quindi spostare la testina in una nuova posizione ed eseguire nuovamente G28 . Prova a spostare la testina in diverse posizioni ed esegui nuovamente G28 da ciascuna posizione. Esegui almeno cinque comandi G28 . Dopo aver eseguito quanto sopra, il comando ENDSTOP_PHASE_CALIBRATE riporter\u00e0 spesso la stessa (o quasi) fase per lo stepper. Questa fase pu\u00f2 essere salvata nel file di configurazione in modo che tutti i futuri comandi G28 utilizzino quella fase. (Quindi, nelle future operazioni di homing, Klipper otterr\u00e0 la stessa posizione anche se il finecorsa si attiva un po' prima o un po' dopo.) Per salvare la fase di fine corsa per un particolare motore passo-passo, eseguire qualcosa di simile a: ENDSTOP_PHASE_CALIBRATE STEPPER=stepper_z Esegui quanto sopra per tutti gli stepper che desideri salvare. Tipicamente, si usa questo su stepper_z per stampanti cartesiane e corexy e per stepper_a, stepper_b e stepper_c su stampanti delta. Infine, eseguire quanto segue per aggiornare il file di configurazione con i dati: SAVE_CONFIG Note aggiuntive \u00b6 Questa funzione \u00e8 particolarmente utile sulle stampanti delta e sul fine corsa Z delle stampanti cartesiane/corexy. \u00c8 possibile utilizzare questa funzione sui fine corsa XY delle stampanti cartesiane, ma ci\u00f2 non \u00e8 particolarmente utile poich\u00e9 \u00e8 improbabile che un errore minore nella posizione dell'arresto X/Y influisca sulla qualit\u00e0 di stampa. Non \u00e8 valido utilizzare questa funzione sugli arresti XY delle stampanti corexy (poich\u00e9 la posizione XY non \u00e8 determinata da un singolo stepper sulla cinematica corexy). Non \u00e8 valido utilizzare questa funzione su una stampante che utilizza un fine corsa Z \"probe:z_virtual_endstop\" (poich\u00e9 la fase stepper \u00e8 stabile solo se il fine corsa si trova in una posizione statica su una guida). Dopo aver calibrato la fase del finecorsa, se il finecorsa viene successivamente spostato o regolato, sar\u00e0 necessario ricalibrarlo. Rimuovere i dati di calibrazione dal file di configurazione ed eseguire nuovamente i passaggi precedenti. Per utilizzare questo sistema, il finecorsa deve essere sufficientemente preciso da identificare la posizione dello stepper entro due \"passi completi\". Quindi, ad esempio, se uno stepper utilizza 16 micropassi con una distanza del passo di 0,005 mm, il finecorsa deve avere una precisione di almeno 0,160 mm. Se si ottengono messaggi di errore di tipo \"Finecorsa stepper_z non corretto\", potrebbero essere dovuti a un finecorsa che non \u00e8 sufficientemente accurato. Se la ricalibrazione non aiuta, disabilitare le regolazioni della fase finecorsa rimuovendole dal file di configurazione. Se si utilizza un tradizionale asse Z controllato da stepper (come su una stampante cartesiana o corexy) insieme alle tradizionali viti di livellamento del letto, \u00e8 anche possibile utilizzare questo sistema per fare in modo che ogni strato di stampa venga eseguito su un confine \"passo completo\" . Per abilitare questa funzione, assicurati che lo slicer del G-Code sia configurato con un'altezza del livello che sia un multiplo di un \"passo completo\", abilita manualmente l'opzione endstop_align_zero nella sezione di configurazione endstop_phase (vedi config reference per ulteriori dettagli), quindi livellare nuovamente le viti del piatto. \u00c8 possibile utilizzare questo sistema con driver per motori passo-passo tradizionali (non Trinamici). Tuttavia, per fare ci\u00f2 \u00e8 necessario assicurarsi che i driver del motore passo-passo vengano ripristinati ogni volta che viene ripristinato il microcontrollore. (Se i due vengono sempre ripristinati insieme, Klipper pu\u00f2 determinare la fase dello stepper tracciando il numero totale di passaggi che ha comandato allo stepper di muoversi.) Attualmente, l'unico modo per farlo in modo affidabile \u00e8 se sia il microcontrollore che il motore passo-passo i driver siano alimentati esclusivamente da USB e che l'alimentazione USB sia fornita da un host in esecuzione su un Raspberry Pi. In questa situazione \u00e8 possibile specificare una configurazione mcu con \"restart_method: rpi_usb\" - quell'opzione far\u00e0 in modo che il microcontrollore venga sempre ripristinato tramite un ripristino dell'alimentazione USB, il che farebbe in modo che sia il microcontrollore che i driver del motore passo-passo siano resettare insieme. Se si utilizza questo meccanismo, \u00e8 necessario configurare manualmente le sezioni di configurazione \"trigger_phase\" (consultare config reference per i dettagli).","title":"Fase di fine corsa"},{"location":"Endstop_Phase.html#fase-di-fine-corsa","text":"Questo documento descrive il sistema di finecorsa di Klipper regolato sulla fase degli stepper. Questa funzionalit\u00e0 pu\u00f2 migliorare la precisione degli interruttori di fine corsa tradizionali. \u00c8 particolarmente utile quando si utilizza un driver per motori passo-passo Trinamic con configurazione runtime. Un tipico interruttore di fine corsa ha una precisione di circa 100 micron. (Ogni volta l'interruttore pu\u00f2 attivarsi leggermente prima o leggermente dopo.) Sebbene si tratti di un errore relativamente piccolo, pu\u00f2 causare artefatti indesiderati. In particolare, questa deviazione di posizione pu\u00f2 essere evidente quando si stampa il primo strato di un oggetto. Al contrario, i tipici motori passo-passo possono ottenere una precisione significativamente maggiore. Il meccanismo di fine corsa con regolazione della fase pu\u00f2 utilizzare la precisione dei motori passo-passo per migliorare la precisione degli interruttori di fine corsa. Un motore passo-passo si muove ciclicamente attraverso una serie di fasi fino a completare quattro \"passi completi\". Quindi, un motore passo-passo che utilizza 16 micro-passi avrebbe 64 fasi e quando si muove in direzione positiva passerebbe in rassegna le fasi: 0, 1, 2, ... 61, 62, 63, 0, 1, 2, ecc. Fondamentalmente, quando il motore passo-passo si trova in una posizione particolare su una guida lineare, dovrebbe essere sempre nella stessa fase passo-passo. Pertanto, quando un carrello fa scattare l'interruttore di fine corsa, lo stepper che controlla quel carrello dovrebbe essere sempre nella stessa fase del motore passo-passo. Il sistema di fase finecorsa di Klipper combina la fase del motore con l'attivazione del finecorsa per migliorare la precisione. Per utilizzare questa funzionalit\u00e0 \u00e8 necessario essere in grado di identificare la fase del motore passo-passo. Se si utilizzano i driver Trinamic TMC2130, TMC2208, TMC2224 o TMC2660 in modalit\u00e0 di configurazione runtime (cio\u00e8 non in modalit\u00e0 stand-alone), Klipper pu\u00f2 interrogare la fase stepper dal driver. (\u00c8 anche possibile utilizzare questo sistema su driver stepper tradizionali se \u00e8 possibile ripristinare in modo affidabile i driver stepper - vedere sotto per i dettagli.)","title":"Fase di fine corsa"},{"location":"Endstop_Phase.html#taratura-fasi-dei-finecorsa","text":"Se si utilizzano driver Trinamic per motori passo-passo in configurazione runtime, \u00e8 possibile calibrare le fasi di fine corsa utilizzando il comando ENDSTOP_PHASE_CALIBRATE. Inizia aggiungendo quanto segue al file di configurazione: [endstop_phase] Quindi RIAVVIARE la stampante ed eseguire un comando G28 seguito da un comando ENDSTOP_PHASE_CALIBRATE . Quindi spostare la testina in una nuova posizione ed eseguire nuovamente G28 . Prova a spostare la testina in diverse posizioni ed esegui nuovamente G28 da ciascuna posizione. Esegui almeno cinque comandi G28 . Dopo aver eseguito quanto sopra, il comando ENDSTOP_PHASE_CALIBRATE riporter\u00e0 spesso la stessa (o quasi) fase per lo stepper. Questa fase pu\u00f2 essere salvata nel file di configurazione in modo che tutti i futuri comandi G28 utilizzino quella fase. (Quindi, nelle future operazioni di homing, Klipper otterr\u00e0 la stessa posizione anche se il finecorsa si attiva un po' prima o un po' dopo.) Per salvare la fase di fine corsa per un particolare motore passo-passo, eseguire qualcosa di simile a: ENDSTOP_PHASE_CALIBRATE STEPPER=stepper_z Esegui quanto sopra per tutti gli stepper che desideri salvare. Tipicamente, si usa questo su stepper_z per stampanti cartesiane e corexy e per stepper_a, stepper_b e stepper_c su stampanti delta. Infine, eseguire quanto segue per aggiornare il file di configurazione con i dati: SAVE_CONFIG","title":"Taratura fasi dei finecorsa"},{"location":"Endstop_Phase.html#note-aggiuntive","text":"Questa funzione \u00e8 particolarmente utile sulle stampanti delta e sul fine corsa Z delle stampanti cartesiane/corexy. \u00c8 possibile utilizzare questa funzione sui fine corsa XY delle stampanti cartesiane, ma ci\u00f2 non \u00e8 particolarmente utile poich\u00e9 \u00e8 improbabile che un errore minore nella posizione dell'arresto X/Y influisca sulla qualit\u00e0 di stampa. Non \u00e8 valido utilizzare questa funzione sugli arresti XY delle stampanti corexy (poich\u00e9 la posizione XY non \u00e8 determinata da un singolo stepper sulla cinematica corexy). Non \u00e8 valido utilizzare questa funzione su una stampante che utilizza un fine corsa Z \"probe:z_virtual_endstop\" (poich\u00e9 la fase stepper \u00e8 stabile solo se il fine corsa si trova in una posizione statica su una guida). Dopo aver calibrato la fase del finecorsa, se il finecorsa viene successivamente spostato o regolato, sar\u00e0 necessario ricalibrarlo. Rimuovere i dati di calibrazione dal file di configurazione ed eseguire nuovamente i passaggi precedenti. Per utilizzare questo sistema, il finecorsa deve essere sufficientemente preciso da identificare la posizione dello stepper entro due \"passi completi\". Quindi, ad esempio, se uno stepper utilizza 16 micropassi con una distanza del passo di 0,005 mm, il finecorsa deve avere una precisione di almeno 0,160 mm. Se si ottengono messaggi di errore di tipo \"Finecorsa stepper_z non corretto\", potrebbero essere dovuti a un finecorsa che non \u00e8 sufficientemente accurato. Se la ricalibrazione non aiuta, disabilitare le regolazioni della fase finecorsa rimuovendole dal file di configurazione. Se si utilizza un tradizionale asse Z controllato da stepper (come su una stampante cartesiana o corexy) insieme alle tradizionali viti di livellamento del letto, \u00e8 anche possibile utilizzare questo sistema per fare in modo che ogni strato di stampa venga eseguito su un confine \"passo completo\" . Per abilitare questa funzione, assicurati che lo slicer del G-Code sia configurato con un'altezza del livello che sia un multiplo di un \"passo completo\", abilita manualmente l'opzione endstop_align_zero nella sezione di configurazione endstop_phase (vedi config reference per ulteriori dettagli), quindi livellare nuovamente le viti del piatto. \u00c8 possibile utilizzare questo sistema con driver per motori passo-passo tradizionali (non Trinamici). Tuttavia, per fare ci\u00f2 \u00e8 necessario assicurarsi che i driver del motore passo-passo vengano ripristinati ogni volta che viene ripristinato il microcontrollore. (Se i due vengono sempre ripristinati insieme, Klipper pu\u00f2 determinare la fase dello stepper tracciando il numero totale di passaggi che ha comandato allo stepper di muoversi.) Attualmente, l'unico modo per farlo in modo affidabile \u00e8 se sia il microcontrollore che il motore passo-passo i driver siano alimentati esclusivamente da USB e che l'alimentazione USB sia fornita da un host in esecuzione su un Raspberry Pi. In questa situazione \u00e8 possibile specificare una configurazione mcu con \"restart_method: rpi_usb\" - quell'opzione far\u00e0 in modo che il microcontrollore venga sempre ripristinato tramite un ripristino dell'alimentazione USB, il che farebbe in modo che sia il microcontrollore che i driver del motore passo-passo siano resettare insieme. Se si utilizza questo meccanismo, \u00e8 necessario configurare manualmente le sezioni di configurazione \"trigger_phase\" (consultare config reference per i dettagli).","title":"Note aggiuntive"},{"location":"Example_Configs.html","text":"Esempi di configurazioni \u00b6 Questo documento contiene le linee guida per contribuire a creare un esempio di configurazione di Klipper nella repository github di Klipper (situato nella directory config ). Nota che il server Klipper Community Discourse \u00e8 anche una risorsa utile per trovare e condividere file di configurazione. Linee guida \u00b6 Seleziona il prefisso del nome del file di configurazione appropriato: Il prefisso printer viene utilizzato per le stampanti stock vendute da un produttore tradizionale. Il prefisso generic viene utilizzato per una scheda per stampante 3d che pu\u00f2 essere utilizzata in molti diversi tipi di stampanti. Il prefisso kit \u00e8 per le stampanti 3d assemblate secondo una specifica ampiamente utilizzata. Queste stampanti \"kit\" sono generalmente distinte dalle normali \"stampanti\" in quanto non sono vendute da un produttore. Il prefisso sample viene utilizzato per i \"ritagli\" di configurazione che \u00e8 possibile copiare e incollare nel file di configurazione principale. Il prefisso example viene utilizzato per descrivere la cinematica della stampante. Questo tipo di configurazione viene in genere aggiunto solo insieme al codice per un nuovo tipo di cinematica della stampante. Tutti i file di configurazione devono terminare con un suffisso .cfg . I file di configurazione della stampante devono terminare con un anno seguito da .cfg (ad es. -2019.cfg ). In questo caso, l'anno \u00e8 un anno approssimativo in cui \u00e8 stata venduta la stampante specificata. Non utilizzare spazi o caratteri speciali nel nome del file di configurazione. Il nome del file deve contenere solo i caratteri A-Z , a-z , 0-9 , - e . . Klipper deve essere in grado di avviare il file di configurazione di esempio printer , generic e kit senza errori. Questi file di configurazione devono essere aggiunti al test di regressione test/klippy/printers.test . Aggiungi nuovi file di configurazione a quel test case nella sezione appropriata e in ordine alfabetico all'interno di quella sezione. La configurazione di esempio dovrebbe essere per la configurazione \"stock\" della stampante. (Ci sono troppe configurazioni \"personalizzate\" da tenere traccia nel repository principale di Klipper.) Allo stesso modo, aggiungiamo solo file di configurazione di esempio per stampanti, kit e schede che hanno la popolarit\u00e0 principale (ad esempio, dovrebbero essercene almeno 100 in uso attivo). Prendi in considerazione l'utilizzo del server Klipper Community Discourse per altre configurazioni. Only specify those devices present on the given printer or board. Do not specify settings specific to your particular setup. For generic config files, only those devices on the mainboard should be described. For example, it would not make sense to add a display config section to a \"generic\" config as there is no way to know if the board will be attached to that type of display. If the board has a specific hardware port to facilitate an optional peripheral (eg, a bltouch port) then one can add a \"commented out\" config section for the given device. Non specificare pressure_advance in una configurazione di esempio, poich\u00e9 quel valore \u00e8 specifico del filamento, non dell'hardware della stampante. Allo stesso modo, non specificare le impostazioni max_extrude_only_velocity n\u00e9 max_extrude_only_accel . Non specificare una sezione di configurazione contenente un percorso host o hardware host. Ad esempio, non specificare le sezioni di configurazione [virtual_sdcard] n\u00e9 [temperature_host] . Definire solo le macro che utilizzano funzionalit\u00e0 specifiche per la stampante specificata o per definire i G-code comunemente emessi dagli slicer configurati per la stampante specificata. Where possible, it is best to use the same wording, phrasing, indentation, and section ordering as the existing config files. The top of each config file should list the type of micro-controller the user should select during \"make menuconfig\". It should also have a reference to \"docs/Config_Reference.md\". Non copiare la documentazione sul campo nei file di configurazione di esempio. (In questo modo si crea un onere di manutenzione poich\u00e9 un aggiornamento della documentazione richiederebbe quindi la modifica in molti punti.) I file di configurazione di esempio non devono contenere una sezione \"SAVE_CONFIG\". Se necessario, copiare i campi rilevanti dalla sezione SAVE_CONFIG alla sezione appropriata nell'area di configurazione principale. Usa la sintassi field: value invece di field=value . Quando si aggiunge la rotation_distance a un estrusore \u00e8 preferibile specificare un gear_ratio se l'estrusore ha un meccanismo di ingranaggi. Ci aspettiamo che la rotation_distance nelle configurazioni di esempio sia correlata alla circonferenza dell'ingranaggio nell'estrusore: normalmente \u00e8 nell'intervallo da 20 a 35 mm. Quando si specifica un gear_ratio \u00e8 preferibile specificare gli ingranaggi effettivi sul meccanismo (ad esempio, preferire gear_ratio: 80:20 su gear_ratio: 4:1 ). Per ulteriori informazioni, vedere il documento sulla distanza di rotazione . Evitare di definire valori di campo impostati sul valore predefinito. Ad esempio, non si dovrebbe specificare min_extrude_temp: 170 poich\u00e9 questo \u00e8 gi\u00e0 il valore predefinito. Ove possibile, le righe non devono superare le 80 colonne. Evita di aggiungere messaggi di attribuzione o revisione ai file di configurazione. (Ad esempio, evita di aggiungere righe come \"questo file \u00e8 stato creato da...\".) Inserisci l'attribuzione e cambia la cronologia nel messaggio di commit git. Non utilizzare alcuna funzionalit\u00e0 deprecata nel file di configurazione di esempio. Non disabilitare un sistema di sicurezza predefinito in un file di configurazione di esempio. Ad esempio, una configurazione non dovrebbe specificare una max_extrude_cross_section personalizzata. Non abilitare le funzionalit\u00e0 di debug. Ad esempio, non dovrebbe esserci una sezione di configurazione force_move . Tutte le schede note supportate da Klipper possono utilizzare la velocit\u00e0 di trasmissione seriale predefinita di 250000. Non consigliare una velocit\u00e0 di trasmissione diversa in un file di configurazione di esempio. I file di configurazione di esempio vengono inviati creando una \"richiesta pull\" di github. Si prega di seguire anche le indicazioni nel documento per contributi .","title":"Esempi di configurazioni"},{"location":"Example_Configs.html#esempi-di-configurazioni","text":"Questo documento contiene le linee guida per contribuire a creare un esempio di configurazione di Klipper nella repository github di Klipper (situato nella directory config ). Nota che il server Klipper Community Discourse \u00e8 anche una risorsa utile per trovare e condividere file di configurazione.","title":"Esempi di configurazioni"},{"location":"Example_Configs.html#linee-guida","text":"Seleziona il prefisso del nome del file di configurazione appropriato: Il prefisso printer viene utilizzato per le stampanti stock vendute da un produttore tradizionale. Il prefisso generic viene utilizzato per una scheda per stampante 3d che pu\u00f2 essere utilizzata in molti diversi tipi di stampanti. Il prefisso kit \u00e8 per le stampanti 3d assemblate secondo una specifica ampiamente utilizzata. Queste stampanti \"kit\" sono generalmente distinte dalle normali \"stampanti\" in quanto non sono vendute da un produttore. Il prefisso sample viene utilizzato per i \"ritagli\" di configurazione che \u00e8 possibile copiare e incollare nel file di configurazione principale. Il prefisso example viene utilizzato per descrivere la cinematica della stampante. Questo tipo di configurazione viene in genere aggiunto solo insieme al codice per un nuovo tipo di cinematica della stampante. Tutti i file di configurazione devono terminare con un suffisso .cfg . I file di configurazione della stampante devono terminare con un anno seguito da .cfg (ad es. -2019.cfg ). In questo caso, l'anno \u00e8 un anno approssimativo in cui \u00e8 stata venduta la stampante specificata. Non utilizzare spazi o caratteri speciali nel nome del file di configurazione. Il nome del file deve contenere solo i caratteri A-Z , a-z , 0-9 , - e . . Klipper deve essere in grado di avviare il file di configurazione di esempio printer , generic e kit senza errori. Questi file di configurazione devono essere aggiunti al test di regressione test/klippy/printers.test . Aggiungi nuovi file di configurazione a quel test case nella sezione appropriata e in ordine alfabetico all'interno di quella sezione. La configurazione di esempio dovrebbe essere per la configurazione \"stock\" della stampante. (Ci sono troppe configurazioni \"personalizzate\" da tenere traccia nel repository principale di Klipper.) Allo stesso modo, aggiungiamo solo file di configurazione di esempio per stampanti, kit e schede che hanno la popolarit\u00e0 principale (ad esempio, dovrebbero essercene almeno 100 in uso attivo). Prendi in considerazione l'utilizzo del server Klipper Community Discourse per altre configurazioni. Only specify those devices present on the given printer or board. Do not specify settings specific to your particular setup. For generic config files, only those devices on the mainboard should be described. For example, it would not make sense to add a display config section to a \"generic\" config as there is no way to know if the board will be attached to that type of display. If the board has a specific hardware port to facilitate an optional peripheral (eg, a bltouch port) then one can add a \"commented out\" config section for the given device. Non specificare pressure_advance in una configurazione di esempio, poich\u00e9 quel valore \u00e8 specifico del filamento, non dell'hardware della stampante. Allo stesso modo, non specificare le impostazioni max_extrude_only_velocity n\u00e9 max_extrude_only_accel . Non specificare una sezione di configurazione contenente un percorso host o hardware host. Ad esempio, non specificare le sezioni di configurazione [virtual_sdcard] n\u00e9 [temperature_host] . Definire solo le macro che utilizzano funzionalit\u00e0 specifiche per la stampante specificata o per definire i G-code comunemente emessi dagli slicer configurati per la stampante specificata. Where possible, it is best to use the same wording, phrasing, indentation, and section ordering as the existing config files. The top of each config file should list the type of micro-controller the user should select during \"make menuconfig\". It should also have a reference to \"docs/Config_Reference.md\". Non copiare la documentazione sul campo nei file di configurazione di esempio. (In questo modo si crea un onere di manutenzione poich\u00e9 un aggiornamento della documentazione richiederebbe quindi la modifica in molti punti.) I file di configurazione di esempio non devono contenere una sezione \"SAVE_CONFIG\". Se necessario, copiare i campi rilevanti dalla sezione SAVE_CONFIG alla sezione appropriata nell'area di configurazione principale. Usa la sintassi field: value invece di field=value . Quando si aggiunge la rotation_distance a un estrusore \u00e8 preferibile specificare un gear_ratio se l'estrusore ha un meccanismo di ingranaggi. Ci aspettiamo che la rotation_distance nelle configurazioni di esempio sia correlata alla circonferenza dell'ingranaggio nell'estrusore: normalmente \u00e8 nell'intervallo da 20 a 35 mm. Quando si specifica un gear_ratio \u00e8 preferibile specificare gli ingranaggi effettivi sul meccanismo (ad esempio, preferire gear_ratio: 80:20 su gear_ratio: 4:1 ). Per ulteriori informazioni, vedere il documento sulla distanza di rotazione . Evitare di definire valori di campo impostati sul valore predefinito. Ad esempio, non si dovrebbe specificare min_extrude_temp: 170 poich\u00e9 questo \u00e8 gi\u00e0 il valore predefinito. Ove possibile, le righe non devono superare le 80 colonne. Evita di aggiungere messaggi di attribuzione o revisione ai file di configurazione. (Ad esempio, evita di aggiungere righe come \"questo file \u00e8 stato creato da...\".) Inserisci l'attribuzione e cambia la cronologia nel messaggio di commit git. Non utilizzare alcuna funzionalit\u00e0 deprecata nel file di configurazione di esempio. Non disabilitare un sistema di sicurezza predefinito in un file di configurazione di esempio. Ad esempio, una configurazione non dovrebbe specificare una max_extrude_cross_section personalizzata. Non abilitare le funzionalit\u00e0 di debug. Ad esempio, non dovrebbe esserci una sezione di configurazione force_move . Tutte le schede note supportate da Klipper possono utilizzare la velocit\u00e0 di trasmissione seriale predefinita di 250000. Non consigliare una velocit\u00e0 di trasmissione diversa in un file di configurazione di esempio. I file di configurazione di esempio vengono inviati creando una \"richiesta pull\" di github. Si prega di seguire anche le indicazioni nel documento per contributi .","title":"Linee guida"},{"location":"Exclude_Object.html","text":"Escludi oggetti \u00b6 The [exclude_object] module allows Klipper to exclude objects while a print is in progress. To enable this feature include an exclude_object config section (also see the command reference and sample-macros.cfg file for a Marlin/RepRapFirmware compatible M486 G-Code macro.) A differenza di altre opzioni del firmware della stampante 3D, una stampante che esegue Klipper utilizza una suite di componenti e gli utenti hanno molte opzioni tra cui scegliere. Pertanto, al fine di fornire un'esperienza utente coerente, il modulo [exclude_object] stabilir\u00e0 un contratto o una sorta di API. Il contratto copre il contenuto del file gcode, come viene controllato lo stato interno del modulo e come tale stato viene fornito ai client. Panoramica del flusso di lavoro \u00b6 Un tipico flusso di lavoro per la stampa di un file potrebbe essere simile a: Lo slicing \u00e8 completato e il file viene caricato per la stampa. Durante il caricamento, il file viene elaborato e gli indicatori [exclude_object] vengono aggiunti al file. In alternativa, i filtri dei dati possono essere configurati per preparare i marcatori di esclusione degli oggetti in modo nativo o nella propria fase di pre-elaborazione. All'avvio della stampa, Klipper ripristiner\u00e0 [exclude_object] status . Quando Klipper elabora il blocco EXCLUDE_OBJECT_DEFINE , aggiorner\u00e0 lo stato con gli oggetti conosciuti e lo passer\u00e0 ai client. Il client pu\u00f2 utilizzare tali informazioni per presentare un'interfaccia all'utente in modo che sia possibile tenere traccia dei progressi. Klipper aggiorner\u00e0 lo stato per includere l'oggetto attualmente in stampa che il client pu\u00f2 utilizzare per scopi di visualizzazione. Se l'utente richiede la cancellazione di un oggetto, il client invier\u00e0 un comando EXCLUDE_OBJECT NAME= a Klipper. Quando Klipper elabora il comando, aggiunger\u00e0 l'oggetto all'elenco degli oggetti esclusi e aggiorner\u00e0 lo stato per i client. Il client ricever\u00e0 lo stato aggiornato da Klipper e potr\u00e0 utilizzare tali informazioni per aggiornare lo stato dell'oggetto nell'interfaccia utente. Al termine della stampa, lo stato [exclude_object] continuer\u00e0 a essere disponibile fino a quando un'altra azione non lo reimposta. Il file GCode \u00b6 L'elaborazione specializzata del gcode necessaria per supportare l'esclusione di oggetti non rientra negli obiettivi di progettazione principali di Klipper. Pertanto, questo modulo richiede che il file venga elaborato prima di essere inviato a Klipper per la stampa. L'utilizzo di uno script di post-elaborazione nello slicer o il middleware che elabora il file durante il caricamento sono due possibilit\u00e0 per preparare il file per Klipper. Uno script di post-elaborazione di riferimento \u00e8 disponibile sia come eseguibile che come libreria Python, vedere cancelobject-preprocessor . Definizioni di oggetti \u00b6 Il comando EXCLUDE_OBJECT_DEFINE viene utilizzato per fornire un riepilogo di ogni oggetto nel file gcode da stampare. Fornisce un riepilogo di un oggetto nel file. Gli oggetti non hanno bisogno di essere definiti per essere referenziati da altri comandi. Lo scopo principale di questo comando \u00e8 fornire informazioni all'interfaccia utente senza dover analizzare l'intero file gcode. Le definizioni degli oggetti sono denominate per consentire agli utenti di selezionare facilmente un oggetto da escludere e possono essere forniti metadati aggiuntivi per consentire la visualizzazione grafica dell'annullamento. I metadati attualmente definiti includono una coordinata X,Y \"CENTRO\" e un elenco \"POLYGON\" di punti X,Y che rappresentano un contorno minimo dell'oggetto. Potrebbe trattarsi di un semplice riquadro di delimitazione o di uno guscio complicato per mostrare visualizzazioni pi\u00f9 dettagliate degli oggetti stampati. Soprattutto quando i file gcode includono pi\u00f9 parti con regioni di delimitazione sovrapposte, i punti centrali diventano difficili da distinguere visivamente. POLYGONS deve essere un array compatibile con json di tuple punto [X,Y] senza spazi. Ulteriori parametri verranno salvati come stringhe nella definizione dell'oggetto e forniti negli aggiornamenti di stato. EXCLUDE_OBJECT_DEFINE NAME=calibration_pyramid CENTER=50,50 POLYGON=[[40,40],[50,60],[60,40]] All available G-Code commands are documented in the G-Code Reference Informazioni sullo stato \u00b6 The state of this module is provided to clients by the exclude_object status . Lo stato viene ripristinato quando: Il firmware di Klipper viene riavviato. C'\u00e8 un reset della [virtual_sdcard] . In particolare, questo viene ripristinato da Klipper all'inizio di una stampa. Quando viene emesso un comando EXCLUDE_OBJECT_DEFINE RESET=1 . L'elenco degli oggetti definiti \u00e8 rappresentato nel campo di stato exclude_object.objects . In un file gcode ben definito, questo sar\u00e0 fatto con i comandi EXCLUDE_OBJECT_DEFINE all'inizio del file. Ci\u00f2 fornir\u00e0 ai client i nomi e le coordinate degli oggetti in modo che l'interfaccia utente possa fornire una rappresentazione grafica degli oggetti, se lo si desidera. Man mano che la stampa procede, il campo di stato exclude_object.current_object verr\u00e0 aggiornato mentre Klipper elabora i comandi EXCLUDE_OBJECT_START e EXCLUDE_OBJECT_END . Il campo oggetto_corrente sar\u00e0 impostato anche se l'oggetto \u00e8 stato escluso. Gli oggetti non definiti contrassegnati con un EXCLUDE_OBJECT_START verranno aggiunti agli oggetti conosciuti per facilitare i suggerimenti dell'interfaccia utente, senza metadati aggiuntivi. Quando vengono emessi i comandi EXCLUDE_OBJECT , l'elenco degli oggetti esclusi viene fornito nell'array exclude_object.excluded_objects . Poich\u00e9 Klipper guarda avanti per elaborare il prossimo gcode, potrebbe esserci un ritardo tra l'emissione del comando e l'aggiornamento dello stato.","title":"Escludi oggetti"},{"location":"Exclude_Object.html#escludi-oggetti","text":"The [exclude_object] module allows Klipper to exclude objects while a print is in progress. To enable this feature include an exclude_object config section (also see the command reference and sample-macros.cfg file for a Marlin/RepRapFirmware compatible M486 G-Code macro.) A differenza di altre opzioni del firmware della stampante 3D, una stampante che esegue Klipper utilizza una suite di componenti e gli utenti hanno molte opzioni tra cui scegliere. Pertanto, al fine di fornire un'esperienza utente coerente, il modulo [exclude_object] stabilir\u00e0 un contratto o una sorta di API. Il contratto copre il contenuto del file gcode, come viene controllato lo stato interno del modulo e come tale stato viene fornito ai client.","title":"Escludi oggetti"},{"location":"Exclude_Object.html#panoramica-del-flusso-di-lavoro","text":"Un tipico flusso di lavoro per la stampa di un file potrebbe essere simile a: Lo slicing \u00e8 completato e il file viene caricato per la stampa. Durante il caricamento, il file viene elaborato e gli indicatori [exclude_object] vengono aggiunti al file. In alternativa, i filtri dei dati possono essere configurati per preparare i marcatori di esclusione degli oggetti in modo nativo o nella propria fase di pre-elaborazione. All'avvio della stampa, Klipper ripristiner\u00e0 [exclude_object] status . Quando Klipper elabora il blocco EXCLUDE_OBJECT_DEFINE , aggiorner\u00e0 lo stato con gli oggetti conosciuti e lo passer\u00e0 ai client. Il client pu\u00f2 utilizzare tali informazioni per presentare un'interfaccia all'utente in modo che sia possibile tenere traccia dei progressi. Klipper aggiorner\u00e0 lo stato per includere l'oggetto attualmente in stampa che il client pu\u00f2 utilizzare per scopi di visualizzazione. Se l'utente richiede la cancellazione di un oggetto, il client invier\u00e0 un comando EXCLUDE_OBJECT NAME= a Klipper. Quando Klipper elabora il comando, aggiunger\u00e0 l'oggetto all'elenco degli oggetti esclusi e aggiorner\u00e0 lo stato per i client. Il client ricever\u00e0 lo stato aggiornato da Klipper e potr\u00e0 utilizzare tali informazioni per aggiornare lo stato dell'oggetto nell'interfaccia utente. Al termine della stampa, lo stato [exclude_object] continuer\u00e0 a essere disponibile fino a quando un'altra azione non lo reimposta.","title":"Panoramica del flusso di lavoro"},{"location":"Exclude_Object.html#il-file-gcode","text":"L'elaborazione specializzata del gcode necessaria per supportare l'esclusione di oggetti non rientra negli obiettivi di progettazione principali di Klipper. Pertanto, questo modulo richiede che il file venga elaborato prima di essere inviato a Klipper per la stampa. L'utilizzo di uno script di post-elaborazione nello slicer o il middleware che elabora il file durante il caricamento sono due possibilit\u00e0 per preparare il file per Klipper. Uno script di post-elaborazione di riferimento \u00e8 disponibile sia come eseguibile che come libreria Python, vedere cancelobject-preprocessor .","title":"Il file GCode"},{"location":"Exclude_Object.html#definizioni-di-oggetti","text":"Il comando EXCLUDE_OBJECT_DEFINE viene utilizzato per fornire un riepilogo di ogni oggetto nel file gcode da stampare. Fornisce un riepilogo di un oggetto nel file. Gli oggetti non hanno bisogno di essere definiti per essere referenziati da altri comandi. Lo scopo principale di questo comando \u00e8 fornire informazioni all'interfaccia utente senza dover analizzare l'intero file gcode. Le definizioni degli oggetti sono denominate per consentire agli utenti di selezionare facilmente un oggetto da escludere e possono essere forniti metadati aggiuntivi per consentire la visualizzazione grafica dell'annullamento. I metadati attualmente definiti includono una coordinata X,Y \"CENTRO\" e un elenco \"POLYGON\" di punti X,Y che rappresentano un contorno minimo dell'oggetto. Potrebbe trattarsi di un semplice riquadro di delimitazione o di uno guscio complicato per mostrare visualizzazioni pi\u00f9 dettagliate degli oggetti stampati. Soprattutto quando i file gcode includono pi\u00f9 parti con regioni di delimitazione sovrapposte, i punti centrali diventano difficili da distinguere visivamente. POLYGONS deve essere un array compatibile con json di tuple punto [X,Y] senza spazi. Ulteriori parametri verranno salvati come stringhe nella definizione dell'oggetto e forniti negli aggiornamenti di stato. EXCLUDE_OBJECT_DEFINE NAME=calibration_pyramid CENTER=50,50 POLYGON=[[40,40],[50,60],[60,40]] All available G-Code commands are documented in the G-Code Reference","title":"Definizioni di oggetti"},{"location":"Exclude_Object.html#informazioni-sullo-stato","text":"The state of this module is provided to clients by the exclude_object status . Lo stato viene ripristinato quando: Il firmware di Klipper viene riavviato. C'\u00e8 un reset della [virtual_sdcard] . In particolare, questo viene ripristinato da Klipper all'inizio di una stampa. Quando viene emesso un comando EXCLUDE_OBJECT_DEFINE RESET=1 . L'elenco degli oggetti definiti \u00e8 rappresentato nel campo di stato exclude_object.objects . In un file gcode ben definito, questo sar\u00e0 fatto con i comandi EXCLUDE_OBJECT_DEFINE all'inizio del file. Ci\u00f2 fornir\u00e0 ai client i nomi e le coordinate degli oggetti in modo che l'interfaccia utente possa fornire una rappresentazione grafica degli oggetti, se lo si desidera. Man mano che la stampa procede, il campo di stato exclude_object.current_object verr\u00e0 aggiornato mentre Klipper elabora i comandi EXCLUDE_OBJECT_START e EXCLUDE_OBJECT_END . Il campo oggetto_corrente sar\u00e0 impostato anche se l'oggetto \u00e8 stato escluso. Gli oggetti non definiti contrassegnati con un EXCLUDE_OBJECT_START verranno aggiunti agli oggetti conosciuti per facilitare i suggerimenti dell'interfaccia utente, senza metadati aggiuntivi. Quando vengono emessi i comandi EXCLUDE_OBJECT , l'elenco degli oggetti esclusi viene fornito nell'array exclude_object.excluded_objects . Poich\u00e9 Klipper guarda avanti per elaborare il prossimo gcode, potrebbe esserci un ritardo tra l'emissione del comando e l'aggiornamento dello stato.","title":"Informazioni sullo stato"},{"location":"FAQ.html","text":"Domande frequenti \u00b6 Come posso donare al progetto? \u00b6 Grazie per il vostro sostegno. Per informazioni, vedere la Pagina degli sponsor . Come faccio a calcolare il parametro di configurazione rotation_distance? \u00b6 Vedere il rotation distance document . Dov'\u00e8 la mia porta seriale? \u00b6 Il modo generico per trovare una porta seriale USB \u00e8 eseguire ls /dev/serial/by-id/* da un terminale ssh sulla macchina host. Probabilmente produrr\u00e0 un output simile al seguente: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 Il nome trovato nel comando precedente \u00e8 stabile ed \u00e8 possibile utilizzarlo nel file di configurazione e durante il flashing del codice del microcontrollore. Ad esempio, un comando flash potrebbe essere simile a: sudo service klipper stop make flash FLASH_DEVICE=/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 sudo service klipper start e la configurazione aggiornata potrebbe essere simile a: [mcu] serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 Assicurati di copiare e incollare il nome dal comando \"ls\" che hai eseguito sopra poich\u00e9 il nome sar\u00e0 diverso per ciascuna stampante. Se stai usando pi\u00f9 microcontrollori e non hanno ID univoci (comune sulle schede con un chip USB CH340), segui invece le indicazioni sopra usando il comando ls /dev/serial/by-path/* . Quando il microcontrollore si riavvia, il dispositivo cambia in /dev/ttyUSB1 \u00b6 egui le istruzioni nella sezione \" Where's my serial port? \" per evitare che ci\u00f2 accada. Il comando \"make flash\" non funziona \u00b6 Il codice tenta di eseguire il flashing del dispositivo utilizzando il metodo pi\u00f9 comune per ciascuna piattaforma. Sfortunatamente, c'\u00e8 molta variabilit\u00e0 nei metodi di flashing, quindi il comando \"make flash\" potrebbe non funzionare su tutte le schede. Se si verifica un errore intermittente o si dispone di una configurazione standard, ricontrolla che Klipper non sia in esecuzione durante il flashing (sudo service klipper stop), assicurati che OctoPrint non stia tentando di connettersi direttamente al dispositivo (apri il scheda Connessione nella pagina Web e fare clic su Disconnetti se la porta seriale \u00e8 impostata sul dispositivo) e assicurarsi che FLASH_DEVICE sia impostato correttamente per la scheda (consultare la question above . Tuttavia, se \"make flash\" non funziona per la tua scheda, dovrai eseguire il flashing manualmente. Verificare se nella config directory \u00e8 presente un file di configurazione con istruzioni specifiche per il flashing del dispositivo. Inoltre, controlla la documentazione del produttore della scheda per vedere se descrive come eseguire il flashing del dispositivo. Infine, potrebbe essere possibile eseguire manualmente il flashing del dispositivo utilizzando strumenti come \"avrdude\" o \"bossac\" - vedere il bootloader document per ulteriori informazioni. Come posso modificare la velocit\u00e0 di trasmissione seriale? \u00b6 Il baud rate consigliato per Klipper \u00e8 250000. Questo baud rate funziona bene su tutte le schede di microcontrollore supportate da Klipper. Se hai trovato una guida online che consiglia una velocit\u00e0 di trasmissione diversa, ignora quella parte della guida e continua con il valore predefinito di 250000. Se si desidera comunque modificare il baud rate, sar\u00e0 necessario configurare la nuova velocit\u00e0 nel microcontrollore (durante make menuconfig ) e il codice aggiornato dovr\u00e0 essere compilato e flashato sul microcontrollore. Anche il file Klipper printer.cfg dovr\u00e0 essere aggiornato in modo che corrisponda a tale velocit\u00e0 di trasmissione (consultare il config reference per i dettagli). Per esempio: [mcu] baud: 250000 La velocit\u00e0 di trasmissione mostrata sulla pagina Web di OctoPrint non ha alcun impatto sulla velocit\u00e0 di trasmissione interna del microcontrollore Klipper. Impostare sempre la velocit\u00e0 di trasmissione OctoPrint su 250000 quando si utilizza Klipper. La velocit\u00e0 in baud del microcontrollore Klipper non \u00e8 correlata alla velocit\u00e0 in baud del bootloader del microcontrollore. Vedere il bootloader document per ulteriori informazioni sui bootloader. Posso eseguire Klipper su qualcosa di diverso da un Raspberry Pi 3? \u00b6 L'hardware consigliato \u00e8 un Raspberry Pi 2, Raspberry Pi 3 o Raspberry Pi 4. Klipper funzioner\u00e0 su un Raspberry Pi 1 e su Raspberry Pi Zero, ma queste schede non hanno una potenza di elaborazione sufficiente per eseguire bene OctoPrint. \u00c8 normale che si verifichino interruzioni di stampa su queste macchine pi\u00f9 lente quando si stampa direttamente da OctoPrint. (La stampante potrebbe muoversi pi\u00f9 velocemente di quanto OctoPrint possa inviare comandi di movimento.) Se desideri comunque eseguire su una di queste schede pi\u00f9 lente, considera l'utilizzo della funzione \"virtual_sdcard\" durante la stampa (consulta config reference per dettagli). Per l'esecuzione su Beaglebone, vedere le Istruzioni di installazione specifiche di Beaglebone . Klipper \u00e8 stato eseguito su altre macchine. Il software host Klipper richiede solo Python in esecuzione su un computer Linux (o simile). Tuttavia, se desideri eseguirlo su una macchina diversa, avrai bisogno della conoscenza dell'amministratore Linux per installare i prerequisiti di sistema per quella particolare macchina. Consulta lo script install-octopi.sh per ulteriori informazioni sui passaggi necessari. Se stai cercando di eseguire il software host Klipper su un chip di fascia bassa, tieni presente che, come minimo, \u00e8 necessaria una macchina con hardware a \"virgola mobile a doppia precisione\". Se stai cercando di eseguire il software host Klipper su un desktop generico condiviso o una macchina di classe server, tieni presente che Klipper ha alcuni requisiti di scheduling in tempo reale. Se, durante una stampa, il computer host esegue anche un'intensa attivit\u00e0 di elaborazione generica (come deframmentazione di un disco rigido, rendering 3D, scambi pesanti e cos\u00ec via), Klipper potrebbe segnalare errori di stampa. Nota: se non stai utilizzando un'immagine OctoPi, tieni presente che diverse distribuzioni Linux abilitano un pacchetto \"ModemManager\" (o simile) che pu\u00f2 interrompere la comunicazione seriale. (Il che pu\u00f2 far s\u00ec che Klipper riporti errori apparentemente casuali \"Comunicazione persa con MCU\".) Se installi Klipper su una di queste distribuzioni potresti dover disabilitare quel pacchetto. Posso eseguire pi\u00f9 istanze di Klipper sulla stessa macchina host? \u00b6 \u00c8 possibile eseguire pi\u00f9 istanze del software host Klipper, ma per farlo \u00e8 necessaria la conoscenza dell'amministratore Linux. Gli script di installazione di Klipper determinano l'esecuzione del seguente comando Unix: ~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer.cfg -l /tmp/klippy.log \u00c8 possibile eseguire pi\u00f9 istanze del comando precedente purch\u00e9 ogni istanza abbia il proprio file di configurazione della stampante, il proprio file di registro e il proprio pseudo-tty. Per esempio: ~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer2.cfg -l /tmp/klippy2.log -I /tmp/printer2 Se scegli di farlo, dovrai implementare gli script di avvio, arresto e installazione necessari (se presenti). Lo script install-octopi.sh e lo script klipper-start.sh possono essere utili come esempi. Devo usare OctoPrint? \u00b6 Il software Klipper non dipende da OctoPrint. \u00c8 possibile utilizzare un software alternativo per inviare comandi a Klipper, ma ci\u00f2 richiede la conoscenza dell'amministratore Linux. Klipper crea una \"porta seriale virtuale\" tramite il file \"/tmp/printer\" ed emula una classica interfaccia seriale per stampante 3D tramite quel file. In generale, un software alternativo pu\u00f2 funzionare con Klipper purch\u00e9 possa essere configurato per utilizzare \"/tmp/printer\" per la porta seriale della stampante. Perch\u00e9 non riesco a spostare lo stepper prima di riposizionare la stampante? \u00b6 Il codice fa questo per ridurre la possibilit\u00e0 di comandare accidentalmente la testa nel piatto o altri limiti. Una volta che la stampante \u00e8 stata localizzata, il software tenta di verificare che ogni mossa rientri nella posizione_min/max definita nel file di configurazione. Se i motori sono disabilitati (tramite un comando M84 o M18), i motori dovranno essere nuovamente riposizionati prima del movimento. Se desideri spostare la testina dopo aver annullato una stampa tramite OctoPrint, considera di modificare la sequenza di annullamento di OctoPrint per farlo per te. \u00c8 configurato in OctoPrint tramite un browser web in: Impostazioni-> Script GCODE | Settings->GCODE Scripts Se desideri spostare la testina al termine di una stampa, considera di aggiungere il movimento desiderato alla sezione \"G-code personalizzato\" del tuo slicer. Se la stampante richiede un movimento aggiuntivo come parte del processo stesso di homing (o fondamentalmente non ha un processo di homing), considera l'utilizzo di una sezione safe_z_home o homing_override nel file di configurazione. Se \u00e8 necessario spostare uno stepper per scopi diagnostici o di debug, considerare l'aggiunta di una sezione force_move al file di configurazione. Vedere config reference per ulteriori dettagli su queste opzioni. Perch\u00e9 Z position_endstop \u00e8 impostato su 0.5 nelle configurazioni predefinite? \u00b6 Per le stampanti cartesiane Z position_endstop specifica la distanza dell'ugello dal piatto quando si attiva ilfinecorsa. Se possibile, si consiglia di utilizzare un finecorsa Z-max e di tornare a casa lontano dal piatto (in quanto ci\u00f2 riduce il rischio di collisioni con il piatto). Tuttavia, se ci si deve avvicinare al piatto, si consiglia di posizionare il finecorsa in modo che si attivi quando la bocchetta \u00e8 ancora a una piccola distanza dal piatto. In questo modo, durante l'homing dell'asse, si fermer\u00e0 prima che l'ugello tocchi il letto. Per ulteriori informazioni, vedere il bed level document . Ho convertito la mia configurazione da Marlin e gli assi X/Y funzionano bene, ma ottengo solo un rumore stridente durante homing dell'asse Z \u00b6 Risposta breve: in primo luogo, assicurati di aver verificato la configurazione dello stepper come descritto nel config check document . Se il problema persiste, provare a ridurre l'impostazione max_z_velocity nella configurazione della stampante. Risposta lunga: in pratica Marlin pu\u00f2 in genere fare solo un passo a una velocit\u00e0 di circa 10000 passi al secondo. Se gli viene richiesto di muoversi a una velocit\u00e0 che richiederebbe una velocit\u00e0 di passo pi\u00f9 alta, Marlin generalmente far\u00e0 un passo pi\u00f9 veloce possibile. Klipper \u00e8 in grado di raggiungere velocit\u00e0 di passo molto pi\u00f9 elevate, ma il motore passo-passo potrebbe non avere una coppia sufficiente per muoversi a una velocit\u00e0 pi\u00f9 elevata. Quindi, per un asse Z con un rapporto di trasmissione elevato o un'impostazione di micropassi elevata, l'effettiva velocit\u00e0 max_z_ottenibile potrebbe essere inferiore a quella configurata in Marlin. Il mio driver TMC del motore si spegne nel mezzo di una stampa \u00b6 Se si utilizza il driver TMC2208 (o TMC2224) in \"modalit\u00e0 standalone\", assicurarsi di utilizzare l' latest version of Klipper . Una soluzione alternativa per un problema del driver \"stealthchop\" TMC2208 \u00e8 stata aggiunta a Klipper a met\u00e0 marzo del 2020. Continuo a ricevere errori casuali \"Comunicazione persa con MCU\" |\"Lost communication with MCU\" \u00b6 Ci\u00f2 \u00e8 comunemente causato da errori hardware sulla connessione USB tra la macchina host e il microcontrollore. Cose da cercare: Utilizzare un cavo USB di buona qualit\u00e0 tra la macchina host e il microcontrollore. Assicurati che i connettori siano ben saldi. Se si utilizza un Raspberry Pi, utilizzare un alimentatore di buona qualit\u00e0 per il Raspberry Pi e utilizzare un cavo USB di buona qualit\u00e0 per collegare quell'alimentatore al Pi. Se ricevi avvisi di \"sottotensione\" da OctoPrint, questo \u00e8 correlato all'alimentatore e deve essere risolto. Assicurarsi che l'alimentazione della stampante non sia sovraccarica. (Le fluttuazioni di alimentazione del chip USB del microcontrollore possono comportare il reset di quel chip.) Verificare che i cavi dello stepper, del riscaldatore e di altri cavi della stampante non siano arricciati o sfilacciati. (Il movimento della stampante pu\u00f2 sollecitare un cavo difettoso causandone la perdita di contatto, un cortocircuito breve o la generazione di rumore eccessivo.) Sono stati segnalati rumori USB elevati quando sia l'alimentazione della stampante che l'alimentazione a 5 V dell'host sono mescolate. (Se si scopre che il microcontrollore si accende quando l'alimentazione della stampante \u00e8 accesa o il cavo USB \u00e8 collegato, significa che gli alimentatori da 5 V vengono mescolati.) Pu\u00f2 essere utile configurare il microcontrollore da utilizzare alimentazione da una sola fonte. (In alternativa, se la scheda del microcontrollore non \u00e8 in grado di configurare la sua fonte di alimentazione, \u00e8 possibile modificare un cavo USB in modo che non trasmetta alimentazione a 5V tra l'host e il microcontrollore.) Il mio Raspberry Pi continua a riavviarsi durante le stampe \u00b6 Questo \u00e8 molto probabilmente dovuto alle fluttuazioni di tensione. Segui gli stessi passaggi per la risoluzione dei problemi per un errore \"Comunicazione persa con MCU\" . Quando imposto restart_method=command il mio dispositivo AVR si blocca al riavvio \u00b6 Alcune vecchie versioni del bootloader AVR hanno un bug noto nella gestione degli eventi di watchdog. Questo in genere si manifesta quando il file printer.cfg ha restart_method impostato su \"command\". Quando si verifica il bug, il dispositivo AVR non risponder\u00e0 fino a quando l'alimentazione non viene rimossa e ricollegata al dispositivo (anche i LED di alimentazione o di stato potrebbero lampeggiare ripetutamente fino a quando l'alimentazione non viene rimossa). La soluzione alternativa \u00e8 utilizzare un restart_method diverso da \"command\" o eseguire il flashing di un bootloader aggiornato sul dispositivo AVR. Il flashing di un nuovo bootloader \u00e8 un passaggio che in genere richiede un programmatore esterno: vedere Bootloaders per ulteriori dettagli. I riscaldatori verranno lasciati accesi se il Raspberry Pi si arresta in modo anomalo? \u00b6 Il software \u00e8 stato progettato per impedirlo. Una volta che l'host abilita un riscaldatore, il software host deve confermare tale abilitazione ogni 5 secondi. Se il microcontrollore non riceve una conferma ogni 5 secondi, entra in uno stato di \"spegnimento\" progettato per spegnere tutti i riscaldatori e i motori passo-passo. Per ulteriori dettagli, vedere il comando \"config_digital_out\" nel documento Comandi MCU . Inoltre, il software del microcontrollore \u00e8 configurato con un intervallo di temperatura minimo e massimo per ciascun riscaldatore all'avvio (consultare i parametri min_temp e max_temp in config reference per i dettagli). Se il microcontrollore rileva che la temperatura \u00e8 al di fuori di tale intervallo, entrer\u00e0 anche in uno stato di \"spegnimento\". Separatamente, il software host implementa anche il codice per verificare che i riscaldatori e i sensori di temperatura funzionino correttamente. Vedere il riferimento di configurazione per ulteriori dettagli. Come posso convertire un numero di pin Marlin in un nome pin di Klipper? \u00b6 Risposta breve: una mappatura \u00e8 disponibile nel file sample-aliases.cfg . Usa quel file come guida per trovare i nomi effettivi dei pin del microcontrollorei. (\u00c8 anche possibile copiare la relativa sezione di configurazione board_pins nel file di configurazione e utilizzare gli alias nella configurazione, ma \u00e8 preferibile tradurre e utilizzare i nomi dei pin del microcontrollore effettivi.) Nota che il file sample-aliases.cfg usa nomi di pin che iniziano con il prefisso \"ar\" invece di \"D\" (ad esempio, il pin Arduino D23 \u00e8 alias Klipper ar23 ) e il prefisso \"analog\" invece di \"A \" (ad esempio, il pin Arduino A14 \u00e8 alias di Klipper analog14 ). Risposta lunga: Klipper utilizza i nomi dei pin standard definiti dal microcontrollore. Sui chip Atmega questi pin hardware hanno nomi come PA4 , PC7 o PD2 . Tempo fa, il progetto Arduino ha deciso di evitare di utilizzare i nomi hardware standard a favore dei propri nomi pin basati su numeri incrementali: questi nomi Arduino generalmente assomigliano a \"D23\" o \"A14\". Questa \u00e8 stata una scelta sfortunata che ha portato a una grande confusione. In particolare, i numeri dei pin di Arduino spesso non si traducono negli stessi nomi hardware. Ad esempio, D21 \u00e8 PD0 su una comune scheda Arduino, ma \u00e8 PC7 su un'altra comune scheda Arduino. Per evitare questa confusione, il codice di base di Klipper utilizza i nomi dei pin standard definiti dal microcontrollore. Devo collegare il mio dispositivo a un tipo specifico di pin del microcontrollore? \u00b6 Dipende dal tipo di dispositivo e dal tipo di pin: Pin ADC (o pin analogici): per termistori e sensori \"analogici\" simili, il dispositivo deve essere collegato a un pin compatibile con \"analogico\" o \"ADC\" sul microcontrollore. Se configuri Klipper per utilizzare un pin che non \u00e8 compatibile con l'analogico, Klipper segnaler\u00e0 un errore \"Non un pin ADC valido\". Pin PWM (o pin Timer): Klipper non utilizza PWM hardware per impostazione predefinita per nessun dispositivo. Quindi, in generale, \u00e8 possibile collegare riscaldatori, ventole e dispositivi simili a qualsiasi pin IO generico. Tuttavia, le ventole e i dispositivi output_pin possono essere opzionalmente configurati per utilizzare hardware_pwm: True , nel qual caso il microcontrollore deve supportare PWM hardware sul pin (altrimenti, Klipper segnaler\u00e0 un errore \"pin PWM non valido\"). Pin IRQ (o pin di interrupt): Klipper non utilizza gli interrupt hardware sui pin IO, quindi non \u00e8 mai necessario collegare un dispositivo a uno di questi pin del microcontrollore. Pin SPI: quando si utilizza l'SPI hardware, \u00e8 necessario collegare i pin ai pin SPI del microcontrollore. Tuttavia, la maggior parte dei dispositivi pu\u00f2 essere configurata per utilizzare \"SPI software\", nel qual caso \u00e8 possibile utilizzare qualsiasi pin IO generico. Pin I2C: quando si utilizza I2C \u00e8 necessario collegare i pin ai pin compatibili con I2C del microcontrollore. Altri dispositivi possono essere collegati a qualsiasi pin IO generico. Ad esempio, stepper, riscaldatori, ventole, sonde Z, servocomandi, LED, comuni display LCD hd44780/st7920, la linea di controllo Trinamic UART pu\u00f2 essere collegata a qualsiasi pin IO generico. Come posso annullare una richiesta di \"attesa temperatura\" M109/M190? \u00b6 Passare alla scheda del terminale OctoPrint ed emettere un comando M112 nel terminale. Il comando M112 far\u00e0 entrare Klipper in uno stato di \"arresto\" e causer\u00e0 la disconnessione di OctoPrint da Klipper. Passare all'area di connessione di OctoPrint e fare clic su \"Connetti\" per fare in modo che OctoPrint si riconnetta. Torna alla scheda del terminale ed emetti un comando FIRMWARE_RESTART per cancellare lo stato di errore di Klipper. Dopo aver completato questa sequenza, la precedente richiesta di riscaldamento verr\u00e0 annullata e potrebbe essere avviata una nuova stampa. Posso scoprire se la stampante ha perso dei passaggi? \u00b6 In un certo senso s\u00ec. Avviare la stampante, emettere un comando GET_POSITION , eseguire la stampa, tornare a casa ed emettere un altro GET_POSITION . Quindi confronta i valori nella riga mcu: . Questo potrebbe essere utile per regolare impostazioni come correnti, accelerazioni e velocit\u00e0 del motore passo-passo senza dover effettivamente stampare qualcosa e sprecare il filamento: basta eseguire alcuni movimenti ad alta velocit\u00e0 tra i comandi GET_POSITION . Si noti che gli stessi interruttori di fine corsa tendono a attivarsi in posizioni leggermente diverse, quindi una differenza di un paio di micropassi \u00e8 probabilmente il risultato di imprecisioni di fine corsa. Un motore passo-passo stesso pu\u00f2 perdere passi solo con incrementi di 4 passi completi. (Quindi, se si utilizzano 16 micropassi, un passo perso sullo stepper comporterebbe lo spegnimento del contatore di passi \"mcu:\" di un multiplo di 64 micropassi.) Perch\u00e9 Klipper segnala errori? Ho perso la mia stampa! \u00b6 Risposta breve: vogliamo sapere se le nostre stampanti rilevano un problema in modo che il problema sottostante possa essere risolto e possiamo ottenere stampe di ottima qualit\u00e0. Non vogliamo assolutamente che le nostre stampanti producano in silenzio stampe di bassa qualit\u00e0. Risposta lunga: Klipper \u00e8 stato progettato per risolvere automaticamente molti problemi transitori. Ad esempio, rileva automaticamente gli errori di comunicazione e li ritrasmette; pianifica le azioni in anticipo e bufferizza i comandi su pi\u00f9 livelli per consentire tempi precisi anche con interferenze intermittenti. Tuttavia, se il software rileva un errore dal quale non pu\u00f2 essere ripristinato, se gli viene ordinato di eseguire un'azione non valida o se rileva che \u00e8 irrimediabilmente incapace di eseguire l'attivit\u00e0 comandata, Klipper segnaler\u00e0 un errore. In queste situazioni c'\u00e8 un alto rischio di produrre una stampa di bassa qualit\u00e0 (o peggio). Si spera che avvisare gli utenti consentir\u00e0 loro di risolvere il problema sottostante e migliorare la qualit\u00e0 complessiva delle loro stampe. Ci sono alcune domande correlate: perch\u00e9 Klipper non mette invece in pausa la stampa? Segnalare invece un avviso? Verificare la presenza di errori prima della stampa? Ignorare gli errori nei comandi digitati dall'utente? eccetera? Attualmente Klipper legge i comandi utilizzando il protocollo G-Code e sfortunatamente il protocollo di comando G-Code non \u00e8 sufficientemente flessibile per rendere pratiche queste alternative oggi. C'\u00e8 l'interesse degli sviluppatori nel migliorare l'esperienza dell'utente durante eventi anomali, ma si prevede che ci\u00f2 richieder\u00e0 un notevole lavoro infrastrutturale (incluso un passaggio dal G-Code). Come si esegue l'aggiornamento al software pi\u00f9 recente? \u00b6 Il primo passaggio per l'aggiornamento del software consiste nell'esaminare l'ultimo documento config changes . A volte, vengono apportate modifiche al software che richiedono agli utenti di aggiornare le proprie impostazioni come parte di un aggiornamento del software. \u00c8 una buona idea rivedere questo documento prima dell'aggiornamento. Quando sei pronto per l'aggiornamento, il metodo generale \u00e8 quello di entrare in Raspberry Pi ed eseguire: cd ~/klipper git pull ~/klipper/scripts/install-octopi.sh Quindi si pu\u00f2 ricompilare e flashare il codice del microcontrollore. Per esempio: make menuconfig make clean make sudo service klipper stop make flash FLASH_DEVICE=/dev/ttyACM0 sudo service klipper start Tuttavia, capita spesso che cambi solo il software host. In questo caso \u00e8 possibile aggiornare e riavviare solo il software host con: cd ~/klipper git pull sudo service klipper restart Se dopo aver utilizzato questo collegamento il software avverte della necessit\u00e0 di eseguire il reflash del microcontrollore o si verifica qualche altro errore insolito, seguire i passaggi completi di aggiornamento descritti sopra. Se gli errori persistono, ricontrolla il documento config changes , poich\u00e9 potrebbe essere necessario modificare la configurazione della stampante. Si noti che i comandi g-code RESTART e FIRMWARE_RESTART non caricano il nuovo software: i comandi \"sudo service klipper restart\" e \"make flash\" di cui sopra sono necessari affinch\u00e9 una modifica del software abbia effetto. Come faccio a disinstallare Klipper? \u00b6 Dal alto del firmware, non deve succedere nulla di speciale. Basta seguire le indicazioni per il flashing del nuovo firmware. Dal lato del raspberry pi, uno script di disinstallazione \u00e8 disponibile in scripts/klipper-uninstall.sh . Per esempio: sudo ~/klipper/scripts/klipper-uninstall.sh rm -rf ~/klippy-env ~/klipper","title":"Domande frequenti"},{"location":"FAQ.html#domande-frequenti","text":"","title":"Domande frequenti"},{"location":"FAQ.html#come-posso-donare-al-progetto","text":"Grazie per il vostro sostegno. Per informazioni, vedere la Pagina degli sponsor .","title":"Come posso donare al progetto?"},{"location":"FAQ.html#come-faccio-a-calcolare-il-parametro-di-configurazione-rotation_distance","text":"Vedere il rotation distance document .","title":"Come faccio a calcolare il parametro di configurazione rotation_distance?"},{"location":"FAQ.html#dove-la-mia-porta-seriale","text":"Il modo generico per trovare una porta seriale USB \u00e8 eseguire ls /dev/serial/by-id/* da un terminale ssh sulla macchina host. Probabilmente produrr\u00e0 un output simile al seguente: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 Il nome trovato nel comando precedente \u00e8 stabile ed \u00e8 possibile utilizzarlo nel file di configurazione e durante il flashing del codice del microcontrollore. Ad esempio, un comando flash potrebbe essere simile a: sudo service klipper stop make flash FLASH_DEVICE=/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 sudo service klipper start e la configurazione aggiornata potrebbe essere simile a: [mcu] serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 Assicurati di copiare e incollare il nome dal comando \"ls\" che hai eseguito sopra poich\u00e9 il nome sar\u00e0 diverso per ciascuna stampante. Se stai usando pi\u00f9 microcontrollori e non hanno ID univoci (comune sulle schede con un chip USB CH340), segui invece le indicazioni sopra usando il comando ls /dev/serial/by-path/* .","title":"Dov'\u00e8 la mia porta seriale?"},{"location":"FAQ.html#quando-il-microcontrollore-si-riavvia-il-dispositivo-cambia-in-devttyusb1","text":"egui le istruzioni nella sezione \" Where's my serial port? \" per evitare che ci\u00f2 accada.","title":"Quando il microcontrollore si riavvia, il dispositivo cambia in /dev/ttyUSB1"},{"location":"FAQ.html#il-comando-make-flash-non-funziona","text":"Il codice tenta di eseguire il flashing del dispositivo utilizzando il metodo pi\u00f9 comune per ciascuna piattaforma. Sfortunatamente, c'\u00e8 molta variabilit\u00e0 nei metodi di flashing, quindi il comando \"make flash\" potrebbe non funzionare su tutte le schede. Se si verifica un errore intermittente o si dispone di una configurazione standard, ricontrolla che Klipper non sia in esecuzione durante il flashing (sudo service klipper stop), assicurati che OctoPrint non stia tentando di connettersi direttamente al dispositivo (apri il scheda Connessione nella pagina Web e fare clic su Disconnetti se la porta seriale \u00e8 impostata sul dispositivo) e assicurarsi che FLASH_DEVICE sia impostato correttamente per la scheda (consultare la question above . Tuttavia, se \"make flash\" non funziona per la tua scheda, dovrai eseguire il flashing manualmente. Verificare se nella config directory \u00e8 presente un file di configurazione con istruzioni specifiche per il flashing del dispositivo. Inoltre, controlla la documentazione del produttore della scheda per vedere se descrive come eseguire il flashing del dispositivo. Infine, potrebbe essere possibile eseguire manualmente il flashing del dispositivo utilizzando strumenti come \"avrdude\" o \"bossac\" - vedere il bootloader document per ulteriori informazioni.","title":"Il comando \"make flash\" non funziona"},{"location":"FAQ.html#come-posso-modificare-la-velocita-di-trasmissione-seriale","text":"Il baud rate consigliato per Klipper \u00e8 250000. Questo baud rate funziona bene su tutte le schede di microcontrollore supportate da Klipper. Se hai trovato una guida online che consiglia una velocit\u00e0 di trasmissione diversa, ignora quella parte della guida e continua con il valore predefinito di 250000. Se si desidera comunque modificare il baud rate, sar\u00e0 necessario configurare la nuova velocit\u00e0 nel microcontrollore (durante make menuconfig ) e il codice aggiornato dovr\u00e0 essere compilato e flashato sul microcontrollore. Anche il file Klipper printer.cfg dovr\u00e0 essere aggiornato in modo che corrisponda a tale velocit\u00e0 di trasmissione (consultare il config reference per i dettagli). Per esempio: [mcu] baud: 250000 La velocit\u00e0 di trasmissione mostrata sulla pagina Web di OctoPrint non ha alcun impatto sulla velocit\u00e0 di trasmissione interna del microcontrollore Klipper. Impostare sempre la velocit\u00e0 di trasmissione OctoPrint su 250000 quando si utilizza Klipper. La velocit\u00e0 in baud del microcontrollore Klipper non \u00e8 correlata alla velocit\u00e0 in baud del bootloader del microcontrollore. Vedere il bootloader document per ulteriori informazioni sui bootloader.","title":"Come posso modificare la velocit\u00e0 di trasmissione seriale?"},{"location":"FAQ.html#posso-eseguire-klipper-su-qualcosa-di-diverso-da-un-raspberry-pi-3","text":"L'hardware consigliato \u00e8 un Raspberry Pi 2, Raspberry Pi 3 o Raspberry Pi 4. Klipper funzioner\u00e0 su un Raspberry Pi 1 e su Raspberry Pi Zero, ma queste schede non hanno una potenza di elaborazione sufficiente per eseguire bene OctoPrint. \u00c8 normale che si verifichino interruzioni di stampa su queste macchine pi\u00f9 lente quando si stampa direttamente da OctoPrint. (La stampante potrebbe muoversi pi\u00f9 velocemente di quanto OctoPrint possa inviare comandi di movimento.) Se desideri comunque eseguire su una di queste schede pi\u00f9 lente, considera l'utilizzo della funzione \"virtual_sdcard\" durante la stampa (consulta config reference per dettagli). Per l'esecuzione su Beaglebone, vedere le Istruzioni di installazione specifiche di Beaglebone . Klipper \u00e8 stato eseguito su altre macchine. Il software host Klipper richiede solo Python in esecuzione su un computer Linux (o simile). Tuttavia, se desideri eseguirlo su una macchina diversa, avrai bisogno della conoscenza dell'amministratore Linux per installare i prerequisiti di sistema per quella particolare macchina. Consulta lo script install-octopi.sh per ulteriori informazioni sui passaggi necessari. Se stai cercando di eseguire il software host Klipper su un chip di fascia bassa, tieni presente che, come minimo, \u00e8 necessaria una macchina con hardware a \"virgola mobile a doppia precisione\". Se stai cercando di eseguire il software host Klipper su un desktop generico condiviso o una macchina di classe server, tieni presente che Klipper ha alcuni requisiti di scheduling in tempo reale. Se, durante una stampa, il computer host esegue anche un'intensa attivit\u00e0 di elaborazione generica (come deframmentazione di un disco rigido, rendering 3D, scambi pesanti e cos\u00ec via), Klipper potrebbe segnalare errori di stampa. Nota: se non stai utilizzando un'immagine OctoPi, tieni presente che diverse distribuzioni Linux abilitano un pacchetto \"ModemManager\" (o simile) che pu\u00f2 interrompere la comunicazione seriale. (Il che pu\u00f2 far s\u00ec che Klipper riporti errori apparentemente casuali \"Comunicazione persa con MCU\".) Se installi Klipper su una di queste distribuzioni potresti dover disabilitare quel pacchetto.","title":"Posso eseguire Klipper su qualcosa di diverso da un Raspberry Pi 3?"},{"location":"FAQ.html#posso-eseguire-piu-istanze-di-klipper-sulla-stessa-macchina-host","text":"\u00c8 possibile eseguire pi\u00f9 istanze del software host Klipper, ma per farlo \u00e8 necessaria la conoscenza dell'amministratore Linux. Gli script di installazione di Klipper determinano l'esecuzione del seguente comando Unix: ~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer.cfg -l /tmp/klippy.log \u00c8 possibile eseguire pi\u00f9 istanze del comando precedente purch\u00e9 ogni istanza abbia il proprio file di configurazione della stampante, il proprio file di registro e il proprio pseudo-tty. Per esempio: ~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer2.cfg -l /tmp/klippy2.log -I /tmp/printer2 Se scegli di farlo, dovrai implementare gli script di avvio, arresto e installazione necessari (se presenti). Lo script install-octopi.sh e lo script klipper-start.sh possono essere utili come esempi.","title":"Posso eseguire pi\u00f9 istanze di Klipper sulla stessa macchina host?"},{"location":"FAQ.html#devo-usare-octoprint","text":"Il software Klipper non dipende da OctoPrint. \u00c8 possibile utilizzare un software alternativo per inviare comandi a Klipper, ma ci\u00f2 richiede la conoscenza dell'amministratore Linux. Klipper crea una \"porta seriale virtuale\" tramite il file \"/tmp/printer\" ed emula una classica interfaccia seriale per stampante 3D tramite quel file. In generale, un software alternativo pu\u00f2 funzionare con Klipper purch\u00e9 possa essere configurato per utilizzare \"/tmp/printer\" per la porta seriale della stampante.","title":"Devo usare OctoPrint?"},{"location":"FAQ.html#perche-non-riesco-a-spostare-lo-stepper-prima-di-riposizionare-la-stampante","text":"Il codice fa questo per ridurre la possibilit\u00e0 di comandare accidentalmente la testa nel piatto o altri limiti. Una volta che la stampante \u00e8 stata localizzata, il software tenta di verificare che ogni mossa rientri nella posizione_min/max definita nel file di configurazione. Se i motori sono disabilitati (tramite un comando M84 o M18), i motori dovranno essere nuovamente riposizionati prima del movimento. Se desideri spostare la testina dopo aver annullato una stampa tramite OctoPrint, considera di modificare la sequenza di annullamento di OctoPrint per farlo per te. \u00c8 configurato in OctoPrint tramite un browser web in: Impostazioni-> Script GCODE | Settings->GCODE Scripts Se desideri spostare la testina al termine di una stampa, considera di aggiungere il movimento desiderato alla sezione \"G-code personalizzato\" del tuo slicer. Se la stampante richiede un movimento aggiuntivo come parte del processo stesso di homing (o fondamentalmente non ha un processo di homing), considera l'utilizzo di una sezione safe_z_home o homing_override nel file di configurazione. Se \u00e8 necessario spostare uno stepper per scopi diagnostici o di debug, considerare l'aggiunta di una sezione force_move al file di configurazione. Vedere config reference per ulteriori dettagli su queste opzioni.","title":"Perch\u00e9 non riesco a spostare lo stepper prima di riposizionare la stampante?"},{"location":"FAQ.html#perche-z-position_endstop-e-impostato-su-05-nelle-configurazioni-predefinite","text":"Per le stampanti cartesiane Z position_endstop specifica la distanza dell'ugello dal piatto quando si attiva ilfinecorsa. Se possibile, si consiglia di utilizzare un finecorsa Z-max e di tornare a casa lontano dal piatto (in quanto ci\u00f2 riduce il rischio di collisioni con il piatto). Tuttavia, se ci si deve avvicinare al piatto, si consiglia di posizionare il finecorsa in modo che si attivi quando la bocchetta \u00e8 ancora a una piccola distanza dal piatto. In questo modo, durante l'homing dell'asse, si fermer\u00e0 prima che l'ugello tocchi il letto. Per ulteriori informazioni, vedere il bed level document .","title":"Perch\u00e9 Z position_endstop \u00e8 impostato su 0.5 nelle configurazioni predefinite?"},{"location":"FAQ.html#ho-convertito-la-mia-configurazione-da-marlin-e-gli-assi-xy-funzionano-bene-ma-ottengo-solo-un-rumore-stridente-durante-homing-dellasse-z","text":"Risposta breve: in primo luogo, assicurati di aver verificato la configurazione dello stepper come descritto nel config check document . Se il problema persiste, provare a ridurre l'impostazione max_z_velocity nella configurazione della stampante. Risposta lunga: in pratica Marlin pu\u00f2 in genere fare solo un passo a una velocit\u00e0 di circa 10000 passi al secondo. Se gli viene richiesto di muoversi a una velocit\u00e0 che richiederebbe una velocit\u00e0 di passo pi\u00f9 alta, Marlin generalmente far\u00e0 un passo pi\u00f9 veloce possibile. Klipper \u00e8 in grado di raggiungere velocit\u00e0 di passo molto pi\u00f9 elevate, ma il motore passo-passo potrebbe non avere una coppia sufficiente per muoversi a una velocit\u00e0 pi\u00f9 elevata. Quindi, per un asse Z con un rapporto di trasmissione elevato o un'impostazione di micropassi elevata, l'effettiva velocit\u00e0 max_z_ottenibile potrebbe essere inferiore a quella configurata in Marlin.","title":"Ho convertito la mia configurazione da Marlin e gli assi X/Y funzionano bene, ma ottengo solo un rumore stridente durante homing dell'asse Z"},{"location":"FAQ.html#il-mio-driver-tmc-del-motore-si-spegne-nel-mezzo-di-una-stampa","text":"Se si utilizza il driver TMC2208 (o TMC2224) in \"modalit\u00e0 standalone\", assicurarsi di utilizzare l' latest version of Klipper . Una soluzione alternativa per un problema del driver \"stealthchop\" TMC2208 \u00e8 stata aggiunta a Klipper a met\u00e0 marzo del 2020.","title":"Il mio driver TMC del motore si spegne nel mezzo di una stampa"},{"location":"FAQ.html#continuo-a-ricevere-errori-casuali-comunicazione-persa-con-mcu-lost-communication-with-mcu","text":"Ci\u00f2 \u00e8 comunemente causato da errori hardware sulla connessione USB tra la macchina host e il microcontrollore. Cose da cercare: Utilizzare un cavo USB di buona qualit\u00e0 tra la macchina host e il microcontrollore. Assicurati che i connettori siano ben saldi. Se si utilizza un Raspberry Pi, utilizzare un alimentatore di buona qualit\u00e0 per il Raspberry Pi e utilizzare un cavo USB di buona qualit\u00e0 per collegare quell'alimentatore al Pi. Se ricevi avvisi di \"sottotensione\" da OctoPrint, questo \u00e8 correlato all'alimentatore e deve essere risolto. Assicurarsi che l'alimentazione della stampante non sia sovraccarica. (Le fluttuazioni di alimentazione del chip USB del microcontrollore possono comportare il reset di quel chip.) Verificare che i cavi dello stepper, del riscaldatore e di altri cavi della stampante non siano arricciati o sfilacciati. (Il movimento della stampante pu\u00f2 sollecitare un cavo difettoso causandone la perdita di contatto, un cortocircuito breve o la generazione di rumore eccessivo.) Sono stati segnalati rumori USB elevati quando sia l'alimentazione della stampante che l'alimentazione a 5 V dell'host sono mescolate. (Se si scopre che il microcontrollore si accende quando l'alimentazione della stampante \u00e8 accesa o il cavo USB \u00e8 collegato, significa che gli alimentatori da 5 V vengono mescolati.) Pu\u00f2 essere utile configurare il microcontrollore da utilizzare alimentazione da una sola fonte. (In alternativa, se la scheda del microcontrollore non \u00e8 in grado di configurare la sua fonte di alimentazione, \u00e8 possibile modificare un cavo USB in modo che non trasmetta alimentazione a 5V tra l'host e il microcontrollore.)","title":"Continuo a ricevere errori casuali \"Comunicazione persa con MCU\" |\"Lost communication with MCU\""},{"location":"FAQ.html#il-mio-raspberry-pi-continua-a-riavviarsi-durante-le-stampe","text":"Questo \u00e8 molto probabilmente dovuto alle fluttuazioni di tensione. Segui gli stessi passaggi per la risoluzione dei problemi per un errore \"Comunicazione persa con MCU\" .","title":"Il mio Raspberry Pi continua a riavviarsi durante le stampe"},{"location":"FAQ.html#quando-imposto-restart_methodcommand-il-mio-dispositivo-avr-si-blocca-al-riavvio","text":"Alcune vecchie versioni del bootloader AVR hanno un bug noto nella gestione degli eventi di watchdog. Questo in genere si manifesta quando il file printer.cfg ha restart_method impostato su \"command\". Quando si verifica il bug, il dispositivo AVR non risponder\u00e0 fino a quando l'alimentazione non viene rimossa e ricollegata al dispositivo (anche i LED di alimentazione o di stato potrebbero lampeggiare ripetutamente fino a quando l'alimentazione non viene rimossa). La soluzione alternativa \u00e8 utilizzare un restart_method diverso da \"command\" o eseguire il flashing di un bootloader aggiornato sul dispositivo AVR. Il flashing di un nuovo bootloader \u00e8 un passaggio che in genere richiede un programmatore esterno: vedere Bootloaders per ulteriori dettagli.","title":"Quando imposto restart_method=command il mio dispositivo AVR si blocca al riavvio"},{"location":"FAQ.html#i-riscaldatori-verranno-lasciati-accesi-se-il-raspberry-pi-si-arresta-in-modo-anomalo","text":"Il software \u00e8 stato progettato per impedirlo. Una volta che l'host abilita un riscaldatore, il software host deve confermare tale abilitazione ogni 5 secondi. Se il microcontrollore non riceve una conferma ogni 5 secondi, entra in uno stato di \"spegnimento\" progettato per spegnere tutti i riscaldatori e i motori passo-passo. Per ulteriori dettagli, vedere il comando \"config_digital_out\" nel documento Comandi MCU . Inoltre, il software del microcontrollore \u00e8 configurato con un intervallo di temperatura minimo e massimo per ciascun riscaldatore all'avvio (consultare i parametri min_temp e max_temp in config reference per i dettagli). Se il microcontrollore rileva che la temperatura \u00e8 al di fuori di tale intervallo, entrer\u00e0 anche in uno stato di \"spegnimento\". Separatamente, il software host implementa anche il codice per verificare che i riscaldatori e i sensori di temperatura funzionino correttamente. Vedere il riferimento di configurazione per ulteriori dettagli.","title":"I riscaldatori verranno lasciati accesi se il Raspberry Pi si arresta in modo anomalo?"},{"location":"FAQ.html#come-posso-convertire-un-numero-di-pin-marlin-in-un-nome-pin-di-klipper","text":"Risposta breve: una mappatura \u00e8 disponibile nel file sample-aliases.cfg . Usa quel file come guida per trovare i nomi effettivi dei pin del microcontrollorei. (\u00c8 anche possibile copiare la relativa sezione di configurazione board_pins nel file di configurazione e utilizzare gli alias nella configurazione, ma \u00e8 preferibile tradurre e utilizzare i nomi dei pin del microcontrollore effettivi.) Nota che il file sample-aliases.cfg usa nomi di pin che iniziano con il prefisso \"ar\" invece di \"D\" (ad esempio, il pin Arduino D23 \u00e8 alias Klipper ar23 ) e il prefisso \"analog\" invece di \"A \" (ad esempio, il pin Arduino A14 \u00e8 alias di Klipper analog14 ). Risposta lunga: Klipper utilizza i nomi dei pin standard definiti dal microcontrollore. Sui chip Atmega questi pin hardware hanno nomi come PA4 , PC7 o PD2 . Tempo fa, il progetto Arduino ha deciso di evitare di utilizzare i nomi hardware standard a favore dei propri nomi pin basati su numeri incrementali: questi nomi Arduino generalmente assomigliano a \"D23\" o \"A14\". Questa \u00e8 stata una scelta sfortunata che ha portato a una grande confusione. In particolare, i numeri dei pin di Arduino spesso non si traducono negli stessi nomi hardware. Ad esempio, D21 \u00e8 PD0 su una comune scheda Arduino, ma \u00e8 PC7 su un'altra comune scheda Arduino. Per evitare questa confusione, il codice di base di Klipper utilizza i nomi dei pin standard definiti dal microcontrollore.","title":"Come posso convertire un numero di pin Marlin in un nome pin di Klipper?"},{"location":"FAQ.html#devo-collegare-il-mio-dispositivo-a-un-tipo-specifico-di-pin-del-microcontrollore","text":"Dipende dal tipo di dispositivo e dal tipo di pin: Pin ADC (o pin analogici): per termistori e sensori \"analogici\" simili, il dispositivo deve essere collegato a un pin compatibile con \"analogico\" o \"ADC\" sul microcontrollore. Se configuri Klipper per utilizzare un pin che non \u00e8 compatibile con l'analogico, Klipper segnaler\u00e0 un errore \"Non un pin ADC valido\". Pin PWM (o pin Timer): Klipper non utilizza PWM hardware per impostazione predefinita per nessun dispositivo. Quindi, in generale, \u00e8 possibile collegare riscaldatori, ventole e dispositivi simili a qualsiasi pin IO generico. Tuttavia, le ventole e i dispositivi output_pin possono essere opzionalmente configurati per utilizzare hardware_pwm: True , nel qual caso il microcontrollore deve supportare PWM hardware sul pin (altrimenti, Klipper segnaler\u00e0 un errore \"pin PWM non valido\"). Pin IRQ (o pin di interrupt): Klipper non utilizza gli interrupt hardware sui pin IO, quindi non \u00e8 mai necessario collegare un dispositivo a uno di questi pin del microcontrollore. Pin SPI: quando si utilizza l'SPI hardware, \u00e8 necessario collegare i pin ai pin SPI del microcontrollore. Tuttavia, la maggior parte dei dispositivi pu\u00f2 essere configurata per utilizzare \"SPI software\", nel qual caso \u00e8 possibile utilizzare qualsiasi pin IO generico. Pin I2C: quando si utilizza I2C \u00e8 necessario collegare i pin ai pin compatibili con I2C del microcontrollore. Altri dispositivi possono essere collegati a qualsiasi pin IO generico. Ad esempio, stepper, riscaldatori, ventole, sonde Z, servocomandi, LED, comuni display LCD hd44780/st7920, la linea di controllo Trinamic UART pu\u00f2 essere collegata a qualsiasi pin IO generico.","title":"Devo collegare il mio dispositivo a un tipo specifico di pin del microcontrollore?"},{"location":"FAQ.html#come-posso-annullare-una-richiesta-di-attesa-temperatura-m109m190","text":"Passare alla scheda del terminale OctoPrint ed emettere un comando M112 nel terminale. Il comando M112 far\u00e0 entrare Klipper in uno stato di \"arresto\" e causer\u00e0 la disconnessione di OctoPrint da Klipper. Passare all'area di connessione di OctoPrint e fare clic su \"Connetti\" per fare in modo che OctoPrint si riconnetta. Torna alla scheda del terminale ed emetti un comando FIRMWARE_RESTART per cancellare lo stato di errore di Klipper. Dopo aver completato questa sequenza, la precedente richiesta di riscaldamento verr\u00e0 annullata e potrebbe essere avviata una nuova stampa.","title":"Come posso annullare una richiesta di \"attesa temperatura\" M109/M190?"},{"location":"FAQ.html#posso-scoprire-se-la-stampante-ha-perso-dei-passaggi","text":"In un certo senso s\u00ec. Avviare la stampante, emettere un comando GET_POSITION , eseguire la stampa, tornare a casa ed emettere un altro GET_POSITION . Quindi confronta i valori nella riga mcu: . Questo potrebbe essere utile per regolare impostazioni come correnti, accelerazioni e velocit\u00e0 del motore passo-passo senza dover effettivamente stampare qualcosa e sprecare il filamento: basta eseguire alcuni movimenti ad alta velocit\u00e0 tra i comandi GET_POSITION . Si noti che gli stessi interruttori di fine corsa tendono a attivarsi in posizioni leggermente diverse, quindi una differenza di un paio di micropassi \u00e8 probabilmente il risultato di imprecisioni di fine corsa. Un motore passo-passo stesso pu\u00f2 perdere passi solo con incrementi di 4 passi completi. (Quindi, se si utilizzano 16 micropassi, un passo perso sullo stepper comporterebbe lo spegnimento del contatore di passi \"mcu:\" di un multiplo di 64 micropassi.)","title":"Posso scoprire se la stampante ha perso dei passaggi?"},{"location":"FAQ.html#perche-klipper-segnala-errori-ho-perso-la-mia-stampa","text":"Risposta breve: vogliamo sapere se le nostre stampanti rilevano un problema in modo che il problema sottostante possa essere risolto e possiamo ottenere stampe di ottima qualit\u00e0. Non vogliamo assolutamente che le nostre stampanti producano in silenzio stampe di bassa qualit\u00e0. Risposta lunga: Klipper \u00e8 stato progettato per risolvere automaticamente molti problemi transitori. Ad esempio, rileva automaticamente gli errori di comunicazione e li ritrasmette; pianifica le azioni in anticipo e bufferizza i comandi su pi\u00f9 livelli per consentire tempi precisi anche con interferenze intermittenti. Tuttavia, se il software rileva un errore dal quale non pu\u00f2 essere ripristinato, se gli viene ordinato di eseguire un'azione non valida o se rileva che \u00e8 irrimediabilmente incapace di eseguire l'attivit\u00e0 comandata, Klipper segnaler\u00e0 un errore. In queste situazioni c'\u00e8 un alto rischio di produrre una stampa di bassa qualit\u00e0 (o peggio). Si spera che avvisare gli utenti consentir\u00e0 loro di risolvere il problema sottostante e migliorare la qualit\u00e0 complessiva delle loro stampe. Ci sono alcune domande correlate: perch\u00e9 Klipper non mette invece in pausa la stampa? Segnalare invece un avviso? Verificare la presenza di errori prima della stampa? Ignorare gli errori nei comandi digitati dall'utente? eccetera? Attualmente Klipper legge i comandi utilizzando il protocollo G-Code e sfortunatamente il protocollo di comando G-Code non \u00e8 sufficientemente flessibile per rendere pratiche queste alternative oggi. C'\u00e8 l'interesse degli sviluppatori nel migliorare l'esperienza dell'utente durante eventi anomali, ma si prevede che ci\u00f2 richieder\u00e0 un notevole lavoro infrastrutturale (incluso un passaggio dal G-Code).","title":"Perch\u00e9 Klipper segnala errori? Ho perso la mia stampa!"},{"location":"FAQ.html#come-si-esegue-laggiornamento-al-software-piu-recente","text":"Il primo passaggio per l'aggiornamento del software consiste nell'esaminare l'ultimo documento config changes . A volte, vengono apportate modifiche al software che richiedono agli utenti di aggiornare le proprie impostazioni come parte di un aggiornamento del software. \u00c8 una buona idea rivedere questo documento prima dell'aggiornamento. Quando sei pronto per l'aggiornamento, il metodo generale \u00e8 quello di entrare in Raspberry Pi ed eseguire: cd ~/klipper git pull ~/klipper/scripts/install-octopi.sh Quindi si pu\u00f2 ricompilare e flashare il codice del microcontrollore. Per esempio: make menuconfig make clean make sudo service klipper stop make flash FLASH_DEVICE=/dev/ttyACM0 sudo service klipper start Tuttavia, capita spesso che cambi solo il software host. In questo caso \u00e8 possibile aggiornare e riavviare solo il software host con: cd ~/klipper git pull sudo service klipper restart Se dopo aver utilizzato questo collegamento il software avverte della necessit\u00e0 di eseguire il reflash del microcontrollore o si verifica qualche altro errore insolito, seguire i passaggi completi di aggiornamento descritti sopra. Se gli errori persistono, ricontrolla il documento config changes , poich\u00e9 potrebbe essere necessario modificare la configurazione della stampante. Si noti che i comandi g-code RESTART e FIRMWARE_RESTART non caricano il nuovo software: i comandi \"sudo service klipper restart\" e \"make flash\" di cui sopra sono necessari affinch\u00e9 una modifica del software abbia effetto.","title":"Come si esegue l'aggiornamento al software pi\u00f9 recente?"},{"location":"FAQ.html#come-faccio-a-disinstallare-klipper","text":"Dal alto del firmware, non deve succedere nulla di speciale. Basta seguire le indicazioni per il flashing del nuovo firmware. Dal lato del raspberry pi, uno script di disinstallazione \u00e8 disponibile in scripts/klipper-uninstall.sh . Per esempio: sudo ~/klipper/scripts/klipper-uninstall.sh rm -rf ~/klippy-env ~/klipper","title":"Come faccio a disinstallare Klipper?"},{"location":"Features.html","text":"Caratteristiche \u00b6 Klipper ha diverse caratteristiche interessanti: Movimento passo-passo di alta precisione. Klipper utilizza un processore applicativo (come un Raspberry Pi a basso costo) per calcolare i movimenti della stampante. Il processore dell'applicazione determina quando far avanzare ciascun motore passo-passo, comprime quegli eventi, li trasmette al microcontrollore e quindi il microcontrollore esegue ogni evento all'ora richiesta. Ogni evento stepper \u00e8 programmato con una precisione di 25 microsecondi o superiore. Il software non utilizza stime cinematiche (come l'algoritmo di Bresenham), ma calcola tempi di passo precisi in base alla fisica dell'accelerazione e alla fisica della cinematica della macchina. Il movimento passo-passo pi\u00f9 preciso garantisce un funzionamento della stampante pi\u00f9 silenzioso e stabile. Le migliori prestazioni della categoria. Klipper \u00e8 in grado di raggiungere velocit\u00e0 di passo elevate sia sui microcontrollori nuovi che su quelli vecchi. Anche i vecchi microcontrollori a 8 bit possono ottenere velocit\u00e0 superiori a 175.000 passi al secondo. Sui microcontrollori pi\u00f9 recenti sono possibili diversi milioni di passi al secondo. Velocit\u00e0 di stepper pi\u00f9 elevate consentono velocit\u00e0 di stampa pi\u00f9 elevate. La temporizzazione degli eventi dello stepper rimane precisa anche a velocit\u00e0 elevate, migliorando la stabilit\u00e0 generale. Klipper supporta stampanti con pi\u00f9 microcontrollori. Ad esempio, un microcontrollore potrebbe essere utilizzato per controllare un estrusore, mentre un altro controlla i riscaldatori della stampante, mentre un terzo controlla il resto della stampante. Il software host Klipper implementa la sincronizzazione dell'orologio per tenere conto della deriva dell'orologio tra i microcontrollori. Non \u00e8 necessario alcun codice speciale per abilitare pi\u00f9 microcontrollori: sono necessarie solo alcune righe in pi\u00f9 nel file di configurazione. Configurazione tramite semplice file. Non \u00e8 necessario eseguire il reflash del microcontrollore per modificare un'impostazione. Tutta la configurazione di Klipper \u00e8 memorizzata in un file di configurazione standard che pu\u00f2 essere facilmente modificato. Ci\u00f2 semplifica la configurazione e la manutenzione dell'hardware. Klipper supporta \"Smooth Pressure Advance\", un meccanismo per tenere conto degli effetti della pressione all'interno di un estrusore. Ci\u00f2 riduce la \"melma\" dell'estrusore e migliora la qualit\u00e0 degli angoli di stampa. L'implementazione di Klipper non introduce variazioni istantanee della velocit\u00e0 dell'estrusore, il che migliora la stabilit\u00e0 e la robustezza complessive. Klipper supporta \"Input Shaping\" per ridurre l'impatto delle vibrazioni sulla qualit\u00e0 di stampa. Ci\u00f2 pu\u00f2 ridurre o eliminare il \"ringing\" (noto anche come \"ghosting\", \"eco\" o \"increspatura\") nelle stampe. Pu\u00f2 anche consentire di ottenere velocit\u00e0 di stampa pi\u00f9 elevate pur mantenendo un'elevata qualit\u00e0 di stampa. Klipper utilizza un \"risolutore iterativo\" per calcolare sequenze temporali precisi da semplici equazioni cinematiche. Ci\u00f2 semplifica il porting di Klipper su nuovi tipi di robot e mantiene i tempi precisi anche con cinematiche complesse (non \u00e8 necessaria la \"segmentazione della linea\"). Klipper \u00e8 indipendente dall'hardware. Si dovrebbe ottenere la stessa tempistica precisa indipendentemente dall'hardware dell'elettronica di basso livello. Il codice del microcontrollore Klipper \u00e8 progettato per seguire fedelmente la pianificazione fornita dal software host Klipper (o avvisare in modo evidente l'utente se non \u00e8 in grado di farlo). Ci\u00f2 semplifica l'utilizzo dell'hardware disponibile, l'aggiornamento al nuovo hardware e la fiducia nell'hardware. Codice portatile. Klipper funziona su microcontrollori basati su ARM, AVR e PRU. Le stampanti esistenti in stile \"reprap\" possono eseguire Klipper senza modifiche hardware: basta aggiungere un Raspberry Pi. Il layout del codice interno di Klipper semplifica il supporto anche di altre architetture di microcontrollori. Codice pi\u00f9 semplice. Klipper utilizza un linguaggio di alto livello (Python) per la maggior parte del codice. Gli algoritmi cinematici, l'analisi del G-code, gli algoritmi di riscaldamento e termistore, ecc. sono tutti scritti in Python. Ci\u00f2 semplifica lo sviluppo di nuove funzionalit\u00e0. Macro programmabili personalizzate. \u00c8 possibile definire nuovi comandi G-Code nel file di configurazione della stampante (non sono necessarie modifiche al codice). Questi comandi sono programmabili, consentendo loro di produrre azioni diverse a seconda dello stato della stampante. Server API integrato. Oltre all'interfaccia G-Code standard, Klipper supporta una ricca interfaccia applicativa basata su JSON. Ci\u00f2 consente ai programmatori di creare applicazioni esterne con un controllo dettagliato della stampante. Caratteristiche aggiuntive \u00b6 Klipper supporta molte funzionalit\u00e0 standard della stampante 3D: Diverse interfacce web disponibili. Funziona con Randa, Fluidd, OctoPrint e altri. Ci\u00f2 consente di controllare la stampante utilizzando un normale browser web. Lo stesso Raspberry Pi che esegue Klipper pu\u00f2 anche eseguire l'interfaccia web. Supporto G-code standard. Sono supportati i comandi G-code comuni prodotti dai tipici \"slicer\" (SuperSlicer, Cura, PrusaSlicer, ecc.). Supporto per pi\u00f9 estrusori. Sono supportati anche estrusori con riscaldatori condivisi ed estrusori su carrelli indipendenti (IDEX). Supporto per stampanti cartesiane, delta, corexy, corexz, hybrid-corexy, hybrid-corexz, deltesian, rotary delta, polar e cable winch. Supporto per il livellamento automatico del letto. Klipper pu\u00f2 essere configurato per il rilevamento di base dell'inclinazione del piatto o per il livellamento del piatto a mesh completa. Se il piatto utilizza pi\u00f9 stepper Z, Klipper pu\u00f2 anche livellare manipolando in modo indipendente gli stepper Z. Sono supportate la maggior parte delle sonde di altezza Z, comprese le sonde BL-Touch e le sonde servoattivate. Supporto per la calibrazione delta automatica. Lo strumento di calibrazione pu\u00f2 eseguire la calibrazione dell'altezza di base e una calibrazione avanzata delle dimensioni X e Y. La calibrazione pu\u00f2 essere eseguita con una sonda di altezza Z o tramite tastatura manuale. Supporto \"escludi oggetto\" in fase di esecuzione. Se configurato, questo modulo pu\u00f2 facilitare l'annullamento di un solo oggetto in una stampa multiparte. Supporto per sensori di temperatura comuni (ad es. termistori comuni, AD595, AD597, AD849x, PT100, PT1000, MAX6675, MAX31855, MAX31856, MAX31865, BME280, HTU21D, DS18B20 e LM75). \u00c8 inoltre possibile configurare termistori personalizzati e sensori di temperatura analogici personalizzati. \u00c8 possibile monitorare il sensore di temperatura del microcontrollore interno e il sensore di temperatura interna di un Raspberry Pi. Protezione del riscaldatore termico di base abilitata di default. Supporto per ventole standard, ventole per ugelli e ventole a temperatura controllata. Non \u00e8 necessario mantenere le ventole in funzione quando la stampante \u00e8 inattiva. La velocit\u00e0 della ventola pu\u00f2 essere monitorata su ventole dotate di contagiri. Supporto per la configurazione in fase di esecuzione dei driver per motori passo-passo TMC2130, TMC2208/TMC2224, TMC2209, TMC2660 e TMC5160. \u00c8 inoltre disponibile il supporto per il controllo corrente dei tradizionali driver passo-passo tramite i pin AD5206, DAC084S085, MCP4451, MCP4728, MCP4018 e PWM. Supporto per comuni display LCD collegati direttamente alla stampante. \u00c8 disponibile anche un menu predefinito. Il contenuto del display e del menu pu\u00f2 essere completamente personalizzato tramite il file di configurazione. Accelerazione costante e supporto \"look-ahead\". Tutti i movimenti della stampante accelereranno gradualmente dall'arresto alla velocit\u00e0 di crociera, quindi decelereranno fino all'arresto. Il flusso in entrata dei comandi di movimento del G-code viene messo in coda e analizzato: l'accelerazione tra i movimenti in una direzione simile sar\u00e0 ottimizzata per ridurre gli arresti di stampa e migliorare il tempo di stampa complessivo. Klipper implementa un algoritmo \"stepper phase endstop\" che pu\u00f2 migliorare la precisione dei tipici interruttori endstop. Se regolato correttamente, pu\u00f2 migliorare l'adesione del primo strato di stampa. Supporto per sensori di presenza del filamento, sensori di movimento del filamento e sensori di larghezza del filamento. Supporto per misurare e registrare l'accelerazione utilizzando gli accelerometri adxl345, mpu9250 e mpu6050. Supporto per limitare la velocit\u00e0 massima di brevi spostamenti a \"zigzag\" per ridurre le vibrazioni e il rumore della stampante. Per ulteriori informazioni, vedere il documento cinematica . Sono disponibili file di configurazione di esempio per molte stampanti comuni. Controllare la directory di configurazione per un elenco. Per iniziare con Klipper, leggi la guida installazione . Benchmark dei passi \u00b6 Di seguito sono riportati i risultati dei test delle prestazioni degli stepper. I numeri visualizzati rappresentano il numero totale di passi al secondo sul microcontrollore. Microcontrollore 1 stepper attivo 3 stepper attivi 16Mhz AVR 157K 99K 20Mhz AVR 196K 123K SAMD21 686K 471K STM32F042 814K 578K Beaglebone PRU 866K 708K STM32G0B1 1103K 790K STM32F103 1180K 818K SAM3X8E 1273K 981K SAM4S8C 1690K 1385K LPC1768 1923K 1351K LPC1769 2353K 1622K RP2040 2400K 1636K SAM4E8E 2500K 1674K SAMD51 3077K 1885K AR100 3529K 2507K STM32F407 3652K 2459K STM32F446 3913K 2634K STM32H743 9091K 6061K Se non sei sicuro del microcontrollore su una particolare scheda, trova il file di configurazione appropriato e cerca il nome del microcontrollore nei commenti nella parte superiore di quel file. Ulteriori dettagli sui benchmark sono disponibili nel documento Benchmarks .","title":"Caratteristiche"},{"location":"Features.html#caratteristiche","text":"Klipper ha diverse caratteristiche interessanti: Movimento passo-passo di alta precisione. Klipper utilizza un processore applicativo (come un Raspberry Pi a basso costo) per calcolare i movimenti della stampante. Il processore dell'applicazione determina quando far avanzare ciascun motore passo-passo, comprime quegli eventi, li trasmette al microcontrollore e quindi il microcontrollore esegue ogni evento all'ora richiesta. Ogni evento stepper \u00e8 programmato con una precisione di 25 microsecondi o superiore. Il software non utilizza stime cinematiche (come l'algoritmo di Bresenham), ma calcola tempi di passo precisi in base alla fisica dell'accelerazione e alla fisica della cinematica della macchina. Il movimento passo-passo pi\u00f9 preciso garantisce un funzionamento della stampante pi\u00f9 silenzioso e stabile. Le migliori prestazioni della categoria. Klipper \u00e8 in grado di raggiungere velocit\u00e0 di passo elevate sia sui microcontrollori nuovi che su quelli vecchi. Anche i vecchi microcontrollori a 8 bit possono ottenere velocit\u00e0 superiori a 175.000 passi al secondo. Sui microcontrollori pi\u00f9 recenti sono possibili diversi milioni di passi al secondo. Velocit\u00e0 di stepper pi\u00f9 elevate consentono velocit\u00e0 di stampa pi\u00f9 elevate. La temporizzazione degli eventi dello stepper rimane precisa anche a velocit\u00e0 elevate, migliorando la stabilit\u00e0 generale. Klipper supporta stampanti con pi\u00f9 microcontrollori. Ad esempio, un microcontrollore potrebbe essere utilizzato per controllare un estrusore, mentre un altro controlla i riscaldatori della stampante, mentre un terzo controlla il resto della stampante. Il software host Klipper implementa la sincronizzazione dell'orologio per tenere conto della deriva dell'orologio tra i microcontrollori. Non \u00e8 necessario alcun codice speciale per abilitare pi\u00f9 microcontrollori: sono necessarie solo alcune righe in pi\u00f9 nel file di configurazione. Configurazione tramite semplice file. Non \u00e8 necessario eseguire il reflash del microcontrollore per modificare un'impostazione. Tutta la configurazione di Klipper \u00e8 memorizzata in un file di configurazione standard che pu\u00f2 essere facilmente modificato. Ci\u00f2 semplifica la configurazione e la manutenzione dell'hardware. Klipper supporta \"Smooth Pressure Advance\", un meccanismo per tenere conto degli effetti della pressione all'interno di un estrusore. Ci\u00f2 riduce la \"melma\" dell'estrusore e migliora la qualit\u00e0 degli angoli di stampa. L'implementazione di Klipper non introduce variazioni istantanee della velocit\u00e0 dell'estrusore, il che migliora la stabilit\u00e0 e la robustezza complessive. Klipper supporta \"Input Shaping\" per ridurre l'impatto delle vibrazioni sulla qualit\u00e0 di stampa. Ci\u00f2 pu\u00f2 ridurre o eliminare il \"ringing\" (noto anche come \"ghosting\", \"eco\" o \"increspatura\") nelle stampe. Pu\u00f2 anche consentire di ottenere velocit\u00e0 di stampa pi\u00f9 elevate pur mantenendo un'elevata qualit\u00e0 di stampa. Klipper utilizza un \"risolutore iterativo\" per calcolare sequenze temporali precisi da semplici equazioni cinematiche. Ci\u00f2 semplifica il porting di Klipper su nuovi tipi di robot e mantiene i tempi precisi anche con cinematiche complesse (non \u00e8 necessaria la \"segmentazione della linea\"). Klipper \u00e8 indipendente dall'hardware. Si dovrebbe ottenere la stessa tempistica precisa indipendentemente dall'hardware dell'elettronica di basso livello. Il codice del microcontrollore Klipper \u00e8 progettato per seguire fedelmente la pianificazione fornita dal software host Klipper (o avvisare in modo evidente l'utente se non \u00e8 in grado di farlo). Ci\u00f2 semplifica l'utilizzo dell'hardware disponibile, l'aggiornamento al nuovo hardware e la fiducia nell'hardware. Codice portatile. Klipper funziona su microcontrollori basati su ARM, AVR e PRU. Le stampanti esistenti in stile \"reprap\" possono eseguire Klipper senza modifiche hardware: basta aggiungere un Raspberry Pi. Il layout del codice interno di Klipper semplifica il supporto anche di altre architetture di microcontrollori. Codice pi\u00f9 semplice. Klipper utilizza un linguaggio di alto livello (Python) per la maggior parte del codice. Gli algoritmi cinematici, l'analisi del G-code, gli algoritmi di riscaldamento e termistore, ecc. sono tutti scritti in Python. Ci\u00f2 semplifica lo sviluppo di nuove funzionalit\u00e0. Macro programmabili personalizzate. \u00c8 possibile definire nuovi comandi G-Code nel file di configurazione della stampante (non sono necessarie modifiche al codice). Questi comandi sono programmabili, consentendo loro di produrre azioni diverse a seconda dello stato della stampante. Server API integrato. Oltre all'interfaccia G-Code standard, Klipper supporta una ricca interfaccia applicativa basata su JSON. Ci\u00f2 consente ai programmatori di creare applicazioni esterne con un controllo dettagliato della stampante.","title":"Caratteristiche"},{"location":"Features.html#caratteristiche-aggiuntive","text":"Klipper supporta molte funzionalit\u00e0 standard della stampante 3D: Diverse interfacce web disponibili. Funziona con Randa, Fluidd, OctoPrint e altri. Ci\u00f2 consente di controllare la stampante utilizzando un normale browser web. Lo stesso Raspberry Pi che esegue Klipper pu\u00f2 anche eseguire l'interfaccia web. Supporto G-code standard. Sono supportati i comandi G-code comuni prodotti dai tipici \"slicer\" (SuperSlicer, Cura, PrusaSlicer, ecc.). Supporto per pi\u00f9 estrusori. Sono supportati anche estrusori con riscaldatori condivisi ed estrusori su carrelli indipendenti (IDEX). Supporto per stampanti cartesiane, delta, corexy, corexz, hybrid-corexy, hybrid-corexz, deltesian, rotary delta, polar e cable winch. Supporto per il livellamento automatico del letto. Klipper pu\u00f2 essere configurato per il rilevamento di base dell'inclinazione del piatto o per il livellamento del piatto a mesh completa. Se il piatto utilizza pi\u00f9 stepper Z, Klipper pu\u00f2 anche livellare manipolando in modo indipendente gli stepper Z. Sono supportate la maggior parte delle sonde di altezza Z, comprese le sonde BL-Touch e le sonde servoattivate. Supporto per la calibrazione delta automatica. Lo strumento di calibrazione pu\u00f2 eseguire la calibrazione dell'altezza di base e una calibrazione avanzata delle dimensioni X e Y. La calibrazione pu\u00f2 essere eseguita con una sonda di altezza Z o tramite tastatura manuale. Supporto \"escludi oggetto\" in fase di esecuzione. Se configurato, questo modulo pu\u00f2 facilitare l'annullamento di un solo oggetto in una stampa multiparte. Supporto per sensori di temperatura comuni (ad es. termistori comuni, AD595, AD597, AD849x, PT100, PT1000, MAX6675, MAX31855, MAX31856, MAX31865, BME280, HTU21D, DS18B20 e LM75). \u00c8 inoltre possibile configurare termistori personalizzati e sensori di temperatura analogici personalizzati. \u00c8 possibile monitorare il sensore di temperatura del microcontrollore interno e il sensore di temperatura interna di un Raspberry Pi. Protezione del riscaldatore termico di base abilitata di default. Supporto per ventole standard, ventole per ugelli e ventole a temperatura controllata. Non \u00e8 necessario mantenere le ventole in funzione quando la stampante \u00e8 inattiva. La velocit\u00e0 della ventola pu\u00f2 essere monitorata su ventole dotate di contagiri. Supporto per la configurazione in fase di esecuzione dei driver per motori passo-passo TMC2130, TMC2208/TMC2224, TMC2209, TMC2660 e TMC5160. \u00c8 inoltre disponibile il supporto per il controllo corrente dei tradizionali driver passo-passo tramite i pin AD5206, DAC084S085, MCP4451, MCP4728, MCP4018 e PWM. Supporto per comuni display LCD collegati direttamente alla stampante. \u00c8 disponibile anche un menu predefinito. Il contenuto del display e del menu pu\u00f2 essere completamente personalizzato tramite il file di configurazione. Accelerazione costante e supporto \"look-ahead\". Tutti i movimenti della stampante accelereranno gradualmente dall'arresto alla velocit\u00e0 di crociera, quindi decelereranno fino all'arresto. Il flusso in entrata dei comandi di movimento del G-code viene messo in coda e analizzato: l'accelerazione tra i movimenti in una direzione simile sar\u00e0 ottimizzata per ridurre gli arresti di stampa e migliorare il tempo di stampa complessivo. Klipper implementa un algoritmo \"stepper phase endstop\" che pu\u00f2 migliorare la precisione dei tipici interruttori endstop. Se regolato correttamente, pu\u00f2 migliorare l'adesione del primo strato di stampa. Supporto per sensori di presenza del filamento, sensori di movimento del filamento e sensori di larghezza del filamento. Supporto per misurare e registrare l'accelerazione utilizzando gli accelerometri adxl345, mpu9250 e mpu6050. Supporto per limitare la velocit\u00e0 massima di brevi spostamenti a \"zigzag\" per ridurre le vibrazioni e il rumore della stampante. Per ulteriori informazioni, vedere il documento cinematica . Sono disponibili file di configurazione di esempio per molte stampanti comuni. Controllare la directory di configurazione per un elenco. Per iniziare con Klipper, leggi la guida installazione .","title":"Caratteristiche aggiuntive"},{"location":"Features.html#benchmark-dei-passi","text":"Di seguito sono riportati i risultati dei test delle prestazioni degli stepper. I numeri visualizzati rappresentano il numero totale di passi al secondo sul microcontrollore. Microcontrollore 1 stepper attivo 3 stepper attivi 16Mhz AVR 157K 99K 20Mhz AVR 196K 123K SAMD21 686K 471K STM32F042 814K 578K Beaglebone PRU 866K 708K STM32G0B1 1103K 790K STM32F103 1180K 818K SAM3X8E 1273K 981K SAM4S8C 1690K 1385K LPC1768 1923K 1351K LPC1769 2353K 1622K RP2040 2400K 1636K SAM4E8E 2500K 1674K SAMD51 3077K 1885K AR100 3529K 2507K STM32F407 3652K 2459K STM32F446 3913K 2634K STM32H743 9091K 6061K Se non sei sicuro del microcontrollore su una particolare scheda, trova il file di configurazione appropriato e cerca il nome del microcontrollore nei commenti nella parte superiore di quel file. Ulteriori dettagli sui benchmark sono disponibili nel documento Benchmarks .","title":"Benchmark dei passi"},{"location":"G-Codes.html","text":"G-Codes \u00b6 Questo documento descrive i comandi che Klipper supporta. Questi sono i comandi che si possono inserire nella scheda del terminale OctoPrint. Comandi G-Code \u00b6 Klipper supporta i seguenti comandi G-Code standard: Movimento (G0 or G1): G1 [X] [Y] [Z] [E] [F] Sosta: G4 P Sposta all'origine: G28 [X] [Y] [Z] Spegnere i motori: M18 o M84 Attendi che li movimenti correnti finiscano: M400 Utilizzare distanze assolute/relative per l'estrusione: M82 , M83 Usa coordinate assolute/relative: G90 , G91 Impostare la posizione: G92 [X] [Y] [Z] [E] Impostare la percentuale di override del fattore di velocit\u00e0: M220 S Imposta la percentuale di sostituzione del fattore di estrusione: M221 S Impostare l'accelerazione: M204 S OPPURE M204 P T Nota: se S non viene specificato e vengono specificati sia P che T, l'accelerazione viene impostata al minimo di P e T. Se viene specificato solo uno di P o T, il comando non ha effetto. Ottieni la temperatura dell'estrusore: M105 Imposta la temperatura dell'estrusore: M104 [T] [S] Imposta la temperatura dell'estrusore e attende: M109 [T] S Nota: M109 attende sempre che la temperatura si assesti al valore richiesto Imposta la temperatura del piatto: M140 [S] Imposta la temperatura del piatto e attende: M190 S Nota: M190 attende sempre che la temperatura si assesti al valore richiesto Imposta la velocit\u00e0 della ventola: M106 S Spegnere la ventola: M107 Arresto di emergenza: M112 Ottieni la posizione attuale: M114 Ottieni la versione del firmware: M115 Per ulteriori dettagli sui comandi precedenti, vedere la documentazione RepRap G-Code . L'obiettivo di Klipper \u00e8 supportare i comandi G-Code prodotti da comuni software di terze parti (ad es. OctoPrint, Printrun, Slic3r, Cura, ecc.) nelle loro configurazioni standard. Non \u00e8 un obiettivo supportare ogni possibile comando G-Code. Invece, Klipper preferisce comandi leggibili dall'uomo \"comandi G-Code estesi\" . Allo stesso modo, l'output del terminale G-Code \u00e8 inteso solo per essere leggibile dall'uomo - vedere il documento del server API se si controlla Klipper da un software esterno. Se si necessita di un comando G-Code meno comune, potrebbe essere possibile implementarlo con una [sezione di configurazione gcode_macro] personalizzata (Config_Reference.md#gcode_macro). Ad esempio, si potrebbe usare questo per implementare: G12 , G29 , G30 , G31 , M42 , M80 , M81 , T1 , ecc. Comandi aggiuntivi \u00b6 Klipper utilizza comandi G-Code \"estesi\" per la configurazione e lo stato generale. Questi comandi estesi seguono tutti un formato simile: iniziano con un nome di comando e possono essere seguiti da uno o pi\u00f9 parametri. Ad esempio: SET_SERVO SERVO=mioservo ANGLE=5.3 . In questo documento, i comandi ed i parametri sono mostrati in maiuscolo, tuttavia non fanno distinzione tra maiuscole e minuscole. (Quindi, \"SET_SERVO\" e \"set_servo\" eseguono entrambi lo stesso comando.) Questa sezione \u00e8 organizzata in base al nome del modulo Klipper, che generalmente segue i nomi delle sezioni specificati nel file di configurazione della stampante . Si noti che alcuni moduli vengono caricati automaticamente. [adxl345] \u00b6 I seguenti comandi sono disponibili quando una sezione di configurazione adxl345 \u00e8 abilitata. ACCELEROMETER_MEASURE \u00b6 ACCELEROMETER_MEASURE [CHIP=] [NAME=] : Avvia le misurazioni dell'accelerometro al numero richiesto di campioni al secondo. Se CHIP non \u00e8 specificato, il valore predefinito \u00e8 \"adxl345\". Il comando funziona in modalit\u00e0 start-stop: alla prima esecuzione avvia le misure, alla successiva esecuzione le interrompe. I risultati delle misurazioni vengono scritti in un file denominato /tmp/adxl345--.csv dove \u00e8 il nome del chip dell'accelerometro ( my_chip_name da [adxl345 my_chip_name] ) e \u00e8 il parametro NAME facoltativo. Se NAME non \u00e8 specificato, il valore predefinito \u00e8 l'ora corrente nel formato \"AAAAMMGG_HHMMSS\". Se l'accelerometro non ha un nome nella sua sezione di configurazione (semplicemente [adxl345] ), allora la parte del nome non viene generata. ACCELEROMETER_QUERY \u00b6 ACCELEROMETER_QUERY [CHIP=] [RATE=] : interroga l'accelerometro per il valore corrente. Se CHIP non \u00e8 specificato, il valore predefinito \u00e8 \"adxl345\". Se RATE non \u00e8 specificato, viene utilizzato il valore predefinito. Questo comando \u00e8 utile per testare la connessione all'accelerometro ADXL345: uno dei valori restituiti dovrebbe essere un'accelerazione di caduta libera (+/- un po' di rumore del chip). ACCELEROMETER_DEBUG_READ \u00b6 ACCELEROMETER_DEBUG_READ [CHIP=] REG= : interroga l'ADXL345 register \"register\" (es. 44 o 0x2C). Pu\u00f2 essere utile per scopi di debug. ACCELEROMETER_DEBUG_WRITE \u00b6 ACCELEROMETER_DEBUG_WRITE [CHIP=] REG= VAL= : Scrive il valore \"value\" grezzo in un registro \"register\". Sia \"value\" che \"registrer\" possono essere un numero intero decimale o esadecimale. Usare con cura e fare riferimento alla scheda tecnica ADXL345 per riferimento. [angle] \u00b6 I seguenti comandi sono disponibili quando una sezione di configurazione dell'angolo \u00e8 abilitata. ANGLE_CALIBRATE \u00b6 ANGLE_CALIBRATE CHIP= : Esegue la calibrazione dell'angolo sul sensore dato (deve esserci una sezione di configurazione [angle chip_name] che ha specificato un parametro stepper ). IMPORTANTE - questo strumento comander\u00e0 al motore passo-passo di muoversi senza controllare i normali limiti della cinematica. Idealmente, il motore dovrebbe essere scollegato da qualsiasi carrello della stampante prima di eseguire la calibrazione. Se non \u00e8 possibile scollegare lo stepper dalla stampante, assicurarsi che il carrello sia vicino al centro della sua guida prima di iniziare la calibrazione. (Il motore passo-passo pu\u00f2 spostarsi avanti o indietro di due rotazioni complete durante questo test.) Dopo aver completato questo test, utilizzare il comando SAVE_CONFIG per salvare i dati di calibrazione nel file di configurazione. Per utilizzare questo strumento \u00e8 necessario installare il pacchetto Python \"numpy\" (consultare il measuring resonance document per ulteriori informazioni). ANGLE_DEBUG_READ \u00b6 ANGLE_DEBUG_READ CHIP= REG= : Interroga il registro del sensore \"register\" (ad es. 44 o 0x2C). Pu\u00f2 essere utile per scopi di debug. Questo \u00e8 disponibile solo per i chip tle5012b. ANGLE_DEBUG_WRITE \u00b6 ANGLE_DEBUG_WRITE CHIP= REG= VAL= : scrive il valore \"value\" grezzo nel registro \"register\". Sia \"value\" che \"register\" possono essere un numero intero decimale o esadecimale. Usare con cautela e fare riferimento alla scheda tecnica del sensore per riferimento. Questo \u00e8 disponibile solo per i chip tle5012b. [bed_mesh] \u00b6 I seguenti comandi sono disponibili quando la sezione di configurazione bed_mesh \u00e8 abilitata (consultare anche la guida della mesh del letto ). BED_MESH_CALIBRATE \u00b6 BED_MESH_CALIBRATE [METHOD=manual] [HORIZONTAL_MOVE_Z=] [=] [=] : questo comando sonda il piatto utilizzando i punti generati specificati dai parametri nella configurazione. Dopo il sondaggio, viene generata una mesh e il movimento z viene regolato in base alla mesh. Vedere il comando PROBE per i dettagli sui parametri opzionali della sonda. Se viene specificato METHOD=manual, viene attivato lo strumento di rilevamento manuale: vedere il comando MANUAL_PROBE sopra per dettagli sui comandi aggiuntivi disponibili mentre questo strumento \u00e8 attivo. Il valore opzionale \"HORIZONTAL_MOVE_Z\" sovrascrive l'opzione \"horizontal_move_z\" specificata nel file di configurazione. BED_MESH_OUTPUT \u00b6 BED_MESH_OUTPUT PGP=[<0:1>] : questo comando restituisce i valori z sondati e i valori mesh correnti al terminale. Se viene specificato PGP=1, le coordinate X, Y generate da bed_mesh, insieme ai relativi indici associati, verranno inviate al terminale. BED_MESH_MAP \u00b6 BED_MESH_MAP : Come per BED_MESH_OUTPUT, questo comando stampa lo stato corrente della mesh sul terminale. Invece di stampare i valori in un formato leggibile, lo stato viene serializzato in formato json. Ci\u00f2 consente ai plug-in di Octoprint di acquisire facilmente i dati e generare mappe di altezza che si approssimano la superficie del piatto. BED_MESH_CLEAR \u00b6 BED_MESH_CLEAR : questo comando cancella la mesh e rimuove tutte le regolazioni z. Si consiglia di inserirlo nella parte finale del gcode. BED_MESH_PROFILE \u00b6 BED_MESH_PROFILE LOAD= SAVE= REMOVE= : questo comando fornisce la gestione del profilo per lo stato della mesh. LOAD ripristiner\u00e0 lo stato della mesh dal profilo corrispondente al nome fornito. SAVE salver\u00e0 lo stato della mesh corrente in un profilo che corrisponde al nome fornito. Rimuovi eliminer\u00e0 il profilo corrispondente al nome fornito dalla memoria persistente. Si noti che dopo aver eseguito le operazioni SAVE o REMOVE \u00e8 necessario eseguire il gcode SAVE_CONFIG per rendere permanenti le modifiche alla memoria persistente. BED_MESH_OFFSET \u00b6 BED_MESH_OFFSET [X=] [Y=] : applica gli offset X e/o Y alla ricerca della mesh. Ci\u00f2 \u00e8 utile per le stampanti con estrusori indipendenti, poich\u00e9 \u00e8 necessario un offset per produrre la corretta regolazione Z dopo un cambio utensile. [bed_screws] \u00b6 I seguenti comandi sono disponibili quando la sezione di configurazione bed_screws \u00e8 abilitata (consultare anche la manual level guide ). BED_SCREWS_ADJUST \u00b6 BED_SCREWS_ADJUST : questo comando richiamer\u00e0 lo strumento di regolazione delle viti del piatto. Comander\u00e0 l'ugello in posizioni diverse (come definito nel file di configurazione) e consentir\u00e0 di effettuare regolazioni alle viti del piatto in modo che il piatto sia a una distanza costante dall'ugello. [bed_tilt] \u00b6 I seguenti comandi sono disponibili quando la sezione di configurazione inclinazione_piatto \u00e8 abilitata. BED_TILT_CALIBRATE \u00b6 BED_TILT_CALIBRATE [METHOD=manual] [HORIZONTAL_MOVE_Z=] [=] : questo comando sonda i punti specificati nella configurazione e quindi consiglia le regolazioni aggiornate dell'inclinazione x e y. Vedere il comando PROBE per i dettagli sui parametri opzionali della sonda. Se viene specificato METHOD=manual, viene attivato lo strumento di rilevamento manuale: vedere il comando MANUAL_PROBE sopra per dettagli sui comandi aggiuntivi disponibili mentre questo strumento \u00e8 attivo. Il valore opzionale HORIZONTAL_MOVE_Z sovrascrive l'opzione horizontal_move_z specificata nel file di configurazione. [bltouch] \u00b6 Il comando seguente \u00e8 disponibile quando \u00e8 abilitata una sezione di configurazione bltouch (vedere anche la Guida BL-Touch ). BLTOUCH_DEBUG \u00b6 BLTOUCH_DEBUG COMMAND= : Invia un comando al BLTouch. Pu\u00f2 essere utile per il debug. I comandi disponibili sono: pin_down , touch_mode , pin_up , self_test , reset . Un BL-Touch V3.0 o V3.1 pu\u00f2 anche supportare i comandi set_5V_output_mode , set_OD_output_mode , output_mode_store . BLTOUCH_STORE \u00b6 BLTOUCH_STORE MODE= : memorizza una modalit\u00e0 di output nella EEPROM di un BLTouch V3.1 Le modalit\u00e0 di output disponibili sono: 5V , OD [configfile] \u00b6 Il modulo configfile viene caricato automaticamente. SAVE_CONFIG \u00b6 SAVE_CONFIG : questo comando sovrascriver\u00e0 il file di configurazione della stampante principale e riavvier\u00e0 il software host. Questo comando viene utilizzato insieme ad altri comandi di calibrazione per memorizzare i risultati dei test di calibrazione. [delayed_gcode] \u00b6 Il comando seguente \u00e8 abilitato se \u00e8 stata abilitata una sezione di configurazione di gcode ritardata (consultare anche la guida ai modelli ). UPDATE_DELAYED_GCODE \u00b6 UPDATE_DELAYED_GCODE [ID=] [DURATION=] : aggiorna la durata del ritardo per il [gcode_ritardato] identificato e avvia il timer per l'esecuzione di gcode. Un valore di 0 annuller\u00e0 l'esecuzione di un gcode ritardato in sospeso. [delta_calibrate] \u00b6 I seguenti comandi sono disponibili quando la sezione di configurazione delta_calibrate \u00e8 abilitata (consultare anche la guida alla calibrazione delta ). DELTA_CALIBRATE \u00b6 DELTA_CALIBRATE [METHOD=manual] [HORIZONTAL_MOVE_Z=] [=] : questo comando sonda sette punti sul piatto e consiglia le posizioni aggiornate dei finecorsa, gli angoli della torre e il raggio. Vedere il comando PROBE per i dettagli sui parametri opzionali della sonda. Se viene specificato METHOD=manual, viene attivato lo strumento di rilevamento manuale: vedere il comando MANUAL_PROBE sopra per dettagli sui comandi aggiuntivi disponibili mentre questo strumento \u00e8 attivo. Il valore opzionale HORIZONTAL_MOVE_Z sovrascrive l'opzione horizontal_move_z specificata nel file di configurazione. DELTA_ANALYZE \u00b6 DELTA_ANALYZE : questo comando viene utilizzato durante la calibrazione avanzata delle stampanti delta. Vedere Delta Calibrate per i dettagli. [display] \u00b6 Il comando seguente \u00e8 disponibile quando \u00e8 abilitata una sezione di configurazione display . SET_DISPLAY_GROUP \u00b6 SET_DISPLAY_GROUP [DISPLAY=] GROUP= : Imposta il gruppo di visualizzazione attivo di un display LCD. Ci\u00f2 consente di definire pi\u00f9 gruppi di dati di visualizzazione nella configurazione, ad es. [display_data ] e passare da uno all'altro usando questo comando gcode esteso. Se DISPLAY non \u00e8 specificato, l'impostazione predefinita \u00e8 \"display\" (il display principale). [display_status] \u00b6 Il modulo display_status viene caricato automaticamente se una sezione di configurazione display \u00e8 abilitata. Fornisce i seguenti comandi G-Code standard: Messaggio visualizzato: M117 Imposta la percentuale di costruzione: M73 P Viene inoltre fornito il seguente comando G-Code esteso: SET_DISPLAY_TEXT MSG= : esegue l'equivalente di M117, impostando il MSG fornito come messaggio visualizzato. Se MSG viene omesso, il display verr\u00e0 cancellato. [dual_carriage] \u00b6 Il comando seguente \u00e8 disponibile quando la sezione di configurazione dual_carriage \u00e8 abilitata. SET_DUAL_CARRIAGE \u00b6 SET_DUAL_CARRIAGE CARRIAGE=[0|1] [MODE=[PRIMARY|COPY|MIRROR]] : This command will change the mode of the specified carriage. If no MODE is provided it defaults to PRIMARY . Setting the mode to PRIMARY deactivates the other carriage and makes the specified carriage execute subsequent G-Code commands as-is. COPY and MIRROR modes are supported only for CARRIAGE=1 . When set to either of these modes, carriage 1 will then track the subsequent moves of the carriage 0 and either copy relative movements of it (in COPY mode) or execute them in the opposite (mirror) direction (in MIRROR mode). SAVE_DUAL_CARRIAGE_STATE \u00b6 SAVE_DUAL_CARRIAGE_STATE [NAME=] : Save the current positions of the dual carriages and their modes. Saving and restoring DUAL_CARRIAGE state can be useful in scripts and macros, as well as in homing routine overrides. If NAME is provided it allows one to name the saved state to the given string. If NAME is not provided it defaults to \"default\". RESTORE_DUAL_CARRIAGE_STATE \u00b6 RESTORE_DUAL_CARRIAGE_STATE [NAME=] [MOVE=[0|1] [MOVE_SPEED=]] : Restore the previously saved positions of the dual carriages and their modes, unless \"MOVE=0\" is specified, in which case only the saved modes will be restored, but not the positions of the carriages. If positions are being restored and \"MOVE_SPEED\" is specified, then the toolhead moves will be performed with the given speed (in mm/s); otherwise the toolhead move will use the rail homing speed. Note that the carriages restore their positions only over their own axis, which may be necessary to correctly restore COPY and MIRROR mode of the dual carraige. [endstop_phase] \u00b6 I seguenti comandi sono disponibili quando una sezione di configurazione endstop_phase \u00e8 abilitata (consultare anche la guida alla fase endstop ). ENDSTOP_PHASE_CALIBRATE \u00b6 ENDSTOP_PHASE_CALIBRATE [STEPPER=] : Se non viene fornito alcun parametro STEPPER, questo comando riporter\u00e0 le statistiche sulle fasi stepper dell'arresto durante le precedenti operazioni di homing. Quando viene fornito un parametro STEPPER, fa in modo che l'impostazione della fase di fine corsa fornita sia scritta nel file di configurazione (insieme al comando SAVE_CONFIG). [exclude_object] \u00b6 I seguenti comandi sono disponibili quando \u00e8 abilitata una exclude_object config section (consultare anche la exclude object guide ): EXCLUDE_OBJECT \u00b6 EXCLUDE_OBJECT [NAME=object_name] [CURRENT=1] [RESET=1] : Senza parametri, questo restituir\u00e0 un elenco di tutti gli oggetti attualmente esclusi. Quando viene fornito il parametro NAME , l'oggetto denominato verr\u00e0 escluso dalla stampa. Quando viene fornito il parametro CURRENT , l'oggetto corrente verr\u00e0 escluso dalla stampa. Quando viene fornito il parametro RESET l'elenco degli oggetti esclusi verr\u00e0 cancellato. Inoltre l'inclusione di NAME ripristiner\u00e0 solo l'oggetto denominato. Questo pu\u00f2 causare errori di stampa, se i livelli sono gi\u00e0 stati saltati. EXCLUDE_OBJECT_DEFINE \u00b6 EXCLUDE_OBJECT_DEFINE [NAME=object_name [CENTER=X,Y] [POLYGON=[[x,y],...]] [RESET=1] [JSON=1] : fornisce un riepilogo di un oggetto nel file. Senza parametri forniti, questo elencher\u00e0 gli oggetti definiti noti a Klipper. Restituisce un elenco di stringhe, a meno che non venga fornito il parametro JSON , quando restituir\u00e0 i dettagli dell'oggetto in formato json. Quando il parametro NAME \u00e8 incluso, definisce un oggetto da escludere. NAME : questo parametro \u00e8 obbligatorio. \u00c8 l'identificatore utilizzato da altri comandi in questo modulo. CENTER : una coordinata X,Y per l'oggetto. POLYGON : Un array di coordinate X,Y che fornisce un contorno per l'oggetto. Quando viene fornito il parametro RESET , tutti gli oggetti definiti verranno cancellati e il modulo [exclude_object] verr\u00e0 ripristinato. EXCLUDE_OBJECT_START \u00b6 EXCLUDE_OBJECT_START NAME=object_name : questo comando prende un parametro NAME e marca l'inizio del gcode per un oggetto sul livello corrente. EXCLUDE_OBJECT_END \u00b6 EXCLUDE_OBJECT_END [NAME=object_name] : Denota la fine del gcode dell'oggetto per il livello. \u00c8 accoppiato con EXCLUDE_OBJECT_START . Un parametro NAME \u00e8 facoltativo e avviser\u00e0 solo quando il nome fornito non corrisponde all'oggetto corrente. [extruder] \u00b6 I seguenti comandi sono disponibili se una sezione di configurazione dell'estrusore \u00e8 abilitata: ACTIVATE_EXTRUDER \u00b6 ACTIVATE_EXTRUDER EXTRUDER= : in una stampante con pi\u00f9 sezioni di configurazione extruder , questo comando cambia l'hotend attivo. SET_PRESSURE_ADVANCE \u00b6 SET_PRESSURE_ADVANCE [EXTRUDER=] [ADVANCE=] [SMOOTH_TIME=] : Imposta i parametri di pressure advance delleo stepper di un estrusore (come definito in un estrusore o [ extruder_stepper] (sezione di configurazione Config_Reference.md#extruder_stepper). Se EXTRUDER non \u00e8 specificato, per impostazione predefinita viene utilizzato lo stepper definito nell'hotend attivo. SET_EXTRUDER_ROTATION_DISTANCE \u00b6 SET_EXTRUDER_ROTATION_DISTANCE EXTRUDER= [DISTANCE=] : Imposta un nuovo valore per la \"distanza di rotazione\" dello stepper dell'estrusore fornito (come definito in un extruder o extruder_stepper sezione di configurazione). Se la distanza di rotazione \u00e8 un numero negativo, il movimento passo-passo verr\u00e0 invertito (rispetto alla direzione passo-passo specificata nel file di configurazione). Le impostazioni modificate non vengono mantenute al ripristino di Klipper. Usare con cautela poich\u00e9 piccole modifiche possono causare una pressione eccessiva tra l'estrusore e l'hotend. Eseguire una corretta calibrazione con il filamento prima dell'uso. Se il valore 'DISTANZA' non viene fornito, questo comando restituir\u00e0 la distanza di rotazione corrente. SYNC_EXTRUDER_MOTION \u00b6 SYNC_EXTRUDER_MOTION EXTRUDER= MOTION_QUEUE= : questo comando attiver\u00e0 lo stepper specificato da EXTRUDER (come definito in un extruder o extruder_stepper config sezione) per sincronizzarsi con il movimento di un estrusore specificato da MOTION_QUEUE (come definito in una sezione di configurazione estrusore ). Se MOTION_QUEUE \u00e8 una stringa vuota, lo stepper verr\u00e0 desincronizzato da tutti i movimenti dell'estrusore. SET_EXTRUDER_STEP_DISTANCE \u00b6 Questo comando \u00e8 deprecato e verr\u00e0 rimosso nel prossimo futuro. SYNC_STEPPER_TO_EXTRUDER \u00b6 Questo comando \u00e8 deprecato e verr\u00e0 rimosso nel prossimo futuro. [fan_generic] \u00b6 Il comando seguente \u00e8 disponibile quando una sezione di configurazione fan_generic \u00e8 abilitata. SET_FAN_SPEED \u00b6 SET_FAN_SPEED FAN=config_name SPEED= Questo comando imposta la velocit\u00e0 di una ventola. \"velocit\u00e0\" deve essere compresa tra 0.0 e 1.0. [filament_switch_sensor] \u00b6 Il comando seguente \u00e8 disponibile quando \u00e8 abilitata una sezione di configurazione filament_switch_sensor o filament_motion_sensor . QUERY_FILAMENT_SENSOR \u00b6 QUERY_FILAMENT_SENSOR SENSOR= : Interroga lo stato del sensore di filamento. I dati visualizzati sul terminale dipenderanno dal tipo di sensore definito nella configurazione. SET_FILAMENT_SENSOR \u00b6 SET_FILAMENT_SENSOR SENSOR=