Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

no response from Kvaser after a long delay between messages

Aberta
  • Algo errado?
#2,017 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
38/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
python
Domínio
embedded-iot

Direção de pesquisa

Comece reproduzindo o problema com um Kvaser Leaf Light v2 ou U100 usando a interface kvaser e, em seguida, inspecione o caminho de recebimento em torno de bus.recv() e os valores reportados de canGetBusStatistics/canReadStatus. Compare o comportamento antes e depois de 1–5 minutos de inatividade. Está concluído quando os frames ECU recebidos são recebidos após o atraso ou quando um erro claro de recebimento é reportado em vez de None.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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
Linguagem predominante
Python
Estrelas
1.6k
Forks
697
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de hardbyte/python-can

Todas as issues de hardbyte/python-can

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.