Repository navigation
Add async support to canopen #272
Description
I have a use case where I have a need to control many independent CAN nodes with separate controls. In order to do that one could either do regular CAN callbacks and state machines, or do them concurrently with an async framework in Python. After investigating a bit, the python-can package does support async operations and I think that canopen should get async support. The biggest upside to concurrent async programming is that the async user code is linearized as if using regular blocking functions, and it makes coding and maintenance much simpler.
I have started on the concept work in my own private fork using asyncio, linked here https://github.com/sveinse/canopen-asyncio/tree/feature-asyncio. For a peek I have a simple example code at https://github.com/sveinse/canopen-asyncio/blob/feature-asyncio/examples/canopen_async.py. This specific example won't work out of box, but a modified variant of the same script with real PDOs and SDOs is tested against physical CANopen HW devices.
I believe it should be rather feasible to add asyncio support alongside the existing API, which is what I've started on in my branch. I'd argue strongly for releasing it as one package/repo due to the constant risk of getting any asyncio fork out of sync with the official upstream canopen package.
This work is currently WIP. I hope this work could be considered for the official upstream canopen. I had hoped we could use this issue as a place to discuss async support. A warning is in order: My motivation in this is a specific use case for a very specific CAN system diagnostics tool and I plan to take it as far as that task requires. The system doesn't implement all of canopen and thus there are many functions in the canopen package I will never encounter. Hopefully this work may become a start point that can inspire others to continue developing it.
Activity
sveinse commentedon Jun 22, 2022
I'd like to publish canopen-asyncio. Is the canopen project open to having the asyncio support built into it? @christiansandberg. The change footprint of canopen-asyncio is actually not that big and I believe it is possible to have them live side by side in the same codebase. If so, I can start working towards a PR. Otherwise, canopen-asyncio will become a separate package. The challenge with the latter is keeping the async variant in sync with upstream canopen.
We have been running the canopen-asyncio port of this library in a semi-production environment for 6 months and it works extremely well for us. The async await capabilities on user-level makes it very convenient to write very compact business logic with data to/from can nodes.
If this is interesting, is there anything that you'd like to know?
acolomb commentedon Jun 22, 2022
I haven't looked at your code yet, but in principle I would be interested in getting asyncio support integrated into this package. My experience with it is very limited, but I'd be open to investigate, learn and test your solution. Definitely sounds like a better idea to not split it into a separate package, as long as there are still ways to use the library without depending on asyncio.
sveinse commentedon Jun 22, 2022
Awesome. Let me prepare for a PR towards migration into this repo, and we can take it from there. I guess it will be easier to discuss the particulars when we do.
friederschueler commentedon Mar 6, 2023
Hi Svein, I would like to port some of my python-can code with asyncio dependencies to canopen. Can you provide a PR? Do you still use canopen with asyncio?
Edit: after having a look at your code, it already seems to provide all the things I wanted. I will test it myself and provide some feedback.
mrk-its commentedon Mar 8, 2023
@sveinse I started using your fork (I really need async) and it works great!
@christiansandberg what are your the plans about providing async interface? I think it is must have in more serious usage cases.
Thank you both for your work!
sveinse commentedon Jun 20, 2025
canopen-asyncio published
While waiting for the process of getting the PR for asyncio reviewed, refined and approved, I have published canopen-asyncio on PyPI from https://github.com/sveinse/canopen-asyncio. There are other users waiting on the asyncio port of canopen and not being able to download it from pypi is a limitation. The package is not clashing with the namespace of the canopen package.
The canopen-asyncio package was not created to be a permanent fork of this repo. Rather the opposite, we all agree that the intention is to make asyncio a part of the canopen package. However, history shows that this will take time, and I needed a solution in the interrim. As soon as the official canopen package gets asyncio support, I plan to deprecate canopen-asyncio.
acolomb commentedon Jun 22, 2025
Thanks for the heads-up! I'm sorry we couldn't really make progress with #359 yet, as I wanted to tackle the smaller PRs first and reach the v2.4.0 milestone with hopefully all non-breaking improvements. You could help finish that by giving feedback on the two remaining PRs. I plan to make the release shortly after that milestone completes. Then we can focus on the bigger additions for v3.0.0.
acolomb commentedon Jun 5, 2026
I must apologize again for not reviewing your suggested PR #358 in time, @sveinse. This is still on my agenda, just got held up by Real Life and trying to handle many smaller contributions / fixes and overall cleanup. I have completely read the PR diff now and there are some design considerations which need discussion IMO, some already addressed in the comments above. Indeed the actual functional changes are not huge and look pretty sensible. But it is a large chunk to review, sprinkled with some unrelated changes, comments and references to bugs which have been fixed by now. I'm happy to see the changes are mostly additional methods, with little potential for conflicts. My biggest concern however is duplication - whether we can do better than copy-pasting methods in many cases, where both implementations (and docs / annotations) need to be kept in sync.
I will try to give some concrete comments in PR #359 to continue with a focus on the code itself.