The DAX/2 System – Version 8.0.5
33
This is caused by an improper value (or no value) stored for the unit’s permanent color. Devices such as the NS illumination
control panel only set the unit’s accent color temporarily. To store a permanent color, type
color save
over the remote
console (or have the unit perform the equivalent
@color save
) once it has been set. Alternatively, the
manage ::
identity :: set color
prompt in the menu system will always set the permanent accent color. This should also resolve
issues with inconsistent coloring of the screen following module resets.
Fixing stuck subsystems.
In rare cases following charging, or when recovering from a period of low power, the unit may still have certain subsystems
powered off. Use the
status
main menu item on the local panel or TTY access (or the remote command
power
) to deter-
mine which subsystems are disabled—or, if no subsystems appear to be disabled, use the chart on page 11 to diagnose
which subsystems have entered a powered-down state unexpectedly. Then, toggle the subsystems until they regain normal
behavior via the
subsystems
menu or with the command
power
<subsystem>
, wh
ere <subsys
tem> is the name of
the affected component. If the subsystem is listed as disabled, one toggle should suffice; if it is not, then it will be neces-
sary to toggle it twice.
Charging-related issues
: The DAX/2 deliberately powers down certain subsystems during charging to accelerate the re-
generation process. If a charger malfunction occurs, and your unit remains unable to move or speak freely, reset the
coil
module in the
manage :: module reset
menu, or type
coil reset
via the remote console.
Interference-related issues
: If the unit reports that a fault has been detected in one or more of its subsystems, it may
appear to behave as though these subsystems are disabled. These anomalies in function, called
interference
, are a result of
exposure to improperly shielded electromagnetic sources that are not compliant with FCC guidelines. Depending on the se-
verity of the interference, the subsystems may remain disabled for up to an hour after the unit is removed from the vicinity
of the source of the malfunction. If it is absolutely vital to clear the malfunction in a more timely manner, resetting the
power
module in the
manage :: module reset
menu and then rebooting the unit is generally adequate to fix the be-
havior. (There is no remote access command for this in 8.0.5.)
Vision remains obscured after controller is removed.
Reattach and remove the controller again to properly reset the host unit’s vision processors.