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.
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
Opening a PCanBus in FD mode with Bus.__new__ breaks with python-can 4.0.0 / 4.1.0 #1458
Labels
Comments
lumagi
added a commit
to lumagi/python-can
that referenced
this issue
Dec 18, 2022
lumagi
added a commit
to lumagi/python-can
that referenced
this issue
Dec 18, 2022
The BitTiming class is an attempt at unifying the various timing parameters of the individual interfaces. The idea is that instead of manually supplying multiple parameters that make up the timing definition of the interface, one can instead supply a single instance of the BitTiming class, which will also automatically calculate derivative values from its input. At the moment, this class is only used by two interfaces: CANtact and CANanalystii. Both either accept a single bitrate or a BitTiming instance. The latter will overrule the former. The code that is removed with this commit is part of the generic Bus.__new__ constructor. The removed code searches the set of kwargs parameters for timing-related values. If it finds at least one such value, it creates a BitTiming class instance and adds it to the list of parameters. However, it breaks compatibility with the PEAK interface, see issue hardbyte#1458. Additionally, the code in question is generic and applies to all interfaces. Instantiating a class here is prone to issues since it must be generic enough to fit all use cases. A better approach would be to simply forward the parameters as was done previously and leave it up to the individual interfaces to handle things properly.
For reference, there are multiple issues/PR that discuss / implement the |
zariiii9003
pushed a commit
that referenced
this issue
Dec 21, 2022
* Add failing unit test to verify that issue #1485 is fixed #1458 * Remove unused generic BitTiming creation in Bus.__new__ The BitTiming class is an attempt at unifying the various timing parameters of the individual interfaces. The idea is that instead of manually supplying multiple parameters that make up the timing definition of the interface, one can instead supply a single instance of the BitTiming class, which will also automatically calculate derivative values from its input. At the moment, this class is only used by two interfaces: CANtact and CANanalystii. Both either accept a single bitrate or a BitTiming instance. The latter will overrule the former. The code that is removed with this commit is part of the generic Bus.__new__ constructor. The removed code searches the set of kwargs parameters for timing-related values. If it finds at least one such value, it creates a BitTiming class instance and adds it to the list of parameters. However, it breaks compatibility with the PEAK interface, see issue #1458. Additionally, the code in question is generic and applies to all interfaces. Instantiating a class here is prone to issues since it must be generic enough to fit all use cases. A better approach would be to simply forward the parameters as was done previously and leave it up to the individual interfaces to handle things properly. * Format code with black Co-authored-by: lumagi <lumagi@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I am using the PCAN interface in an FD configuration with custom bit timings. I provide the parameters, i.e.
f_clock
,nom_brp
,data_brp
, ..., directly as kwargs toBus.__new__
(see example below). With the transition from versionv3.3.4
tov4.1.0
, I can no longer instantiate the bus and always receive the error message below.I took a look at the code in question, and it appears like this might be a corner case that was forgotten about when adding the
BitTiming
class. When instantiating thePcanBus
for a CAN-FD bus, it is mandatory to supply thef_clock
parameter as well as the bit timings directly to the constructor. Thebitrate
parameter is ignored because the PCAN driver configures the interface directly based on the timing parameters (see pcan.py).The exception is thrown in
_create_bus_config
in util.py. The function in question assumes that whenever certain timing-related arguments (such asf_clock
,tseg1
,tseg2
orbrp
) are present in kwargs, thebitrate
argument must be present as well. For the case of thePcanBus
, this is not the case since the interface implementation does not use theBitTiming
class nor requiresbitrate
to be set when running in CAN-FD mode.I did some searching in the repository and found issue #614 by @christiansandberg . I also added a comment there, but didn't receive a response.
To Reproduce
See code example below
Expected behavior
The constructor should not require the
bitrate
parameter to be set and instantiate the bus correctly.Additional context
OS and version: Windows
Python version: 3.9
python-can version: 4.1.0
python-can interface/s (if applicable): PEAK PCAN-USB FD
Traceback and logs
The text was updated successfully, but these errors were encountered: