CANdapter Support for Extended Arbitration ID's (slcan ASCII Protocol)

[BroderickJack]

Hello,

I am integrating the Ewert Energy CANdapter. The protocol ASCII protocol seems to be extremely similar to what is device under the slcan interface. The slcan interface works for standard length arbitration ID's.

The extended length ID's however, were not working at first. The CANdapter reports the first ASCII character as x. I was able to integrate without any issues by changing the T to the x in the linked line.

python-can/can/interfaces/slcan.py

Line 213 in dcf15c9

elif string[0] == "T":

I would be interested in determining a way for these characters to be a part of the configuration, and if this specific adapter is unique in how it implements this "protocol".

Cheers,
Jack

[NoahMaceri]

Seconding this, I can confirm that changing the line @BroderickJack mentioned does allow the CANdapter to support extended-length IDs. The CANdapter doesn't exactly follow the SLCAN protocol (see Linux kernel slcan.c) line 121.

As @BroderickJack mentioned, maybe a configuration can be implemented to change the extended length ID ASCII identifier when creating a SLCAN interface. On the other hand, the current slcan.py directly follows the above-mentioned slcan.c, and this seems like a niche case; maybe this issue can serve as a note for other CANdapter users.

[BroderickJack]

Thanks for the input @NoahMaceri. I did want to follow up that in our patch we ended up just making an or to support the CANdapter identifier.

elif string[0] == "T" or string[0] == "x":

Although it is a niche case, it seems that this change could be made and not impact the official SLCAN protocol. I would be happy to make a PR if these seems like a worthwhile change.