UIST CAR errors and the faults that cause them

General Note:
You’ll need to look at the following: (open them now if you don’t have them open already)

• WFG serial console (you can get to errors that happened before you open it by scrolling the buffer (hitting 1 followed by carriage return), or just get the new output by hitting 2 followed by carriage return. I usually first look at the buffer and then hit “2 “)
• Uist_oper screen
• Sequence console and its error boxes

Remember the following two things:

• it is almost always unnecessary to reboot Edict to fix most problems.
• ocs_down/ocs_up rarely gets you anywhere.

FAULT STATES in detail:

fault state: newGroup error:
newGroup errors never occur by themselves and are (almost?) always caused by running from too high up in a sequence after an error has occurred.
– run the OCS down; fix underlying errors (see below: CCS-Edict communication problems, mechanism errors, disabled array); run the OCS back up.

fault state: UOCS CAR error:
hardly ever happens by itself. It is usually caused by an underlying problem that is reported that way at a level that you can’t get past without acknowledging error boxes. In itself a CAR error is generally harmless. Look for the underlying errors.

• mechanism errors (on uist_oper screen): datum the mechanism that has the error, set the highlight on the sequence console to the previous “set OBJECT|DARK|FLAT|ARC|” and run from highlight. You DON’T need to run from set config.
• array disabled itself: see below
• command and/or observe status on the uist_oper screen is “error” – this will usually but not always also disable the array unless there is a mechanism error involved. If there is a mechanism error involved, it should go away after the “set config”, otherwise treat it like a “array disabled” error.

fault state: array disabled itself

See main trouble-shooting page…