Deploying to gh-pages from @ Klipper3d/klipper@9323a5dfe2 🚀
This commit is contained in:
KevinOConnor
Binary file not shown.
@@ -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>Le champ "en-tête" dans la réponse initiale à la requête est utilisé pour décrire les champs présents dans les réponses "données" ultérieures.</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>Ce point final est similaire à l'exécution de la commande G-Code "PRINT_CANCEL". Par exemple : <code>{"id": 123, "method": "pause_resume/cancel"}</code></p>
|
||||
<p>Comme pour le point de terminaison "gcode/script", ce point de terminaison ne se termine qu'après la fin de toutes les commandes G-Code en attente.</p>
|
||||
|
||||
@@ -2083,7 +2083,7 @@ scan_overshoot: 8
|
||||
<h3 id="calibration">Calibration<a class="headerlink" href="#calibration" 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>Lance la procédure de palpage de l'étalonnage du maillage du lit.</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>Tout autre profil enregistré peut être supprimé de la même manière, en remplaçant <em>default</em> par le nom du profil que vous souhaitez supprimer.</p>
|
||||
<h4 id="chargement-du-profil-par-defaut">Chargement du profil par défaut<a class="headerlink" href="#chargement-du-profil-par-defaut" title="Permanent link">¶</a></h4>
|
||||
<p>Les versions précédentes de <code>bed_mesh</code> chargeaient toujours le profil nommé <em>default</em> au démarrage s'il était présent. Ce comportement a été supprimé afin de permettre à l'utilisateur de déterminer quand un profil est chargé. Si un utilisateur souhaite charger le profil par défaut, il est recommandé d'ajouter <code>BED_MESH_PROFILE LOAD=default</code> à sa macro <code>START_PRINT</code> ou à la configuration "Start G-Code" de son trancheur, selon ce qui est applicable.</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>Alternativement, l'ancien comportement de chargement d'un profil au démarrage peut être restauré avec 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 @@
|
||||
Test du taux de pas sur 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 @@
|
||||
Test du taux de pas sur 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 moteur pas à pas</td>
|
||||
<td>47</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>3 moteurs pas à pas</td>
|
||||
<td>208</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h3 id="test-du-taux-de-pas-sur-lpc176x">Test du taux de pas sur LPC176x<a class="headerlink" href="#test-du-taux-de-pas-sur-lpc176x" title="Permanent link">¶</a></h3>
|
||||
<p>La séquence de configuration suivante est utilisée sur le 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="test-du-taux-de-pas-pour-le-mcu-linux">Test du taux de pas pour le MCU Linux<a class="headerlink" href="#test-du-taux-de-pas-pour-le-mcu-linux" title="Permanent link">¶</a></h3>
|
||||
<p>La séquence de configuration suivante est utilisée sur 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>Une fois le test terminé, déterminez la différence entre les horloges signalées dans les deux messages de réponse "uptime". Le nombre total de commandes par seconde est alors <code>100000 * mcu_frequency / clock_diff</code>.</p>
|
||||
<p>Notez que ce test peut saturer la capacité USB/CPU d'un Raspberry Pi. En cas d'exécution sur un Raspberry Pi, Beaglebone ou un ordinateur hôte similaire, augmentez le délai (par exemple, <code>DELAY {clock + 20*freq} get_uptime</code>). Le cas échéant, les tests de performances ci-dessous concernent console.py exécuté sur une machine de bureau avec l'appareil connecté via un concentrateur à haut débit.</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>Le « pont mcu » n'est pas en fait sur le bus CAN. Les messages entrant et sortant du bridge mcu ne seront pas vus par les autres adaptateurs présents sur le bus CAN.</li>
|
||||
<li>
|
||||
<p>La bande passante disponible pour tous les appareils du bus CAN (et du bridge mcu) est limitée par la fréquence de bus CAN. Par conséquent, il est recommandé d'utiliser une fréquence de bus CAN de 1000000 lors de l'utilisation du mode "USB to CAN bus bridge".</p>
|
||||
<p>Même à une fréquence de bus CAN de 1000000, il peut ne pas y avoir assez de bande passante pour exécuter un test <code>SHAPER_CALIBRATE</code> si les deux steppers XY et l'accéléromètre communiquent tous par une seule interface "USB to CAN bus".</p>
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>La bande passante disponible pour tous les appareils du bus CAN (et du bridge mcu) est limitée par la fréquence de bus CAN. Par conséquent, il est recommandé d'utiliser une fréquence de bus CAN de 1000000 lors de l'utilisation du mode "USB to CAN bus bridge".</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>Une carte de pont USB à CAN n'apparaîtra pas en tant que périphérique série USB, elle ne s'affichera pas lors de l'execution de la commande <code>ls /dev/serial/by-id</code>, et elle ne peut pas être configurée dans le fichier Klipper avec un paramètre <code>serial:</code>. La carte pont apparaît comme un « adaptateur CAN USB » et est configuré dans le printer.cfg en tant que <a href="#configuring-klipper">Nœud CAN</a>.</li>
|
||||
</ul>
|
||||
|
||||
@@ -1577,6 +1577,7 @@
|
||||
</ul>
|
||||
</li>
|
||||
<li>S'il y a une erreur dans la configuration de l'utilisateur, assurez-vous de la signaler pendant les phases <code>load_config()</code> ou "connect event". Utilisez soit <code>raise config.error("mon erreur")</code> soit <code>raise printer.config_error("mon erreur")</code> pour signaler l'erreur.</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>Utilisez le module "pins" pour configurer une broche sur un micro-contrôleur. Ceci est typiquement fait avec quelque chose de similaire à <code>printer.lookup_object("pins").setup_pin("pwm", config.get("my_pin"))</code>. L'objet retourné peut alors être commandé au moment de l'exécution.</li>
|
||||
<li>Si l'objet imprimante définit une méthode <code>get_status()</code>, le module peut exporter des <a href="Status_Reference.html">informations d'état</a> via des <a href="Command_Templates.html">macros</a> et via le <a href="API_Server.html">serveur API</a>. La méthode <code>get_status()</code> doit retourner un dictionnaire Python dont les clés sont des chaînes de caractères et les valeurs des entiers, des flottants, des chaînes de caractères, des listes, des dictionnaires, True, False ou None. Les tuples (et les tuples nommés) peuvent également être utilisés (ils apparaissent comme des listes lorsqu'on y accède via le serveur API). Les listes et les dictionnaires exportés doivent être traités comme "immuables" - si leur contenu change, un nouvel objet doit être renvoyé par <code>get_status()</code>, sinon le serveur API ne détectera pas ces changements.</li>
|
||||
<li>Si le module doit accéder à la temporisation du système ou à des descripteurs de fichiers externes, utilisez <code>printer.get_reactor()</code> pour obtenir l'accès à la classe globale "event reactor". Cette classe de réacteur permet de programmer des temporisations, d'attendre des entrées sur des descripteurs de fichiers, et d'"endormir" le code hôte.</li>
|
||||
|
||||
@@ -657,6 +657,13 @@
|
||||
Cinématique du treuil à câble
|
||||
</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 @@
|
||||
Cinématique du treuil à câble
|
||||
</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>
|
||||
@@ -4027,8 +4055,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.
|
||||
@@ -4536,6 +4565,123 @@ anchor_z:
|
||||
# Ces paramètres doivent être fournis.
|
||||
</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="aucune-cinematique">Aucune cinématique<a class="headerlink" href="#aucune-cinematique" title="Permanent link">¶</a></h3>
|
||||
<p>Il est possible de définir une cinématique particulière "aucune (none)" pour désactiver le support cinématique dans Klipper. Cela peut être utile pour contrôler des périphériques qui ne sont pas des imprimantes 3D typiques ou encore à des fins de débogage.</p>
|
||||
<div class="highlight"><pre><span></span><code>[printer]
|
||||
@@ -5752,9 +5898,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>En outre, on pourrait utiliser les commandes "SET_DUAL_CARRIAGE CARRIAGE=1 MODE=COPY" ou "SET_DUAL_CARRIAGE CARRIAGE=1 MODE=MIRROR" pour activer le mode copie ou miroir du double chariot, auquel cas il suivra le mouvement du chariot 0 en conséquence. Ces commandes peuvent être utilisées pour imprimer deux pièces simultanément - soit deux pièces identiques (en mode COPY) ou des pièces miroirs (en mode MIRROR). Notez que les modes COPY et MIRROR nécessitent également la configuration appropriée de l'extrudeur sur le double chariot, qui peut généralement être atteint avec "SYNC_EXTRUDER_MOTION MOTION_QUEUE=extruder EXTRUDER=exedual_carriage_extruderю" ou une commande similaire.</p>
|
||||
<p>Voir <a href="https://github.com/Klipper3d/klipper/blob/master/config/sample-idex.cfg">sample-idex.cfg</a> pour un exemple de configuration.</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
|
||||
@@ -5766,7 +5912,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:
|
||||
@@ -5780,6 +5926,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>Support pour des moteurs supplémentaires synchronisés avec le mouvement d'une extrudeuse (on peut définir un nombre quelconque de sections avec un préfixe "extruder_stepper").</p>
|
||||
<p>Voir la <a href="G-Codes.html#extruder">référence des commandes</a> pour plus d'informations.</p>
|
||||
@@ -5800,25 +6005,32 @@ extruder:
|
||||
<h3 id="manual_stepper">[manual_stepper]<a class="headerlink" href="#manual_stepper" title="Permanent link">¶</a></h3>
|
||||
<p>Pilotes de moteur manuels (on peut définir un nombre quelconque de sections avec le préfixe "manual_stepper"). Ce sont des pilotes de moteur contrôlés par la commande g-code MANUAL_STEPPER. Par exemple "MANUAL_STEPPER STEPPER=my_stepper MOVE=10 SPEED=5". Voir le fichier <a href="G-Codes.html#manual_stepper">G-Codes</a> pour une description de la commande MANUAL_STEPPER. Les pilotes de moteur ne sont pas connectés à la cinématique normale de l'imprimante.</p>
|
||||
<div class="highlight"><pre><span></span><code>[manual_stepper my_stepper]
|
||||
#step_pin :
|
||||
#dir_pin :
|
||||
#enable_pin :
|
||||
#microsteps :
|
||||
#rotation_distance :
|
||||
# Voir la section "stepper" pour une description de ces paramètres.
|
||||
#velocity :
|
||||
# Définit la vitesse par défaut (en mm/s) pour le pilote moteur. Cette valeur
|
||||
# sera utilisée si une commande MANUAL_STEPPER ne spécifie pas de paramètre SPEED
|
||||
# La valeur par défaut est 5mm/s.
|
||||
#accel
|
||||
# Définit l'accélération par défaut (en mm/s^2) pour le pilote moteur Une
|
||||
# accélération de zéro n'entraînera aucune accélération. Cette valeur
|
||||
# sera utilisée si une commande MANUAL_STEPPER ne spécifie pas de
|
||||
# paramètre ACCEL. La valeur par défaut est zéro.
|
||||
#endstop_pin :
|
||||
# Broche de détection de l'interrupteur de fin de course. Si elle est spécifiée, on peut effectuer
|
||||
# des "mouvements de retour à l'origine" en ajoutant un paramètre STOP_ON_ENDSTOP aux
|
||||
# commandes de mouvement MANUAL_STEPPER.
|
||||
#step_pin:
|
||||
#dir_pin:
|
||||
#enable_pin:
|
||||
#microsteps:
|
||||
#rotation_distance:
|
||||
# See the "stepper" section for a description of these parameters.
|
||||
#velocity:
|
||||
# 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:
|
||||
# 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:
|
||||
# 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="elements-chauffants-et-capteurs-personnalises">Éléments chauffants et capteurs personnalisés<a class="headerlink" href="#elements-chauffants-et-capteurs-personnalises" title="Permanent link">¶</a></h2>
|
||||
@@ -7977,6 +8189,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="support-materiel-specifique-a-une-carte">Support matériel spécifique à une carte<a class="headerlink" href="#support-materiel-specifique-a-une-carte" title="Permanent link">¶</a></h2>
|
||||
<h3 id="sx1509">[sx1509]<a class="headerlink" href="#sx1509" title="Permanent link">¶</a></h3>
|
||||
<p>Configuration d'un expandeur SX1509 I2C vers GPIO. En raison du délai encouru par la communication I2C, vous ne devez PAS utiliser les broches du SX1509 comme activation du moteur pas à pas, pas ou direction ou toute autre broche nécessitant un changement de bit rapide. Il est préférable de les utiliser comme sorties numériques statiques ou contrôlées par gcode ou comme broches hardware-pwm pour des ventilateurs par exemple. On peut définir un nombre quelconque de sections avec un préfixe "sx1509". Chaque expandeur fournit un ensemble de 16 broches (sx1509_my_sx1509:PIN_0 à sx1509_my_sx1509:PIN_15) pouvant être utilisées dans la configuration de l'imprimante.</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
fr/G-Codes.html
117
fr/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>Les commandes suivantes sont disponibles lorsque la section <a href="Config_Reference.html#bed_mesh">configuration de bed_mesh</a> est activée (voir également le <a href="Bed_Mesh.html">guide de bed_mesh</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> : Cette commande écrit les valeurs z palpées actuelles et les valeurs de maillage actuelles sur le terminal. Si PGP=1 est spécifié, les coordonnées X, Y générées par bed_mesh, ainsi que leurs indices associés, seront envoyés au terminal.</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>La commande suivante est disponible lorsque la section <a href="Config_Reference.html#dual_carriage">config dual_carriage</a> est activée.</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=<nom_de_l'état>]</code> : Sauvegarde l'état actuel de l'analyse des coordonnées du g-code. La sauvegarde et le rétablissement de l'état du g-code sont utiles dans les scripts et les macros. Cette commande enregistre le mode actuel de coordonnées absolues en g-code (G90/G91), le mode d'extrusion absolue (M82/M83), l'origine (G92), le décalage (SET_GCODE_OFFSET), la priorité de vitesse (M220), la priorité d'extrusion (M221), la vitesse de déplacement, la position XYZ actuelle et la position relative de l'extrudeuse "E". Si NOM est fourni, cela permet de nommer l'état sauvegardé avec la chaîne de caractères donnée. Si le NOM n'est pas fourni, la valeur par défaut est "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=<nom_de_l'état>] [MOVE=1 [MOVE_SPEED=<speed>]]</code> : Restaure un état précédemment sauvegardé via SAVE_GCODE_STATE. Si "MOVE=1" est spécifié, un déplacement de la tête d'outil sera effectué pour revenir à la position XYZ précédente. Si "MOVE_SPEED" est spécifié, alors le déplacement de la tête d'outil sera effectué avec la vitesse donnée (en mm/s) ; sinon, le déplacement de la tête d'outil utilisera la vitesse du G-Code restauré.</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>Les commandes suivantes sont disponibles lorsque la section de configuration <a href="Config_Reference.html#tsl1401cl_filament_width_sensor">tsl1401cl filament width sensor</a> ou <a href="Config_Reference. md#hall_filament_width_sensor">hall filament width sensor</a> est activée (voir également <a href="TSL1401CL_Filament_Width_Sensor.html">TSLl401CL Filament Width Sensor</a> et <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>Le module manual_probe est automatiquement chargé.</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>La commande suivante est disponible lorsqu'une section <a href="Config_Reference.html#manual_stepper">manual_stepper config</a> est activée.</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=nom_du_config [ENABLE=[0|1]]] [SET_POSITION=<pos>] [SPEED=<speed>] [ACCEL=<accel>] [MOVE=<pos> [STOP_ON_ENDSTOP=[1|2|-1|-2]] [SYNC=0]]</code> : Cette commande modifie l'état du stepper. Utilisez le paramètre ENABLE pour activer/désactiver le stepper. Utilisez le paramètre SET_POSITION pour forcer le moteur pas à pas à penser qu'il se trouve à la position donnée. Utilisez le paramètre MOVE pour déplacer vers la position donnée. Si SPEED et/ou ACCEL sont spécifiés, les valeurs données seront utilisées à la place de celles par défaut issues du fichier de configuration. Si un ACCEL de zéro est spécifié, aucune accélération ne sera effectuée. Si STOP_ON_ENDSTOP=1 est spécifié, le déplacement se terminera prématurément si la fin de course est déclenchée (utilisez STOP_ON_ENDSTOP=2 pour terminer le déplacement sans erreur même si la fin de course n'est pas déclenchée, utilisez -1 ou -2 pour s'arrêter lorsque la fin de course n'est pas déclenchée). Normalement, les futures commandes G-Code seront programmées pour être exécutées après la fin du déplacement de la commande de pas, mais si un déplacement manuel de la commande de pas utilise SYNC=0, les futures commandes de déplacement G-Code peuvent être exécutées en parallèle avec le déplacement de la commande de pas.</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>La commande suivante est disponible lorsqu'une section <a href="Config_Reference.html#mcp4018">mcp4018 config</a> est activée.</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>Les informations suivantes sont disponibles dans l'objet <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>Les informations suivantes sont disponibles dans l'objet <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
fr/sitemap.xml
112
fr/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.
@@ -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>A kezdeti lekérdezési válasz "header" mezője a későbbi "data" válaszokban található mezők leírására szolgál.</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>Ez a végpont hasonló a "PRINT_CANCEL" G-kód parancs futtatásához. Például: <code>{"id": }</code></p>
|
||||
<p>A "gcode/script" végponthoz hasonlóan ez a végpont is csak a függőben lévő G-kód parancsok befejezése után fejeződik be.</p>
|
||||
|
||||
@@ -2083,7 +2083,7 @@ scan_overshoot: 8
|
||||
<h3 id="kalibracio">Kalibráció<a class="headerlink" href="#kalibracio" 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>Alapértelmezett profil: alapértelmezett</em> <em>Alapértelmezett módszer: automatikus, ha szondát észlel, egyébként manuális</em> <em>Alapértelmezett adaptív: 0</em> <em>Alapértelmezett adaptív margó: 0</em></p>
|
||||
<p>Mérési eljárást indítása a tárgyasztal háló kalibrálásához.</p>
|
||||
<p>A háló a <code>PROFILE</code> paraméter által megadott profilba lesz mentve, vagy a <code>default</code>, ha nincs megadva. A <code>METHOD</code> paraméter a következő értékek egyikét veszi fel:</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>: lehetővé teszi a kézi mérést a fúvókával és a papírlappal</li>
|
||||
<li><code>METHOD=automatic</code>: Automatikus (szabvány) mérés. Ez az alapértelmezett.</li>
|
||||
@@ -2123,6 +2123,7 @@ scan_overshoot: 8
|
||||
<p>Bármely más elmentett profil ugyanígy eltávolítható, a <em>default</em> helyettesítve az eltávolítani kívánt névvel.</p>
|
||||
<h4 id="az-alapertelmezett-profil-betoltese">Az alapértelmezett profil betöltése<a class="headerlink" href="#az-alapertelmezett-profil-betoltese" title="Permanent link">¶</a></h4>
|
||||
<p>A <code>bed_mesh</code> korábbi verziói indításkor mindig betöltötték az <em>alapértelmezett</em> nevű profilt, ha az jelen volt. Ezt a viselkedést megszüntettük annak érdekében, hogy a felhasználó határozhassa meg, mikor töltődik be egy profil. Ha a felhasználó az <code>alapértelmezett</code> profilt kívánja betölteni, ajánlott a <code>BED_MESH_PROFILE LOAD=default</code> hozzáadása a <code>START_PRINT</code> makróhoz vagy a szeletelő "Start G-Code" konfigurációjához, attól függően, hogy melyik alkalmazandó.</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>Alternatívaként a <code>[delayed_gcode]</code> segítségével visszaállítható a profil indításkor történő betöltésének régi viselkedése:</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 lépésszám referencia
|
||||
</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 lépésszám referencia
|
||||
</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>trükkök</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>1 léptető</td>
|
||||
<td>47</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>3 léptető</td>
|
||||
<td>208</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h3 id="lpc176x-lepesszam-referencia">LPC176x lépésszám referencia<a class="headerlink" href="#lpc176x-lepesszam-referencia" title="Permanent link">¶</a></h3>
|
||||
<p>Az LPC176x esetében a következő konfigurációs sorrendet használjuk:</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-lepesszam-referencia">Linux MCU lépésszám referencia<a class="headerlink" href="#linux-mcu-lepesszam-referencia" title="Permanent link">¶</a></h3>
|
||||
<p>A következő konfigurációs sorrendet egy Raspberry Pi esetében használjuk:</p>
|
||||
<div class="highlight"><pre><span></span><code>allocate_oids count=3
|
||||
@@ -2289,7 +2331,8 @@ get_uptime
|
||||
</code></pre></div>
|
||||
|
||||
<p>A teszt befejezésekor határozd meg a két "üzemidő" válaszüzenetben jelentett órák közötti különbséget. A másodpercenkénti parancsok teljes száma ekkor <code>100000 * mcu_frequency / clock_diff</code>.</p>
|
||||
<p>Vedd figyelembe, hogy ez a teszt telítheti a Raspberry Pi USB/CPU kapacitását. Ha Raspberry Pi, Beaglebone vagy hasonló gazdagépen fut, akkor növeld a késleltetést (pl. <code>DELAY {clock + 20*freq} get_uptime</code>). Ahol alkalmazható, az alábbi referenciák a console.py futtatásával készültek egy asztali számítógépen, ahol az eszköz egy nagy sebességű HUB-on keresztül van csatlakoztatva.</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>A "bridge mcu" valójában nem a CAN-buszon van. A híd mcu-nak küldött és onnan érkező üzeneteket a CAN-buszon lévő más adapterek nem látják.</li>
|
||||
<li>
|
||||
<p>A rendelkezésre álló sávszélességet mind a "híd mcu", mind a CAN-buszon lévő összes eszköz számára a CAN-busz frekvenciája korlátozza. Ennek eredményeképpen az "USB és CAN-busz közötti híd üzemmód" használatakor ajánlott 1000000-es CAN-busz frekvenciát használni.</p>
|
||||
<p>Még 1000000-es CAN-busz frekvencia esetén sem biztos, hogy elegendő sávszélesség áll rendelkezésre a <code>SHAPER_CALIBRATE</code> teszt futtatásához, ha mind az XY-léptetők, mind a gyorsulásmérő egyetlen "USB és CAN-busz" interfészen keresztül kommunikálnak.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>A rendelkezésre álló sávszélességet mind a "híd mcu", mind a CAN-buszon lévő összes eszköz számára a CAN-busz frekvenciája korlátozza. Ennek eredményeképpen az "USB és CAN-busz közötti híd üzemmód" használatakor ajánlott 1000000-es CAN-busz frekvenciát használni.</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>Az USB-CAN hídlap nem jelenik meg USB soros eszközként, nem jelenik meg az <code>ls /dev/serial/by-id</code> futtatásakor, és nem konfigurálható a Klipper printer.cfg fájljában a <code>serial:</code> paraméterrel. A hídlap "USB CAN adapter"-ként jelenik meg, és a printer.cfg fájlban <a href="#configuring-klipper">CAN node-ként</a> van konfigurálva .</li>
|
||||
</ul>
|
||||
|
||||
@@ -1577,6 +1577,7 @@
|
||||
</ul>
|
||||
</li>
|
||||
<li>Ha hiba van a felhasználó konfigurációjában, mindenképpen hívd fel a figyelmet a <code>load_config()</code> vagy a "connect event" fázisokban. Használd a <code>raise config.error("my error")</code> vagy <code>raise printer.config_error("my error")</code> hibajelzést.</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>A "pins" modul segítségével konfigurálhatsz egy tűt a mikrokontrollerben. Ez általában a <code>printer.lookup_object("pins").setup_pin("pwm", config.get("my_pin"))</code>-hoz hasonló módon történik. A visszakapott objektumot ezután futásidőben lehet utasítani.</li>
|
||||
<li>Ha a nyomtató objektum definiál egy <code>get_status()</code> metódust, akkor a modul <a href="Status_Reference.html">állapotinformációt</a> exportálhat a <a href="Command_Templates.html">makrókon</a> és az <a href="API_Server.html">API Szerveren</a> keresztül. A <code>get_status()</code> metódusnak egy Python szótárat kell visszaadnia, amelynek kulcsai karakterláncok, értékei pedig egész számok, lebegő számok, karakterláncok, listák, szótárak, True, False vagy None. Használhatók tuplik (és nevesített tuplik) is (ezek az API-kiszolgálón keresztül történő eléréskor listaként jelennek meg). Az exportált "immutable" listákat és szótárakat. Ha tartalmuk megváltozik, akkor egy új objektumot kell visszaküldeni a <code>get_status()</code> parancsból, különben az API-kiszolgáló nem fogja észlelni a változásokat.</li>
|
||||
<li>Ha a modulnak hozzáférésre van szüksége a rendszer időzítéséhez vagy külső fájlleírókhoz, akkor a <code>printer.get_reactor()</code> segítségével hozzáférhetünk a globális "event reactor" osztályhoz. Ez a reactor osztály lehetővé teszi az időzítők ütemezését, a fájlleírók bemenetének várakozását, valamint a gazdakód "sleep" használatát.</li>
|
||||
|
||||
@@ -657,6 +657,13 @@
|
||||
Kábelcsörlős Kinematika
|
||||
</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 @@
|
||||
Kábelcsörlős Kinematika
|
||||
</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,49 +4057,50 @@ serial:
|
||||
<p>A nyomtató szakasz a nyomtató magas szintű beállításait vezérli.</p>
|
||||
<div class="highlight"><pre><span></span><code>[printer]
|
||||
kinematics:
|
||||
# A használt nyomtató típusa. Ez a lehetőség a következők egyike lehet: derékszögű,
|
||||
# corexy, corexz, hibrid_corexy, hibrid_corexz, rotary_delta, delta,
|
||||
# deltézi, sarki, csörlős vagy egyik sem. Ezt a paramétert meg kell adni.
|
||||
# The type of printer in use. This option may be one of: cartesian,
|
||||
# corexy, corexz, hybrid_corexy, hybrid_corexz, generic_cartesian,
|
||||
# rotary_delta, delta, deltesian, polar, winch, or none.
|
||||
# This parameter must be specified.
|
||||
max_velocity:
|
||||
# A nyomtatófej maximális sebessége (mm/s-ban) (a
|
||||
# nyomtatás alatt). Ezt a paramétert meg kell adni.
|
||||
# Maximum velocity (in mm/s) of the toolhead (relative to the
|
||||
# print). This parameter must be specified.
|
||||
max_accel:
|
||||
# A nyomtatófej maximális gyorsulása (mm/s^2-ben) (a
|
||||
# nyomtatás alatt). Bár ez a paraméter "maximális"
|
||||
# gyorsulás, a gyakorlatban a legtöbb mozdulat, amely gyorsul vagy lassul
|
||||
# ezt az itt megadott sebességgel teszi meg. Az itt megadott érték
|
||||
# futás közben módosítható a SET_VELOCITY_LIMIT paranccsal.
|
||||
# Ezt a paramétert meg kell adni.
|
||||
#minimum_cruise_ratio: 0,5
|
||||
# A legtöbb mozdulat utazósebességre gyorsul, ezt használja az
|
||||
# utazósebesség, majd lassul. Néhányan azonban ezt használják
|
||||
# rövid távolságok megtételére részben felgyorsulhat, majd
|
||||
# azonnal lelassulhat. Ez az opció csökkenti a fej végsebességét
|
||||
# mozdulatoknál, hogy mindig legyen egy minimális megtett távolság a pontok
|
||||
# közt utazósebességen. Vagyis egy minimális megtett távolságot érvényesít
|
||||
# utazósebességgel a teljes megtett távolsághoz képest. Ennek
|
||||
# célja a rövid cikk-cakk mozgások végsebességének csökkentése (és így
|
||||
# csökkenti a nyomtató rezgését ezekből a lépésekből). Például a
|
||||
# A 0,5-ös minimum_cruise_ratio biztosítaná, hogy egy önálló 1,5 mm-es
|
||||
# mozdulat minimális utazótávolsága 0,75 mm. Add meg a
|
||||
# 0,0 arány a funkció letiltásához (nem lenne minimum
|
||||
# a gyorsítás és a lassítás között érvényesített utazótávolság).
|
||||
# Az itt megadott érték futás közben módosítható a
|
||||
# SET_VELOCITY_LIMIT paranccsal. Az alapértelmezett érték 0,5.
|
||||
# Maximum acceleration (in mm/s^2) of the toolhead (relative to the
|
||||
# print). Although this parameter is described as a "maximum"
|
||||
# acceleration, in practice most moves that accelerate or decelerate
|
||||
# will do so at the rate specified here. The value specified here
|
||||
# may be changed at runtime using the SET_VELOCITY_LIMIT command.
|
||||
# This parameter must be specified.
|
||||
#minimum_cruise_ratio: 0.5
|
||||
# Most moves will accelerate to a cruising speed, travel at that
|
||||
# cruising speed, and then decelerate. However, some moves that
|
||||
# travel a short distance could nominally accelerate and then
|
||||
# immediately decelerate. This option reduces the top speed of these
|
||||
# moves to ensure there is always a minimum distance traveled at a
|
||||
# cruising speed. That is, it enforces a minimum distance traveled
|
||||
# at cruising speed relative to the total distance traveled. It is
|
||||
# intended to reduce the top speed of short zigzag moves (and thus
|
||||
# reduce printer vibration from these moves). For example, a
|
||||
# minimum_cruise_ratio of 0.5 would ensure that a standalone 1.5mm
|
||||
# move would have a minimum cruising distance of 0.75mm. Specify a
|
||||
# ratio of 0.0 to disable this feature (there would be no minimum
|
||||
# cruising distance enforced between acceleration and deceleration).
|
||||
# The value specified here may be changed at runtime using the
|
||||
# SET_VELOCITY_LIMIT command. The default is 0.5.
|
||||
#square_corner_velocity: 5.0
|
||||
# Az a maximális sebesség (mm/s-ban), amellyel a nyomtatófej megközelíthet egy 90
|
||||
# fokos sarkot. A nullától eltérő érték csökkentheti az extruder változásait
|
||||
# áramlási sebességet azáltal, hogy lehetővé teszi a pillanatnyi sebességváltozást
|
||||
# a nyomtatófej kanyarodása közben. Ez az érték konfigurálja a belső
|
||||
# centripetális sebességű kanyarodási algoritmust; sarkokban a szögek
|
||||
# 90 foknál nagyobb kanyarsebessége nagyobb lesz
|
||||
# 90 foknál kisebb szögű sarok esetében kevesebb lesz a
|
||||
# kanyarsebesség. Ha ez nullára van állítva, akkor a nyomtatófej
|
||||
# minden sarkon lassít nullára. Az itt megadott értéket lehet
|
||||
# futás közben módosítani a SET_VELOCITY_LIMIT paranccsal. Az
|
||||
# alapértelmezett érték 5 mm/s.
|
||||
# The maximum velocity (in mm/s) that the toolhead may travel a 90
|
||||
# degree corner at. A non-zero value can reduce changes in extruder
|
||||
# flow rates by enabling instantaneous velocity changes of the
|
||||
# toolhead during cornering. This value configures the internal
|
||||
# centripetal velocity cornering algorithm; corners with angles
|
||||
# larger than 90 degrees will have a higher cornering velocity while
|
||||
# corners with angles less than 90 degrees will have a lower
|
||||
# cornering velocity. If this is set to zero then the toolhead will
|
||||
# decelerate to zero at each corner. The value specified here may be
|
||||
# changed at runtime using the SET_VELOCITY_LIMIT command. The
|
||||
# default is 5mm/s.
|
||||
#max_accel_to_decel:
|
||||
# Ez a paraméter elavult, ezért nem szabad többé használni.
|
||||
# This parameter is deprecated and should no longer be used.
|
||||
</code></pre></div>
|
||||
|
||||
<h3 id="stepper">[stepper]<a class="headerlink" href="#stepper" title="Permanent link">¶</a></h3>
|
||||
@@ -4549,6 +4578,123 @@ anchor_z:
|
||||
# Ezeket a paramétereket meg kell adni.
|
||||
</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="nincs-kinematika">Nincs Kinematika<a class="headerlink" href="#nincs-kinematika" title="Permanent link">¶</a></h3>
|
||||
<p>Lehetőség van egy speciális "none" kinematika definiálására a Klipper kinematikai támogatásának kikapcsolásához. Ez hasznos lehet olyan eszközök vezérléséhez, amelyek nem tipikus 3D nyomtatók, vagy hibakeresési célok.</p>
|
||||
<div class="highlight"><pre><span></span><code>[printer]
|
||||
@@ -5794,24 +5940,22 @@ calibrate_x: ...
|
||||
</code></pre></div>
|
||||
|
||||
<h3 id="dual_carriage">[dual_carriage]<a class="headerlink" href="#dual_carriage" title="Permanent link">¶</a></h3>
|
||||
<p>Támogatja a derékszögű és hibrid_corexy/z nyomtatókat, amelyek egy tengelyen vannak két kocsival. A kocsi mód a SET_DUAL_CARRIAGE kiterjesztett G-kód paranccsal állítható be. Például a "SET_DUAL_CARRIAGE CARRIAGE=1" parancs aktiválja az ebben a szakaszban meghatározott kocsit (CARRIAGE=0 visszaadja az aktiválást az elsődleges kocsinak). A kettős kocsi támogatását általában extra extruderekkel kombinálják – a SET_DUAL_CARRIAGE parancsot gyakran az ACTIVATE_EXTRUDER paranccsal egy időben hívják. Ügyelj arra, hogy a kocsikat leállítsd a deaktiválás alatt. Ne feledd, hogy a G28 parancs során általában először az elsődleges kocsit küldi kezdőpontra, majd ezt követi a <code>[dual_carriage]' konfigurációs részben meghatározott kocsi. Azonban a</code>[dual_carriage]<code>kocsi indul először kezdőpontra, ha mindkét kocsi pozitív irányba indul kezdőpontra, és a [dual_carriage] kocsi</code>position_endstop<code>nagyobb, mint az elsődleges kocsié, vagy ha mindkét kocsi kezdőpont felé negatív irányban, és a</code> A [dual_carriage]<code>kocsi</code>position_endstop` értéke kisebb, mint az elsődleges kocsié.</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>Ezenkívül használhatod a "SET_DUAL_CARRIAGE CARRIAGE=1 MODE=COPY" vagy a "SET_DUAL_CARRIAGE CARRIAGE=1 MODE=MIRROR" parancsokat a kettős kocsi másolási vagy tükrözési módjának aktiválásához, amely esetben a kocsi megfelelően követi a 0 kocsi mozgását. Ezekkel a parancsokkal egyszerre két rész nyomtatható – vagy két azonos rész (MÁSOLÁS módban), vagy tükrözött rész (MIRROR módban). Vedd figyelembe, hogy a MÁSOLÁS és a TÜKRÖZÉS módok az extruder megfelelő konfigurációját is megkövetelik a kettős kocsin, ami általában a "SYNC_EXTRUDER_MOTION MOTION_QUEUE=extruder EXTRUDER=<dual_carriage_extruder>" vagy hasonló paranccsal érhető el.</p>
|
||||
<p>Lásd a <a href="https://github.com/Klipper3d/klipper/blob/master/config/sample-idex.cfg">sample-idex.cfg</a> példakonfigurációt.</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:
|
||||
# Azon a tengelyen, amelyen ez az extra kocsi van (x vagy y).
|
||||
# Ezt a paramétert meg kell adni.
|
||||
# The axis this extra carriage is on (either x or y). This parameter
|
||||
# must be provided.
|
||||
#safe_distance:
|
||||
# A minimális távolság (mm-ben) a kettős és az elsődleges kocsi
|
||||
# között. Ha olyan G-kód parancsot hajtanak végre, amely közelebb
|
||||
# hozza a kocsikat a megadott határértékhez, az ilyen parancs
|
||||
# hibával elutasításra kerül. Ha a safe_distance nincs
|
||||
# megadva, a rendszer a position_min és a position_max alapján
|
||||
# lesz kikövetkeztetve a kettős és az elsődleges kocsik esetében.
|
||||
# Ha 0-ra van állítva (vagy a safe_distance nincs beállítva,
|
||||
# és a position_min és a position_max értéke megegyezik az
|
||||
# elsődleges és a kettős kocsinál), a kocsik közelségének
|
||||
# ellenőrzése le lesz tiltva.
|
||||
# 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.
|
||||
#step_pin:
|
||||
#dir_pin:
|
||||
#enable_pin:
|
||||
@@ -5821,9 +5965,68 @@ axis:
|
||||
#position_endstop:
|
||||
#position_min:
|
||||
#position_max:
|
||||
# A fenti paraméterek meghatározásához lásd a "léptető" részt.
|
||||
# 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>Az extruder mozgásához szinkronizált további léptetők támogatása (tetszőleges számú szakasz definiálható "extruder_stepper" előtaggal).</p>
|
||||
<p>További információkért lásd a <a href="G-Codes.html#extruder">parancshivatkozás</a> dokumentumot.</p>
|
||||
@@ -5848,20 +6051,27 @@ extruder:
|
||||
#enable_pin:
|
||||
#microsteps:
|
||||
#rotation_distance:
|
||||
# A paraméterek leírását lásd a "léptető" részben.
|
||||
# See the "stepper" section for a description of these parameters.
|
||||
#velocity:
|
||||
# Állítsd be a léptető alapértelmezett sebességét (mm/sec-ben).
|
||||
# Ezt az értéket használja a rendszer, ha a MANUAL_STEPPER parancs nem
|
||||
# ad meg SPEED paramétert. Az alapértelmezett érték 5 mm/sec.
|
||||
# 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:
|
||||
# Állítsd be a léptető alapértelmezett gyorsulását (mm/sec^2-en). A nulla
|
||||
# gyorsulás nem eredményez gyorsulást. Ezt az értéket használja a rendszer,
|
||||
# ha a MANUAL_STEPPER parancs nem ad meg ACCEL paramétert.
|
||||
# Az alapértelmezett érték 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:
|
||||
# Végálláskapcsoló csatlakozási tű. Ha meg van adva, akkor egy
|
||||
# STOP_ON_ENDSTOP paraméter hozzáadásával a MANUAL_STEPPER
|
||||
# mozgásparancsokhoz "kezdőpont felvételi mozgások" hajthatók végre.
|
||||
# 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="egyedi-futotestek-es-erzekelok">Egyedi fűtőtestek és érzékelők<a class="headerlink" href="#egyedi-futotestek-es-erzekelok" title="Permanent link">¶</a></h2>
|
||||
@@ -8058,6 +8268,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="alaplap-specifikus-hardvertamogatas">Alaplap specifikus hardvertámogatás<a class="headerlink" href="#alaplap-specifikus-hardvertamogatas" title="Permanent link">¶</a></h2>
|
||||
<h3 id="sx1509">[sx1509]<a class="headerlink" href="#sx1509" title="Permanent link">¶</a></h3>
|
||||
<p>Konfiguráljon egy SX1509 I2C-GPIO bővítőt. Az I2C-kommunikáció által okozott késleltetés miatt NEM szabad az SX1509 tűit motorvezérlő engedélyező, STEP vagy DIR tűként vagy bármilyen más olyan tűként használni, amely gyors bit-impulzust igényel. Legjobban statikus vagy G-kód vezérelt digitális kimenetekként vagy hardveres PWM tűként használhatók pl. ventilátorokhoz. Bármennyi szekciót definiálhatunk "sx1509" előtaggal. Minden egyes bővítő egy 16 tűből álló készletet biztosít (sx1509_my_sx1509:PIN_0-tól sx1509_my_sx1509:PIN_15-ig), amelyek a nyomtató konfigurációjában használhatók.</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
hu/G-Codes.html
117
hu/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>A következő parancsok akkor érhetők el, ha a <a href="Config_Reference.html#bed_mesh">bed_mesh konfigurációs szakasz</a> engedélyezve van (lásd még a <a href="Bed_Mesh.html">tárgyasztal háló útmutatót</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>: Ez a parancs a konfigban megadott paraméterek által generált pontok segítségével szondázza az ágyat. A szondázás után egy háló generálódik, és a Z elmozdulás a hálónak megfelelően kerül beállításra. A háló a <code>PROFILE</code> paraméter által megadott profilba kerül elmentésre, vagy <code>default</code>, ha nincs megadva. Az opcionális szondázó paraméterek részletes leírását lásd a PROBE parancsban. Ha a METHOD=manual meg van adva, akkor a kézi tapintás eszköze aktiválódik - lásd a fenti MANUAL_PROBE parancsot az ezen eszköz aktív állapotában elérhető további parancsok részleteiért. Az opcionális <code>HORIZONTAL_MOVE_Z</code> érték felülírja a konfigurációs fájlban megadott <code>horizontal_move_z</code> opciót. Ha az ADAPTIVE=1 érték van megadva, akkor a nyomtatás alatt álló G-Kód fájl által meghatározott objektumok lesznek használva a vizsgált terület meghatározásához. Az opcionális <code>ADAPTIVE_MARGIN</code> érték felülírja a konfigurációs fájlban megadott <code>adaptive_margin</code> opciót.</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>: Ez a parancs az aktuális mért Z értékeket és az aktuális hálóértékeket adja ki a terminálra. A PGP=1 megadása esetén a bed_mesh által generált X, Y koordináták és a hozzájuk tartozó indexek kerülnek a terminálra.</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 következő parancs akkor érhető el, ha a <a href="Config_Reference.html#dual_carriage">dual_carriage konfigurációs szakasz</a> engedélyezve van.</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>: Ez a parancs megváltoztatja a megadott kocsi üzemmódját. Ha nincs megadva a <code>MODE</code>, akkor az alapértelmezett érték a <code>PRIMARY</code>. Az üzemmód <code>PRIMARY</code>-re állítása kikapcsolja a másik kocsit, és a megadott kocsi a következő G-kód parancsokat változatlanul végrehajtja. A <code>COPY</code> és a <code>MIRROR</code> üzemmódok csak a <code>CARRIAGE=1</code> esetén támogatottak. Ha az 1-es kocsi ezen üzemmódok valamelyikére van állítva, akkor az 1-es kocsi követi a 0 kocsi következő mozgásait, és vagy lemásolja annak relatív mozgásait (<code>COPY</code> üzemmódban), vagy ellenkező (tükör) irányban hajtja végre azokat (<code>MIRROR</code> üzemmódban).</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>: Mentsd el a kettős kocsik aktuális helyzetét és módjukat. A DUAL_CARRIAGE állapot mentése és visszaállítása hasznos lehet szkriptekben és makrókban, valamint a rutin felülírásainál. Ha meg van adva a NÉV, akkor lehetővé teszi a mentett állapot elnevezését az adott karakterlánchoz. Ha a NÉV nincs megadva, akkor az alapértelmezés szerint "alapértelmezett".</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>: Az aktuális G-kód koordináták elemzési állapotának mentése. A G-kód állapotának mentése és visszaállítása hasznos a szkriptekben és makrókban. Ez a parancs elmenti az aktuális G-kód abszolút koordinátamódot (G90/G91), az abszolút extrudálási módot (M82/M83), az origót (G92), az eltolást (SET_GCODE_OFFSET), a sebesség felülbírálását (M220), az extruder felülbírálását (M221), a mozgási sebességet, az aktuális XYZ pozíciót és a relatív extruder "E" pozíciót. A NAME megadása esetén lehetővé teszi, hogy a mentett állapotot a megadott karakterláncnak nevezzük el. Ha a NAME nincs megadva, az alapértelmezett érték "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>: A SAVE_GCODE_STATE segítségével korábban elmentett állapot visszaállítása. Ha "MOVE=1" van megadva, akkor a nyomtatófej mozgatása az előző XYZ-pozícióba való visszalépéshez történik. Ha "MOVE_SPEED" van megadva, akkor a nyomtatófej mozgatása a megadott sebességgel (mm/sec-ben) történik; egyébként a nyomtatófej mozgatása a visszaállított G-kód sebességét használja.</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>A következő parancsok akkor érhetők el, ha a <a href="Config_Reference.html#tsl1401cl_filament_width_sensor">tsl1401cl szálszélesség érzékelő konfigurációs szakasz</a> vagy a <a href="Config_Reference.html#hall_filament_width_sensor">hall szálszélesség érzékelő konfigurációs szakasz</a> engedélyezve van (lásd még <a href="TSL1401CL_Filament_Width_Sensor.html">TSLll401CL Szálszélesség érzékelő</a> és a <a href="Hall_Filament_Width_Sensor.html">Hall Szálszélesség érzékelő</a> dokumentumot):</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>A manual_probe modul automatikusan betöltődik.</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 következő parancs akkor érhető el, ha a <a href="Config_Reference.html#manual_stepper">manual_stepper konfigurációs szakasz</a> engedélyezve van.</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|2|-1|-2]] [SYNC=0]]]</code>: Ez a parancs megváltoztatja a léptető állapotát. Az ENABLE paraméterrel engedélyezheted/letilthatod a léptetőt. A SET_POSITION paraméterrel kényszerítheted a léptetőt arra, hogy azt higgye, az adott helyzetben van. A MOVE paraméterrel kezdeményezhetsz mozgást egy adott pozícióba. Ha a SPEED és/vagy az ACCEL paraméter meg van adva, akkor a rendszer a megadott értékeket használja a konfigurációs fájlban megadott alapértelmezett értékek helyett. Ha nulla ACCEL-t ad meg, akkor nem történik gyorsítás. Ha STOP_ON_ENDSTOP=1 van megadva, akkor a lépés korán véget ér. Ha a végálláskapcsoló aktiválódik (a STOP_ON_ENDSTOP=2 paranccsal hiba nélkül befejezheted a mozgást, még akkor is, ha a végálláskapcsoló nem aktiválódott. Használd a -1 vagy a -2 jelölést, hogy leálljon, amikor a végálláskapcsoló még nem aktiválódott). Normális esetben a későbbi G-kód parancsok a léptetőmozgás befejezése után kerülnek ütemezésre, azonban ha a kézi léptetőmozgás parancs a SYNC=0 értéket használja, akkor a későbbi G-kód mozgatási parancsok a léptetőmozgással párhuzamosan is futhatnak.</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>A következő parancs akkor érhető el, ha az <a href="Config_Reference.html#mcp4018">mcp4018 config szekció</a> engedélyezve van.</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>Gyakori, hogy minden nyomtatónak saját egyedi soros port neve van. Ez az egyedi név kerül felhasználásra a mikrokontroller égetésekor. Lehetséges, hogy a fenti kimeneten több sor is szerepel - ha igen, válaszd ki a mikrokontrollernek megfelelő sort. Ha több elem is szerepel a listában, és a választás nem egyértelmű, húzd ki a kártyát, és futtasd le újra a parancsot, a hiányzó elem a nyomtató alaplapod lesz(további információért lásd <a href="FAQ.html#wheres-my-serial-port">GYIK</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>Az Atmega chipeket használó általános mikrovezérlők, például a 2560-asok esetében a kódot a következő módon lehet égetni:</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>A következő információk a <code>manual_probe</code> objektumban találhatók:</p>
|
||||
<ul>
|
||||
@@ -2402,6 +2424,10 @@
|
||||
<li><code>carriage_0</code>: A kocsi 0. A lehetséges értékek a következők: "INACTIVE" és "PRIMARY".</li>
|
||||
<li><code>carriage_1</code>: A kocsi 1 üzemmódja. A lehetséges értékek a következők: "INACTIVE", "PRIMARY", "COPY" és "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 következő információk a <a href="Config_Reference.html#virtual_sdcard">virtual_sdcard</a> objektumban érhetők el:</p>
|
||||
<ul>
|
||||
|
||||
Binary file not shown.
File diff suppressed because one or more lines are too long
112
hu/sitemap.xml
112
hu/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.
@@ -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.
110
sitemap.xml
110
sitemap.xml
@@ -2,277 +2,277 @@
|
||||
<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>
|
||||
</urlset>
|
||||
BIN
sitemap.xml.gz
BIN
sitemap.xml.gz
Binary file not shown.
@@ -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”字段用於描述在以後的“data”響應中找到的字段。</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>此端點類似於運行“PRINT_CANCEL”G 代碼命令。例如：<code>{"id": 123, "method": "pause_resume/cancel"}</code></p>
|
||||
<p>與“gcode/script”端點一樣，此端點僅在任何待處理的 G 代碼命令完成後才會完成。</p>
|
||||
|
||||
@@ -2083,7 +2083,7 @@ scan_overshoot: 8
|
||||
<h3 id="_10">校準<a class="headerlink" href="#_10" 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="loading-the-default-profile">Loading the default profile<a class="headerlink" href="#loading-the-default-profile" title="Permanent link">¶</a></h4>
|
||||
<p>Previous versions of <code>bed_mesh</code> always loaded the profile named <em>default</em> on startup if it was present. This behavior has been removed in favor of allowing the user to determine when a profile is loaded. If a user wishes to load the <code>default</code> profile it is recommended to add <code>BED_MESH_PROFILE LOAD=default</code> to either their <code>START_PRINT</code> macro or their slicer's "Start G-Code" configuration, whichever is applicable.</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>Alternatively the old behavior of loading a profile at startup can be restored with a <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 (序列匯流排)</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>如果使用者配置中存在錯誤，應在<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>
|
||||
@@ -4027,8 +4055,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.
|
||||
@@ -4562,6 +4591,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="_9">無機型<a class="headerlink" href="#_9" title="Permanent link">¶</a></h3>
|
||||
<p>可以定義特殊的 "none" 機型來禁用 Klipper 中的機型支援。可以用於控制不是 3D 印表機的裝置或除錯。</p>
|
||||
<div class="highlight"><pre><span></span><code>[printer]
|
||||
@@ -5761,9 +5907,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>有關示例配置，請參閱 <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
|
||||
@@ -5775,7 +5921,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:
|
||||
@@ -5789,6 +5935,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>
|
||||
@@ -5808,25 +6013,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-code 命令控制的步進器。例如：“MANUAL_STEPPER STEPPER=my_stepper MOVE=10 SPEED=5”。有關 MANUAL_STEPPER 命令的說明，請參見 <a href="G-Codes.html#manual_stepper">G-Codes</a> 文件。步進器未連接到正常的打印機運動學。</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>
|
||||
@@ -7988,6 +8201,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="_27">控制板特定硬體支援<a class="headerlink" href="#_27" 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>
|
||||
|
||||
@@ -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>當啟用 <a href="Config_Reference.html#bed_mesh">bed_mesh config section</a> 時，以下命令可用（另請參閱 <a href="Bed_Mesh.html">bed mesh guide</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>：該命令將目前探測到的 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 config section</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>當啟用 <a href="Config_Reference.html#tsl1401cl_filament_width_sensor">tsl1401cl filament width sensor config section</a> 或 <a href="Config_Reference.html#hall_filament_width_sensor">hall filament width sensor config section</a> 時，以下命令可用（另請參閱 <a href="TSL1401CL_Filament_Width_Sensor.html">TSLl401CL Filament Width Sensor</a> 和 <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>模組manual_probe已自動載入.</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>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>The following information is available in the <code>manual_probe</code> object:</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><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
@@ -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.
@@ -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