Pass flags instead of flags_t type for USB2CAN#1252
Pass flags instead of flags_t type for USB2CAN#1252felixdivo merged 2 commits intohardbyte:developfrom
Conversation
|
This is the traceback when encountering this error: Unable to create CAN node Traceback (most recent call last):
File "...\site-packages\can\interfaces\usb2can\usb2canabstractionlayer.py", line 141, in open
result = self.__m_dllBasic.CanalOpen(config_ascii, flags)
│ │ └ <class 'ctypes.c_ulong'>
│ └ b'F8BAFED8; 500'
└ <can.interfaces.usb2can.usb2canabstractionlayer.Usb2CanAbstractionLayer object at 0x0000020F03E5D370>
ctypes.ArgumentError: argument 2: <class 'TypeError'>: Don't know how to convert parameter 2 |
|
|
||
| super().__init__( | ||
| channel=channel, dll=dll, flags_t=flags_t, bitrate=bitrate, *args, **kwargs | ||
| channel=channel, dll=dll, flags=flags, bitrate=bitrate, *args, **kwargs |
There was a problem hiding this comment.
Since BusABC does not know these, we can also ignore them here.
| channel=channel, dll=dll, flags=flags, bitrate=bitrate, *args, **kwargs | |
| channel=channel, bitrate=bitrate, *args, **kwargs |
There was a problem hiding this comment.
I've also removed bitrate as it looks like BusABC doesn't use this either, so now this line is super().__init__(channel=channel, **kwargs).
I've removed the *args as well to prevent errors from positional vs keyword argument ordering. the BusABC argument can_filters could get passed into Usb2canBus via kwargs.
|
Thanks @jacobian91! |
Codecov Report
@@ Coverage Diff @@
## develop #1252 +/- ##
========================================
Coverage 65.89% 65.89%
========================================
Files 86 86
Lines 8887 8887
========================================
Hits 5856 5856
Misses 3031 3031 |
| dll="usb2can.dll", | ||
| flags=0x00000008, | ||
| *args, | ||
| *_, |
There was a problem hiding this comment.
Optional style change, this documents that all additional positional arguments get ignored but won't throw an exception when passed in.
There was a problem hiding this comment.
Yeah, that's fine. We don't have a unified handling of that case anyways.
It looks like flags_t the type was being used instead of the flags argument.