On Jan 13, 2020, at 10:17 PM, Gene Heskett wrote:> >>> (I was looking at the hid-subdrivers.txt file in the latest NUT >>> tree, which has the command line amended to not generate that "too >>> many non-option arguments" error. Also, I wanted it to use the >>> existing cps-hid.c tables, not the generic "explore" sub-driver.) >> >> Attached, about 30 seconds worth >> > Was that enough to get it all?I should probably just ask for 60 seconds in the future :-) There are nearly 30 seconds' worth of "Quick update..." lines, but because the 30-second timer doesn't start until after everything is initialized (takes a few seconds at USB 1.1 speeds...), the "Full update..." line isn't there. But no matter, it is quite similar to the CPS SX650g dump - the HID report is byte-for-byte the same. Notably, the "hidrd-convert" tool fails part of the way through parsing it, which is why I suspect that CPS is not following the HID spec. (That's more applicable for the high/low transfer voltages.) It does seem to be reporting 0% load, though: 0.094786 Report[get]: (3 bytes) => 13 00 00 0.094875 Path: UPS.Output.PercentLoad, Type: Feature, ReportID: 0x13, Offset: 0, Size: 8, Value: 0 0.094908 Report[buf]: (3 bytes) => 13 00 00 0.095318 Path: UPS.Output.Overload, Type: Feature, ReportID: 0x13, Offset: 8, Size: 1, Value: 0
On Monday 13 January 2020 22:42:46 Charles Lepple wrote:> On Jan 13, 2020, at 10:17 PM, Gene Heskett wrote: > >>> (I was looking at the hid-subdrivers.txt file in the latest NUT > >>> tree, which has the command line amended to not generate that "too > >>> many non-option arguments" error. Also, I wanted it to use the > >>> existing cps-hid.c tables, not the generic "explore" sub-driver.) > >> > >> Attached, about 30 seconds worth > > > > Was that enough to get it all? > > I should probably just ask for 60 seconds in the future :-) > > There are nearly 30 seconds' worth of "Quick update..." lines, but > because the 30-second timer doesn't start until after everything is > initialized (takes a few seconds at USB 1.1 speeds...), the "Full > update..." line isn't there. > > But no matter, it is quite similar to the CPS SX650g dump - the HID > report is byte-for-byte the same. Notably, the "hidrd-convert" tool > fails part of the way through parsing it, which is why I suspect that > CPS is not following the HID spec. (That's more applicable for the > high/low transfer voltages.) > > It does seem to be reporting 0% load, though: > > 0.094786 Report[get]: (3 bytes) => 13 00 00 > 0.094875 Path: UPS.Output.PercentLoad, Type: Feature, ReportID: > 0x13, Offset: 0, Size: 8, Value: 0 0.094908 Report[buf]: (3 bytes) => > 13 00 00 > 0.095318 Path: UPS.Output.Overload, Type: Feature, ReportID: 0x13, > Offset: 8, Size: 1, Value: 0At this stage, its so much bigger than the load as its just the pi and interface logic on it, nothing else. Under 10 watts for sure. I should for safety's sake rig an advisory circuit from one of the motor supplies, to exert an e-stop signal on a power failure, else when power comes back it will start moving motors, without knowing where they are since theres no real hardware based position feedback in stepper driven machinery. Might see if the vfd has a power fail alarm, its pretty smart. Nothing is ever done until the paper is completed. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
On Tuesday 14 January 2020 00:03:09 Gene Heskett wrote:> On Monday 13 January 2020 22:42:46 Charles Lepple wrote: > > On Jan 13, 2020, at 10:17 PM, Gene Heskett wrote: > > >>> (I was looking at the hid-subdrivers.txt file in the latest NUT > > >>> tree, which has the command line amended to not generate that > > >>> "too many non-option arguments" error. Also, I wanted it to use > > >>> the existing cps-hid.c tables, not the generic "explore" > > >>> sub-driver.) > > >> > > >> Attached, about 30 seconds worth > > > > > > Was that enough to get it all? > > > > I should probably just ask for 60 seconds in the future :-) > > > > There are nearly 30 seconds' worth of "Quick update..." lines, but > > because the 30-second timer doesn't start until after everything is > > initialized (takes a few seconds at USB 1.1 speeds...), the "Full > > update..." line isn't there. > > > > But no matter, it is quite similar to the CPS SX650g dump - the HID > > report is byte-for-byte the same. Notably, the "hidrd-convert" tool > > fails part of the way through parsing it, which is why I suspect > > that CPS is not following the HID spec. (That's more applicable for > > the high/low transfer voltages.) > > > > It does seem to be reporting 0% load, though: > > > > 0.094786 Report[get]: (3 bytes) => 13 00 00 > > 0.094875 Path: UPS.Output.PercentLoad, Type: Feature, ReportID: > > 0x13, Offset: 0, Size: 8, Value: 0 0.094908 Report[buf]: (3 bytes) > > => 13 00 00 > > 0.095318 Path: UPS.Output.Overload, Type: Feature, ReportID: > > 0x13, Offset: 8, Size: 1, Value: 0 > > At this stage, its so much bigger than the load as its just the pi and > interface logic on it, nothing else. Under 10 watts for sure. >Trying to build a better kernel, a "make -j4 zImage", which puts all 4 cores to work, actually shows an 8% load, and that, running on the ondemand governor. I'll be curious what it says if this kernel works, because this one building is limited to performance only, which despite the fans, is about 4 times the clock speed so it is going to warm itself up.> I should for safety's sake rig an advisory circuit from one of the > motor supplies, to exert an e-stop signal on a power failure, else > when power comes back it will start moving motors, without knowing > where they are since theres no real hardware based position feedback > in stepper driven machinery. Might see if the vfd has a power fail > alarm, its pretty smart. Nothing is ever done until the paper is > completed. > > Cheers, Gene HeskettCheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
On Tuesday 14 January 2020 00:03:09 Gene Heskett wrote:> On Monday 13 January 2020 22:42:46 Charles Lepple wrote: > > On Jan 13, 2020, at 10:17 PM, Gene Heskett wrote: > > >>> (I was looking at the hid-subdrivers.txt file in the latest NUT > > >>> tree, which has the command line amended to not generate that > > >>> "too many non-option arguments" error. Also, I wanted it to use > > >>> the existing cps-hid.c tables, not the generic "explore" > > >>> sub-driver.) > > >> > > >> Attached, about 30 seconds worth > > > > > > Was that enough to get it all? > > > > I should probably just ask for 60 seconds in the future :-) > > > > There are nearly 30 seconds' worth of "Quick update..." lines, but > > because the 30-second timer doesn't start until after everything is > > initialized (takes a few seconds at USB 1.1 speeds...), the "Full > > update..." line isn't there. > > > > But no matter, it is quite similar to the CPS SX650g dump - the HID > > report is byte-for-byte the same. Notably, the "hidrd-convert" tool > > fails part of the way through parsing it, which is why I suspect > > that CPS is not following the HID spec. (That's more applicable for > > the high/low transfer voltages.) > > > > It does seem to be reporting 0% load, though: > > > > 0.094786 Report[get]: (3 bytes) => 13 00 00 > > 0.094875 Path: UPS.Output.PercentLoad, Type: Feature, ReportID: > > 0x13, Offset: 0, Size: 8, Value: 0 0.094908 Report[buf]: (3 bytes) > > => 13 00 00 > > 0.095318 Path: UPS.Output.Overload, Type: Feature, ReportID: > > 0x13, Offset: 8, Size: 1, Value: 0 > > At this stage, its so much bigger than the load as its just the pi and > interface logic on it, nothing else. Under 10 watts for sure. > > I should for safety's sake rig an advisory circuit from one of the > motor supplies, to exert an e-stop signal on a power failure, else > when power comes back it will start moving motors, without knowing > where they are since theres no real hardware based position feedback > in stepper driven machinery. Might see if the vfd has a power fail > alarm, its pretty smart. Nothing is ever done until the paper is > completed. > > Cheers, Gene HeskettNow I've got another of those WTF questions. This ups doesn't ID itself the same to an lsusb as it does to upsc. From an lsusb: Bus 001 Device 004: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS From a upsc: device.mfr: CPS device.model: CP625HGa ???? And while its not your problem, its keyboard and mouse goes away at random intervals, and isn't rediscovered by unplugging and replugging the hub the dongles are plugged into requireing a powerdown reboot, but the reboot isn't needed for an ssh -Y login! Its the local usb that failing? Still scratching head on this, but first move that hubs wall wart to the ups. It doesn't need it to run, but... Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>