SYSTEC interface¶

Windows interface for the USBCAN devices supporting up to 2 channels based on the particular product. There is support for the devices also on Linux through the SocketCAN interface and for Windows using this systec interface.

Installation¶

The interface requires installation of the USBCAN32.dll library. Download and install the driver for specific SYSTEC device.

Supported devices¶

The interface supports following devices:

GW-001 (obsolete),
GW-002 (obsolete),
Multiport CAN-to-USB G3,
USB-CANmodul1 G3,
USB-CANmodul2 G3,
USB-CANmodul8 G3,
USB-CANmodul16 G3,
USB-CANmodul1 G4,
USB-CANmodul2 G4.

Bus¶

class can.interfaces.systec.ucanbus.UcanBus(channel, can_filters=None, **kwargs)[source]¶

Bases: can.bus.BusABC

The CAN Bus implemented for the SYSTEC interface.

Parameters:	channel (int) – The Channel id to create this bus with. can_filters (list) – See `can.BusABC.set_filters()`.

Backend Configuration

Parameters:

bitrate (int) – Channel bitrate in bit/s. Default is 500000.
device_number (int) – The device number of the USB-CAN. Valid values: 0 through 254. Special value 255 is reserved to detect the first connected device (should only be used, in case only one module is connected to the computer). Default is 255.
state (can.bus.BusState) – BusState of the channel. Default is ACTIVE.
receive_own_messages (bool) – If messages transmitted should also be received back. Default is False.
rx_buffer_entries (int) – The maximum number of entries in the receive buffer. Default is 4096.
tx_buffer_entries (int) – The maximum number of entries in the transmit buffer. Default is 4096.

Raises:

ValueError – If invalid input parameter were passed.
can.CanError – If hardware or CAN interface initialization failed.

static create_filter(extended, from_id, to_id, rtr_only, rtr_too)[source]¶

Calculates AMR and ACR using CAN-ID as parameter.

Parameters:	extended (bool) – if True parameters from_id and to_id contains 29-bit CAN-ID from_id (int) – first CAN-ID which should be received to_id (int) – last CAN-ID which should be received rtr_only (bool) – if True only RTR-Messages should be received, and rtr_too will be ignored rtr_too (bool) – if True CAN data frames and RTR-Messages should be received
Returns:	Returns list with one filter containing a “can_id”, a “can_mask” and “extended” key.

flush_tx_buffer()[source]¶

Flushes the transmit buffer.

Raises:	can.CanError – If flushing of the transmit buffer failed.

send(msg, timeout=None)[source]¶

Sends one CAN message.

When a transmission timeout is set the firmware tries to send a message within this timeout. If it could not be sent the firmware sets the “auto delete” state. Within this state all transmit CAN messages for this channel will be deleted automatically for not blocking the other channel.

Parameters:	msg (can.Message) – The CAN message. timeout (float) – Transmit timeout in seconds (value 0 switches off the “auto delete”)
Raises:	can.CanError – If the message could not be sent.

shutdown()[source]¶: Shuts down all CAN interfaces and hardware interface.

state¶

Return the current state of the hardware

Type:	can.BusState

Configuration¶

The simplest configuration would be:

interface = systec
channel = 0

Python-can will search for the first device found if not specified explicitly by the device_number parameter. The interface and channel are the only mandatory parameters. The interface supports two channels 0 and 1. The maximum number of entries in the receive and transmit buffer can be set by the parameters rx_buffer_entries and tx_buffer_entries, with default value 4096 set for both.

Optional parameters:

bitrate (default 500000) Channel bitrate in bit/s
device_number (default first device) The device number of the USB-CAN
rx_buffer_entries (default 4096) The maximum number of entries in the receive buffer
tx_buffer_entries (default 4096) The maximum number of entries in the transmit buffer
state (default BusState.ACTIVE) BusState of the channel
receive_own_messages (default False) If messages transmitted should also be received back

Internals¶

Message filtering¶

The interface and driver supports only setting of one filter per channel. If one filter is requested, this is will be handled by the driver itself. If more than one filter is needed, these will be handled in Python code in the recv method. If a message does not match any of the filters, recv() will return None.

Periodic tasks¶

The driver supports periodic message sending but without the possibility to set the interval between messages. Therefore the handling of the periodic messages is done by the interface using the ThreadBasedCyclicSendTask.