Asyncio (or something better) for control of a vacuum system/components.

[dieter]

Shishir <shishirk at gmail.com> writes:
> ...
> I am writing a software to control and monitor a vacuum
> furnace+attachments. It has a few mass flow controllers, a butterfly valve,
> a labjack unit for analog/digital outputs etc. They use RS485, RS232 and
> USB to communicate with the computer and follow special protocols for
> commands and response. The response time to execute commands can be from 5
> ms to 1 s.
>
> To achieve this, I thought of a server which reads commands on a network
> connections, parses the command and calls methods of appropriate device
> classes, which then use the corresponding channel protocol to execute the
> command. The response provided by the devices (flow controllers, valve) is
> sent back on the network connection.
>
> As there can be multiple clients (e.g. for monitoring from several
> computers), and some commands can take long, the server should not block
> when getting a command executed.

"Asyncio" is targeted at asynchronous (i.e. non-blocking) input/output.

To ensure that the server remains responsive during command execution,
you will need something in addition - e.g. threads or subprocesses.
This way, the commands can be executed (by a separate thread/subprocess)
while the server is still listening to communication.

I know of one framework which supports this kind of interaction:
"medusa/ZServer". However, it is targeted mainly towards standard
internet communication protocols ("HTTP", "FTP", ...).


>From your message, I have gained the impression that you want to support
multiple (concurrent) requests on the same communication channel.
This significantly complicates the task as the responses to those
requests may arrive out of order and may even mix with one another
(on the channel), unless you avoid this carefully.

The "medusa/ZServer" framework (mentioned above) supports HTTP pipelining (i.e.
the client can issue multiple requests without waiting for a response).
However, it starts processing of a request only when all previous
requests from the same (communication) channel have been completed.
This way, it ensures that all responses are delivered in the
same order as the requests (as required by HTTP pipelining).

If out of order responses must be supported, then "medusa/ZServer"
is not an appropriate approach. Special logic is then necessary on
both server and client to associate the responses to the proper
requests.