You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
socketcan cannot create multiple periodic messages with same arb id #930
When using a socketcan device and sending multiple periodic messages I receive the below error
"ValueError: A periodic Task for Arbitration ID XXXX has already been created." Where XXX is the arbitration ID of the message I am trying to send periodically.
Is it possible to send multiple periodic messages with same ID using socketcan?
I found this issue when running few tests using a systec probe on Linux. On Windows using the systec probe, and the systec option in python-can, I am able to create multiple cyclic messages with the same ID. Running on Linux with the systec probe as a socketcan device the same test fails. I verified with another socket can device as well.
Some context is we will be trying to simulate an ECU on a bus. So its possible that there will be multiple periodic messages coming from the same ID with different data.
I ran into a similar issue. It looks to be an issue with socketcan itself. The socketcan docs mention this under the Broadcast Manager doc (section 4.2) where it says: "The different RX/TX jobs are distinguished by the unique can_id in each BCM message."
It shall not be an issue anymore since #785 has been merged. The only thing is that this fix probably has not been released as it wasn't backported to Python 2.
Activity
ga-dmorey commentedon Jan 12, 2021
I ran into a similar issue. It looks to be an issue with socketcan itself. The socketcan docs mention this under the Broadcast Manager doc (section 4.2) where it says: "The different RX/TX jobs are distinguished by the unique can_id in each BCM message."
tysonite commentedon Mar 15, 2021
It shall not be an issue anymore since #785 has been merged. The only thing is that this fix probably has not been released as it wasn't backported to Python 2.
felixdivo commentedon Apr 14, 2021
@SiouxerSkate @ga-dmorey Is this now solved?
felixdivo commentedon Apr 16, 2021
I read the referenced PR again. It should indeed be fixed by #785. If not, please comment or open a new issue. Thanks for reporting!