Re: [Owfs-developers] More on Hanging Problems
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 -- Where do you want Bill Gates to go today? --- 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=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
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.00) 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.00 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=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] RE: 1-wire on Linux...
Matthew, 1. Hello and welcome aboard 2. The best place for questions (and answers) is the mailing list. http://sourceforge.net/mail/?group_id=85502 3. The only driver you will need is for the user-space filesystem, FUSE. http://fuse.sourceforge.net 4. Almost all the devices are supported, you don't need anything extra. This includes temperature, memory, switches, voltage, current, timers, counters and some LCD and humidity 3rd party devices. 5. Access to the data is via filesystem, web server, or perl/python/tcl/php Paul Alfille -Original Message- From: Matthew Percival [mailto:[EMAIL PROTECTED] Sent: Thursday, June 30, 2005 7:38 PM To: Alfille, Paul H.,M.D. Subject: 1-wire on Linux... G'Day, I hope you do not mind me emailing you out of the blue like this, but I was not sure where to take this question. I have recently been introduced to 1-wire, and now need to put a 1-wire device onto a Linux system --- considering I am still learning what they are, your OWFS will make this all a lot easier for me. I just have a simple question about kernel, however. Obviously I will need to compile in 1-wire support, but do I need to get a driver for the specific device I have, or are they all so similar that the basic support is enough? I had assumed I would need a specific driver, but I have not found anything about any such drivers yet. I expected I would need to write my own driver first, but had hoped to find an example from a similar device to use as a guide. Thank you for any assistance you can provide, Matthew Percival --- 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_idt77alloc_id492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
RE: [Owfs-developers] More on Hanging Problems
This works for newer DS9490s, the older ones used an 01 device. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christian Magnusson Sent: Friday, July 01, 2005 5:26 AM To: owfs-developers@lists.sourceforge.net Cc: Paul Alfille; [EMAIL PROTECTED] Subject: Re: [Owfs-developers] More on Hanging Problems 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.00) 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.00 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=7477alloc_id=16492op=click
