Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

no response from Kvaser after a long delay between messages

未關閉
  • 哪裡不對？
#2,017 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
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
分支
700
30 天內沒有已合併 PR

環境準備

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

hardbyte/python-can 的其他 Issue

查看 hardbyte/python-can 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。