You're welcome! It could well be that the sleep() is rounded up to 0.017 seconds on Windows, but not on Linux.
On Thu, Dec 3, 2015 at 5:09 AM, Alan Yorinks <[email protected]> wrote: > I found the problem and it was indeed in my code. To read serial data, I > wrap the pyserial read method in a future. This all works without issue. > After retrieving a character using this future, I had added (incorrectly) > an additional asyncio.sleep(.001). Because of the constant barrage of > data, this became additive on Windows. Removing that sleep solved the > problem. This still does not explain why Linux and Windows behaves > differently, but at least both Python 3.5 and Windows are off the hook. > > Thanks for your patient suggestions. > > > On Sunday, November 29, 2015 at 1:15:31 PM UTC-5, Alan Yorinks wrote: >> >> I tried changing the loop type, but pyserial stopped functioning. I think >> the best thing at this point is for me to create a simple application that >> receives data from the Arduino, and then simply print out what is being >> sent back every x number of seconds. This will eliminate the bulk of my >> code from the picture. If things fail, it will be simpler to pinpoint >> where, and if things work, then it points to something in my code. >> >> Hopefully I will be able to get it this week and will report back with >> any findings. >> >> >> >> On Sunday, November 29, 2015 at 11:47:04 AM UTC-5, Guido van Rossum wrote: >>> >>> Another thought: you can use the SelectorEventLoop even on Windows. That >>> could help you narrow it down. >>> >>> On Sun, Nov 29, 2015 at 5:09 AM, Alan Yorinks <[email protected]> wrote: >>> >>>> I agree that the USB port is not the problem and but I believe that it >>>> is not my callback mechanism either. The reason I say this, is that if I >>>> run pymata_iot , an application that wraps the pymata-aio library with >>>> Autobahn WebSockets and exposes the pymata-aio API through a set of JSON >>>> messages, and then bring up a webpage that implements the JSON protocol >>>> (http://mryslab.github.io/pymata-aio/examples/uno_iot_tester.html), I >>>> can enable all 5 analog inputs and no lag is exhibited at all. The same >>>> holds true for another application, s2aio >>>> <https://github.com/MrYsLab/s2aio/wiki>, that uses pymata-aio to >>>> interface the Scratch programming language to Arduino boards. No lag >>>> exhibited there either. >>>> >>>> I can't guarantee that the problem is not internal to pymata-aio, so I >>>> will try to come up with an example independent of pymata-aio that >>>> reproduces the problem. >>>> >>>> Again thanks. >>>> >>>> On Saturday, November 28, 2015 at 5:15:24 PM UTC-5, Guido van Rossum >>>> wrote: >>>>> >>>>> Hm, I don't know how much data your device sends every 17ms or how >>>>> inefficient the hardware is, but it does sound a bit unlikely that the >>>>> Windows USB port can't keep up. I certainly don't believe that the >>>>> ProactorEventLoop itself can't keep up. >>>>> >>>>> But there may be other differences. One thing to know is that on >>>>> Windows some important timers run only at (roughly) 17ms precision. >>>>> Perhaps >>>>> you are getting bursts of multiple callbacks and not handling them right? >>>>> I >>>>> haven't looked at the PyMata code itself, but you may want to dive into >>>>> this further before just giving up and saying "it's Windows". >>>>> >>>>> >>>>> >>>>> On Sat, Nov 28, 2015 at 12:29 PM, Alan Yorinks <[email protected]> >>>>> wrote: >>>>> >>>>>> You are quite correct, that is not the issue. When I tested, I had >>>>>> originally executed through Pycharm and it masked the problem. When >>>>>> executing through a terminal console, the problem was still there even >>>>>> with >>>>>> the -u and flush=True options. >>>>>> >>>>>> I think I may have a better understanding now, and perhaps it is the >>>>>> difference between the ProactorEventLoop and SelectorEventLoop. I slowed >>>>>> down the speed that the Arduino is sending blocks of data from the >>>>>> original >>>>>> rate of every 17 ms to a rate of every 30 ms and the problem disappears. >>>>>> Luckily, this is easy to do through an API call I implemented and so I >>>>>> will >>>>>> document this for Windows users. My code uses the default event loops >>>>>> chosen for the operating system. >>>>>> >>>>>> The amount of data coming through the USB serial port seems to be >>>>>> overwhelming Windows. (But no so for Linux/Mac). >>>>>> >>>>>> I am not sure if this is a Windows issue or a ProactorEventLoop >>>>>> issue, and I am not sure if this would be considered a bug or not, but I >>>>>> really appreciate your taking the time to address the issue. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Alan Yorinks >>>>>> >>>>>> On Friday, November 27, 2015 at 3:25:49 PM UTC-5, Guido van Rossum >>>>>> wrote: >>>>>>> >>>>>>> From the looks of it this doesn't have anything to do with asyncio. >>>>>>> It seems to be about the default buffering of sys.stdout, which asyncio >>>>>>> doesn't touch. Does this program exhibit the same behavior? >>>>>>> >>>>>>> import time >>>>>>> while True: >>>>>>> print('hello') >>>>>>> time.sleep(5) >>>>>>> >>>>>>> On Fri, Nov 27, 2015 at 5:44 AM, Alan Yorinks <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> I forgot to mention this is Python 3.5 >>>>>>>> >>>>>>>> >>>>>>>> On Friday, November 27, 2015 at 8:43:24 AM UTC-5, Alan Yorinks >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I am the author of pymata-aio >>>>>>>>> <https://github.com/MrYsLab/pymata-aio/wiki>, an asyncio library >>>>>>>>> for communicating with Arduino boards. The example code below is a >>>>>>>>> "fix" >>>>>>>>> for a problem encountered only on Windows, and I don't know if this is >>>>>>>>> expected behavior or a bug. >>>>>>>>> >>>>>>>>> The code uses pymata-aio to configure an Arduino for analog input >>>>>>>>> on 2 pins and digital input input on 2 other pins. The Arduino reports >>>>>>>>> analog and digital input data updates asynchronously approximately >>>>>>>>> every 17 >>>>>>>>> ms. To have the code work properly on Windows, the user must start >>>>>>>>> python >>>>>>>>> with the -u option and in addition, add the flush=True option to the >>>>>>>>> print >>>>>>>>> statement. If this is not done, the data that is being printed lags >>>>>>>>> behind >>>>>>>>> the actual data changes. >>>>>>>>> >>>>>>>>> Neither the -u option nor the flush=True are required for >>>>>>>>> Linux/Mac operation. I suspect the differences between the OS's event >>>>>>>>> loop >>>>>>>>> implementations is at the root of the problem. >>>>>>>>> >>>>>>>>> The code may be viewed here: >>>>>>>>> https://gist.github.com/MrYsLab/c3a69625cf844cbeb9e0. >>>>>>>>> >>>>>>>>> Any thoughts if this is a bug or not? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> --Guido van Rossum (python.org/~guido) >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> --Guido van Rossum (python.org/~guido) >>>>> >>>> >>> >>> >>> -- >>> --Guido van Rossum (python.org/~guido) >>> >> -- --Guido van Rossum (python.org/~guido)
