Fast single threaded non-blocking serial RTU client using Tornado (async)

[Cougar]

Hi,

I needed single threaded, non-blocking and fast serial RTU Modbus client for embedded Linux controllers. Because I have used Pymodbus and Tornado non-blocking IOLoop before, I decided to make my work based on them.

Pymodbus has already async client implemented with Twisted but it didn't look a good idea to run Twisted on top of Tornado or Tornado on top of Twisted (it should be possible). It is not very well documented either and based on code I can't see how it can be run in non-blocking without additional threads or processes. At least all existing serial I/O is blocking.

Anyway, here is the module right now including example code in the comments:
https://github.com/droid4control/pymodbus_async

At 19200 I can make 67 register read requests in second (with patch from #74).

This code includes a lot of debugging witch can be removed. It also needs unit tests and maybe some more documentation. The module works in Python3 only right now. Back porting to Python2 should be possible.

I use FifoTransactionManager but it is not possible to queue multiple requests right now. New request can be sent only after previous one is finished (by calling callback function). I do not need such queueing right now but this would be nice feature to add.

I would like to merge it with Pymodbus but client/async is already taken by Twisted example. Maybe we can rename it so that two different async implementations can co-exist?

PS! Suggestions for the licence are also welcome. I mostly write code under GPL but Tornado is licensed under Apache License and Pymodbus is released under the BSD License. I'm not very familiar with differences between them.

Enjoy!

[Cougar]

Hi,

I need some opinions for exception (error) handling in async way. There are two possible ways to receive error conditions.

One is from sync calls like class instance initialization and from calls like read_holding_registers() when something bad happens (problems with serial connection for example). These can raise exception like always.

Another type of errors can happen already in async code where raising exception is not possible. For that exception object instance can be passed to the callback function. For example when something happens with serial connection (timeout or system error).

Now I'm thinking about errors from sync calls. For example the hotplug serial port has been removed (USB serial) and user calls read_holding_registers(). There are two ways how to notify user:

1. raise exception right away
2. return *TransactionManager instance and then when user calls *TransactionManager.addCallback(), call it with exception

Right now it does the first. At the same time I feel like the second one is better because then user can keep all error handling code in one place. It also makes sure that every operation calls callback function and user can be sure that callback will be always called. If request needs to repeated by user it can also be in one place instead of two.

All comments are appreciated

Next I plan to extend async client for ModbusTCP too.

[neldog2]

Looking forward to the TCP version as I have had no luck getting the twisted version to work.

[dhoomakethu]

@Cougar I know this might be late, Off late we came up with this PR #226 to provide async client support based on twisted/tornodo/asyncio. Please have a look and share your comments if possible.