Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
BroderickJack opened this issue Jan 26, 2023 · 2 comments · May be fixed by #1528
Open

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

BroderickJack opened this issue Jan 26, 2023 · 2 comments · May be fixed by #1528

Comments

@BroderickJack
Copy link

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
@BroderickJack BroderickJack changed the title CANdapter Support CANdapter Support for Extended Arbitration ID's (slcan ASCII Protocol) Jan 26, 2023
@NoahMaceri
Copy link

NoahMaceri commented Feb 25, 2023 •
edited

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
Copy link
Author

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.

@BroderickJack BroderickJack linked a pull request Feb 27, 2023 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Support CANdapter extended length arbitration ID BroderickJack/python-can
2 participants
@NoahMaceri @BroderickJack