python-can USB Adapter: SocketCAN, gs_usb or SLCAN?

python-can gives applications a common Bus and Message API over many device-specific interfaces. Its own hardware-interface index warns that adapters differ and that each backend’s documentation still matters.

The abstraction does not make USB drivers, firmware, bit timing, timestamps, error frames, filters, isolation or connectors interchangeable. Those remain properties of the complete adapter-and-host path.

Start from the operating system and the interface the application will open, then verify the exact device revision. Do not start from enclosure shape or a seller’s claim that the device “supports Python.”

On a narrow screen, scroll the table horizontally.

SocketCAN represents supported controllers as Linux network interfaces such as can0. The Linux networking tools configure bit timing and expose controller state and counters; python-can then opens the named network interface.

sudo ip link set can0 down
sudo ip link set can0 up type can bitrate <known-bitrate>
ip -details -statistics link show can0

import can

with can.Bus(
    interface="socketcan",
    channel="can0",
    ignore_config=True,
) as bus:
    message = bus.recv(timeout=1.0)
    print(message if message is not None else "No frame in 1 second")

Set the real bus only to a documented bitrate on a controlled bench. Opening can0 proves the software path, not the adapter’s isolation, connector mapping or capture integrity.

The stable python-can documentation lists a direct gs_usb interface for Geschwister Schneider and candleLight-compatible devices on Windows, Linux and macOS. It uses PyUSB and a libusb backend; Windows may need a compatible USB driver binding.

python -m pip install "python-can[gs-usb]"

The backend can select a device by index or by USB bus/address and takes the CAN bitrate directly. The documentation also says message filtering is not supported by this interface. Record those constraints instead of assuming parity with Linux SocketCAN.

SLCAN is useful when the adapter intentionally exposes the serial-line CAN protocol and the application needs a direct serial path across operating systems. The stable backend accepts a local serial channel such as /dev/ttyUSB0@115200 or a Windows COM port.

The TTY rate and the CAN bitrate are different settings. Firmware variants also differ in supported bitrates, listen-only commands, CAN FD extensions and status reporting. A seller’s “SLCAN compatible” label is therefore the start of the test, not the result.

On Linux, an SLCAN device can alternatively be attached through slcand and then opened as SocketCAN. Compare both paths under the expected bus load before selecting the production route.

Yes. The virtual interface tests application logic inside one Python process without a CAN controller. The example below sends a Classical CAN frame back to the same virtual bus:

import can

with can.Bus(
    interface="virtual",
    channel="mallmars-check",
    receive_own_messages=True,
    ignore_config=True,
) as bus:
    sent = can.Message(
        arbitration_id=0x123,
        data=[0x10, 0x20, 0x30],
        is_extended_id=False,
    )
    bus.send(sent)
    received = bus.recv(timeout=1.0)
    assert received is not None
    assert received.arbitration_id == sent.arbitration_id

This proves only the application’s Bus/Message path. The virtual backend does not model USB enumeration, electrical arbitration, termination, bus load, hardware timestamps, isolation or error-state behavior.

• exact manufacturer, model, PCB revision, firmware version/hash and USB VID/PID;
• the named python-can interface, library version, host OS/architecture and driver package;
• Classical CAN or CAN FD scope, supported bitrates, channel count, frame types and termination control;
• listen-only, error-frame, filtering and timestamp behavior for that backend;
• signal-and-power isolation boundary, component identities, protection parts and test report;
• connector pinout, cable, ground/shield path and sample acceptance trace;
• 10/50/200-unit quote, lead time, compliance documents, resale rights and warranty route.

Run the same acceptance script on two samples and keep the raw log, host counters, firmware identity and test wiring. “Python compatible” without this evidence is not a purchasable requirement.

Not yet. CAN Isolated is a planned isolated Classical CAN pilot. The public product target names Linux/Windows workflows, but MallMars has not published a passed python-can backend matrix, production firmware identity, long-run capture result or product-level isolation report.

Public checkout remains closed. A candidate can claim socketcan, gs_usb, SLCAN or a vendor backend only after the exact assembled revision passes the corresponding host and capture tests.