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>初始查询响应中的“Header”字段用于描述在随后的“数据”响应中找到的字段。</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="_">暂停_继续/取消<a class="headerlink" href="#_" title="Permanent link">¶</a></h3>
|
||||
<p>该端点类似于运行“PRINT_CANCEL”G-Code命令。例如：<code>{“id”：123，“方法”：“PAUSE_RESUME/Cancel”}</code></p>
|
||||
<p>与“gcode/脚本”终结点一样，该终结点只有在所有挂起的G-Code命令完成后才会完成。</p>
|
||||
|
||||
@@ -2083,7 +2083,7 @@ scan_overshoot: 8
|
||||
<h3 id="_11">校准<a class="headerlink" href="#_11" 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>启动床网校准的探测程序。</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>任何其他保存的配置也可以用相同的方式删除，用你想删除的配置名称替换<em>default</em>。</p>
|
||||
<h4 id="_13">加载默认配置文件<a class="headerlink" href="#_13" title="Permanent link">¶</a></h4>
|
||||
<p>以前版本的<code>bed_mesh</code>如果(default)默认配置存在，则始终在启动时加载名为<em>default</em>的配置文件。现已删除此行为，以允许用户确定何时加载配置文件。如果用户希望加载<code>default</code>配置文件，则建议将 <code>BED_MESH_PROFILE LOAD=default</code> 添加到其 <code>START_PRINT</code> 宏或其切片软件的“启动 G代码”配置中，视情况而定。</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>或者可以通过添加<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 @@
|
||||
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 @@
|
||||
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个步进电机</td>
|
||||
<td>47</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>3个步进电机</td>
|
||||
<td>208</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h3 id="lpc176x">LPC176x 步进率基准测试<a class="headerlink" href="#lpc176x" title="Permanent link">¶</a></h3>
|
||||
<p>在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="linux-mcu">Linux MCU 步速率基准测试<a class="headerlink" href="#linux-mcu" title="Permanent link">¶</a></h3>
|
||||
<p>树莓派上使用以下配置序列：</p>
|
||||
<div class="highlight"><pre><span></span><code>allocate_oids count=3
|
||||
@@ -2289,7 +2331,8 @@ get_uptime
|
||||
</code></pre></div>
|
||||
|
||||
<p>当测试完成后，确定两个 "正常运行时间 "响应信息中报告的时钟之间的差异。然后，每秒钟的总命令数是<code>100000 * mcu_frequency / clock_diff</code>。</p>
|
||||
<p>注意，这个测试可能会使Raspberry Pi的USB/CPU容量达到饱和。如果在Raspberry Pi、Beaglebone或类似的主机上运行，那么要增加延迟（例如，<code>DELAY {clock + 20*freq} get_uptime</code>）。在适用的情况下，下面的基准是用控制台.py在桌面类机器上运行，设备通过高速集线器连接。</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>“桥接MCU”实际上并不在CAN总线上。可能位于CAN总线上的其他适配器不会看到进出桥接器MCU的消息。</li>
|
||||
<li>
|
||||
<p>“桥式MCU”本身和CAN总线上的所有设备的可用带宽都受到CAN总线频率的有效限制。因此，在使用“USB转CAN总线桥模式”时，建议使用1000000的CAN总线频率。</p>
|
||||
<p>即使在CAN总线频率为1000000的情况下，如果XY步进器和加速度计都通过单个“USB to CAN Bus”接口进行通信，也可能没有足够的带宽来运行 <code>SHAPER_CALIBRATE</code> 测试。</p>
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>“桥式MCU”本身和CAN总线上的所有设备的可用带宽都受到CAN总线频率的有效限制。因此，在使用“USB转CAN总线桥模式”时，建议使用1000000的CAN总线频率。</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>USB转CAN桥板不会显示为USB串口设备，也不会在运行<code>ls/dev/Serial/by-id</code>时出现，也不能在Klipper的printer.cfg文件中使用<code>Serial：</code>参数进行配置。桥接板显示为“USB CAN适配器”，并在printer.cfg中配置为<a href="#configuring-klipper">CAN节点</a>。</li>
|
||||
</ul>
|
||||
|
||||
@@ -1577,6 +1577,7 @@
|
||||
</ul>
|
||||
</li>
|
||||
<li>如果用户配置中存在错误，应在<code>load_config()</code>或连接事件（connect event）中抛出异常。使用 <code>raise config.error("my error")</code> 或 <code>raise printer.config_error("my error")</code> 进行告警。</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>使用"pins"模块对微控制器的引脚进行定义，例如<code>printer.lookup_object("pins").setup_pin("pwm", config.get("my_pin"))</code>。此后，运行时，可通过返回的对象对针脚进行控制。</li>
|
||||
<li>如果打印机对象中定义了 <code>get_status()</code> 方法，则在模块中可以通过<a href="Command_Templates.html">宏</a>或<a href="API_Server.html">API服务</a>输出<a href="Status_Reference.html">状态信息</a>。 <code>get_status()</code> 必须返回一个Python字典对象，其键需要为字符串，而值应为整形、浮点数、列表、字典、True、False或者None。元组（或命名元组）也可以作为值（它们在API服务中将被视为列表）。列表和字典的输出值必须为“不可变的（immutable）”，即在函数内，如果 <code>get_status()</code> 需要输出上述类型的实例，则需要新建或者进行深层复制，否则API服务会识别出输出值中的内容变更。</li>
|
||||
<li>如果模块需要使用系统时钟或外部文件描述符，可通过<code>printer.get_reactor()</code>对获取全局事件反应器进行访问（event reactor）。通过该反应器类可以部署定时器，等待文件描述符输入，或者“挂起”上位机程序。</li>
|
||||
|
||||
@@ -657,6 +657,13 @@
|
||||
缆绳绞盘运动学
|
||||
</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 @@
|
||||
缆绳绞盘运动学
|
||||
</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>
|
||||
@@ -4026,8 +4054,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.
|
||||
@@ -4503,6 +4532,123 @@ anchor_z:
|
||||
# 必须提供这些参数。
|
||||
</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="_9">无运动学<a class="headerlink" href="#_9" title="Permanent link">¶</a></h3>
|
||||
<p>可以定义特殊的 "none" 运动学来禁用 Klipper 中的运动学支持。可以用于控制不是 3D 打印机的设备或调试。</p>
|
||||
<div class="highlight"><pre><span></span><code>[printer]
|
||||
@@ -5673,9 +5819,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>Additionally, one could use "SET_DUAL_CARRIAGE CARRIAGE=1 MODE=COPY" or "SET_DUAL_CARRIAGE CARRIAGE=1 MODE=MIRROR" commands to activate either copying or mirroring mode of the dual carriage, in which case it will follow the motion of the carriage 0 accordingly. These commands can be used to print two parts simultaneously - either two identical parts (in COPY mode) or mirrored parts (in MIRROR mode). Note that COPY and MIRROR modes also require appropriate configuration of the extruder on the dual carriage, which can typically be achieved with "SYNC_EXTRUDER_MOTION MOTION_QUEUE=extruder EXTRUDER=<dual_carriage_extruder>" or a similar command.</p>
|
||||
<p>Idex参考示例<a href="https://github.com/Klipper3d/klipper/blob/master/config/sample-idex.cfg">sample-idex.cfg</a></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
|
||||
@@ -5687,7 +5833,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:
|
||||
@@ -5701,6 +5847,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>支持额外和挤出机运动同步的步进电机（可以定义任意数量的带有“extruder_stepper”前缀的分段）。</p>
|
||||
<p>更多信息请参阅<a href="G-Codes.html#extruder">命令参考</a>。</p>
|
||||
@@ -5719,25 +5924,33 @@ extruder:
|
||||
|
||||
<h3 id="manual_stepper">[manual_stepper]<a class="headerlink" href="#manual_stepper" title="Permanent link">¶</a></h3>
|
||||
<p>手动步进器（可以通过定义任何数量"manual_stepper"前缀的配置分段）。这些是由 MANUAL_STEPPER G代码命令控制的步进电机。例如："MANUAL_STEPPER STEPPER=my_stepper MOVE=10 SPEED=5"。参见<a href="G-Code.md#manual_stepper">G-Code</a>文档中关于 MANUAL_STEPPER 命令的描述。手动步进器械不会连接到正常的打印机运动学中。</p>
|
||||
<div class="highlight"><pre><span></span><code>[manual_stepper my_stepper]。
|
||||
<div class="highlight"><pre><span></span><code>[manual_stepper my_stepper]
|
||||
#step_pin:
|
||||
#dir_pin:
|
||||
#enable_pin:
|
||||
#microsteps:
|
||||
#rotation_distance:
|
||||
# 有关这些参数的描述请见"stepper"分段。
|
||||
# See the "stepper" section for a description of these parameters.
|
||||
#velocity:
|
||||
# 设置步进电机的默认速度（单位：mm/s）。这个值会在 MANUAL_STEPPER
|
||||
# 命令没有指定一个 SPEED 参数时会被使用。
|
||||
# 默认为 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:
|
||||
# 设置步进电机的默认加速度（单位：mm/s^2）。设置加速度为零将导致
|
||||
# 没有加速度。这个值会在 MANUAL_STEPPER 命令没有指定 ACCEL 参数时
|
||||
# 会被使用。
|
||||
# 默认为 0。
|
||||
# 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:
|
||||
# 限位开关检测引脚。如果定义了这个参数，可以通过在 MANUAL_STEPPER
|
||||
# 运动命令中添加一个 STOP_ON_ENDSTOP 参数来执行 "归位动作" 。
|
||||
# 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="_17">自定义加热器和传感器<a class="headerlink" href="#_17" title="Permanent link">¶</a></h2>
|
||||
@@ -7859,6 +8072,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="_28">控制板特定硬件支持<a class="headerlink" href="#_28" title="Permanent link">¶</a></h2>
|
||||
<h3 id="sx1509">[sx1509]<a class="headerlink" href="#sx1509" title="Permanent link">¶</a></h3>
|
||||
<p>将一个 SX1509 I2C 配置为 GPIO 扩展器。由于 I2C 通信本身的延迟，不应将 SX1509 引脚用作步进电机的 enable （启用)、step（步进）或 dir （方向）引脚或任何其他需要快速 bit-banging（位拆裂）的引脚。它们最适合用作静态或G代码控制的数字输出或硬件 pwm 引脚，例如风扇。可以使用“sx1509”前缀定义任意数量的分段。每个扩展器提供可用于打印机配置的一组 16 个引脚（sx1509_my_sx1509:PIN_0 到 sx1509_my_sx1509:PIN_15）。</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
zh/G-Codes.html
117
zh/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>启用[床网格配置部分]（config_Reference.md#bed_mesh）时，以下命令可用（另请参阅[床网格指南]（bed_mesh.md））。</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>：此命令使用配置中的参数指定的生成点探测床。探测后，将生成一个网格，并根据网格调整 z 方向的移动。网格将保存到由 <code>PROFILE</code> 参数指定的配置文件中，如果未指定，则保存到 <code>default</code> 中。有关可选探测参数的详细信息，请参阅 PROBE 命令。如果指定了 METHOD=manual，则将激活手动探测工具 - 有关此工具处于活动状态时可用的其他命令的详细信息，请参阅上面的 MANUAL_PROBE 命令。可选的 <code>HORIZONTAL_MOVE_Z</code> 值将覆盖配置文件中指定的 <code>horizontal_move_z</code> 选项。如果指定了 ADAPTIVE=1，则将使用正在打印的 Gcode 文件定义的对象来定义探测区域。可选的 <code>ADAPTIVE_MARGIN</code> 值将覆盖配置文件中指定的 <code>adaptive_margin</code> 选项。</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>：该命令将当前探测到的 Z 值和当前网格的值输出到终端。如果指定 PGP=1，则将bed_mesh产生的X、Y坐标，以及它们关联的指数，输出到终端。</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>使用<a href="Config_Reference.html#dual_carriage">dual_carriage 配置分段</a>时，以下命令可用：</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=<state_name>]</code>：保存当前的g-code坐标解析状态。保存和恢复g-code状态在脚本和宏中很有用。该命令保存当前g-code绝对坐标模式（G90/G91）绝对挤出模式（M82/M83）原点（G92）偏移量（SET_GCODE_OFFSET）速度覆盖（M220）挤出机覆盖（M221）移动速度。当前XYZ位置和相对挤出机 "E "位置。如果提供NAME，它可以将保存的状态命名为给定的字符串。如果没有提供NAME，则默认为 "default"</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=<state_name>] [MOVE=1 [MOVE_SPEED=<speed>]]</code>：恢复之前通过 SAVE_GCODE_STATE 保存的状态。如果指定“MOVE=1”，则将发出刀头移动以返回到先前的 XYZ 位置。如果指定了“MOVE_SPEED”，则刀头移动将以给定的速度（以mm/s为单位）执行；否则工具头移动将使用恢复的G-Code速度。</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>The following commands are available when the <a href="Config_Reference.html#tsl1401cl_filament_width_sensor">tsl1401cl filament width sensor config section</a> or <a href="Config_Reference.html#hall_filament_width_sensor">hall filament width sensor config section</a> is enabled (also see <a href="TSL1401CL_Filament_Width_Sensor.html">TSLl401CL Filament Width Sensor</a> and <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>The manual_probe module is automatically loaded.</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>当<a href="Config_Reference.html#manual_stepper">manual_stepper 配置分段</a>被启用时，以下命令可用。</p>
|
||||
<h4 id="manual_stepper_1">MANUAL_STEPPER<a class="headerlink" href="#manual_stepper_1" title="Permanent link">¶</a></h4>
|
||||
<p><code>MANUAL_STEPPER STEPPER=config_name [ENABLE=[0|1]] [SET_POSITION=<pos>] [SPEED=<speed>] [ACCEL=<accel>] [MOVE=<pos> [STOP_ON_ENDSTOP=[1|2|-1|-2]] [SYNC=0]]</code>：该命令将改变步进器的状态。使用ENABLE参数来启用/禁用步进。使用SET_POSITION参数，迫使步进认为它处于给定的位置。使用MOVE参数，要求移动到给定位置。如果指定了SPEED或者ACCEL，那么将使用给定的值而不是配置文件中指定的默认值。如果指定ACCEL为0，那么将不执行加速。如果STOP_ON_ENDSTOP=1被指定，那么如果止动器报告被触发，动作将提前结束（使用STOP_ON_ENDSTOP=2来完成动作，即使止动器没有被触发也不会出错，使用-1或-2来在止动器报告没有被触发时停止）。通常情况下，未来的G-Code命令将被安排在步进运动完成后运行，但是如果手动步进运动使用SYNC=0，那么未来的G-Code运动命令可能与步进运动平行运行。</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>The following command is available when a <a href="Config_Reference.html#mcp4018">mcp4018 config section</a> is enabled.</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>通常，每台打印机都有自己独特的串行端口名称。此唯一名称将在刷新微控制器时使用。上面的输出中可能有多行 - 如果是这样，请选择与微控制器相对应的行。如果列出了许多项目并且选择不明确，请拔下电路板并再次运行命令，缺少的项目将是您的打印板（有关更多信息，请参阅 <a href="FAQ.html#wheres-my-serial-port">FAQ</a>）。</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>对于使用 Atmega 芯片的常见微控制器，例如 2560，代码可以使用类似以下内容进行烧录：</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><code>manual_probe</code> 对象中提供了以下信息：</p>
|
||||
<ul>
|
||||
@@ -2402,6 +2424,10 @@
|
||||
<li><code>Carty_0</code>：表示0的车厢模式。可能的值为：“非活动”和“主要”。</li>
|
||||
<li><code>Carrance_1</code>：马车1的模式，可选值为：Inactive、PRIMARY、COPY、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><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
zh/sitemap.xml
112
zh/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