What interface do you you use for these reads? We could make owread (or the owcapi interface) multithreaded.
On Fri, Jul 11, 2014 at 1:27 PM, Colin Reese <colin.re...@gmail.com> wrote: > Hi Paul, > > Thanks for the detailed response. > > Yes, the concern is power draw. We find that converting groups of > sensors simultaneously by ROM actually scales quite well. Using the TMEX > API, you can easily issue a Skip ROM (xCC) followed by a Convert Temp > (x44) to convert all devices simultaneously, but in the case that the > user wants to manage both how many devices are converted (and which are > currently being converted), it is nice to be able to send a list. Here > is some raw data in a plot here (sorry if this appears spammy): > http://interfaceinnovations.org/onewireoptimization.html > > In principle, I think you are right that threading is the way to go. > I've not written code structured this way, so I'd have to learn myself > how to. I assume you are describing a process where the calling code > creates a thread for each owfs read operation, carries the reads out and > returns them to the calling function (or puts them where they go). > > Thanks, > Colin > > > On 7/11/2014 05:14, Paul Alfille wrote: > > Hi Colin, > > > > I wonder if OWFS can already do what you want. If not, I have some ideas. > > > > OWFS has a "simultaneous" command to trigger temperature conversion. > > > > 1. It works on all the sensors on a bus, using the trick that there is a > > command to select the single slave on a 1-slave bus (for efficiency) but > > that will actually select them all. > > 2. The sensors do need external power because temperature conversion is > > power hungry and running many simultaneously can tax the data bus, > > especially if other communication is being done. > > 3. OWFS remembers the time of the "simultaneous" and will wait "long > > enough" before returning a temperature reading when temperature reading > > is attempted. (A "blocking read" in other words). > > 4. Not all temperature sensors are involved. Many read temperature > > continuously (Like DS2438, and 3rd party sensors) and all this fuss is > > irrelevant. > > > > You wanted to specify a list of sensors to do "conversion" on, rather > > than all of them I guess. Is there a mix of passive and active sensors? > > Are you worried about the total power budget or self-heating? > > > > 1. The command will be slower that the current "simultaneous" since each > > sensor must be addressed independently. > > 2. I don't see an elegant way of implementing the interface to such a > > command. > > A. We could have a separate "start" temperature reading. We'd need > > a separate timer for each and still "block" if read too early (or > > restart if read too late). > > B. We could write a list of slave addresses to a "convert" file, > > then read the sorted results from another linked file, but this really > > bends our syntax. (Variable-length fields). Doable, though. > > > > Have you considered another approach? Use the threaded nature of OWFS > > and just issue reads for each of your sensors in separate threads. Each > > will return when done. They can run concurrently if the sensor is > powered. > > > > Paul Alfille > > > > > > > > On Thu, Jul 10, 2014 at 2:09 PM, Colin Reese <colin.re...@gmail.com > > <mailto:colin.re...@gmail.com>> wrote: > > > > Hello, > > > > After talking with iButtonLink, it was brought to my attention that > > without > > additional power, it is possible to have unsuccessful simultaneous > > read if > > too many sensors are on the network, due to current draw during the > > conversion. > > > > Using the TMEX API, I can perform a match ROM and then issue a > > conversion > > command, and then come back later to read the converted value. This > > way I > > can issue conversion commands for, say, 20 ROMs without waiting for > > conversion more than once. > > > > Is there an analogous feature in owfs, e.g. a 'simultaneous' with a > > specified group of ROMs? > > > > Thanks, > > Colin > > > > > ------------------------------------------------------------------------------ > > Open source business process management suite built on Java and > Eclipse > > Turn processes into business applications with Bonita BPM Community > > Edition > > Quickly connect people, data, and systems into organized workflows > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > http://p.sf.net/sfu/Bonitasoft > > _______________________________________________ > > Owfs-developers mailing list > > Owfs-developers@lists.sourceforge.net > > <mailto:Owfs-developers@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > > > > > > > > > ------------------------------------------------------------------------------ > > Open source business process management suite built on Java and Eclipse > > Turn processes into business applications with Bonita BPM Community > Edition > > Quickly connect people, data, and systems into organized workflows > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > http://p.sf.net/sfu/Bonitasoft > > > > > > > > _______________________________________________ > > Owfs-developers mailing list > > Owfs-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers >
------------------------------------------------------------------------------
_______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
