Repository navigation
Not able to send FD message on pcan interface #507
Description
Activity
FD support has not been implemented for pcan yet. Maybe you’re up to it?
I am looking into implementing FD support for pcan. I have some poc code which uses pcanBasic successfully, but I am debating the design. It seems that the the pcan interface in python-can uses explicit parameters while the kvasar interface uses mostly implicit parameters. What are the design guidelines of the project on this subject?
They way I think this should be implemented is by adding optional arguments to the constructor of PcanBus and holding a internal flag specifying if we are using an FD enabled bus. Whenever an API is supposed to be called I would check the flag and call the correct API (FD / non FD).
I can see 2 issues:
- How should the FD config be passed?
In PcanBasic it is a string of form "VAR=VAL, ..." Where VAR is replaced by a name of a configuration parameter and VAL is it's numeric value. - What configuration options are legal? (should we maintain a list of these?)
To the best of my understanding the pull request mentioned here in the thread doesn't actually enable connecting to an FD bus as it doesn't use the PcanFD aware APIs.
- How should the FD config be passed?
But if you use flags do you not have to uninitalize, when you change between CAN and CAN-FD, because of the different initalization?
Or is your goal to have one class, which sets the type staticly in initalization.For parsing the bitrate you "only" need the channel and a c_char_p Byte string with the bitrate settings for FD.
I concidered for my local version only that the Peak supplied settings are valid, but my local version is not clean.To the best of my understanding FD enabled pcan can connect to a non FD bus using the FD APIs.
The FD flag in the PcanBasic API controls if an actual FD message is sent or received. If my understanding is correct there is no need to be able to change dynamically between FD and non FD APIs.I think that passing the config as a string is quite ugly. Instead I would suggest generating the config string based on parameters passed to the constructor.
Hmm have to test it. I only tested to send message over a FD enabled bus.
For my configuration, I did it with a string, because parsing up to 9 new arguments were bit too much.
I additionally created a new class with some error handling (verifying the input types) for creating the string.
Thanks for the anwsers.I have written and initial implementation for FD on Pcan.
It can be found hereI don't have a PcanFD on hand to test right now, but it should work.
Before i proceed to open a pull request i would like some feedback on the current implementation:
-
Parameters for the bit rate are passed as keyword args.
Should this be switched to be a single string? (this is what the Pcan API accepts).
The benefit to switching would be a simpler interface. -
Messages with a non standard message size are padded right now with zeros.
Should we allow for an option to configure the padding?
What should the default padding be?
-
https://github.com/hardbyte/python-can/blob/develop/can/interfaces/pcan/pcan.py#L228
pcan does not check msg.is_fd value, it is using TPCANMsgMac/TPCANMsg for FD message . When message DLC > 8, it will be failed by IndexError in https://github.com/hardbyte/python-can/blob/develop/can/interfaces/pcan/pcan.py#L251
CANMsg.DATA[i] = msg.data[i]