I have done some testing with it, and have managed to reconnect the adapter even if it's unplugged manually. It's perhaps not a very nice solution, but it works at least.
Right now it detects the 1-wire adapters as usual at startup. At the first 1-wire scan, the serial number of the ds1420 chip (81.0000000000) is saved in the connin.usb struct. If the adapter fails at *_reset(), owserver tries to close the usb-handle, and reopen it as I did before (it solves most situations). If it's not possible to reopen the usb device, then I assume the USB adapter is unplugged (manually or by some EMP problem). It will then do a full usb device-scan (which is done at startup). If an USB adapter is found, I make a 1-wire scan on it. If the 1-wire device 81.0000000000 is found, I use this usb-adapter in the future. It works even if you unplug it and reconnect it to some other usb-hub. It works pretty good for me, and I assume it will solve your problem too when it's a small glitch and the kernel thinks it's disconnected. I will cleanup the source and checkin the changes during the day. It will be nice to hear if it works for you too after that. Paul, do you have any comments about it? /Christian On Fri, 2005-07-01 at 09:06 +0200, Jan Kandziora wrote: > Am Donnerstag, 30. Juni 2005 21:56 schrieb Christian Magnusson: > > You are right... The kernel thinks the usb adapter is physically > > removed and then inserted again and get a new device number. > > This problem is very fatal and question is if such thing should > > be handled by owfs. > > > Hm. owserver does handle the whole 1-Wire tunneling. If it could not handle > exceptional situations, like network breakdown, by itself it has very few > benefits to use it. > > In that case, I would have to implement a secondary client-server-connection, > which detects at least the errors correctly. In such a setup, owserver is no > longer needed because my connection could transfer the 1-Wire data, too. > > > > It could of course be added to detect a new > > 1-wire adapter if it disappears, but strange things can happen. > > > Does this apply if the hardware of the machine is not touched? > > > > Have you heard about any printer or scanner driver which solve the > > issue of a disconnected device? > > > That's a different world: home or small office appliances are known to fail > often, most times beyond repair. > > That's totally different from a commercial or industrial automation > environment, where anthing must work as long as possible and any error that > could be recovered from automatically must be recovered automatically. > > And sure, I can think of a driver which recovers from failures itself: TCP. > I think it's best to solve this issue inside owserver. It is a network > component and networks fail if someone pulls the cable. > > BTW: A backup ethernet connection for owserver is something to think of - I > don't need it for now, but this is really hot in high-available automation > environments. > > > > > Let say you have 2 DS9490 adapters. (Called A & B) > > Start: owfs -p19160 -u /var/1wire > > /var/1wire/system/adapter/name.0 = DS9490 (The first found adapter A) > > > > If adapter A get a hard error (like you) or is physically removed and > > inserted, the second adapter B will easily replace the first adapter > > which disappeared. It's perhaps possible to solve in some way, but I > > hope you understand this issue I see as a problem. > > > What miserably fails in that situation? From the owfs point of view, it's > totally indifferent on which adapter a chip connects - they are all put into > one directory tree. > > The only situation I can think of this as a problem is with several > owservers, > where each one connects to a different adapter, and the chips keep seperated > all up the line, even in the applications - and that's a setup which hardly > anybody would use. > > > > > My usb-adapter have a unique id 81.01010101010101 which could be used to > > find the same adapter when re-connected, but does every adapter have > > a unique id? I thought there where old adapters without this feature... > > > The passive ones don't have. But it's only a small problem anyway, as the > passive adapters won't get you into "USB disconnect" troubles. > > Kind regards > > Jan -- Christian Magnusson <[EMAIL PROTECTED]> ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
