CUPS has 3 fields that are used in issue reporting,
printer-state (enum): Either idle, processing or stopped.
printer-state-message: Plain text human readable explanation.
printer-state-reasons: Listed description of the printer state, as described in RFC8011 p.152 this is where the real issue reporting happens. It has a list of comma delimited keywords describing the state of a printer eg. 'media-needed' or 'toner-low'
When testing a Zebra LP 2844 on Ubuntu 16.04 (and mac but let's keep this simple for now) using the Zebra EPL2 Label Printer driver, I get the following results.
----Printer out of paper----
Status Enum: processing
Status Message: printer-state-message: 1 textWithoutLanguage {Waiting for
printer to become available.}
Status Reason: printer-state-reasons: 1 keyword {none}
----Printer rejecting jobs----
Status Enum: idle
Status Message: printer-state-message: 1 textWithoutLanguage {Rejecting Jobs}
Status Reason: printer-state-reasons: 1 keyword {none}
As you can see, the 'Printer out of paper' issue and most issues that prevent the printer from printing resolve as 'processing' and never give me more information. You could figure out how long the printer has been 'processing' and deduce if there is a problem from there, but besides that being janky, the cause of the issue would remain unknown.
Meanwhile, the 'Printer rejecting jobs' state tells me absolutely nothing (remember, the Status Message is just human readable plain text and is not parsable due to there being no guidelines on what is put there). Besides hiring someone to read state-message there is no way for my program to know there is an issue.
This is not the case with all printers, for example, this is the output from a Brother HL-L2380DW
----Printer out of paper----
Status Enum: processing
Status Message: printer-state-message: 1 textWithoutLanguage {Waiting for job to complete.}
Status Reason: printer-state-reasons: 2 keyword {cups-waiting-for-job-completed, media-needed-error}
Of the 3 printers tested so far (HP, Brother, and Zebra), the Brother HL-L2380DW was the only printer to properly communicate issues. If you wish to test it yourself you can run this crude CUPS tool I tossed together in java https://github.com/Vzor-/cupstool More data helps!
I do not know if the issue lies with cups or with the manufacturers. Either way I need a way forward, be it as a fix or a group I can help to make a fix.
Edit: It seems Zebra does not make or maintain its own Linux drivers.
From Michael Sweet,
Kyle,
Status reporting is complicated, but in general the problem with
driver-based queues can come from the driver not implementing STATE:
message support (typically because the printer's communication channel
does not provide support) or from the printer itself not supporting
any kind of status reporting.
In the case of the Zebra printer, it does not support in-band status
reporting so the CUPS-bundled driver has no way of getting status from
the printer that way. It also does not support the SNMP Printer MIB
for status, so we don't even get out-of-band status... :/ Sadly,
these kind of printers often do not support status reporting, which is
funny given that many are deployed in industrial settings where remote
monitoring is common...
Printers that implement IPP (typically all printers these days except
label printers - so 98%+ of printers) support the IPP
printer-state-reasons keywords for status, in addition to other IPP
attributes and (in many cases) SNMP Printer MIB properties as well.
So it seems this is mostly just an issue with some label printers.
Related
I've been exploring the ADAM 6717 from Advantech.
This is the ModBus address table for said device:
At first I wanted to modify the value of the Digital output channel 0(DO0), so, as can be seen from the picture above, such address is the 0x0017.
I succeed at this by using a ModBus tool and the following settings:
Sending either "On" or "Off", turns On and off a LED connected to that output. Everything runs smoothly according to my expectation up to this point.
The problem arises when I want to read the Analog Input channel 6 or equivalently, address 400431~40044.
Since that address lies on the Analog Output Holding Registers part of the address table, I though that the following settings would accomplish the job:
However, as can be seen above, the reading shows 0.0 when there is actually 6V connected to that input (a potentiometer)
It is worth mentioning that I've made sure to enable the AI6 channel as well as setting it to Voltage mode instead of current. Also, the web utility for the device shows the AI6 reading correctly as I change the potentiometer's resistance value.
So the problem doesn't lie in the connection from the potentiometer to the AI6 but somewhere else.
Out of nothing and leaving aside what I think I know on this topic, I though of changing the function from 0x03 to 0x04
However, the response is exactly the same.
It bugs me that I can read and write values to the output coils but not the Analog output holding registers.
Is there any configuration that I might be missing over here?
Thanks in advance.
Device settings:
IP address: 10.0.0.1
Port in which the ModBus service is running: 5020
I have the problems with both SAVIHost v1.43 and VSTHost v1.57 for the case of Dexed 0.9.6. As I am a hobbist only, related to both MIDI and IT, I wish to ask some help to overcome these problems detailed below.
My problem with SAVIHost V1.43:
I copied savihost.exe (extracted from savihost3x64.zip) copied into directory "C:\Program Files\Common Files\VST3" (i.e. into the installation directory of Dexed.vst3) then renamed it to Dexed.exe, and launched this Dexed.exe.
I set "loopMIDI Port 1" (created prior by "loopMIDI v1.0.16 (27)") as "Input Port 1" via "Devices|MIDI..." and "1764 samples (25 b/s)" via "Devices|Wave...". (The sample rate was 44100 Hz, and both ports were "MME: Microsoft Sound Mapper).
Then I played some sounds by use of the virtual keyboard, and changed Dexed's programs (instruments) randomly - and Dexed seemed to work well, it played the different sounds with the actually selected instruments. Then I sent some MIDI Messages by Cakewalk by Bandlab to "loopMIDI 1"; Dexed produced the appropriate sounds, according to MIDI Note On/Off messages received - except that all the MIDI Program Change messages (C0 xx) were ignored.
Finally, when I clicked onto icon of Dexed.exe (i.e. renamed savihost.exe) in the Windows 10 Taskbar on the screen: the main window of Dexed.exe was minimized,
but when I clicked onto its icon again, although its main window is restored but crashed immediately. A dialog titled as "Dexed" appered,
containing an error message:
Unhandled exception 0xC0000005 at 00000014005BEBA
reading from FFFFFFFFFFFFFFFF
(followed by a list of the recent content of registers).
Furthermore, I noticed that resizing of window of Dexed.exe (moving its bottom edge upward) also causes a crash, but only after when Dexed.exe received some MIDI messages through "loopMIDI Port 1".
(i.e. playing on virtual keyboard, followed by similar resizing did not cause crashes - at least, I have not realized that.)
The situation was ditto for the case of SAVIHost V1.44 beta.
Problem with VSTHost V1.56 x64:
In the second case, I started VTSHost.exe, then loaded Dexed.vst3 via File|New Plugin... . Dexed.vst3 also seemed to work well at the beginning, i.e. while I played on the virtual keyboard bar, and changed the programs (instruments) and modified some parameters by the knobs on the screen. But when VSTHost received the first MIDI messages through the "loopMIDI Port 1", Dexed does not played any notes anymore. Instead, some extra message lines appeared in the dialog "Info" below the line "Chained as Insert before 1: Engine Output":
...
Processing is turned off (errors in PlugIn?)
ProcessReplacing
Exception 0xC0000005 at 000000014007ABF6 reading from 0000000000000000
...
Stack Trace:
...
Unfortunately, the situation was the same in case of VSTHost V1.57 beta x64.
Comments:
Dexed.vst3 worked without problems in case of other VST host apps (e.g. CakeWalk by BandLab and Cantabile 4 Lite), i.e. also the MIDI Program Change messages were executed properly.
(CakeWalk by Bandlab used Dexed.vst3 directly, Cantabile 4 Light received MIDI messages from CakeWalk by BandLab through "loopMIDI Port 1".)
similarly, the original standalone Dexed application also processed the MIDI Program Change messages through "loopMIDI Port 1" correctly.
version number of Dexed.vst3 reported as 1.0.0 by VSTHost (although is is originated from unzipping of "dexed-0.9.6-win.zip").
my PC has the followings:
-- OS: MS Windows 10, 22H2, build: 19045.2311 (x64)
-- CPU: Intel(R) Core(TM) i5-4460 CPU # 3.20GHz
-- RAM: 8 GB
-- motherboard: Gigabyte Technology Co., Ltd. B85M-D2V
-- sound: Realtek, High Definition Audio (on-board)
Finally, I wish to mention that I have tried other VSTs than Dexed's one with both SAVIHost and VSTHost: "sforzando.vst3" and "Roland Sound Canvas VA.dll".
There were no problem at all - no interception of any MIDI Message, no crash, etc -, they had been worked without any problem for hours. So I am not really sure, what and where are the root of the problems above: maybe in SAVIHost or VSTHost - or maybe in Dexed.
I wish ask some help, how I shall continue to determine, which component - ie. savihost/svthost or Dexed - is failed and resulted the problem?
Thank you very much for you kind efforts in advance!
To illustrate an example scenario that prompted this question, please consider the following:
A room, attic, that contains 3 devices: one light that supports both ColorSpectrum and ColorTemperature, one light that only supports ColorTemperature and one light that only supports ColorSpectrum (all 3 also support OnOff and Brightness, but this appears to be irrelevant).
"Set the attic to warm white" will result in two of the lights receiving a temperature value in Kelvin, whereas the third (which didn't support ColorTemperature) will receive an rgb/hsv color value approximating the correct hue of white.
Conversely: "Set the attic to red" will result in all 3 lights receiving an rgb/hsv color value (including the light that does not support the ColorSpectrum trait).
We are unsure how a light that supports only ColorTemperature is supposed to respond to an rgb/hsv value. This final scenario - after the light's failure to be able to execute the user's command - left us with 3 options to respond:
Lie and respond 'SUCCESS' for all 3 lights, "Ok, changing 3 lights to red."
Omit the third light from the response entirely, "Ok, changing 3 lights to red."
Respond with "notSupported" 'ERROR' for the third light, "Ok, changing 2 lights to red. That mode isn't available for the LIGHT_3."
Option 1 is clearly undesirable, incorrect feedback is worse than no feedback at all.
Option 2 is equivalent to 1, though it seems odd that Google Home should assume that a device omitted from a response was successfully processed.
Option 3 we deem unideal as well, as we expect the user may get bored of hearing that a certain light in their room is unable to change color when they might be perfectly aware of this fact. Our preference would go to a response of: "Ok, changing 2 lights to red." We feel that this communicates clearly that one light didn't change, without the potentially superfluous error message.
Our question, then, is how we might realize this?
Is the behavior listed above unintended (a bug)?
Is there some response that we are unaware of that can be used to communicate to Google Home that a device simply is not eligible for the provided execution?
Is the behavior listed above not experienced by others or the result of a mistake on our part?
Thank you for reading.
I'm going to check about this scenario as it might be a bug in which devices get commands when they shouldn't.
Canonically, option three may be undesirable but is the right implementation. Trying to ignore the command will also create a bad user experience as they receive an incorrect reply.
We have an virtual audio device driver similar to Sound flower. This virtual device will be listed in sound system preferences. Whenever our device gets selected in system preferences, it prevents idle sleep. If we switch the selection to default output device, everything works as expected.
If we execute 'pmset -g assertions' command in Terminal, it gives below output
Assertion status system-wide:
ChargeInhibit 0
PreventUserIdleDisplaySleep 0
PreventUserIdleSystemSleep 1
NoRealPowerSources_debug 0
CPUBoundAssertion 0
EnableIdleSleep 1
PreventSystemSleep 0
DisableInflow 0
DisableLowPowerBatteryWarnings 0
ExternalMedia 0
Listed by owning process:
pid 115: [0x0000012c00000073] PreventUserIdleSystemSleep named: MY_DRIVER_IDENTIFER.noidlesleep"
Could any one suggest me some pointers to resolve this issue.
I think this governed by the flag kIOPMPreventIdleSleep, which resides in the capabilityFlags field of the IOPMPowerState struct.
To participate in power management decisions, you'll need to add your device driver to the power management plane, typically in your overridden IOService::start(provider) method:
PMinit();
provider->joinPMtree(this);
registerPowerDriver(this, powerStates, numPowerStates);
where powerStates and numPowerStates specifies an array of power states you want your device to be able to be in. You'll probably not want more than 2 for a virtual device, and maybe you even only need one. I suspect a superclass of your class is setting states that are inhibiting sleep. Once you've registered for power management, your driver will be expected to handle the power management methods such as IOService::setPowerState().
Depending on how you want your device to behave, you might want to create 2 power states, one "live" when playing back or capturing sound (and inhibiting sleep) and the other "idle" when the device isn't doing anything, and allowing sleep.
The power management topic is a bit too big to cover entirely in a StackOverflow answer, so I suggest you read the docs on the stuff I've mentioned above and try clearing the relevant flag in your power state(s).
Hope that helps.
I am using xen hypervisor. I am trying to get the IO count of the VMs running on top of the xen hypervisor. Can someone suggest me some way or tool to get the IO count ? I tried using xenmon and virt-top. Virt-top doesnt give any value and xenmon always shows 0. Any suggestions to get the number of read or write calls made by a VM or the read and write(Block IO) bandwidth of a particular VM. Thanks !
Regards,
Sethu
You can read this directly from sysfs on most systems. You want to open the following directory:
/sys/devices/xen-backend
And look for directories starting with vbd-
The nomenclature is:
vbd-{domain_id}-{vbd_id}/statistics
Inside, you'll find what you need, which is:
br_req - Number of block read requests
oo_req - Number of 'out of' requests (no room left in list to service any given request)
rd_req - Number of read requests
rd_sect - Number of sectors read
wr_sect - Number of sectors written
The br_req will be an aggregate count of things like write barriers, aborts, etc.
Note, for this to work, The kernel has to be told to export Xen attributes via sysfs, but most Xen packages have this enabled. Additionally, the location in sysfs might be different with earlier versions of Xen.
have you tried xentop?
There is also bwm-ng (check your distro). It shows block utilization per disk (real/virtual). If you know the name of the virtual disk attached to the VM, then you can use bwm-ng to get those stats.