[Nut-upsuser] mge-utalk ESV8+ comm problem
karabojkov at kit.bg
Thu Oct 18 21:21:14 UTC 2012
Sorry for being away for the last week and thank you all for your time
Today I tried to collect newer log file than one attached in my first post.
I used the same HDD with no modifications of config or OS, on the same
computer with the same interface cable (original MGE, not hand-made).
The computer is real - not VM to avoid eventual malfunction caused by
virtual access to RS232 ports.
It was very odd that the connection to the UPS suddenly started working!
I am able to read status and perform tests including fsd with 100 % success!
Before my first try I had UPS repaired. The inverter transistors had to
be resoldered. This does not impact communication circuits, at least not
The difference today was that since I was away and the device was
freshly repaired I disconnected its acumulators to avoid eventual
damages. Maybe this "hard reset" helped to the UPS controller to start
comunicating normally? But it worked with Eaton's Windows software!
I'll test it for at least a week before attaching it to my production
system. Non-reasonal function or malfunction is really disturbing.
The unit is old but it is from this low-efficiency generation that
produces very good sine waveform and does not wear its electronic
components (ex. capaciotrs) It surely has lead in its soldering
compounds and is not CFC-free (during production). The large and
half-empty heavy metal enclosure is also important for unit's
reliability. In fact the only reason to throw it out would be it's
denial to work with NUT on one of my FreeBSD servers.
I would be very glad if I can help testing the driver (and if you still
I have also access for testing to MGE Pulsar ES 11+ and an EL (i'll
clarify the exact model tomorrow).
Both are working without software support. I can test them with NUT.
Sorry for (maybe) false allarm.
On 18.10.2012 22:13 ч., Arnaud Quette wrote:
> 2012/10/16 Martin Loyer
> Salut Arnaud :D
> salut Martin !!
> спасение Ivo
> Ivo, we really need your implication to solve *your* issue!
> I have an old ESV8 UPS down here, and I did code patching
> years ago to
> support old model on nut.
> is your ESV8 still working?
> For sure :)
> This UPS is strong! By now, it is 18 years old :O
> made to last until the end of time ;)
> ah, good ol' MGE time.
> But, I got some bad effect, like Debian bug you mentionned
> on your email.
> Would be difficult for me to gain access to an ESV8+, but
> we can work
> together to test.
> even to me. all this goes back to MGE time, now defunct for 5
> the only things that survived is the Comet and E Series DX
> (see below)
> I may have access to an old ESV8+. I gave one to a friend of mine,
> years ago.
> that would be nice
> I can make some test, but I need more information. Could
> you send me your
> debug log?
> I think I've found a Comet and a E Series DX (so speaking
> UTalk) at Eaton today.
> this is the kind of things that becomes rare nowadays!
> on the patch side, I'd also like to:
> - add some more inter-char delay, since mge_command() only has
> 100 ms.
> I've just checked again Utalk spec , and we should be at
> least 500
> ms between commands.
> the point here is that this inter-char delay is not satisfied with
> commands that do not receive an answer (such as Z)
> Interesting. If we are hearing too fast, it's not that good.
> we're *talking* too fast actually ;)
> For specific commands (such as Z), we may just wait and ignore any
> answers (as we did by the past).
> not sure to get your point!? we still ignore the result of
> mge_command(... Z)
> - see the result of Marek's mention, i.e moving the double Z
> before the Si test.
> For sure. I dig on my archives, and found a serial spy log taken
> on Windows between PSP and ESV8.
> Z is send twice, then AX 1, then SI 1.
> yep, with 500 ms inter-commands... I still have access to that code ;)
> By the way, I worked a lot to make support of programmable
> outlets. By now, it is not supported (even for recent UPS, working
> on usb-hid). I may test and patch.
> @Ivo: could you send me your log file?
> @Martin: how do you want to proceed on the UTalk issue?
> I can either provide a (set of) patch(es), or few directions...
> Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
> Debian Developer - http://www.debian.org
> Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsuser