Deploying to gh-pages from @ Klipper3d/klipper@9323a5dfe2 🚀
This commit is contained in:
KevinOConnor
@@ -1181,6 +1181,13 @@
|
||||
load_cell/dump_force
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load_cell_probedump_taps" class="md-nav__link">
|
||||
load_cell_probe/dump_taps
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -1711,6 +1718,13 @@
|
||||
load_cell/dump_force
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load_cell_probedump_taps" class="md-nav__link">
|
||||
load_cell_probe/dump_taps
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -1871,6 +1885,19 @@ gcode:
|
||||
<p>This endpoint is used to subscribe to force data produced by a load_cell. Using this endpoint may increase Klipper's system load.</p>
|
||||
<p>A request may look like: <code>{"id": 123, "method":"load_cell/dump_force", "params": {"sensor": "load_cell", "response_template": {}}}</code> and might return: <code>{"id": 123,"result":{"header":["time", "force (g)", "counts", "tare_counts"]}}</code> and might later produce asynchronous messages such as: <code>{"params":{"data":[[3292.432935, 40.65, 562534, -234467]]}}</code></p>
|
||||
<p>Il campo "intestazione" nella risposta alla query iniziale viene utilizzato per descrivere i campi trovati nelle risposte "dati" successive.</p>
|
||||
<h3 id="load_cell_probedump_taps">load_cell_probe/dump_taps<a class="headerlink" href="#load_cell_probedump_taps" title="Permanent link">¶</a></h3>
|
||||
<p>This endpoint is used to subscribe to details of probing "tap" events. Using this endpoint may increase Klipper's system load.</p>
|
||||
<p>A request may look like: <code>{"id": 123, "method":"load_cell/dump_force", "params": {"sensor": "load_cell", "response_template": {}}}</code> and might return: <code>{"id": 123,"result":{"header":["probe_tap_event"]}}</code> and might later produce asynchronous messages such as:</p>
|
||||
<div class="highlight"><pre><span></span><code>{"params":{"tap":'{
|
||||
"time": [118032.28039, 118032.2834, ...],
|
||||
"force": [-459.4213119680034, -458.1640702543264, ...],
|
||||
}}}
|
||||
</code></pre></div>
|
||||
|
||||
<p>This data can be used to render:</p>
|
||||
<ul>
|
||||
<li>The time/force graph</li>
|
||||
</ul>
|
||||
<h3 id="pause_resumecancel">pause_resume/cancel<a class="headerlink" href="#pause_resumecancel" title="Permanent link">¶</a></h3>
|
||||
<p>Questo endpoint è simile all'esecuzione del comando G-Code "PRINT_CANCEL". Ad esempio: <code>{"id": 123, "method": "pause_resume/cancel"}</code></p>
|
||||
<p>Come con l'endpoint "gcode/script", questo endpoint viene completato solo dopo il completamento di tutti i comandi G-Code in sospeso.</p>
|
||||
|
||||
@@ -2083,7 +2083,7 @@ scan_overshoot: 8
|
||||
<h3 id="calibrazione">Calibrazione<a class="headerlink" href="#calibrazione" title="Permanent link">¶</a></h3>
|
||||
<p><code>BED_MESH_CALIBRATE PROFILE=<name> METHOD=[manual | automatic | scan | rapid_scan] \ [<probe_parameter>=<value>] [<mesh_parameter>=<value>] [ADAPTIVE=[0|1] \ [ADAPTIVE_MARGIN=<value>]</code> <em>Default Profile: default</em> <em>Default Method: automatic if a probe is detected, otherwise manual</em> <em>Default Adaptive: 0</em> <em>Default Adaptive Margin: 0</em></p>
|
||||
<p>Avvia la procedura di sondaggio per la calibrazione della mesh del piatto.</p>
|
||||
<p>The mesh will be saved into a profile specified by the <code>PROFILE</code> parameter, or <code>default</code> if unspecified. The <code>METHOD</code> parameter takes one of the following values:</p>
|
||||
<p>The mesh will be immediately ready to use when the command completes and saved into a profile specified by the <code>PROFILE</code> parameter, or <code>default</code> if unspecified. The <code>METHOD</code> parameter takes one of the following values:</p>
|
||||
<ul>
|
||||
<li><code>METHOD=manual</code>: enables manual probing using the nozzle and the paper test</li>
|
||||
<li><code>METHOD=automatic</code>: Automatic (standard) probing. This is the default.</li>
|
||||
@@ -2123,6 +2123,7 @@ scan_overshoot: 8
|
||||
<p>Qualsiasi altro profilo salvato può essere rimosso allo stesso modo, sostituendo <em>default</em> con il nome del profilo che desideri rimuovere.</p>
|
||||
<h4 id="caricamento-del-profilo-predefinito">Caricamento del profilo predefinito<a class="headerlink" href="#caricamento-del-profilo-predefinito" title="Permanent link">¶</a></h4>
|
||||
<p>Le versioni precedenti di <code>bed_mesh</code> caricavano sempre il profilo denominato <em>default</em> all'avvio se era presente. Questo comportamento è stato rimosso per consentire all'utente di determinare quando viene caricato un profilo. Se un utente desidera caricare il profilo <code>predefinito</code>, si consiglia di aggiungere <code>BED_MESH_PROFILE LOAD=default</code> alla macro <code>START_PRINT</code> o alla configurazione "Start G-Code" del proprio slicer, a seconda di quale sia applicabile.</p>
|
||||
<p>Note that this is not required if a new mesh is generated with <code>BED_MESH_CALIBRATE</code> in the <code>START_PRINT</code> macro or the slicer's "Start G-Code" and may produce unexpected results, especially with adaptive meshing.</p>
|
||||
<p>In alternativa, il vecchio comportamento di caricamento di un profilo all'avvio può essere ripristinato con un <code>[delayed_gcode]</code>:</p>
|
||||
<div class="highlight"><pre><span></span><code><span class="k">[delayed_gcode bed_mesh_init]</span>
|
||||
<span class="na">initial_duration</span><span class="o">:</span><span class="w"> </span><span class="s">.01</span>
|
||||
|
||||
@@ -1174,6 +1174,13 @@
|
||||
Benchmark step rate STM32G0B1
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#stm32g4-step-rate-benchmark" class="md-nav__link">
|
||||
STM32G4 step rate benchmark
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -1613,6 +1620,13 @@
|
||||
Benchmark step rate STM32G0B1
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#stm32g4-step-rate-benchmark" class="md-nav__link">
|
||||
STM32G4 step rate benchmark
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -2040,6 +2054,34 @@ finalize_config crc=0
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h3 id="stm32g4-step-rate-benchmark">STM32G4 step rate benchmark<a class="headerlink" href="#stm32g4-step-rate-benchmark" title="Permanent link">¶</a></h3>
|
||||
<p>The following configuration sequence is used on the STM32G431:</p>
|
||||
<div class="highlight"><pre><span></span><code>allocate_oids count=3
|
||||
config_stepper oid=0 step_pin=PA0 dir_pin=PB5 invert_step=-1 step_pulse_ticks=17
|
||||
config_stepper oid=1 step_pin=PB2 dir_pin=PB6 invert_step=-1 step_pulse_ticks=17
|
||||
config_stepper oid=2 step_pin=PB3 dir_pin=PB7 invert_step=-1 step_pulse_ticks=17
|
||||
finalize_config crc=0
|
||||
</code></pre></div>
|
||||
|
||||
<p>The test was last run on commit <code>cfa48fe3</code> with gcc version <code>arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0</code>.</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>stm32g431</th>
|
||||
<th>ticks</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>1 stepper</td>
|
||||
<td>47</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>3 stepper</td>
|
||||
<td>208</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h3 id="benchmark-step-rate-lpc176x">Benchmark step rate LPC176x<a class="headerlink" href="#benchmark-step-rate-lpc176x" title="Permanent link">¶</a></h3>
|
||||
<p>La seguente sequenza di configurazione viene utilizzata sull'LPC176x:</p>
|
||||
<div class="highlight"><pre><span></span><code>allocate_oids count=3
|
||||
@@ -2252,7 +2294,7 @@ finalize_config crc=0
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>(*) Note that the reported rp2040 ticks are relative to a 12Mhz scheduling timer and do not correspond to its 200Mhz internal ARM processing rate. It is expected that 5 scheduling ticks corresponds to ~42 ARM core cycles and 14 scheduling ticks corresponds to ~225 ARM core cycles.</p>
|
||||
<p>(*) Note that the reported rp2040 ticks are relative to a 12Mhz scheduling timer and do not correspond to its 200Mhz internal ARM processing rate. It is expected that 3 scheduling ticks corresponds to ~42 ARM core cycles and 14 scheduling ticks corresponds to ~225 ARM core cycles.</p>
|
||||
<h3 id="benchmark-step-rate-mcu-linux">Benchmark step rate MCU Linux<a class="headerlink" href="#benchmark-step-rate-mcu-linux" title="Permanent link">¶</a></h3>
|
||||
<p>La seguente sequenza di configurazione viene utilizzata su un Raspberry Pi:</p>
|
||||
<div class="highlight"><pre><span></span><code>allocate_oids count=3
|
||||
@@ -2289,7 +2331,8 @@ get_uptime
|
||||
</code></pre></div>
|
||||
|
||||
<p>Al termine del test, determinare la differenza tra gli orologi riportati nei due messaggi di risposta "uptime". Il numero totale di comandi al secondo è quindi <code>100000 * mcu_frequency / clock_diff</code>.</p>
|
||||
<p>Nota che questo test potrebbe saturare la capacità USB/CPU di un Raspberry Pi. Se è in esecuzione su un computer host Raspberry Pi, Beaglebone o simile, aumenta il ritardo (ad esempio, <code>DELAY {clock + 20*freq} get_uptime</code>). 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à.</p>
|
||||
<p>The USB tests may exceed the CPU capacity of a Raspberry Pi. If running on a Raspberry Pi, Beaglebone, or similar host computer then increase the delay (eg, <code>DELAY {clock + 20*freq} get_uptime</code>). Where applicable, the benchmarks below are with console.py running on a desktop class machine with the device connected via a super-speed hub.</p>
|
||||
<p>The CAN bus tests may saturate the USB host controller of a Raspberry Pi (when testing via a standard gs_usb USB to CAN bus adapter). Where applicable, the CAN bus benchmarks below are with console.py running on a desktop class machine with a USB to CAN bus adapter connected via a super-speed USB hub.</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
@@ -2301,12 +2344,6 @@ get_uptime
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>stm32f042 (CAN)</td>
|
||||
<td>18K</td>
|
||||
<td>c105adc8</td>
|
||||
<td>arm-none-eabi-gcc (GNU Tools 7-2018-q3-update) 7.3.1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>atmega2560 (serial)</td>
|
||||
<td>23K</td>
|
||||
<td>b161a69e</td>
|
||||
@@ -2319,6 +2356,12 @@ get_uptime
|
||||
<td>arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>rp2350 (CAN)</td>
|
||||
<td>59K</td>
|
||||
<td>17b8ce4c</td>
|
||||
<td>arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>at90usb1286 (USB)</td>
|
||||
<td>75K</td>
|
||||
<td>01d2183f</td>
|
||||
|
||||
@@ -1543,12 +1543,7 @@ iface can0 can static
|
||||
|
||||
<ul>
|
||||
<li>The "bridge mcu" is not actually on the CAN bus. Messages to and from the bridge mcu will not be seen by other adapters that may be on the CAN bus.</li>
|
||||
<li>
|
||||
<p>The available bandwidth to both the "bridge mcu" itself and all devices on the CAN bus is effectively limited by the CAN bus frequency. As a result, it is recommended to use a CAN bus frequency of 1000000 when using "USB to CAN bus bridge mode".</p>
|
||||
<p>Even at a CAN bus frequency of 1000000, there may not be sufficient bandwidth to run a <code>SHAPER_CALIBRATE</code> test if both the XY steppers and the accelerometer all communicate via a single "USB to CAN bus" interface.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>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".</li>
|
||||
<li>It is only valid to use USB to CAN bridge mode if there is a functioning CAN bus with at least one other node available (in addition to the bridge node itself). Use a standard USB configuration if the goal is to communicate only with the single USB device. Using USB to CAN bridge mode without a fully functioning CAN bus (including terminating resistors and an additional node) may result in sporadic errors even when communicating with the bridge node.</li>
|
||||
<li>A USB to CAN bridge board will not appear as a USB serial device, it will not show up when running <code>ls /dev/serial/by-id</code>, and it can not be configured in Klipper's printer.cfg file with a <code>serial:</code> parameter. The bridge board appears as a "USB CAN adapter" and it is configured in the printer.cfg as a <a href="#configuring-klipper">CAN node</a>.</li>
|
||||
</ul>
|
||||
|
||||
@@ -1577,6 +1577,7 @@
|
||||
</ul>
|
||||
</li>
|
||||
<li>Se c'è un errore nella configurazione dell'utente, assicurati di sollevarlo durante le fasi <code>load_config()</code> o "connect event". Utilizzare <code>raise config.error("my error")</code> o <code>raise printer.config_error ("my error")</code> per segnalare l'errore.</li>
|
||||
<li>Do not store a reference to the <code>config</code> object in a class member variable (nor in any similar location that may persist past initial module loading). The <code>config</code> object is a reference to a "config loading phase" class and it is not valid to invoke its methods after the "config loading phase" has completed.</li>
|
||||
<li>Utilizzare il modulo "pin" per configurare un pin su un microcontrollore. Questo è in genere fatto con qualcosa di simile a <code>printer.lookup_object("pins").setup_pin("pwm", config.get("my_pin"))</code>. L'oggetto restituito può quindi essere comandato in fase di esecuzione.</li>
|
||||
<li>Se l'oggetto stampante definisce un metodo <code>get_status()</code>, il modulo può esportare <a href="Status_Reference.html">informazioni sullo stato</a> tramite <a href="Command_Templates.html">macro</a> e tramite <a href="API_Server.html">Server API</a>. Il metodo <code>get_status()</code> deve restituire un dizionario Python con chiavi che sono stringhe e valori che sono interi, float, stringhe, elenchi, dizionari, True, False o None. È 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, è necessario restituire un nuovo oggetto da <code>get_status()</code>, altrimenti il server API non rileverà tali modifiche.</li>
|
||||
<li>Se il modulo necessita dell'accesso alla temporizzazione del sistema o a descrittori di file esterni, utilizzare <code>printer.get_reactor()</code> 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.</li>
|
||||
|
||||
@@ -657,6 +657,13 @@
|
||||
Cinematica dell'argano a fune
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#generic-cartesian-kinematics" class="md-nav__link">
|
||||
Generic Cartesian Kinematics
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -1714,6 +1721,13 @@
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load_cell_probe" class="md-nav__link">
|
||||
[load_cell_probe]
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
@@ -2793,6 +2807,13 @@
|
||||
Cinematica dell'argano a fune
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#generic-cartesian-kinematics" class="md-nav__link">
|
||||
Generic Cartesian Kinematics
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -3850,6 +3871,13 @@
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load_cell_probe" class="md-nav__link">
|
||||
[load_cell_probe]
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
@@ -4029,8 +4057,9 @@ serial:
|
||||
<div class="highlight"><pre><span></span><code>[printer]
|
||||
kinematics:
|
||||
# The type of printer in use. This option may be one of: cartesian,
|
||||
# corexy, corexz, hybrid_corexy, hybrid_corexz, rotary_delta, delta,
|
||||
# deltesian, polar, winch, or none. This parameter must be specified.
|
||||
# corexy, corexz, hybrid_corexy, hybrid_corexz, generic_cartesian,
|
||||
# rotary_delta, delta, deltesian, polar, winch, or none.
|
||||
# This parameter must be specified.
|
||||
max_velocity:
|
||||
# Maximum velocity (in mm/s) of the toolhead (relative to the
|
||||
# print). This parameter must be specified.
|
||||
@@ -4576,6 +4605,123 @@ anchor_z:
|
||||
# These parameters must be provided.
|
||||
</code></pre></div>
|
||||
|
||||
<h3 id="generic-cartesian-kinematics">Generic Cartesian Kinematics<a class="headerlink" href="#generic-cartesian-kinematics" title="Permanent link">¶</a></h3>
|
||||
<p>See <a href="https://github.com/Klipper3d/klipper/blob/master/config/example-generic-caretesian.cfg">example-generic-cartesian.cfg</a> for an example generic Cartesian kinematics config file.</p>
|
||||
<p>This printer kinematic class allows a user to define in a pretty flexible manner an arbitrary Cartesian-style kinematics. In principle, the regular cartesian, corexy, hybrid_corexy can be defined this way too. However, more importantly, various otherwise unsupported kinematics such as inverted hybrid_corexy or corexyuv can be defined using this kinematic.</p>
|
||||
<p>Notably, the definition of a generic Cartesian kinematic deviates significantly from the other kinematic types. It follows the following convention: a user defines a set of carriages with certain range of motion that can move independently from each other (they should move over the Cartesian axes X, Y, and Z, hence the name of the kinematic) and corresponding endstops that allow the firmware to determine the position of carriages during homing, as well as a set of steppers that move those carriages. The <code>[printer]</code> section must specify the kinematic and other printer-level settings same as the regular Cartesian kinematic:</p>
|
||||
<div class="highlight"><pre><span></span><code>[printer]
|
||||
kinematics: generic_cartesian
|
||||
max_velocity:
|
||||
max_accel:
|
||||
#minimum_cruise_ratio:
|
||||
#square_corner_velocity:
|
||||
#max_accel_to_decel:
|
||||
#max_z_velocity:
|
||||
#max_z_accel:
|
||||
</code></pre></div>
|
||||
|
||||
<p>Then a user must define the following three carriages: <code>[carriage x]</code>, <code>[carriage y]</code>, and <code>[carriage z]</code>, e.g.</p>
|
||||
<div class="highlight"><pre><span></span><code>[carriage x]
|
||||
endstop_pin:
|
||||
# Endstop switch detection pin. If this endstop pin is on a
|
||||
# different mcu than the stepper motor(s) moving this carriage,
|
||||
# then it enables "multi-mcu homing". This parameter must be provided.
|
||||
#position_min: 0
|
||||
# Minimum valid distance (in mm) the user may command the carriage to
|
||||
# move to. The default is 0mm.
|
||||
position_endstop:
|
||||
# Location of the endstop (in mm). This parameter must be provided.
|
||||
position_max:
|
||||
# Maximum valid distance (in mm) the user may command the stepper to
|
||||
# move to. This parameter must be provided.
|
||||
#homing_speed: 5.0
|
||||
# Maximum velocity (in mm/s) of the carriage when homing. The default
|
||||
# is 5mm/s.
|
||||
#homing_retract_dist: 5.0
|
||||
# Distance to backoff (in mm) before homing a second time during
|
||||
# homing. Set this to zero to disable the second home. The default
|
||||
# is 5mm.
|
||||
#homing_retract_speed:
|
||||
# Speed to use on the retract move after homing in case this should
|
||||
# be different from the homing speed, which is the default for this
|
||||
# parameter
|
||||
#second_homing_speed:
|
||||
# Velocity (in mm/s) of the carriage when performing the second home.
|
||||
# The default is homing_speed/2.
|
||||
#homing_positive_dir:
|
||||
# If true, homing will cause the carriage to move in a positive
|
||||
# direction (away from zero); if false, home towards zero. It is
|
||||
# better to use the default than to specify this parameter. The
|
||||
# default is true if position_endstop is near position_max and false
|
||||
# if near position_min.
|
||||
</code></pre></div>
|
||||
|
||||
<p>Afterwards, a user specifies the stepper motors that move these carriages, for instance</p>
|
||||
<div class="highlight"><pre><span></span><code>[stepper my_stepper]
|
||||
carriages:
|
||||
# A string describing the carriages the stepper moves. All defined
|
||||
# carriages can be specified here, as well as their linear combinations,
|
||||
# e.g. x, x+y, y-0.5*z, x-z, etc. This parameter must be provided.
|
||||
step_pin:
|
||||
dir_pin:
|
||||
enable_pin:
|
||||
rotation_distance:
|
||||
microsteps:
|
||||
#full_steps_per_rotation: 200
|
||||
#gear_ratio:
|
||||
#step_pulse_duration:
|
||||
</code></pre></div>
|
||||
|
||||
<p>See <a href="#stepper">stepper</a> section for more information on the regular stepper parameters. The <code>carriages</code> parameter defines how the stepper affects the motion of the carriages. For example, <code>x+y</code> indicates that the motion of the stepper in the positive direction by the distance <code>d</code> moves the carriages <code>x</code> and <code>y</code> by the same distance <code>d</code> in the positive direction, while <code>x-0.5*y</code> means the motion of the stepper in the positive direction by the distance <code>d</code> moves the carriage <code>x</code> by the distance <code>d</code> in the positive direction, but the carriage <code>y</code> will travel distance <code>d/2</code> in the negative direction.</p>
|
||||
<p>More than a single stepper motor can be defined to drive the same axis or belt. For example, on a CoreXY AWD setups two motors driving the same belt can be defined as</p>
|
||||
<div class="highlight"><pre><span></span><code>[carriage x]
|
||||
endstop_pin: ...
|
||||
...
|
||||
|
||||
[carriage y]
|
||||
endstop_pin: ...
|
||||
...
|
||||
|
||||
[stepper a0]
|
||||
carriages: x-y
|
||||
step_pin: ...
|
||||
dir_pin: ...
|
||||
enable_pin: ...
|
||||
rotation_distance: ...
|
||||
...
|
||||
|
||||
[stepper a1]
|
||||
carriages: x-y
|
||||
step_pin: ...
|
||||
dir_pin: ...
|
||||
enable_pin: ...
|
||||
rotation_distance: ...
|
||||
...
|
||||
</code></pre></div>
|
||||
|
||||
<p>with <code>a0</code> and <code>a1</code> steppers having their own control pins, but sharing the same <code>carriages</code> and corresponding endstops.</p>
|
||||
<p>There are situations when a user wants to have more than one endstop per axis. Examples of such configurations include Y axis driven by two independent stepper motors with belts attached to both ends of the X beam, with effectively two carriages on Y axis each having an independent endstop, and multi-stepper Z axis with each stepper having its own endstop (not to be confused with the configurations with multiple Z motors but only a single endstop). These configurations can be declared by specifying additional carriage(s) with their endstops:</p>
|
||||
<div class="highlight"><pre><span></span><code>[extra_carriage my_carriage]
|
||||
primary_carriage:
|
||||
# The name of the primary carriage this carriage corresponds to.
|
||||
# It also effectively defines the axis the carriage moves over.
|
||||
# This parameter must be provided.
|
||||
endstop_pin:
|
||||
# Endstop switch detection pin. This parameter must be provided.
|
||||
</code></pre></div>
|
||||
|
||||
<p>and the corresponding stepper motors, for example:</p>
|
||||
<div class="highlight"><pre><span></span><code>[extra_carriage y1]
|
||||
primary_carriage: y
|
||||
endstop_pin: ...
|
||||
|
||||
[stepper sy1]
|
||||
carriages: y1
|
||||
...
|
||||
</code></pre></div>
|
||||
|
||||
<p>Notably, an <code>[extra_carriage]</code> does not define parameters such as <code>position_min</code>, <code>position_max</code>, and <code>position_endstop</code>, but instead inherits them from the specified <code>primary_carriage</code>, thus sharing the same range of motion with the primary carriage.</p>
|
||||
<p>For the references on how to configure IDEX setups, see the <a href="#dual-carriage">dual carriage</a> section.</p>
|
||||
<h3 id="nessuna-cinematica">Nessuna cinematica<a class="headerlink" href="#nessuna-cinematica" title="Permanent link">¶</a></h3>
|
||||
<p>È possibile definire una cinematica speciale "none" per disabilitare il supporto cinematico in Klipper. Questo può essere utile per controllare dispositivi che non sono le tipiche stampanti 3D o per scopi di debug.</p>
|
||||
<div class="highlight"><pre><span></span><code>[printer]
|
||||
@@ -5809,9 +5955,9 @@ calibrate_x: ...
|
||||
</code></pre></div>
|
||||
|
||||
<h3 id="dual_carriage">[dual_carriage]<a class="headerlink" href="#dual_carriage" title="Permanent link">¶</a></h3>
|
||||
<p>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 <code>[dual_carriage]</code> config section. However, the <code>[dual_carriage]</code> carriage will be homed first if both carriages home in a positive direction and the [dual_carriage] carriage has a <code>position_endstop</code> greater than the primary carriage, or if both carriages home in a negative direction and the <code>[dual_carriage]</code> carriage has a <code>position_endstop</code> less than the primary carriage.</p>
|
||||
<p>Support for cartesian, generic_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 <code>[dual_carriage]</code> config section. However, the <code>[dual_carriage]</code> carriage will be homed first if both carriages home in a positive direction and the [dual_carriage] carriage has a <code>position_endstop</code> greater than the primary carriage, or if both carriages home in a negative direction and the <code>[dual_carriage]</code> carriage has a <code>position_endstop</code> less than the primary carriage.</p>
|
||||
<p>Inoltre, è possibile utilizzare i comandi "SET_DUAL_CARRIAGE CARRIAGE=1 MODE=COPY" o "SET_DUAL_CARRIAGE CARRIAGE=1 MODE=MIRROR" per attivare la modalità di copia o di mirroring del doppio carrello, nel qual caso seguirà di conseguenza il movimento del carrello 0 . Questi comandi possono essere utilizzati per stampare due parti contemporaneamente: due parti identiche (in modalità COPIA) o parti specchiate (in modalità SPECCHIO). Tieni presente che le modalità COPY e MIRROR richiedono anche la configurazione appropriata dell'estrusore sul doppio carrello, che in genere può essere ottenuta con "SYNC_EXTRUDER_MOTION MOTION_QUEUE=extruder EXTRUDER=<dual_carriage_extruder>" o un comando simile.</p>
|
||||
<p>Vedere <a href="https://github.com/Klipper3d/klipper/blob/master/config/sample-idex.cfg">sample-idex.cfg</a> per un esempio di configurazione.</p>
|
||||
<p>See <a href="https://github.com/Klipper3d/klipper/blob/master/config/sample-idex.cfg">sample-idex.cfg</a> for an example configuration with a regular Cartesian kinematic.</p>
|
||||
<div class="highlight"><pre><span></span><code>[dual_carriage]
|
||||
axis:
|
||||
# The axis this extra carriage is on (either x or y). This parameter
|
||||
@@ -5823,7 +5969,7 @@ axis:
|
||||
# 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
|
||||
# identical for the primary and dual carriages), the carriages proximity
|
||||
# checks will be disabled.
|
||||
#step_pin:
|
||||
#dir_pin:
|
||||
@@ -5837,6 +5983,65 @@ axis:
|
||||
# See the "stepper" section for the definition of the above parameters.
|
||||
</code></pre></div>
|
||||
|
||||
<p>For an example of dual carriage configuration with <code>generic_cartesian</code> kinematic, see the following configuration <a href="https://github.com/Klipper3d/klipper/blob/master/config/example-generic-caretesian.cfg">sample</a>. Please note that in this case the <code>[dual_carriage]</code> configuration deviates from the configuration described above:</p>
|
||||
<div class="highlight"><pre><span></span><code>[dual_carriage my_dc_carriage]
|
||||
primary_carriage:
|
||||
# Defines the matching primary carriage of this dual carriage and
|
||||
# the corresponding IDEX axis. Valid choices are x, y, z.
|
||||
# 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 carriages), the carriages proximity
|
||||
# checks will be disabled.
|
||||
endstop_pin:
|
||||
#position_min:
|
||||
position_endstop:
|
||||
position_max:
|
||||
#homing_speed:
|
||||
#homing_retract_dist:
|
||||
#homing_retract_speed:
|
||||
#second_homing_speed:
|
||||
#homing_positive_dir:
|
||||
...
|
||||
</code></pre></div>
|
||||
|
||||
<p>Refer to <a href="#generic-cartesian">generic cartesian</a> section for more information on the regular <code>carriage</code> parameters.</p>
|
||||
<p>Then a user must define one or more stepper motors moving the dual carriage (and other carriages as appropriate), for instance</p>
|
||||
<div class="highlight"><pre><span></span><code>[carriage x]
|
||||
...
|
||||
|
||||
[carriage y]
|
||||
...
|
||||
|
||||
[dual_carriage u]
|
||||
primary_carriage: x
|
||||
...
|
||||
|
||||
[stepper dc_stepper]
|
||||
carriages: u-y
|
||||
...
|
||||
</code></pre></div>
|
||||
|
||||
<p><code>[dual_carriage]</code> requires special configuration for the input shaper. In general, it is necessary to run input shaper calibration twice - for the <code>dual_carriage</code> and its <code>primary_carriage</code> for the axis they share. Then the input shaper can be configured as follows, assuming the example above:</p>
|
||||
<div class="highlight"><pre><span></span><code>[input_shaper]
|
||||
# Intentionally empty
|
||||
|
||||
[delayed_gcode init_shaper]
|
||||
initial_duration: 0.1
|
||||
gcode:
|
||||
SET_DUAL_CARRIAGE CARRIAGE=u
|
||||
SET_INPUT_SHAPER SHAPER_TYPE_X=<dual_carriage_x_shaper> SHAPER_FREQ_X=<dual_carriage_x_freq> SHAPER_TYPE_Y=<y_shaper> SHAPER_FREQ_Y=<y_freq>
|
||||
SET_DUAL_CARRIAGE CARRIAGE=x
|
||||
SET_INPUT_SHAPER SHAPER_TYPE_X=<primary_carriage_x_shaper> SHAPER_FREQ_X=<primary_carriage_x_freq> SHAPER_TYPE_Y=<y_shaper> SHAPER_FREQ_Y=<y_freq>
|
||||
</code></pre></div>
|
||||
|
||||
<p>Note that <code>SHAPER_TYPE_Y</code> and <code>SHAPER_FREQ_Y</code> must be the same in both commands in this case, since the same motors drive Y axis when either of the <code>x</code> and <code>u</code> carriages are active.</p>
|
||||
<p>It is worth noting that <code>generic_cartesian</code> kinematic can support two dual carriages for X and Y axes. For reference, see for instance a <a href="https://github.com/Klipper3d/klipper/blob/master/config/sample-corexyuv.cfg">sample</a> of CoreXYUV configuration.</p>
|
||||
<h3 id="extruder_stepper">[extruder_stepper]<a class="headerlink" href="#extruder_stepper" title="Permanent link">¶</a></h3>
|
||||
<p>Supporto per stepper aggiuntivi sincronizzati al movimento di un estrusore (si può definire un numero qualsiasi di sezioni con un prefisso "extruder_stepper").</p>
|
||||
<p>Per ulteriori informazioni, vedere <a href="G-Codes.html#extruder">riferimento comando</a>.</p>
|
||||
@@ -5862,20 +6067,27 @@ extruder:
|
||||
#enable_pin:
|
||||
#microsteps:
|
||||
#rotation_distance:
|
||||
# Vedere la sezione "stepper" per una descrizione di questi parametri.
|
||||
# See the "stepper" section for a description of these parameters.
|
||||
#velocity:
|
||||
# Impostare la velocità predefinita (in mm/s) per lo stepper. Questo
|
||||
# valore verrà utilizzato se un comando MANUAL_STEPPER non specifica
|
||||
# un parametro SPEED. Il valore predefinito è 5 mm/s.
|
||||
# Set the default velocity (in mm/s) for the stepper. This value
|
||||
# will be used if a MANUAL_STEPPER command does not specify a SPEED
|
||||
# parameter. The default is 5mm/s.
|
||||
#accel:
|
||||
# Imposta l'accelerazione predefinita (in mm/s^2) per lo stepper.
|
||||
# Un'accelerazione pari a zero non risulterà in nessuna accelerazione.
|
||||
# Questo valore verrà utilizzato se un comando MANUAL_STEPPER non
|
||||
# specifica un parametro ACCEL. Il valore predefinito è zero.
|
||||
# Set the default acceleration (in mm/s^2) for the stepper. An
|
||||
# acceleration of zero will result in no acceleration. This value
|
||||
# will be used if a MANUAL_STEPPER command does not specify an ACCEL
|
||||
# parameter. The default is zero.
|
||||
#endstop_pin:
|
||||
# Pin di rilevamento interruttore di fine corsa. Se specificato, è possibile
|
||||
# eseguire "movimenti di riferimento" aggiungendo un parametro
|
||||
# STOP_ON_ENDSTOP ai comandi di movimento MANUAL_STEPPER.
|
||||
# Endstop switch detection pin. If specified, then one may perform
|
||||
# "homing moves" by adding a STOP_ON_ENDSTOP parameter to
|
||||
# MANUAL_STEPPER movement commands.
|
||||
#position_min:
|
||||
#position_max:
|
||||
# The minimum and maximum position the stepper can be commanded to
|
||||
# move to. If specified then one may not command the stepper to move
|
||||
# past the given position. Note that these limits do not prevent
|
||||
# setting an arbitrary position with the `MANUAL_STEPPER
|
||||
# SET_POSITION=x` command. The default is to not enforce a limit.
|
||||
</code></pre></div>
|
||||
|
||||
<h2 id="riscaldatori-e-sensori-personalizzati">Riscaldatori e sensori personalizzati<a class="headerlink" href="#riscaldatori-e-sensori-personalizzati" title="Permanent link">¶</a></h2>
|
||||
@@ -8070,6 +8282,63 @@ data_ready_pin:
|
||||
# and 'analog_supply'. Default is 'internal'.
|
||||
</code></pre></div>
|
||||
|
||||
<h3 id="load_cell_probe">[load_cell_probe]<a class="headerlink" href="#load_cell_probe" title="Permanent link">¶</a></h3>
|
||||
<p>Load Cell Probe. This combines the functionality of a [probe] and a [load_cell].</p>
|
||||
<div class="highlight"><pre><span></span><code>[load_cell_probe]
|
||||
sensor_type:
|
||||
# This must be one of the supported bulk ADC sensor types and support
|
||||
# load cell endstops on the mcu.
|
||||
#counts_per_gram:
|
||||
#reference_tare_counts:
|
||||
#sensor_orientation:
|
||||
# These parameters must be configured before the probe will operate.
|
||||
# See the [load_cell] section for further details.
|
||||
#force_safety_limit: 2000
|
||||
# The safe limit for probing force relative to the reference_tare_counts on
|
||||
# the load_cell. The default is +/-2Kg.
|
||||
#trigger_force: 75.0
|
||||
# The force that the probe will trigger at. 75g is the default.
|
||||
#drift_filter_cutoff_frequency: 0.8
|
||||
# Enable optional continuous taring while homing & probing to reject drift.
|
||||
# The value is a frequency, in Hz, below which drift will be ignored. This
|
||||
# option requires the SciPy library. Default: None
|
||||
#drift_filter_delay: 2
|
||||
# The delay, or 'order', of the drift filter. This controls the number of
|
||||
# samples required to make a trigger detection. Can be 1 or 2, the default
|
||||
# is 2.
|
||||
#buzz_filter_cutoff_frequency: 100.0
|
||||
# The value is a frequency, in Hz, above which high frequency noise in the
|
||||
# load cell will be igfiltered outnored. This option requires the SciPy
|
||||
# library. Default: None
|
||||
#buzz_filter_delay: 2
|
||||
# The delay, or 'order', of the buzz filter. This controle the number of
|
||||
# samples required to make a trigger detection. Can be 1 or 2, the default
|
||||
# is 2.
|
||||
#notch_filter_frequencies: 50, 60
|
||||
# 1 or 2 frequencies, in Hz, to filter out of the load cell data. This is
|
||||
# intended to reject power line noise. This option requires the SciPy
|
||||
# library. Default: None
|
||||
#notch_filter_quality: 2.0
|
||||
# Controls how narrow the range of frequencies are that the notch filter
|
||||
# removes. Larger numbers produce a narrower filter. Minimum value is 0.5 and
|
||||
# maximum is 3.0. Default: 2.0
|
||||
#tare_time:
|
||||
# The rime in seconds used for taring the load_cell before each probe. The
|
||||
# default value is: 4 / 60 = 0.066. This collects samples from 4 cycles of
|
||||
# 60Hz mains power to cancel power line noise.
|
||||
#z_offset:
|
||||
#speed:
|
||||
#samples:
|
||||
#sample_retract_dist:
|
||||
#lift_speed:
|
||||
#samples_result:
|
||||
#samples_tolerance:
|
||||
#samples_tolerance_retries:
|
||||
#activate_gcode:
|
||||
#deactivate_gcode:
|
||||
# See the "[probe]" section for a description of the above parameters.
|
||||
</code></pre></div>
|
||||
|
||||
<h2 id="supporto-hardware-per-specifica-scheda">Supporto hardware per specifica scheda<a class="headerlink" href="#supporto-hardware-per-specifica-scheda" title="Permanent link">¶</a></h2>
|
||||
<h3 id="sx1509">[sx1509]<a class="headerlink" href="#sx1509" title="Permanent link">¶</a></h3>
|
||||
<p>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ò 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.</p>
|
||||
|
||||
@@ -1541,6 +1541,11 @@
|
||||
<td>2507K</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>STM32G431</td>
|
||||
<td>3617K</td>
|
||||
<td>2452K</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>STM32F407</td>
|
||||
<td>3652K</td>
|
||||
<td>2459K</td>
|
||||
|
||||
117
it/G-Codes.html
117
it/G-Codes.html
@@ -1484,6 +1484,26 @@
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#generic_cartesian" class="md-nav__link">
|
||||
[generic_cartesian]
|
||||
</a>
|
||||
|
||||
<nav class="md-nav" aria-label="[generic_cartesian]">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#set_stepper_carriages" class="md-nav__link">
|
||||
SET_STEPPER_CARRIAGES
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -1682,6 +1702,27 @@
|
||||
LOAD_CELL_READ load_cell="name"
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load_cell_probe" class="md-nav__link">
|
||||
[load_cell_probe]
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load_cell_test_tap" class="md-nav__link">
|
||||
LOAD_CELL_TEST_TAP
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load-cell-command-extensions" class="md-nav__link">
|
||||
Load Cell Command Extensions
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -3780,6 +3821,26 @@
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#generic_cartesian" class="md-nav__link">
|
||||
[generic_cartesian]
|
||||
</a>
|
||||
|
||||
<nav class="md-nav" aria-label="[generic_cartesian]">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#set_stepper_carriages" class="md-nav__link">
|
||||
SET_STEPPER_CARRIAGES
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -3978,6 +4039,27 @@
|
||||
LOAD_CELL_READ load_cell="name"
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load_cell_probe" class="md-nav__link">
|
||||
[load_cell_probe]
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load_cell_test_tap" class="md-nav__link">
|
||||
LOAD_CELL_TEST_TAP
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load-cell-command-extensions" class="md-nav__link">
|
||||
Load Cell Command Extensions
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -4909,7 +4991,7 @@ section</a> is enabled.</p>
|
||||
<h3 id="bed_mesh">[bed_mesh]<a class="headerlink" href="#bed_mesh" title="Permanent link">¶</a></h3>
|
||||
<p>I seguenti comandi sono disponibili quando la <a href="Config_Reference.html#bed_mesh">sezione di configurazione bed_mesh</a> è abilitata (consultare anche la <a href="Bed_Mesh.html">guida della mesh del letto</a>).</p>
|
||||
<h4 id="bed_mesh_calibrate">BED_MESH_CALIBRATE<a class="headerlink" href="#bed_mesh_calibrate" title="Permanent link">¶</a></h4>
|
||||
<p><code>BED_MESH_CALIBRATE [PROFILE=<name>] [METHOD=manual] [HORIZONTAL_MOVE_Z=<value>] [<probe_parameter>=<value>] [<mesh_parameter>=<value>] [ADAPTIVE=1] [ADAPTIVE_MARGIN=<value>]</code>: This command probes the bed using generated points specified by the parameters in the config. After probing, a mesh is generated and z-movement is adjusted according to the mesh. The mesh will be saved into a profile specified by the <code>PROFILE</code> parameter, or <code>default</code> if unspecified. See the PROBE command for details on the optional probe parameters. If METHOD=manual is specified then the manual probing tool is activated - see the MANUAL_PROBE command above for details on the additional commands available while this tool is active. The optional <code>HORIZONTAL_MOVE_Z</code> value overrides the <code>horizontal_move_z</code> option specified in the config file. If ADAPTIVE=1 is specified then the objects defined by the Gcode file being printed will be used to define the probed area. The optional <code>ADAPTIVE_MARGIN</code> value overrides the <code>adaptive_margin</code> option specified in the config file.</p>
|
||||
<p><code>BED_MESH_CALIBRATE [PROFILE=<name>] [METHOD=manual] [HORIZONTAL_MOVE_Z=<value>] [<probe_parameter>=<value>] [<mesh_parameter>=<value>] [ADAPTIVE=1] [ADAPTIVE_MARGIN=<value>]</code>: This command probes the bed using generated points specified by the parameters in the config. After probing, a mesh is generated and z-movement is adjusted according to the mesh. The mesh is immediately active after successful completion of <code>BED_MESH_CALIBRATE</code>. The mesh will be saved into a profile specified by the <code>PROFILE</code> parameter, or <code>default</code> if unspecified. If ADAPTIVE=1 is specified then the profile name will begin with <code>adaptive-</code> and should not be saved for reuse. See the PROBE command for details on the optional probe parameters. If METHOD=manual is specified then the manual probing tool is activated - see the MANUAL_PROBE command above for details on the additional commands available while this tool is active. The optional <code>HORIZONTAL_MOVE_Z</code> value overrides the <code>horizontal_move_z</code> option specified in the config file. If ADAPTIVE=1 is specified then the objects defined by the Gcode file being printed will be used to define the probed area. The optional <code>ADAPTIVE_MARGIN</code> value overrides the <code>adaptive_margin</code> option specified in the config file.</p>
|
||||
<h4 id="bed_mesh_output">BED_MESH_OUTPUT<a class="headerlink" href="#bed_mesh_output" title="Permanent link">¶</a></h4>
|
||||
<p><code>BED_MESH_OUTPUT PGP=[<0:1>]</code>: 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.</p>
|
||||
<h4 id="bed_mesh_map">BED_MESH_MAP<a class="headerlink" href="#bed_mesh_map" title="Permanent link">¶</a></h4>
|
||||
@@ -4965,7 +5047,7 @@ section</a> is enabled.</p>
|
||||
<h3 id="dual_carriage">[dual_carriage]<a class="headerlink" href="#dual_carriage" title="Permanent link">¶</a></h3>
|
||||
<p>Il comando seguente è disponibile quando la <a href="Config_Reference.html#dual_carriage">sezione di configurazione dual_carriage</a> è abilitata.</p>
|
||||
<h4 id="set_dual_carriage">SET_DUAL_CARRIAGE<a class="headerlink" href="#set_dual_carriage" title="Permanent link">¶</a></h4>
|
||||
<p><code>SET_DUAL_CARRIAGE CARRIAGE=[0|1] [MODE=[PRIMARY|COPY|MIRROR]]</code>: This command will change the mode of the specified carriage. If no <code>MODE</code> is provided it defaults to <code>PRIMARY</code>. Setting the mode to <code>PRIMARY</code> deactivates the other carriage and makes the specified carriage execute subsequent G-Code commands as-is. <code>COPY</code> and <code>MIRROR</code> modes are supported only for <code>CARRIAGE=1</code>. 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 <code>COPY</code> mode) or execute them in the opposite (mirror) direction (in <code>MIRROR</code> mode).</p>
|
||||
<p><code>SET_DUAL_CARRIAGE CARRIAGE=<carriage> [MODE=[PRIMARY|COPY|MIRROR]]</code>: This command will change the mode of the specified carriage. If no <code>MODE</code> is provided it defaults to <code>PRIMARY</code>. <code><carriage></code> must reference a defined primary or dual carriage for <code>generic_cartesian</code> kinematics or be 0 (for primary carriage) or 1 (for dual carriage) for all other kinematics supporting IDEX. Setting the mode to <code>PRIMARY</code> deactivates the other carriage and makes the specified carriage execute subsequent G-Code commands as-is. <code>COPY</code> and <code>MIRROR</code> modes are supported only for dual carriages. When set to either of these modes, dual carriage will then track the subsequent moves of its primary carriage and either copy relative movements of it (in <code>COPY</code> mode) or execute them in the opposite (mirror) direction (in <code>MIRROR</code> mode).</p>
|
||||
<h4 id="save_dual_carriage_state">SAVE_DUAL_CARRIAGE_STATE<a class="headerlink" href="#save_dual_carriage_state" title="Permanent link">¶</a></h4>
|
||||
<p><code>SAVE_DUAL_CARRIAGE_STATE [NAME=<state_name>]</code>: 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".</p>
|
||||
<h4 id="restore_dual_carriage_state">RESTORE_DUAL_CARRIAGE_STATE<a class="headerlink" href="#restore_dual_carriage_state" title="Permanent link">¶</a></h4>
|
||||
@@ -5068,6 +5150,13 @@ section</a> is enabled.</p>
|
||||
<p><code>SAVE_GCODE_STATE [NAME=<nome_stato>]</code>: salva lo stato di analisi delle coordinate del G-code corrente. Il salvataggio e il ripristino dello stato del G-code è utile negli script e nelle macro. Questo comando salva la modalità di coordinate assolute del G-code corrente (G90/G91), la modalità di estrusione assoluta (M82/M83), l'origine (G92), l'offset (SET_GCODE_OFFSET), l'override della velocità (M220), l'override dell'estrusore (M221), la velocità di spostamento , la posizione XYZ corrente e la posizione relativa dell'estrusore "E". Se viene fornito NAME, consente di assegnare un nome allo stato salvato alla stringa data. Se NAME non viene fornito, il valore predefinito è "predefinito".</p>
|
||||
<h4 id="restore_gcode_state">RESTORE_GCODE_STATE<a class="headerlink" href="#restore_gcode_state" title="Permanent link">¶</a></h4>
|
||||
<p><code>RESTORE_GCODE_STATE [NAME=<nome_stato>] [MOVE=1 [MOVE_SPEED=<velocità>]]</code>: ripristina uno stato precedentemente salvato tramite SAVE_GCODE_STATE. Se viene specificato "MOVE=1", verrà emesso un movimento della testa utensile per tornare alla posizione XYZ precedente. Se viene specificato "MOVE_SPEED", lo spostamento della testa utensile verrà eseguito con la velocità data (in mm/s); in caso contrario, lo spostamento della testa utensile utilizzerà la velocità del codice g ripristinata.</p>
|
||||
<h3 id="generic_cartesian">[generic_cartesian]<a class="headerlink" href="#generic_cartesian" title="Permanent link">¶</a></h3>
|
||||
<p>The commands in this section become automatically available when <code>kinematics: generic_cartesian</code> is specified as the printer kinematics.</p>
|
||||
<h4 id="set_stepper_carriages">SET_STEPPER_CARRIAGES<a class="headerlink" href="#set_stepper_carriages" title="Permanent link">¶</a></h4>
|
||||
<p><code>SET_STEPPER_CARRIAGES STEPPER=<stepper_name> CARRIAGES=<carriages> [DISABLE_CHECKS=[0|1]]</code>: Set or update the stepper carriages. <code><stepper_name></code> must reference an existing stepper defined in <code>printer.cfg</code>, and <code><carriages></code> describes the carriages the stepper moves. See <a href="Config_Reference.html#generic-cartesian-kinematics">Generic Cartesian Kinematics</a> for a more detailed overview of the <code>carriages</code> parameter in the stepper configuration section. Note that it is only possible to change the coefficients or signs of the carriages with this command, but a user cannot add or remove the carriages that the stepper controls.</p>
|
||||
<p><code>SET_STEPPER_CARRIAGES</code> is an advanced tool, and the user is advised to exercise an extreme caution using it, since specifying incorrect configuration may physically damage the printer.</p>
|
||||
<p>Note that <code>SET_STEPPER_CARRIAGES</code> performs certain internal validations of the new printer kinematics after the change. Keep in mind that if it detects an issue, it may leave printer kinematics in an invalid state. This means that if <code>SET_STEPPER_CARRIAGES</code> reports an error, it is unsafe to issue other GCode commands, and the user must inspect the error message and either fix the problem, or manually restore the previous stepper(s) configuration.</p>
|
||||
<p>Since <code>SET_STEPPER_CARRIAGES</code> can update a configuration of a single stepper at a time, some sequences of changes can lead to invalid intermediate kinematic configurations, even if the final configuration is valid. In such cases a user can pass <code>DISABLE_CHECKS=1</code> parameters to all but the last command to disable intermediate checks. For example, if <code>stepper a</code> and <code>stepper b</code> initially have <code>x-y</code> and <code>x+y</code> carriages correspondingly, then the following sequence of commands will let a user effectively swap the carriage controls: <code>SET_STEPPER_CARRIAGES STEPPER=a CARRIAGES=x+y DISABLE_CHECKS=1</code> and <code>SET_STEPPER_CARRIAGES STEPPER=b CARRIAGES=x-y</code>, while still validating the final kinematics state.</p>
|
||||
<h3 id="hall_filament_width_sensor">[hall_filament_width_sensor]<a class="headerlink" href="#hall_filament_width_sensor" title="Permanent link">¶</a></h3>
|
||||
<p>I seguenti comandi sono disponibili quando la <a href="Config_Reference.html#tsl1401cl_filament_width_sensor">sezione di configurazione del sensore di larghezza del filamento tsl1401cl</a> o <a href="Config_Reference.html#hall_filament_width_sensor">sezione di configurazione del sensore di larghezza del filamento hall</a> è abilitata (consultare anche <a href="TSL1401CL_Filament_Width_Sensor.html">Sensore di larghezza del filamento TSLl401CL</a> e <a href="Hall_Filament_Width_Sensor.html">Hall Filament Width Sensor</a>):</p>
|
||||
<h4 id="query_filament_width">QUERY_FILAMENT_WIDTH<a class="headerlink" href="#query_filament_width" title="Permanent link">¶</a></h4>
|
||||
@@ -5119,9 +5208,30 @@ section</a> is enabled.</p>
|
||||
</ol>
|
||||
<p>You can cancel the calibration process at any time with <code>ABORT</code>.</p>
|
||||
<h3 id="load_cell_tare">LOAD_CELL_TARE<a class="headerlink" href="#load_cell_tare" title="Permanent link">¶</a></h3>
|
||||
<p><code>LOAD_CELL_TARE [LOAD_CELL=<config_name>]</code>: This works just like the tare button on digital scale. It sets the current raw reading of the load cell to be the zero point reference value. The response is the percentage of the sensors range that was read and the raw value in counts.</p>
|
||||
<p><code>LOAD_CELL_TARE [LOAD_CELL=<config_name>]</code>: This works just like the tare button on digital scale. It sets the current raw reading of the load cell to be the zero point reference value. The response is the percentage of the sensors range that was read and the raw value in counts. If the load cell is calibrated a force in grams is also reported.</p>
|
||||
<h3 id="load_cell_read-load_cellname">LOAD_CELL_READ load_cell="name"<a class="headerlink" href="#load_cell_read-load_cellname" title="Permanent link">¶</a></h3>
|
||||
<p><code>LOAD_CELL_READ [LOAD_CELL=<config_name>]</code>: This command takes a reading from the load cell. The response is the percentage of the sensors range that was read and the raw value in counts. If the load cell is calibrated a force in grams is also reported.</p>
|
||||
<h3 id="load_cell_probe">[load_cell_probe]<a class="headerlink" href="#load_cell_probe" title="Permanent link">¶</a></h3>
|
||||
<p>The following commands are enabled if a <a href="Config_Reference.html#load_cell_probe">load_cell config section</a> has been enabled.</p>
|
||||
<h3 id="load_cell_test_tap">LOAD_CELL_TEST_TAP<a class="headerlink" href="#load_cell_test_tap" title="Permanent link">¶</a></h3>
|
||||
<p><code>LOAD_CELL_TEST_TAP [TAPS=<taps>] [TIMEOUT=<timeout>]</code>: Run a testing routine that reports taps on the load cell. The toolhead will not move but the load cell probe will sense taps just as if it was probing. This can be used as a sanity check to make sure that the probe works. This tool replaces QUERY_ENDSTOPS and QUERY_PROBE for load cell probes.</p>
|
||||
<ul>
|
||||
<li><code>TAPS</code>: the number of taps the tool expects</li>
|
||||
<li><code>TIMEOOUT</code>: the time, in seconds, that the tool waits for each tab before aborting.</li>
|
||||
</ul>
|
||||
<h3 id="load-cell-command-extensions">Load Cell Command Extensions<a class="headerlink" href="#load-cell-command-extensions" title="Permanent link">¶</a></h3>
|
||||
<p>Commands that perform probes, such as <a href="#probe"><code>PROBE</code></a>, <a href="#probe_accuracy"><code>PROBE_ACCURACY</code></a>, <a href="#bed_mesh_calibrate"><code>BED_MESH_CALIBRATE</code></a> etc. will accept additional parameters if a <code>[load_cell_probe]</code> is defined. The parameters override the corresponding settings from the <a href="Config_Reference.html#load_cell_probe"><code>[load_cell_probe]</code></a> configuration:</p>
|
||||
<ul>
|
||||
<li><code>FORCE_SAFETY_LIMIT=<grams></code></li>
|
||||
<li><code>TRIGGER_FORCE=<grams></code></li>
|
||||
<li><code>DRIFT_FILTER_CUTOFF_FREQUENCY=<frequency_hz></code></li>
|
||||
<li><code>DRIFT_FILTER_DELAY=<1|2></code></li>
|
||||
<li><code>BUZZ_FILTER_CUTOFF_FREQUENCY=<frequency_hz></code></li>
|
||||
<li><code>BUZZ_FILTER_DELAY=<1|2></code></li>
|
||||
<li><code>NOTCH_FILTER_FREQUENCIES=<list of frequency_hz></code></li>
|
||||
<li><code>NOTCH_FILTER_QUALITY=<quality></code></li>
|
||||
<li><code>TARE_TIME=<seconds></code></li>
|
||||
</ul>
|
||||
<h3 id="manual_probe">[manual_probe]<a class="headerlink" href="#manual_probe" title="Permanent link">¶</a></h3>
|
||||
<p>Il modulo manual_probe viene caricato automaticamente.</p>
|
||||
<h4 id="manual_probe_1">MANUAL_PROBE<a class="headerlink" href="#manual_probe_1" title="Permanent link">¶</a></h4>
|
||||
@@ -5139,6 +5249,7 @@ section</a> is enabled.</p>
|
||||
<p>Il comando seguente è disponibile quando una <a href="Config_Reference.html#stepper_manuale">sezione di configurazione stepper_manuale</a> è abilitata.</p>
|
||||
<h4 id="manual_stepper">MANUAL_STEPPER<a class="headerlink" href="#manual_stepper" title="Permanent link">¶</a></h4>
|
||||
<p><code>MANUAL_STEPPER STEPPER=nome_config [ENABLE=[0|1]] [SET_POSITION=<pos>] [SPEED=<velocità>] [ACCEL=<accelerazione>] [MOVE=<pos> [STOP_ON_ENDSTOP=[1|2|- 1|-2]] [SYNC=0]]</code>: Questo comando altererà lo stato dello stepper. Utilizzare il parametro ENABLE per abilitare/disabilitare lo stepper. Utilizzare il parametro SET_POSITION per forzare lo stepper a pensare di trovarsi nella posizione data. Utilizzare il parametro MOVE per richiedere un movimento alla posizione data. Se viene specificato SPEED e/o ACCEL, verranno utilizzati i valori forniti al posto dei valori predefiniti specificati nel file di configurazione. Se viene specificato un ACCEL pari a zero, non verrà eseguita alcuna accelerazione. Se viene specificato STOP_ON_ENDSTOP=1, lo spostamento terminerà in anticipo se l'endstop segnala come attivato (usa STOP_ON_ENDSTOP=2 per completare lo spostamento senza errori anche se l'endstop non si attiva, usa -1 o -2 per interrompere quando l'endstop segnala non innescato). Normalmente i futuri comandi G-Code verranno programmati per essere eseguiti dopo il completamento del movimento passo-passo, tuttavia se un movimento passo-passo manuale utilizza SYNC=0, i futuri comandi di movimento G-Code potrebbero essere eseguiti in parallelo con il movimento passo-passo.</p>
|
||||
<p><code>MANUAL_STEPPER STEPPER=config_name GCODE_AXIS=[A-Z] [LIMIT_VELOCITY=<velocity>] [LIMIT_ACCEL=<accel>] [INSTANTANEOUS_CORNER_VELOCITY=<velocity>]</code>: If the <code>GCODE_AXIS</code> parameter is specified then it configures the stepper motor as an extra axis on <code>G1</code> move commands. For example, if one were to issue a <code>MANUAL_STEPPER ... GCODE_AXIS=R</code> command then one could issue commands like <code>G1 X10 Y20 R30</code> to move the stepper motor. The resulting moves will occur synchronously with the associated toolhead xyz movements. If the motor is associated with a <code>GCODE_AXIS</code> then one may no longer issue movements using the above <code>MANUAL_STEPPER</code> command - one may unregister the stepper with a <code>MANUAL_STEPPER ... GCODE_AXIS=</code> command to resume manual control of the motor. The <code>LIMIT_VELOCITY</code> and <code>LIMIT_ACCEL</code> parameters allow one to reduce the speed of <code>G1</code> moves if those moves would result in a velocity or acceleration above the specified limits. The <code>INSTANTANEOUS_CORNER_VELOCITY</code> specifies the maximum instantaneous velocity change (in mm/s) of the motor during the junction of two moves (the default is 1mm/s).</p>
|
||||
<h3 id="mcp4018">[mcp4018]<a class="headerlink" href="#mcp4018" title="Permanent link">¶</a></h3>
|
||||
<p>Il comando seguente è disponibile quando una <a href="Config_Reference.html#mcp4018">sezione di configurazione mcp4018</a> è abilitata.</p>
|
||||
<h4 id="set_digipot">SET_DIGIPOT<a class="headerlink" href="#set_digipot" title="Permanent link">¶</a></h4>
|
||||
|
||||
@@ -1522,6 +1522,12 @@ make menuconfig
|
||||
<p>It's common for each printer to have its own unique serial port name. This unique name will be used when flashing the micro-controller. It's possible there may be multiple lines in the above output - if so, choose the line corresponding to the micro-controller. If many items are listed and the choice is ambiguous, unplug the board and run the command again, the missing item will be your print board(see the <a href="FAQ.html#wheres-my-serial-port">FAQ</a> for more information).</p>
|
||||
<p>For common micro-controllers with STM32 or clone chips, LPC chips and others, it is usual that these need an initial Klipper flash via SD card.</p>
|
||||
<p>When flashing with this method, it is important to make sure that the print board is not connected with USB to the host, due to some boards being able to feed power back to the board and stopping a flash from occurring.</p>
|
||||
<p>Please note, that most print boards that use SD cards for flash will implement some kind of flash loop protection for when the sd card is left in place. There are two common methods:</p>
|
||||
<p>Filename Change Required (usually "stock" print boards):</p>
|
||||
<p>These boards require the firmware file to have a different name each time you flash (for example, firmware1.bin, firmware2.bin, etc.). If you reuse the same filename, the board may ignore it and not update.</p>
|
||||
<p>Automatic File Renaming (usually aftermarket print boards:</p>
|
||||
<p>Other boards allow using the same filename, commonly firmware.bin, but after flashing, the board renames the file to firmware.cur. This helps indicate the firmware was successfully flashed and prevents it from flashing again on the next startup.</p>
|
||||
<p>Before flashing, make sure to check which behavior your board follows.</p>
|
||||
<p>For common micro-controllers using Atmega chips, for example the 2560, the code can be flashed with something similar to:</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo service klipper stop
|
||||
make flash FLASH_DEVICE=/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
|
||||
|
||||
@@ -1556,6 +1556,162 @@ Total capacity: +/- 29.14Kg
|
||||
<div class="highlight"><pre><span></span><code>{% set tare_counts = printer.load_cell.tare_counts %}
|
||||
</code></pre></div>
|
||||
|
||||
<h1 id="load-cell-probes">Load Cell Probes<a class="headerlink" href="#load-cell-probes" title="Permanent link">¶</a></h1>
|
||||
<h2 id="related-documentation_1">Related Documentation<a class="headerlink" href="#related-documentation_1" title="Permanent link">¶</a></h2>
|
||||
<ul>
|
||||
<li><a href="Config_Reference.html#load_cell_probe">load_cell_probe Config Reference</a></li>
|
||||
<li><a href="G-Codes.html#load_cell_probe">load_cell_probe G-Code Commands</a></li>
|
||||
<li><a href="Status_Reference.html#load_cell_probe">load_cell_probe Statuc Reference</a></li>
|
||||
</ul>
|
||||
<h2 id="load-cell-probe-safety">Load Cell Probe Safety<a class="headerlink" href="#load-cell-probe-safety" title="Permanent link">¶</a></h2>
|
||||
<p>Because load cells are a direct nozzle contact probe there is a risk of damage to your printer if too much force is used. The load cell probing system includes a number of safety checks that try to keep your machine safe from excessive force to the toolhead. It's important to understand what they are and how they work as you can defeat most of them with poorly chosen config values.</p>
|
||||
<h4 id="calibration-check">Calibration Check<a class="headerlink" href="#calibration-check" title="Permanent link">¶</a></h4>
|
||||
<p>Every time a homing move starts, load_cell_probe checks that the load_cell is calibrated. If not it will stop the move with an error: <code>!! Load Cell not calibrated</code>.</p>
|
||||
<h4 id="counts_per_gram"><code>counts_per_gram</code><a class="headerlink" href="#counts_per_gram" title="Permanent link">¶</a></h4>
|
||||
<p>This setting is used to convert raw sensor counts into grams. All the safety limits are in gram units for your convenience. If the <code>counts_per_gram</code> setting is not accurate you can easily exceed the safe force on the toolhead. You should never guess this value. Use <code>LOAD_CELL_CALIBRATE</code> to find your load cells actual <code>counts_per_gram</code>.</p>
|
||||
<h4 id="trigger_force"><code>trigger_force</code><a class="headerlink" href="#trigger_force" title="Permanent link">¶</a></h4>
|
||||
<p>This is the force in grams that triggers the endstop to halt the homing move. When a homing move starts the endstop tares itself with the current reading from the load cell. <code>trigger_force</code> is measured from that tare value. There is always some overshoot of this value when the probe collides with the bed, so be conservative. e.g. a setting of 100g could result in 350g of peak force before the toolhead stops. This overshoot will increase with faster probing <code>speed</code>, a low ADC sample rate or <a href="Multi_MCU_Homing.html">multi MCU homing</a>.</p>
|
||||
<h4 id="reference_tare_counts"><code>reference_tare_counts</code><a class="headerlink" href="#reference_tare_counts" title="Permanent link">¶</a></h4>
|
||||
<p>This is the baseline tare value that is set by <code>LOAD_CELL_CALIBRATE</code>. This value works with <code>force_safety_limit</code> to limit the maximum force on the toolhead.</p>
|
||||
<h4 id="force_safety_limit"><code>force_safety_limit</code><a class="headerlink" href="#force_safety_limit" title="Permanent link">¶</a></h4>
|
||||
<p>This is the maximum absolute force, relative to <code>reference_tare_counts</code>, that the probe will allow while homing or probing. If the MCU sees this force exceeded it will shut down the printer with the error <code>!! Load cell endstop: too much force!</code>. There are a number of ways this can be triggered:</p>
|
||||
<p>The first risk this protects against is picking too large of a value for <code>drift_filter_cutoff_frequency</code>. This can cause the drift filter to filter out a probe event and continue the homing move. If this happens the <code>force_safety_limit</code> acts as a backup protection.</p>
|
||||
<p>The second problem is probing repeatedly in one place. Klipper does not retract the probe when doing a single <code>PROBE</code> command. This can result in force applied to the toolhead at the end of a probing cycle. Because external forces can vary greatly between probing locations, <code>load_cell_probe</code> performs a tare before beginning each probe. If you repeat the <code>PROBE</code> command, load_cell_probe will tare the endstop at the current force. Multiple cycles of this will result in ever-increasing force on the toolhead. <code>force_safety_limit</code> stops this cycle from running out of control.</p>
|
||||
<p>Another way this run-away can happen is damage to a strain gauge. If the metal part is permanently bent it wil change the <code>reference_tare_counts</code> of the device. This puts the starting tare value much closer to the limit making it more likely to be violated. You want to be notified if this is happening because your hardware has been permanently damaged.</p>
|
||||
<p>The final way this can be triggered is due to temperature changes. If your strain gauges are heated their <code>reference_tare_counts</code> may be very different at ambient temperature vs operating temperature. In this case you may need to increase the <code>force_safety_limit</code> to allow for thermal changes.</p>
|
||||
<h4 id="load-cell-endstop-watchdog-task">Load Cell Endstop Watchdog Task<a class="headerlink" href="#load-cell-endstop-watchdog-task" title="Permanent link">¶</a></h4>
|
||||
<p>When homing the load_cell_endstop starts a task on the MCU to trac measurements arriving from the sensor. If the sensor fails to send measurements for 2 sample periods the watchdog will shut down the printer with an error <code>!! LoadCell Endstop timed out waiting on ADC data</code>.</p>
|
||||
<p>If this happens, the most likely cause is a fault from the ADC. Inadequate grounding of your printer can be the root cause. The frame, power supply case and pint bed should all be connected to ground. You may need to ground the frame in multiple places. Anodized aluminum extrusions do not conduct electricity well. You might need to sand the area where the grounding wire is attached to make good electrical contact.</p>
|
||||
<h2 id="load-cell-probe-setup">Load Cell Probe Setup<a class="headerlink" href="#load-cell-probe-setup" title="Permanent link">¶</a></h2>
|
||||
<p>This section covers the process for commissioning a load cell probe.</p>
|
||||
<h3 id="verify-the-load-cell-first">Verify the Load Cell First<a class="headerlink" href="#verify-the-load-cell-first" title="Permanent link">¶</a></h3>
|
||||
<p>A <code>[load_cell_probe]</code> is also a <code>[load_cell]</code> and G-code commands related to <code>[load_cell]</code> work with <code>[load_cell_probe]</code>. Before attempting to use a load cell probe, follow the directions for <a href="Load_Cell.html#calibrating-a-load-cell">calibrating the load cell</a> with <code>CALIBRATE_LOAD_CELL</code> and checking its operation with <code>LOAD_CELL_DIAGNOSTIC</code>.</p>
|
||||
<h3 id="verify-probe-operation-with-load_cell_test_tap">Verify Probe Operation With LOAD_CELL_TEST_TAP<a class="headerlink" href="#verify-probe-operation-with-load_cell_test_tap" title="Permanent link">¶</a></h3>
|
||||
<p>Use the command <code>LOAD_CELL_TEST_TAP</code> to test the operation of the load cell probe before actually trying to probe with it. This command detects taps, just like the PROBE command, but it does not move the z axis. By default, it listens for 3 taps before ending the test. You have 30 seconds to do each tap, if no taps are detected the command will time out.</p>
|
||||
<p>If this test fails, check your configuration and <code>LOAD_CELL_DIAGNOSTIC</code> carefully to look for issues.</p>
|
||||
<p>Load cell probes don't support the <code>QUERY_ENDSTOPS</code> or <code>QUERY_PROBE</code> commands. Use <code>LOAD_CELL_TEST_TAP</code> for testing functionality before probing.</p>
|
||||
<h3 id="homing-macros">Homing Macros<a class="headerlink" href="#homing-macros" title="Permanent link">¶</a></h3>
|
||||
<p>Load cell probe is not an endstop and doesn't support <code>endstop: prove:z_virtual_endstop</code>. For the time being you'll need to configure your z axis with an MCU pin as its endstop. You won't actually be using the pin but for the time being you have to configure something.</p>
|
||||
<p>To home the axis with just the probe you need to set up a custom homing macro. This requires setting up <a href="Config_Reference.html#homing_override">homing_override</a>.</p>
|
||||
<p>Here is a simple macro that can accomplish this. Note that the <code>_HOME_Z_FROM_LAST_PROBE</code> macro has to be separate because of the way macros work. The sub-call is needed so that the <code>_HOME_Z_FROM_LAST_PROBE</code> macro can see the result of the probe in <code>printer.probe.last_z_result</code>.</p>
|
||||
<div class="highlight"><pre><span></span><code>[gcode_macro _HOME_Z_FROM_LAST_PROBE]
|
||||
gcode:
|
||||
<span class="w"> </span>{% set z_probed = printer.probe.last_z_result %}
|
||||
<span class="w"> </span>{% set z_position = printer.toolhead.position[2] %}
|
||||
<span class="w"> </span>{% set z_actual = z_position - z_probed %}
|
||||
<span class="w"> </span>SET_KINEMATIC_POSITION Z={z_actual}
|
||||
|
||||
[gcode_macro _HOME_Z]
|
||||
gcode:
|
||||
<span class="w"> </span>SET_GCODE_OFFSET Z=0 # load cell probes dont need a Z offset
|
||||
<span class="w"> </span># position toolhead for homing Z, edit for your printers size
|
||||
<span class="w"> </span>#G90 # absolute move
|
||||
<span class="w"> </span>#G1 Y50 X50 F{5 * 60} # move to X/Y position for homing
|
||||
|
||||
<span class="w"> </span># soft home the z axis to its limit so it can be moved:
|
||||
<span class="w"> </span>SET_KINEMATIC_POSITION Z={printer.toolhead.axis_maximum[2]}
|
||||
|
||||
<span class="w"> </span># Fast approach and tap
|
||||
<span class="w"> </span>PROBE PROBE_SPEED={5 * 60} # override the speed for faster homing
|
||||
<span class="w"> </span>_HOME_Z_FROM_LAST_PROBE
|
||||
|
||||
<span class="w"> </span># lift z to 2mm
|
||||
<span class="w"> </span>G91 # relative move
|
||||
<span class="w"> </span>G1 Z2 F{5 * 60}
|
||||
|
||||
<span class="w"> </span># probe at standard speed
|
||||
<span class="w"> </span>PROBE
|
||||
<span class="w"> </span>_HOME_Z_FROM_LAST_PROBE
|
||||
|
||||
<span class="w"> </span># lift z to 10mm for clearance
|
||||
<span class="w"> </span>G91 # relative move
|
||||
<span class="w"> </span>G1 Z10 F{5 * 60}
|
||||
</code></pre></div>
|
||||
|
||||
<h3 id="suggested-probing-temperature">Suggested Probing Temperature<a class="headerlink" href="#suggested-probing-temperature" title="Permanent link">¶</a></h3>
|
||||
<p>Currently, we suggest keeping the nozzle temperature below the level that causes the filament to ooze while homing and probing. 140C is a good starting point. This temperature is also low enough not to scar PEI build surfaces.</p>
|
||||
<p>Fouling of the nozzle and the print bed due to oozing filament is the #1 source of probing error with the load cell probe. Klipper does not yet have a universal way to detect poor quality taps due to filament ooze. The existing code may decide that a tap is valid when it is of poor quality. Classifying these poor quality taps is an area of active research.</p>
|
||||
<p>Klipper also lacks support for re-locating a probe point if the location has become fouled by filament ooze. Modules like <code>quad_gantry_level</code> will repeatedly probe the same coordinates even if a probe previously failed there.</p>
|
||||
<p>Give the above it is strongly suggested not to probe at printing temperatures.</p>
|
||||
<h3 id="hot-nozzle-protection">Hot Nozzle Protection<a class="headerlink" href="#hot-nozzle-protection" title="Permanent link">¶</a></h3>
|
||||
<p>The Voron project has a great macro for protecting your print surface from the hot nozzle. See <a href="https://github.com/VoronDesign/Voron-Tap/blob/main/config/tap_klipper_instructions.md">Voron Tap's
|
||||
<code>activate_gcode</code></a></p>
|
||||
<p>It is highly suggested to add something like this to your config.</p>
|
||||
<h3 id="nozzle-cleaning">Nozzle Cleaning<a class="headerlink" href="#nozzle-cleaning" title="Permanent link">¶</a></h3>
|
||||
<p>Before probing the nozzle should be clean. You could do this manually before every print. You can also implement a nozzle scrubber and automate the process. Here is a suggested sequence:</p>
|
||||
<ol>
|
||||
<li>Wait for the nozzle to heat up to probing temp (e.g. <code>M109 S140</code>)</li>
|
||||
<li>Home the machine (<code>G28</code>)</li>
|
||||
<li>Scrub the nozzle on a brush</li>
|
||||
<li>Heat soak the print bed</li>
|
||||
<li>Perform probing tasks: QGL, bed mesh etc.</li>
|
||||
</ol>
|
||||
<h3 id="temperature-compensation-for-nozzle-growth">Temperature Compensation for Nozzle Growth<a class="headerlink" href="#temperature-compensation-for-nozzle-growth" title="Permanent link">¶</a></h3>
|
||||
<p>If you are probing at a safe temperature, the nozzle will expand after heating to printing temperatures. This will cause the nozzle to get longer and closer to the print surface. You can compensate for this with <a href="Config_Reference.html#z_thermal_adjust">[z_thermal_adjust]</a>. This adjustment will work across a range of printing temperatures from PLA to PC.</p>
|
||||
<h4 id="calculating-the-temp_coeff-for-z_thermal_adjust">Calculating the <code>temp_coeff</code> for <code>[z_thermal_adjust]</code><a class="headerlink" href="#calculating-the-temp_coeff-for-z_thermal_adjust" title="Permanent link">¶</a></h4>
|
||||
<p>The easiest way to do this is to measure at 2 different temperatures. Ideally these should be the upper and lower limits of the printing temperature range. E.g. 180C and 290C. You can perform a <code>PROBE_ACCURACY</code> at both temperatures and then calculate the difference of the <code>average z</code> at both.</p>
|
||||
<p>The adjustment value is the change in nozzle length divided by the change in temperature. e.g.</p>
|
||||
<div class="highlight"><pre><span></span><code>temp_coeff = -0.05 / (290 - 180) = -0.00045455
|
||||
</code></pre></div>
|
||||
|
||||
<p>The expected result is a negative number. Positive values for <code>temp_coeff</code> move the nozzle closer to the bed and negative values move it further away. Expect to have to move the nozzle further away as it gets longer when hot.</p>
|
||||
<h4 id="configure-z_thermal_adjust">Configure <code>[z_thermal_adjust]</code><a class="headerlink" href="#configure-z_thermal_adjust" title="Permanent link">¶</a></h4>
|
||||
<p>Set up z_thermal_adjust to reference the <code>extruder</code> as the source of temperature data. E.g.:</p>
|
||||
<div class="highlight"><pre><span></span><code>[z_thermal_adjust nozzle]
|
||||
temp_coeff=-0.00045455
|
||||
sensor_type: temperature_combined
|
||||
sensor_list: extruder
|
||||
combination_method: max
|
||||
min_temp: 0
|
||||
max_temp: 400
|
||||
max_z_adjustment: 0.1
|
||||
</code></pre></div>
|
||||
|
||||
<h2 id="continuous-tare-filters-for-toolhead-load-cells">Continuous Tare Filters for Toolhead Load Cells<a class="headerlink" href="#continuous-tare-filters-for-toolhead-load-cells" title="Permanent link">¶</a></h2>
|
||||
<p>Klipper implements a configurable IIR filter on the MCU to provide continuous tareing of the load cell while probing. Continuous taring means the 0 value moves with drift caused by external factors like bowden tubes and thermal changes. This is aimed at toolhead sensors and moving beds that experience lots of external forces that change while probing.</p>
|
||||
<h3 id="installing-scipy">Installing SciPy<a class="headerlink" href="#installing-scipy" title="Permanent link">¶</a></h3>
|
||||
<p>The filtering code uses the excellent <a href="https://scipy.org/">SciPy</a> library to compute the filter coefficients based on the values your enter into the config.</p>
|
||||
<p>Pre-compiled SciPi builds are available for Python 3 on 32 bit Raspberry Pi systems. 32 bit + Python 3 is strongly recommended because it will streamline your installation experience. It does work with Python 2 but installation can take 30+ minutes and require installing additional tools.</p>
|
||||
<div class="highlight"><pre><span></span><code>~/klippy-env/bin/pip<span class="w"> </span>install<span class="w"> </span>scipy
|
||||
</code></pre></div>
|
||||
|
||||
<h3 id="filter-workbench">Filter Workbench<a class="headerlink" href="#filter-workbench" title="Permanent link">¶</a></h3>
|
||||
<p>The filter parameters should be selected based on drift seen on the printer during normal operation. A Jupyter notebook is provided in scripts, <a href="https://github.com/Klipper3d/klipper/blob/master/scripts/filter_workbench.ipynb">filter_workbench.ipynb</a>, to perform a detailed investigation with real captured data and FFTs.</p>
|
||||
<h3 id="filtering-suggestions">Filtering Suggestions<a class="headerlink" href="#filtering-suggestions" title="Permanent link">¶</a></h3>
|
||||
<p>For those just trying to get a filter working follow these suggestions:</p>
|
||||
<ul>
|
||||
<li>The only essential option is <code>drift_filter_cutoff_frequency</code>. A conservative starting value is <code>0.5</code>Hz. Prusa shipped the MK4 with a setting of <code>0.8</code>Hz and the XL with <code>11.2</code>Hz. This is probably a safe range to experiment with. This value should be increased only until normal drift due to bowden tube force is eliminated. Setting this value too high will result in slow triggering and excess force going through the toolhead.</li>
|
||||
<li>Keep <code>trigger_force</code> low. The default is <code>75</code>g. The drift filter keeps the internal grams value very close to 0 so a large trigger force is not needed.</li>
|
||||
<li>Keep <code>force_safety_limit</code> to a conservative value. The default value is 2Kg and should keep your toolhead safe while experimenting. If you hit this limit the <code>drift_filter_cutoff_frequency</code> value may be too high.</li>
|
||||
</ul>
|
||||
<h2 id="suggestions-for-load-cell-tool-boards">Suggestions for Load Cell Tool Boards<a class="headerlink" href="#suggestions-for-load-cell-tool-boards" title="Permanent link">¶</a></h2>
|
||||
<p>This section covers suggestions for those developing toolhead boards that want to support [load_cell_probe]</p>
|
||||
<h3 id="adc-sensor-selection-board-development-hints">ADC Sensor Selection & Board Development Hints<a class="headerlink" href="#adc-sensor-selection-board-development-hints" title="Permanent link">¶</a></h3>
|
||||
<p>Ideally a sensor would meet these criteria:</p>
|
||||
<ul>
|
||||
<li>At least 24 bits wide</li>
|
||||
<li>Use SPI communications</li>
|
||||
<li>Has a pin can be used to indicate sample ready without SPI communications. This is often called the "data ready" or "DRDY" pin. Checking a pin is much faster than running an SPI query.</li>
|
||||
<li>Has a programmable gain amplifier gain setting of 128. This should eliminate the need for a separate amplifier.</li>
|
||||
<li>Indicates via SPI if the sensor has been reset. Detecting resets avoids timing errors in homing and using noisy data at startup. It can also help users track down wiring and grounding issues.</li>
|
||||
<li>A selectable sample rate between 350Hz and 2Khz. Very high sample rates don't turn out to be beneficial in our 3D printers because they produce so much noise when moving fast. Sample rates below 250Hz will require slower probing speeds. They also increase the force on the toolhead due to longer delays between measurements. E.g. a 500Hz sensor moving at 5mm/s has the same safety factor as a 100Hz sensor moving at only 1mm/s.</li>
|
||||
<li>If designing for under-bed applications, and you want to sense multiple load cells, use a chip that can sample all of its inputs simultaneously. Multiplex ADCs that require switching channels have a settling of several samples after each channel switch making them unsuitable for probing applications.</li>
|
||||
</ul>
|
||||
<p>Implementing support for a new sensor chip is not particularly difficult with Klipper's <code>bulk_sensor</code> and <code>load_cell_endstop</code> infrastructure.</p>
|
||||
<h3 id="5v-power-filtering">5V Power Filtering<a class="headerlink" href="#5v-power-filtering" title="Permanent link">¶</a></h3>
|
||||
<p>It is strongly suggested to use larger capacitors than specified by the ADC chip manufacturer. ADC chips are usually targeted at low noise environments, like battery powered devices. Sensor manufacturers suggested application notes generally assume a quiet power supply. Treat their suggested capacitor values as minimums.</p>
|
||||
<p>3D printers put huge amounts of noise onto the 5V bus and this can ruin the sensor's accuracy. Test the sensor on the board with a typical 3D printer power supply and active stepper drivers before deciding on smoothing capacitor sizes.</p>
|
||||
<h3 id="grounding-ground-planes">Grounding & Ground Planes<a class="headerlink" href="#grounding-ground-planes" title="Permanent link">¶</a></h3>
|
||||
<p>Analog ADC chips contain components that are very vulnerable to noise and ESD. A large ground plane on the first board layer under the chip can help with noise. Keep the chip away from power sections and DC to DC converters. The board should have proper grounding back to the DC supply.</p>
|
||||
<h3 id="hx711-and-hx717-notes">HX711 and HX717 Notes<a class="headerlink" href="#hx711-and-hx717-notes" title="Permanent link">¶</a></h3>
|
||||
<p>This sensor is popular because of its low cost and availability in the supply chain. However, this is a sensor with some drawbacks:</p>
|
||||
<ul>
|
||||
<li>The HX71x sensors use bit-bang communication which has a high overhead on the MCU. Using a sensor that communicates via SPI would save resources on the tool board's CPU.</li>
|
||||
<li>The HX71x lacks a way to communicate reset events to the MCU. Klipper detects resets with a timing heuristic but this is not ideal. Resets indicate a problem with wiring or grounding.</li>
|
||||
<li>For probing applications the HX717 version is strongly preferred because of its higher sample rate (320 vs 80). Probing speed on the HX711 should be limited to less than 2mm/s.</li>
|
||||
<li>The sample rate on the HX71x cannot be set from klipper's config. If you have the 10SPS version of the sensor (which is widely distributed) it needs to be physically re-wired to run at 80SPS.</li>
|
||||
</ul>
|
||||
|
||||
|
||||
</article>
|
||||
</div>
|
||||
|
||||
@@ -1008,6 +1008,13 @@
|
||||
load_cell
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load_cell_probe" class="md-nav__link">
|
||||
load_cell_probe
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -1867,6 +1874,13 @@
|
||||
load_cell
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#load_cell_probe" class="md-nav__link">
|
||||
load_cell_probe
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -2254,6 +2268,14 @@
|
||||
<li>'min_force_g': The minimum force in grams, over the last polling period.</li>
|
||||
<li>'max_force_g': The maximum force in grams, over the last polling period.</li>
|
||||
</ul>
|
||||
<h2 id="load_cell_probe">load_cell_probe<a class="headerlink" href="#load_cell_probe" title="Permanent link">¶</a></h2>
|
||||
<p>The following information is available for <code>[load_cell_probe]</code>:</p>
|
||||
<ul>
|
||||
<li>all items from <a href="Status_Reference.html#load_cell">load_cell</a></li>
|
||||
<li>all items from <a href="Status_Reference.html#probe">probe</a></li>
|
||||
<li>'endstop_tare_counts': the load cell probe keeps a tare value independent of the load cell. This re-set at the start of each probe.</li>
|
||||
<li>'last_trigger_time': timestamp of the last homing trigger</li>
|
||||
</ul>
|
||||
<h2 id="manual_probe">manual_probe<a class="headerlink" href="#manual_probe" title="Permanent link">¶</a></h2>
|
||||
<p>Le seguenti informazioni sono disponibili nell'oggetto <code>manual_probe</code>:</p>
|
||||
<ul>
|
||||
@@ -2402,6 +2424,10 @@
|
||||
<li><code>carriage_0</code>: The mode of the carriage 0. Possible values are: "INACTIVE" and "PRIMARY".</li>
|
||||
<li><code>carriage_1</code>: The mode of the carriage 1. Possible values are: "INACTIVE", "PRIMARY", "COPY", and "MIRROR".</li>
|
||||
</ul>
|
||||
<p>On a <code>generic_cartesian</code> kinematic, the following information is available in <code>dual_carriage</code>:</p>
|
||||
<ul>
|
||||
<li><code>carriages["<carriage>"]</code>: The mode of the carriage <code><carriage></code>. Possible values are "INACTIVE" and "PRIMARY" for the primary carriage and "INACTIVE", "PRIMARY", "COPY", and "MIRROR" for the dual carriage.</li>
|
||||
</ul>
|
||||
<h2 id="virtual_sdcard">virtual_sdcard<a class="headerlink" href="#virtual_sdcard" title="Permanent link">¶</a></h2>
|
||||
<p>Le seguenti informazioni sono disponibili nell'oggetto <a href="Config_Reference.html#virtual_sdcard">virtual_sdcard</a>:</p>
|
||||
<ul>
|
||||
|
||||
Binary file not shown.
File diff suppressed because one or more lines are too long
112
it/sitemap.xml
112
it/sitemap.xml
@@ -2,282 +2,282 @@
|
||||
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2025-07-16</lastmod>
|
||||
<lastmod>2025-07-17</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
</urlset>
|
||||
Binary file not shown.
Reference in New Issue
Block a user