Add async support to canopen

[sveinse]

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.

[sveinse]

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]

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]

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]

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]

@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!