Deploying to gh-pages from @ Klipper3d/klipper@14a83103c3 🚀

zh/CANBUS_Troubleshooting.html

@@ -449,8 +449,8 @@
   
   
     <li class="md-nav__item">
-      <a href="OctoPrint.md" class="md-nav__link">
-        None
+      <a href="OctoPrint.html" class="md-nav__link">
+        OctoPrint for Klipper
       </a>
     </li>
   
@@ -1277,6 +1277,13 @@
     检查递增BYTES_INVALID计数器
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#use-an-appropriate-txqueuelen-setting" class="md-nav__link">
+    Use an appropriate txqueuelen setting
+  </a>
+  
 </li>
       
         <li class="md-nav__item">
@@ -1349,8 +1356,8 @@
   
   
     <li class="md-nav__item">
-      <a href="Eddy_Probe.md" class="md-nav__link">
-        None
+      <a href="Eddy_Probe.html" class="md-nav__link">
+        Eddy 感应涡流探针
       </a>
     </li>
   
@@ -1416,6 +1423,13 @@
     检查递增BYTES_INVALID计数器
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#use-an-appropriate-txqueuelen-setting" class="md-nav__link">
+    Use an appropriate txqueuelen setting
+  </a>
+  
 </li>
       
         <li class="md-nav__item">
@@ -1478,6 +1492,17 @@ resistors</a> on the CAN bus. If the resistors are not properly installed then m
 <li>已知一些用于嵌入式设备的Linux内核版本会对CAN总线消息进行重新排序。可能需要使用替代的Linux内核，或者使用支持不存在此问题的主流Linux内核的替代硬件。</li>
 </ol>
 <p>重新排序的消息是一个必须解决的严重问题。这将导致行为不稳定，并可能导致打印的任何部分出现令人困惑的错误。</p>
+<h2 id="use-an-appropriate-txqueuelen-setting">Use an appropriate txqueuelen setting<a class="headerlink" href="#use-an-appropriate-txqueuelen-setting" title="Permanent link">&para;</a></h2>
+<p>The Klipper code uses the Linux kernel to manage CAN bus traffic. By default, the kernel will only queue 10 CAN transmit packets. It is recommended to <a href="CANBUS.html#host-hardware">configure the can0 device</a> with a <code>txqueuelen 128</code> to increase that size.</p>
+<p>If Klipper transmits a packet and Linux has filled all of its transmit queue space then Linux will drop that packet and messages like the following will appear in the Klipper log:</p>
+<div class="highlight"><pre><span></span><code>Got error -1 in can write: (105)No buffer space available
+</code></pre></div>
+
+<p>Klipper will automatically retransmit the lost messages as part of its normal application level message retransmit system. Thus, this log message is a warning and it does not indicate an unrecoverable error.</p>
+<p>If a complete CAN bus failure occurs (such as a CAN wire break) then Linux will not be able to transmit any messages on the CAN bus and it is common to find the above message in the Klipper log. In this case, the log message is a symptom of a larger problem (the inability to transmit any messages) and is not directly related to Linux <code>txqueuelen</code>.</p>
+<p>One may check the current queue size by running the Linux command <code>ip link show can0</code>. It should report a bunch of text including the snippet <code>qlen 128</code>. If one sees something like <code>qlen 10</code> then it indicates the CAN device has not been properly configured.</p>
+<p>It is not recommended to use a <code>txqueuelen</code> significantly larger than 128. A CAN bus running at a frequency of 1000000 will typically take around 120us to transmit a CAN packet. Thus a queue of 128 packets is likely to take around 15-20ms to drain. A substantially larger queue could cause excessive spikes in message round-trip-time which could lead to unrecoverable errors. Said another way, Klipper's application retransmit system is more robust if it does not have to wait for Linux to drain an excessively large queue of possibly stale data. This is analogous to the problem of <a href="https://en.wikipedia.org/wiki/Bufferbloat">bufferbloat</a> on internet routers.</p>
+<p>Under normal circumstances Klipper may utilize ~25 queue slots per MCU - typically only utilizing more slots during retransmits. (Specifically, the Klipper host may transmit up to 192 bytes to each Klipper MCU before receiving an acknowledgment from that MCU.) If a single CAN bus has 5 or more Klipper MCUs on it, then it might be necessary to increase the <code>txqueuelen</code> above the recommended value of 128. However, as above, care should be taken when selecting a new value to avoid excessive round-trip-time latency.</p>
 <h2 id="candump">获取candump日志<a class="headerlink" href="#candump" title="Permanent link">&para;</a></h2>
 <p>向微控制器发送和从微控制器发送的CAN总线消息由Linux内核处理。出于调试目的，可以从内核捕获这些消息。这些消息的日志可能在诊断中有用。</p>
 <p>Linux<a href="https://github.com/linux-can/can-utils">can-utils</a>工具提供了捕获软件。通常通过运行以下命令将其安装在计算机上：</p>