Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

no response from Kvaser after a long delay between messages

オープン
#2,017 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
38/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
python
領域
embedded-iot

調査の方向性

まず、kvaser インターフェースを使用して Kvaser Leaf Light v2 または U100 で問題を再現し、次に bus.recv() 周辺の受信パスと、報告された canGetBusStatistics/canReadStatus の値を調査します。1~5 分間非アクティブにした前後の動作を比較します。遅延後に受信 ECU フレームが受信されるか、None ではなく明確な受信エラーが報告されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

bug
Describe the error

When using the Kvaser interface via python-can, the CAN bus can automatically stop transmitting received frames (bus.recv() returns None) after a long period of downtime, even if:

  • The CAN bus is still physically active,
  • ECU responses are present on the wire (externally verified),
  • "bus.send()" continues to run successfully without errors,
  • Kvaser driver statistics report status=ok and no bus shutdown status.

As a result, python-can reports false “no response” timeouts, while valid responses exist on the CAN bus.

This happens without causing an exception and does not require a forced reinitialization of the bus to recover.


For playback
  1. Use python-can with Kvaser leaf light v2 or Kvaser U100.

  2. Open the CAN bus and connect to it in the normal mode (sending a request → receiving a response).

  3. Leave the system in standby mode for a long time (about 1-5 minutes):

    • The application is running,
    • the tire is open,
    • The Kvaser is connected,
  • The control unit is connected and turned on.
  1. After the waiting period has expired, send a new CAN request.

Observed behavior:

  • bus.send() completed successfully.
  • bus.recv(timeout) returns the value None until the timeout expires.
  • Python exception is not generated.
  • External monitoring confirms that ECU responses are present on the bus.

The problem occurs periodically, but can be fixed after sufficient downtime.


Expected behavior

bus.recv() must continue to return incoming CAN frames after periods of downtime until:

  • the tire is open,
  • The hardware is connected,
  • The driver does not report a bus shutdown or a passive status with an error.

At a minimum, python-can must either:

  • automatic recovery or
  • returns a clear error indicating that the reception descriptor has become invalid.

Additional context

This is apparently due to ** inactivity of the Kvaser receive descriptor or internal buffering behavior** after a long downtime.

Observed characteristics:

  • Kvaser Driver Statistics Report ('canGetBusStatistics', `canReadStatus'):

    • status=ok
  • "Bus load=0.0%"

  • no overspending, no bus shutdown

  • However, the function bus.recv() does not return any frames.

  • Forced bus shutdown and reinitialization restore normal operation.


Operating system and version:
Windows 10 / Windows 11 (x64) (tested on both)

Python version:
Python 3.9

python-can version:
4.5.0/4.6.1 (tested on both)

python-can interface/s:
kvaser


Feedback and logs

The Python feedback function does not start.

Example of a diagnostic log collected after the timeout:

[KvaserSnap:frame_write]
statistics=std_data: 0, std_remote: 0, ext_data: 0, ext_remote: 0,
err_frame: 0, bus loading: 0.0%, overspending: 0 status=ok

Additional note:

  • bus.recv(timeout=0) returns the value "None" again
  • An external CAN analyzer confirms that the ECU responses are simultaneously present on the bus
主要言語
Python
スター
1.6k
フォーク
697
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

hardbyte/python-can のほかの issue

hardbyte/python-can の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。