search

yaq-project / yaq-python

Repository for yaq core python packages.
https://yaq.fyi
GNU Lesser General Public License v3.0
6 stars 5 forks source link

aserial timeout...is it necessary to add as kwarg? #27

Closed kameyer226 closed 2 years ago

kameyer226 commented 2 years ago

Looking into use of timeout kwarg at child level rather than parent level...does aserial timeout even work properly if we specified non-zero value?

kameyer226 commented 2 years ago

See branch called "timeout" for a possible code

ksunden commented 2 years ago

aserial very specifically uses 0 timeout to avoid blocking

Can you give a specific reason why you need this functionality?

kameyer226 commented 2 years ago

Motorized pumps seem to at very least temporarily halt serial communication when user pushes buttons on it, was looking to see if it was just temporary by adding a timeout. I can diagnose further.

ksunden commented 2 years ago

timeout on aserial will not address that problem at all...

timeout on a serial object causes it to wait for incoming data, not pause if the data is there or on writes.

aserial does not have timeout so that time is not spent waiting, though it will continue to process if it is not immediately available.

In any case, not the solution to the problem you are trying to solve.

ksunden commented 2 years ago

you can put waits between commands for the individual daemon.

For instance, this is what we do with newport:

we buffer all outgoing requests (actually across multiple daemons which share the serial interface)

and dispense them 1 by 1 with at least a 10 ms wait between each

https://github.com/yaq-project/yaqd-newport/blob/36b814da1f754a7395d3682b13fe59f485ce7435/yaqd_newport/_serial.py#L26

kameyer226 commented 2 years ago

It does look like that is the best thing to do, how many of our serial devices use the Dispatcher and Queues so far?

ksunden commented 2 years ago

Its a pattern I've used on several occasions, can't quite recall how many, but generally those that use the same serial connection to connect to multiple daemons like newport or thorlabs.

It carries with it some complexities to do with timing and ensuring busy state does not toggle inappropriately, but once ironed out I tend to like it. (@untzag may disagree with me on that, though... it can take some ironing out)

ksunden commented 2 years ago

I've thought about standardizing that in some way and bringing it either up into core or an optional dependency we control, but just hasn't been the priority