SLCAN problems retrieving the interface's serial number and version

[rdiez]

I have a LAWICEL CAN bus adapter, which uses the SLCAN protocol.

After a long pause, I have started using this adapter again. The first thing I did was to install the current python-can version 4.5.0 on my Ubuntu MATE 22.04.5. The old Ubuntu Linux PC, which I no longer have, had some python-can development version before 4.0, as I needed the then-unreleased 'robotell' protocol too.

However, I did keep my simple CAN bus test script, and I noticed that getting the serial number from the adapter used to work, but it doesn't anymore. Now I am getting 'None' from bus.get_serial_number().

I do not actually know Python, so I am finding this whole subject a bit of a struggle.

I did some sniffing on the serial port with socat. The version number is being queried with the 'N' command in the SLCAN protocol, and the expected serial number is then sent as a reply. But python-can seems to not store it correctly. There is no error message or warning about it.

Is this problem already known?

Other than that, I can send and receive a single CAN bus message. I haven't done any further tests yet, but I have seen other people complaining here that SLCAN adapters do not work reliably.

bus.get_version() is returning (None, None), but I do not know whether that used to work in the past. The SLCAN protocol does have a 'V' command to retrieve version information, so that should be possible too.

I have a second, inexpensive CAN bus adapter which uses the 'robotell' protocol, and getting the interface serial number does work with the same test script.

The 'robotell' driver does not support getting version information though, so I cannot test it there:
AttributeError: 'robotellBus' object has no attribute 'get_version'

[zariiii9003]

I assume #1490 caused your problem. If any other bytes string is received during the "get_serial_number" call, then None is returned. But the previous implementation wasn't great either: Any messages, that are received before the serial number response are lost.
I do not have access to slcan compatible hardware, so maybe somebody else can improve the code.

[rdiez]

First of all, thanks for your feedback.

I do not understand how other bytes could be received during the get_serial_number call. At least in my controlled scenario, nothing was sending anything on the CAN bus, and my very simple Python script using python-can runs sequentially, so I wouldn't expect any extra async bytes coming up in the SLCAN communication. And that is assuming that CAN message reception makes the SLCAN adapter write asynchronously to the serial port. I didn't actually see an explanation about how message reception works in the protocol documentation.

The SLCAN protocol seems to have "open" and "close" commands. One work-around would be for python-can to retrieve the version and serial number information before opening the CAN bus.

Unfortunately, my Python skills are close to zero, so I cannot really help here.

I am not too worried about version and serial number data, but this issue, together with other bug reports about reliability problems, make me wonder if something is fundamentally wrong with python-can regarding SLCAN.

Perhaps it's time to discourage usage of SLCAN adapters with python-can.

[zariiii9003]

try this branch: pip install git+https://github.com/zariiii9003/python-can.git@fix_slcan

[rdiez]

First of all, thanks for looking at this issue.

Can you help me get this working? I know next to nothing about Python. I tried installing like you suggested:

$ pip install git+https://github.com/zariiii9003/python-can.git@fix_slcan
Defaulting to user installation because normal site-packages is not writeable
Collecting git+https://github.com/zariiii9003/python-can.git@fix_slcan
  Cloning https://github.com/zariiii9003/python-can.git (to revision fix_slcan) to /tmp/pip-req-build-thhs4tfm
  Running command git clone --filter=blob:none --quiet https://github.com/zariiii9003/python-can.git /tmp/pip-req-build-thhs4tfm
  Running command git checkout -b fix_slcan --track origin/fix_slcan
  Switched to a new branch 'fix_slcan'
  Branch 'fix_slcan' set up to track remote branch 'fix_slcan' from 'origin'.
  Resolved https://github.com/zariiii9003/python-can.git to commit 1392a30904c567c6caaacdca03dfee45b93f2ca7
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: UNKNOWN
  Building wheel for UNKNOWN (pyproject.toml) ... done
  Created wheel for UNKNOWN: filename=UNKNOWN-4.5.1.dev1+g1392a30-py3-none-any.whl size=3961 sha256=ef27c59c151e18dae69ba1af18b798abfe3854ddd36ce04331c45aba0a261c09
  Stored in directory: /tmp/pip-ephem-wheel-cache-nll4e0cl/wheels/68/18/43/34f8518cdd72b1846b916c2382883652c68a0c03f714f6e633
Successfully built UNKNOWN
Installing collected packages: UNKNOWN
Successfully installed UNKNOWN-4.5.1.dev1+g1392a30

But then my script does not work:

import can
ModuleNotFoundError: No module named 'can'

I noticed that the package installs as UNKNOWN, so I tried:

$ pip show UNKNOWN
Name: UNKNOWN
Version: 4.5.1.dev1+g1392a30
Summary: UNKNOWN
Home-page: UNKNOWN
Author: 
Author-email: 
License: UNKNOWN
Location: /home/rdiez/.local/lib/python3.10/site-packages
Requires: 
Required-by: 

Under /home/rdiez/.local/lib/python3.10/site-packages/ there is a "UNKNOWN-4.5.1.dev1+g1392a30.dist-info" subdirectory, but nothing else related to CAN bus.

When I install with "pip install python-can", I not only get a "python_can-4.5.0.dist-info" subdirectory, but also a "can" subdirectory with files like "interface.py" inside.

[zariiii9003]

I assume your pip or setuptools version is too old.

Generally it is recommended to create a python virtual environment, so you do not pollute your system python installation.

# Create virtual env
python3 -m venv .venv

# Activate virtual env
source .venv/bin/activate

# Update pip
pip install --upgrade pip

# Install python-can
pip install git+https://github.com/zariiii9003/python-can.git@fix_slcan

# Run your script
python your_script.py

[rdiez]

Those Python commands worked, thanks for your help.

I can confirm that your python-can branch works better. I am getting the serial number I used to get before (Q137), and that matches the NQ137 response I see while sniffing the serial port

I did not record the version numbers in the past, they come up as (10, 11), and that matches the V1011 response I see while sniffing the serial port.

I tried sending and receiving a single CAN message, and that works too.