networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
2.07k stars 350 forks source link

"Driver failed to start" on "upsdrvctl start", with no error info #1897

Open bluieshell opened 1 year ago

bluieshell commented 1 year ago

in NUT window 2.6 "upsc.exe ups" I always get "Error: Data stale" in NUT window 2.8 "upsc.exe ups" I always get "Error: Driver not connected" (I'v modified some code to compile v2.8, it may cause error) I 'v tested with "libusb-win32-bin-1.2.7.3" and "libusb-win32-bin-1.2.6.0" and get same error。

I can't find the way to fix my problem. then, I find that, when I call "upsdrvctl start", I get the driver was fail to start. everything echo No error, but it failed.

C:\Program Files (x86)\NUT\bin>upsdrvctl start Network UPS Tools - UPS driver controller Windows-v2.6.5-6-18-gd1b8d14d1 Network UPS Tools - NUT Huawei UPS2000 (1kVA-3kVA) RS-232 Modbus driver 0.04 (2. 8.0.1) Warning: This is an experimental driver. Some features may not function correctly.

w32_serial_open (\.\COM6) setting initial state on \.\COM6 00000084 = w32_serialopen (\.\COM6) Warning: no locking method is available: No error [操作成功完成。 ] vmin 0, vtime_ 0 action 0 vtime 0, vmin 1

ReadTotalTimeoutConstant -2, ReadIntervalTimeout -1, ReadTotalTimeoutMultiplier -1 modbus_connect: unable to connect: No error Driver failed to start (exit status=1)

jimklimov commented 1 year ago

Wondering if it should be about "serial port" (COM6) when you are using libusb for communications. If there's some USB-to-serial chip involved in a way that you're using serial-port NUT drivers, then libusb should be irrelevant as it is not in codepath. If you're using USB, then the "COM6" should not pop up, I think (at least not on POSIX platforms).

One issue I had was detailed in #1690 about getting Windows to use libusb-compatible OS driver which we can then connect to from NUT driver (not the default HID Battery driver which is exclusive to the OS itself).

Beside that, I'd suggest setting up NetBeans 17 (and C plugins from NetBeans 8.2 Legacy repo) and MSYS2 on Windows, and natively build the current NUT codebase there and run your driver in a debugger step by step - hopefully that would expose more about what goes wrong in your case. Note you'd want to directly run and step through the driver (not upsdrvctl helper) - and at that, maybe the actual drivers/.libs/DRIVERNAME.exe and not the libtool wrapper in drivers.

Per https://github.com/orgs/networkupstools/projects/2/views/1 it may also be that something is just not finished in the NUT port and an ifdef leads to an empty codebase block. There were a few known places listed in issues of that project.

Otherwise, not sure about the mix of upsdrvctl from 2.6.5-based code (so mostly 13 years old) with a more modern driver. By commit I see you used last year's Windows-v2.6.5-8 tag which was a stepping stone to getting Windows support merged back into master branch later in the year), and what else could be mismatched here.

jimklimov commented 1 year ago

Also, CLI arguments for debug verbosity can go a long way towards understanding the problem. With modern upsdrvctl you can pass debug args to the actual driver(s) as upsdrvctl -DDDDDD -d start