Thanks for your input Tommy. I know that I can control the driver objects by using the poll field vs the poll rate, but I don't want to re-create the wheel, Lookout has already done this, I just want to look at it! By developing this algorithm myself, I'm effectively removing the polling queue, only one item in the queue at any given time, therefore I would not consider it a queue at all.
You asked about my motivation, there are several, but the biggest one that I have is to be able to programmatically adjust the poll rates and/or field of each of the individual drivers to 'optimize' the entire poll sequence from driver 1 to driver 65 and beyond. By 'optimize' I mean to reduce the amount of time it takes for all drivers to poll their respective devices. By knowing when a item enters a queue and were it is placed allows me to adjust a polling algorithm for subsequent drivers. Yes, I could wait until the update data member completes, but it could be several minutes down the road before I see any response, therefore all subseqent adjustments must be delayed by this time frame, (or some other type of time delay optimization). If you take this through 65+ drivers, you could see an hour+ go by before you may see the results of your labor. I would rather not have this much delay in this algorithm as it defeats the whole purpose, to obtain the most amount of data in the least amount of time. I want to adjust the next driver placed into the polling queue based upon the position of the last driver entered into the polling queue, and a couple of other variables (total polling queue length, total retries, total active drivers, total of all poll rates and/or queue waiting times, etc.) Complications are numerous with regards to conditions that must be taken into account for poor/no communications, retries, etc. I would rather not have to worry about all of this and let Lookout do its job, I just want to alter the properties of the drivers the next go around until an optimal time frame for the entire application has been achived. By comparing time for the overall polling sequence I can see and effectively rank (number) the overall polling sequence. This poll rating would allow the user to know how well his/her system is performing, not just thinking it's bad or good. By monitoring only the modbus data members (ie valid frames, protocol errors, etc.) you do not see the effects of retries, this I believe has a great impact on the polling sequence and subsequent 'optimal' time of application polling. I hope this helps instead of confusing the topic any more that it already is!
