Hi Carlos, How do you do? :) Can you please clarify the change introduced by the subj (http://boxster.ghz.cc/projects/nut/changeset/1289)? I need to know in particular why did you add these intervals between sending a command and reading the response. They are the root of weird problems with megatec_usb. Can I safely remove READ_PACE and usleep-s? I tried to search the archives and found the related thread: http://lists.alioth.debian.org/pipermail/nut-upsuser/2008-February/003724.html Unfortunately it doesn't answer my question. -- Alexander
Hi! I don't remember why I added those lines, and at first sight they don't make any sense because the read waits up to 2 seconds or a carriage return (whichever comes first), so it would wait those 300ms anyway. Which is why I think they were added for a reason... Now if that reason made sense or not, that's another story... :) But in the remote case those lines really do something, removing them will at most cause some glitches in some single model that only one person has. So I guess if they are causing problems with megatec_usb (and USB models are much more popular nowadays), it is better to just remove them. Regards, Carlos Rodrigues On Mon, Jun 8, 2009 at 2:23 PM, Alexander Gordeev<lasaine at lvk.cs.msu.su> wrote:> Hi Carlos, > > How do you do? :) > > Can you please clarify the change introduced by the subj > (http://boxster.ghz.cc/projects/nut/changeset/1289)? I need to know in > particular why did you add these intervals between sending a command > and reading the response. They are the root of weird problems with > megatec_usb. Can I safely remove READ_PACE and usleep-s? > > I tried to search the archives and found the related thread: > http://lists.alioth.debian.org/pipermail/nut-upsuser/2008-February/003724.html > Unfortunately it doesn't answer my question. > > -- > ?Alexander >
On Mon, 8 Jun 2009 16:57:14 +0100 Carlos Rodrigues <cefrodrigues at gmail.com> wrote:> Hi! > > I don't remember why I added those lines, and at first sight they > don't make any sense because the read waits up to 2 seconds or a > carriage return (whichever comes first), so it would wait those 300ms > anyway. Which is why I think they were added for a reason... Now if > that reason made sense or not, that's another story... :) > > But in the remote case those lines really do something, removing them > will at most cause some glitches in some single model that only one > person has. So I guess if they are causing problems with megatec_usb > (and USB models are much more popular nowadays), it is better to just > remove them.Thanks! So I'll remove them and we'll see if anyone complains. :)> On Mon, Jun 8, 2009 at 2:23 PM, Alexander > Gordeev<lasaine at lvk.cs.msu.su> wrote: > > Hi Carlos, > > > > How do you do? :) > > > > Can you please clarify the change introduced by the subj > > (http://boxster.ghz.cc/projects/nut/changeset/1289)? I need to know > > in particular why did you add these intervals between sending a > > command and reading the response. They are the root of weird > > problems with megatec_usb. Can I safely remove READ_PACE and > > usleep-s? > > > > I tried to search the archives and found the related thread: > > http://lists.alioth.debian.org/pipermail/nut-upsuser/2008-February/003724.html > > Unfortunately it doesn't answer my question. > > > > -- > > ?Alexander > >-- Alexander
Apparently Analagous Threads
- new features on Testing branch (was: Belkin F6H375 not seen by nut 2.2.1)
- new features on Testing branch (was: Belkin F6H375 not seen by nut 2.2.1)
- Re: [nut-commits] svn commit r801 - in branches/megatec-usb: . drivers
- Ippon device does not work
- nut: megatec_usb shows error "ser_send_pace: Device detached" on periodically checks