h3n3/klipper
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Deploying to gh-pages from @ Klipper3d/klipper@c106955850 🚀

Browse Source
This commit is contained in:
KevinOConnor
2024-04-20 16:51:59 +00:00
parent fd055fd5f8
commit c94084a310
14 changed files with 60 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
CANBUS_Troubleshooting.html
View File

@@ -1230,6 +1230,13 @@
Check for incrementing bytes_invalid counter
</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">
@@ -1369,6 +1376,13 @@
Check for incrementing bytes_invalid counter
</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">
@@ -1460,6 +1474,51 @@ reordered messages:</p>
<p>Reordered messages is a severe problem that must be fixed. It will
result in unstable behavior and can lead to confusing errors at any
part of a print.</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</p>
<ol>
<li>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.</li>
</ol>
<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="obtaining-candump-logs">Obtaining candump logs<a class="headerlink" href="#obtaining-candump-logs" title="Permanent link">&para;</a></h2>
<p>The CAN bus messages sent to and from the micro-controller are handled
by the Linux kernel. It is possible to capture these messages from the