What is the best way to deal with Variable attributes? The feedback from #355 indicates that it is desirable to keep the attr based get/set mechanisms. However, this scheme cannot be used for async as there is no await mechanism built into @data.setter.

 var = param.data # Non-async use
 var = await param.aget_data() # Async use

My goal has been to keep the async and non-async uses of canopen as equal as possible, but this is an area where users will see a difference.

There is an implementation for .read() and .write() on the underlying canopen.variable.Variable type. Could that be used in an async wrapper, or something similar added for async?

@acolomb I'm not precisely sure what you mean, so let me guess: You need separate async methods for read and right and they should only call their respective async setters/getters.

Sorry, I was trying to answer your question in the previous comment about synchronous getters / setters used in the properties. What I meant was that instead we already do have methods to access a variable remotely. Those might be a better fit to mirror to the async world:

value = sdo_var.raw # This is the usual, terse style recommended in the docs
value = sdo_var.read(fmt='raw') # This also works already
value = await sdo_var.aread(fmt='raw') # Feels like a natural enhancement for async

Note that the fmt='raw' argument can of course be left out, it's only needed for phys or desc variants. This would give us an easy way to support async without changing the existing synchronous property-based access.

This branch is ready for review and integration into the project. Its not fully complete (I suppose it never will). The biggest lack is that there is no documentation for async.

The branch's README (https://github.com/sveinse/canopen-asyncio?tab=readme-ov-file#difference-between-async-and-non-async-version) contains an overview over the current differences between this branch and the main project.

The port is quite "naive" async-wise as it relies on asyncio.to_thread() on many async operations, which not ideal. The back-end of the canopen library relies on synchronous callbacks which doesn't work too well from an async perspective. To be able to support both non-async (regular) and async use, this approach have been chosen. In time I hope we can refactor the inner working of the library such that we can do it independent of the communication (e.g. vis sansio).