UIST CAR errors and the faults that cause them
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…