no response from Kvaser after a long delay between messages
还没有人认领这个 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 内容生成。
描述
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=okand 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
-
Use python-can with Kvaser leaf light v2 or Kvaser U100.
-
Open the CAN bus and connect to it in the normal mode (sending a request → receiving a response).
-
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.
- After the waiting period has expired, send a new CAN request.
Observed behavior:
bus.send()completed successfully.bus.recv(timeout)returns the valueNoneuntil 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
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
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
hardbyte/python-can 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 88/100
hardbyte/python-can#2103 ·
-
bug
难度 1/5 1 小时以内 新手友好度 78/100
hardbyte/python-can#2077 · 1 条评论 · 1 个 reaction ·
-
bug
难度 1/5 1 小时以内 新手友好度 68/100
hardbyte/python-can#1922 · 1 个 reaction ·
-
enhancement
难度 5/5 一周以上 新手友好度 30/100
hardbyte/python-can#2102 ·
-
bug
难度 3/5 1-2 天 新手友好度 68/100
hardbyte/python-can#2092 ·
查看 hardbyte/python-can 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 90/100
learningequality/ricecooker#747 ·
-
难度 2/5 1-3 小时 新手友好度 68/100
BSData/horus-heresy-3rd-edition#3171 ·
-
enhancement
难度 2/5 1-3 小时 新手友好度 72/100
-
难度 2/5 1-3 小时 新手友好度 76/100
run-llama/llama_index#23199 ·
-
难度 2/5 1-3 小时 新手友好度 84/100
KhronosGroup/glTF-Blender-IO#2769 ·