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] > <javascript:>> 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) >
