Using Snap Connect and schedule

[Cathy_Hanna]

I am trying to schedule three tasks using Snap connect. I have no experience with threads or the scheduling apy. I'm finding the Snap Connect user guide a little slim on explainations. I tried to follow the 'Correct Usage' snippets on page 35. I can get all three functions cycling if I use the individual buttons to trigger the events and I pause a few seconds between each button click. How can I get all three functions to follow eachother every 'x' seconds? (code attached) testSched.py

Thank you.

[jamos]

Cathy, just for clarity, using apy for scheduling isn't using threads, just scheduling a timer for later. For that to work apy has to be the driving force of your program and it doesn't really work with an wxPython program. You did the right kind of concept with your 20mS poll on the snap object. You will need to use wxTimers for these events too. wx has the control here and is driving the system. So instead of using snap scheduler to schedule your events you will just need to create a new wxTimer for updating your time, getTemp, and startPump. The concept you have for the timers will work, but keep in mind that your mcastRpc events will not go out until at least the next poll on the snap object (so could be 20mS later). There are techniques to be able to align those times more closely if you care about those small skews in time between rpcs.

[Cathy_Hanna]

Thank you for your advice jamos . I took your advice and tried to implement wx.Timer for the three tasks I wish to run. I defined a timer for each task (i.e..self.timeTimer = wx.Timer(self) and self.Bind(wx.EVT_TIMER, self.onUpdateTime, self.timeTimer)). Then I defined a function to start all three timers on a button click with each timer having a different timing interval. Is this the proper way of implementing this? If I define all three timers to run at the same time, I lose the response from one of the I2C sensors (the time and the temp are I2C and the pump is writePin()). Is there a better way?

[jamos]

Cathy,

I think without more information it is hard to say what is a better way and what isn't. I don't know that I understand the reason for why the perceived loss of a response is occurring either. What I am implying is that since the SNAP OS is going to execute one function until complete, if you time and temp functions that you are calling get the information and return it immediately on the same function call, then they should actually get the time and temp into the SNAP module. The packet may not be getting received back at your gateway/PC for many reasons. One of those reasons could be that the bridge node on your PC is transmitting rather than listening when the response comes back or your node is. This is something you have to investigate to determine where the packet is going. You may have to blink different LEDs for packet reception on the SNAP module to determine if it is hearing the request or not. The number of ways an mcast message may get lost is reasonably large and vary with your particular network setup and install location.

One thing you might could do rather than calling these all separately is have the function your button press calls be the same function that returns all the values every time and parse out the one you want or update all the values every time. That should be fairly straight forward and would reduce the number of packets over the air by roughly by 66% if you are only doing those 3 calls.

You can attempt to give the timers different timeouts, but sooner or later they will line up again anyway.

I just don't know your application, your end game, etc. to really give you good advice on how to architect your software.

Hope that is helpful.

[Cathy_Hanna]

Very helpful. Thank you. I have a RF200 with two devices that are using the writePin() function, a RGB LED that is being controlled by code gleaned from Eric Ibarra's 2011 masterAtmelPWM program and 2 sensors using I2C. I've tried combining functions, both on the node and in the rpc with no luck, most of the time, everything will freeze. I have determined that when an I2C function on the node is running, it will interfere with the LED when the duty cycle is set to less than 255. For example: if I have the LED's duty cycles set at 100, when I send the rpc to the node for an I2C function that needs to return a value, the LEDs go off and the duty cycles for each color will vary during the transmission of the info sent from the node. I also see errors on the sniffer (inserted a screen capture, it gave me a file type error when I tried to upload the *.sss file).5d25b0 is the bridge and 6084c5 is the node. Any insight you can give me would be appreciated. Capture.PNG sniffer (.