Table of Contents
Previous Chapter
This shell and all of the programs that it launches inherit the open socket descriptor that connects to the CTUE. (This socket descriptor is available in environment variable CTUE_CMD_SD.) To send commands to the CTUE use:
ACISshell% buildCmds < ACIS command script file | sendCmds | writeCCB
or:
ACISshell% cat < CTUE command block file > &$CTUE_CMD_SD
ACISshell tries to open port 541 for CTUE commands. This port number is in the range that only root can open. If ACISshell is not running with root priviledges, it will try to open port 7541 for CTUE commands. The appropriate port number must be entered in the CTUE's c:\windows\thernet.cfg file. The IP address of the host where ACISshell will run must also be entered in this file. The CTUE will connect only to the IP address and port indicated.
To connect to the CTUE, the user should first execute ACISshell and then use the CTUE's GUI to select ACIS commands from the Ethernet control section. ACISshell, like the CTUE, handles only a single connection. When that connection terminates, so does the program and so does the connection to the CTUE. However, commands can be sent repeatedly while the ACISshell% prompt is displayed.
Ann M. Davis, MIT CSR for the network code.
CTUE User's Manual
FEP hardware and software can be simulated using acisFepUnix. Each instance of a simulated FEP is a distinct invocation of acisFepUnix. The BEP simulator communicates with the simulated FEPs through shared memory segments.
cserver must be in the user's search path.
This program is currently only supported for the DECstations running Ultrix.
Fatal Messages:
None
Warning Messages:
None
Informatory Messages:
Discrete Software Telemetry codes (LED codes) appear on stderr as they are written to the "hardware" by the flight software.
The message "WarmFuzzy" is written to stderr once about every 5 seconds.
Commands to the DEA are decoded and written to stderr.
Only one acisFepUnix program with a given fepId may be active on a single machine at a time.
This program is currently only supported for the DECstations running Ultrix.
Fatal Messages:
If the program fails to obtain shared memory segments, it will issue an error message to stderr and exit with a -1.
Warning Messages:
None
Informatory Messages:
During initialization, the program prints information about its shared memory segments to stderr.
When the FEP program is "reset" it prints a "Calling fepCtl()" message to stdout.
acispkts reads the stdout stream from the LRCTU handler, rctu2b, identifies individual ACIS telemetry packets, and writes them to the standard output stream, stdout.
Unless the -np option is specified, acispkts will generate one science frame pseudopacket and one engineering pseudopacket for every simulated LRCTU science pulse, at 2.05 second intervals. The science frame pseudopacket will contain the 32-bit BEP science pulse timestamp and a time-of-day clock value in IRIG-B format derived from the gettimeofday() system call. The origin of the IRIG day number is 0h, January 0 of the current year. CCSD major and minor frame counts start at zero. Engineering pseudopackets contain the 8 LED hardware status bits, recorded in two 16-bit data fields, one bit per nibble, e.g. status bits of `00110110' will be reported as 0x0011, followed by 0x0110.
The bcmd command scripts obey the following rules: a "#" sign begins a comment and causes the remainder of the line to be ignored. Blank lines will also be ignored. Each command must appear on a single line, unless it ends with a "{" sign, in which case it continues on as many lines as necessary to define the block, each containing a single "keyword = value" statement, and terminating with a line containing a single "}". The keyword names are identical to those in the IP&CL structures tables.
In the following command lists, the construction "< x | y >" means "necessarily, either x or y\c ".
Software Serial Commands
Hardware Serial Commands
add n cc badcolumn <{|file> add n te badcolumn <{|file> add n badpixel <{|file> add n patch d d <{|file> change n systemconfig <{|file> continue n uplink <{|file> dump n badpixel dump n cc dump n cc badcolumn dump n dea dump n huffman dump n patchlist dump n systemconfig dump n te dump n te badcolumn dump n window1d dump n window2d exec n n exec n d <{|file> exec n fep d n exec n fep d d <{|file> load n cc d <{|file> load n dea d <{|file> load n te d <{|file> load n window1d d <{|file> load n window2d d <{|file> read n d n read n fep d d n read n pram d d n read n sram d d n remove n patch <{|file> reset n badpixel reset n cc badcolumn reset n te badcolumn start n cc n start n cc bias n start n dea n start n te n start n te bias n start n uplink d d d <{|file> stop n dea stop n science wait n write n d <{|file> write n fep d d <{|file> write n pram d d <{|file> write n sram d d <{|file>
halt bep program eeprom n n run bep select bep <a|b> select eeprom <programming|telemetry> set <warmboot|bootmodifier> <off|on> set radiationmonitor <high|low> verify eeprom nHardware Pulse Commands
<open|close> <door|vent|relief> <a|b> <openabort|closeabort> <door|vent> <a|b> <enable|disable> <dabake|daheater|dea|door|dpa|pressure|relief|vent> <a|b> <poweron|poweroff> <dabake|daheater|dea|dpa> <a|b>
Italicized arguments represent user-supplied values; those in normal type must appear unaltered, except that upper and lower case letters may be freely interchanged, except in file names. All numeric arguments may be entered as signed decimal integers or, if preceded by "0x", as unsigned hexadecimal integers. If preceded by "0" alone, they will be interpreted as unsigned octal integers.
Within parameter blocks, i.e. between the "{" and "}" characters, the following fields are determined from the command line and from other keywords, so they do not need to be specified:
ccBlockSlotIndex checksum commandLength commandIdentifier commandOpcode deaBlockSlotIndex teBlockSlotIndex windowSlotIndex (in window1d and window2d blocks, only)
When a block contains fixed-length arrays, e.g. fepCcdSelect in teBlock, the values, 6 in this case, must appear on the same line, i.e.
fepCcdSelect = 0 1 2 3 10 10
When a block contains varying-length arrays of structures, e.g. windows in window2d, the structures must be defined in the following manner:
load 2 window2d 1 { windowBlockId = 0x00000abc windows = { ccdId = 0 ccdRow = 50 ccdColumn = 150 width = 99 height = 99 sampleCycle = 1 lowerEventAmplitude = 0 eventAmplitudeRange = 65535 } windows = { ccdId = 0 ccdRow = 250 ccdColumn = 350 width = 99 height = 99 sampleCycle = 1 lowerEventAmplitude = 0 eventAmplitudeRange = 65535 } }
buildCmds creates a binary ACIS command stream from a script read from stdin.
The full syntax is as follows:
command cmdId [ arg_1 ... arg_n ]
The remaining arguments arg_1 ... arg_n depend on the particular command. They are of the following types:
{
parameterBlockName = nameId
keyword1 = value 1
keyword2 = value 2
.
keywordN = value N
}
* arguments * badcolumn * badpixel * ccblock * configsetting * deablock * patches * teblock * window1d * window2d
Each ACIS command must therefore appear on a separate input line. The only exception is that in-line param_blocks may contain newline characters within the enclosing braces.
The following commands will be prefixed by a 4-byte header that sends them to the software serial command port of the DPA.
This command reads data to add in BEP memory and outputs a binary stream to the standard output, stdout, which contains the commands in the format requested by the ACIS software.
- add cmdId badPixel paramBlock
- add set of pixels to Timed Exposure Bad Pixel Map
- add cmdId cc badColumn paramBlock
- add set of columns to Continuous Clocking Bad Column Pixel Map.
- add cmdId patch patchId address file
- add a patch to the specified address corresponding to patchId slot.
- add cmdId te badColumn paramBlock
- add set of columns to Timed Exposure Bad Column Pixel Map.
When the entire block cannot be stick in one command, the buildCmds subdivides the parameter block into sections and outputs several commands.
A list of the parameter keywords contained in the parameter block is given in the example section.
Examples:
add 12 cc badColumn { paramBlockName = badColumn ccdId = 2 ccdColumn = 34 }add 23 te badColumn { paramBlockName = badColumn ccdId = 2 ccdColumn = 34 ccdId = 4 ccdColumn = 5 }
add 15 badPixel { paramBlockName = badPixel ccdId = 2 ccdRow = 4 ccdColumn = 50 ccdId = 5 ccdRow = 4 ccdColumn = 60 }
The two sets: ccdId, ccdColumn, and ccdId, ccdRow, ccdColumn, can be repeated until a maximum of TBD times. Note that the order of the keywords is significant-ccdId must precede ccdRow, which must precede the ccdColumn to which it refers.
This command reads the list of parameters to change in the System Configuration parameter block and outputs a binary stream, stdout, which contains the command in the format requested by the ACIS software.
- change cmdId systemConfig paramBlock
- request to overwrite the existing system configuration block as indicated by the entries in the command packet
A list of the parameter keywords contained in the parameter block is given in the example section.
Example:
change 22 systemConfig { paramBlockName = configSetting itemId = 2 itemValue = 8 }
The set, itemId and itemValue, can be repeated until a maximum of TBD times.
This command reads a binary file containing the data to uplink and outputs a binary stream to the standard output, stdout, which contains the command and the data to uplink in the format requested by the ACIS software. The maximum size of the binary file is 249 16-bit words corresponding to one command packet.
- continue cmdId uplink file
- request to continue the uplink boot using the data contained in the packet
file is the name of a binary file containing the data to uplink.
Example:
continue 35 uplink file
This command reads the identification of the memory section to dump and outputs a binary stream to the standard output, stdout, which contains the command in the format requested by the ACIS software.
- dump cmdId badPixel
- request to dump the Bad Pixel Map
- dump cmdId cc
- request to dump every Continuous Clocking parameter block stored in memory
- dump cmdId cc badColumn
- request to dump the Continuous Clocking Bad Column Pixel Map
- dump cmdId dea
- request to dump every DEA parameter block stored in memory
- dump cmdId huffman
- request to dump huffman tables
- dump cmdId patchList
- request to dump the patchList
- dump cmdId systemConfig
- request to dump the System Configuration parameter block
- dump cmdId te
- request to dump every Timed Exposure parameter block stored in memory
- dump cmdId te badColumn
- request to dump the Timed Exposure Bad Column Pixel Map
- dump cmdId window1D
- request to dump every window 1D blocks stored in memory
- dump cmdId window2D
- request to dump every window 2D blocks stored in memory
Example:
dump 35 badPixel dump 36 cc badColumn dump 37 te
This command reads memory bank, address, and optional arguments of the function to execute and outputs a binary stream to the standard output, stdout, which contains the command in the format requested by the ACIS software.
- exec cmdId address
- request to execute the function located in bep memory at the indicated address
- exec cmdId address argumentBlock
- request to execute the function located in bep memory at the indicated address with the specified arguments
- exec cmdId fep fepId address
- request to execute the function located in fep memory at the indicated address
- exec cmdId fep fepId address argumentBlock
- request to execute the function located in fep memory at the indicated address with the specified arguments
fepId specifies the FEP memory where the function is located. The value is a decimal integer in the range 0-5. If the fep and fepId keywords are missing, the default memory is BEP.
argumentBlock contains the list of arguments used by the function.
Example:
- exec 2 0x1111111
- execute the function located in the BEP at address 0x11111111
- exec 56 fep 5 0x12345678
- execute the function located in the FEP 5 at address 0x12345678
- exec 44 0x22222222 {
- exec 24 fep 3 0x1234 {
The command reads the parameter block information and outputs a binary stream to the standard output, stdout, which contains the command in the format requested by the ACIS software.
- load cmdId cc slotId paramBlock
- request to load the Continuous Clocking parameter block in the specified slot
- load cmdId dea slotId paramBlock
- request to load the dea parameter block in the specified slot
- load cmdId te slotId paramBlock
- request to load the Timed Exposure parameter block in the specified slot
- load cmdId window1D slotId paramBlock
- request to load the window 1-D parameter block in the specified slot
- load cmdId window2D slotId paramBlock
- request to load the window 2-D parameter block in the specified slot
cc, te, dea, window1D, and window2D are keywords identifying the parameter block to which the action is applied. In particular, cc specifies the Continuous Clocking parameter block, te the Timed Exposure parameter block, dea the DEA housekeeping parameter block, window1D and window2D respectively the Window 1-D and Window 2-D parameter block.
The parameterBlocks "window1D" and "window2D" contain an additional parameter name "arrayDim" which indicate the number of windows contained in the paramBlock. A list of the parameter keywords contained in the parameter block is given in the example section. As explained above, keyword order is significant.
Examples:
load 2 cc 3 { paramBlockName = ccBlock parameterBlockId = 2030 fepCcdSelect = 0 1 2 3 4 5 fepMode = 1 bepPackingMode = 2 ignoreBadColumnMap = 1 recomputeBias = 1 trickleBias = 0 rowSum = 8 columnSum = 6 overclockPairsPerNode = 8 outputRegisterMode = 2 ccdVideoResponse = 1 1 0 1 1 0 fep0EventThreshold = 100 100 100 100 fep1EventThreshold = 100 100 100 100 fep2EventThreshold = 100 100 100 100 fep3EventThreshold = 100 100 100 100 fep4EventThreshold = 100 100 100 100 fep5EventThreshold = 100 100 100 100 fep0SplitThreshold = 0 0 0 0 fep1SplitThreshold = 0 0 0 0 fep2SplitThreshold = 0 0 0 0 fep3SplitThreshold = 0 0 0 0 fep4SplitThreshold = 0 0 0 0 fep5SplitThreshold = 0 0 0 0 lowerEventAmplitude = 0 eventAmplitudeRange = 40 gradeSelections = 0 windowSlotIndex = 1 rawCompressionSlotIndex = 255 ignoreInitialFrames = 2 biasAlgorithmId = 2 2 2 2 2 2 biasRejection = 1 2 4 6 5 6 fep0VideoOffset = 1000 1000 1000 1000 fep1VideoOffset = 1000 1000 1000 1000 fep2VideoOffset = 1000 1000 1000 1000 fep3VideoOffset = 1000 1000 1000 1000 fep4VideoOffset = 1000 1000 1000 1000 fep5VideoOffset = 1000 1000 1000 1000 deaLoadOverride = 0 fepLoadOverride = 0 }load 3 te 2 { parameterBlockName = teBlock parameterBlockId = 0x2345 fepCcdSelect = 0 1 2 3 4 5 fepMode = 2 bepPackingMode = 1 onChip2x2Summing = 0 ignoreBadPixelMap = 0 ignoreBadColumnMap = 0 recomputeBias = 1 trickleBias = 1 subarrayStartRow = 0 subarrayRowCount = 1023 overclockPairsPerNode = 16 outputRegisterMode = 0 ccdVideoResponse = 0 0 0 0 0 0 primaryExposure = 1 secondaryExposure = 10 dutyCycle = 0 fep0EventThreshold = 100 100 100 100 fep1EventThreshold = 100 100 100 100 fep2EventThreshold = 100 100 100 100 fep3EventThreshold = 100 100 100 100 fep4EventThreshold = 100 100 100 100 fep5EventThreshold = 100 100 100 100 fep0SplitThreshold = 0 0 0 0 fep1SplitThreshold = 0 0 0 0 fep2SplitThreshold = 0 0 0 0 fep3SplitThreshold = 0 0 0 0 fep4SplitThreshold = 0 0 0 0 fep5SplitThreshold = 0 0 0 0 lowerEventAmplitude = 0 eventAmplitudeRange = 65535 gradeSelections = 0 windowSlotIndex = 0 histogramCount = 0 biasCompressionSlotIndex = 255 255 255 255 255 255 rawCompressionSlotIndex = 0 ignoreInitialFrames = 2 biasAlgorithmId = 2 2 2 2 2 2 biasArg0 = 10 10 10 10 10 10 biasArg1 = 0 0 0 0 0 0 biasArg2 = 1 1 1 1 1 1 biasArg3 = 0 0 0 0 0 0 biasArg4 = 0 0 0 0 0 0 fep0VideoOffset = 1000 1000 1000 1000 fep1VideoOffset = 1000 1000 1000 1000 fep2VideoOffset = 1000 1000 1000 1000 fep3VideoOffset = 1000 1000 1000 1000 fep4VideoOffset = 1000 1000 1000 1000 fep5VideoOffset = 1000 1000 1000 1000 deaLoadOverride = 0 fepLoadOverride = 0 }
load 4 dea 4 { paramBlockName = deaBlock deaBlockId = 123456 sampleRate = 4 arrayDim = 2 ccdId = 5 queryId = 2 ccdId = 5 queryId = 2 }
load 4 window1D 4 { parameterBlockName = window1D windowBlockId = 45 arrayDim = 3
ccdId = 1 ccdColumn = 2 width = 4 sampleCycle = 6 lowerEventAmplitude = 7 eventAmplitudeRange = 8
ccdId = 1 ccdColumn = 2 width = 4 sampleCycle = 6 lowerEventAmplitude = 7 eventAmplitudeRange = 8
ccdId = 1 ccdColumn = 2 width = 4 sampleCycle = 6 lowerEventAmplitude = 7 eventAmplitudeRange = 8 }
load 2 window2D 3 { paramBlockName = window2D windowBlockId = 50 arrayDim = 3
ccdId = 0 ccdRow = 490 ccdColumn = 490 width = 20 height = 20 sampleCycle = 0 lowerEventAmplitude = 0 eventAmplitudeRange = 64535
ccdId = 0 ccdRow = 500 ccdColumn = 500 width = 100 height = 100 sampleCycle = 1 lowerEventAmplitude = 0 eventAmplitudeRange = 64535
ccdId = 0 ccdRow = 0 ccdColumn = 0 width = 1023 height = 1023 sampleCycle = 0 lowerEventAmplitude = 0 eventAmplitudeRange = 0 }
The command reads memory bank, address, and number of words to read and outputs a binary stream to the standard output, stdout, which contains the command in the format requested by the ACIS software.
- read cmdId address length
- request to read a chunk of bep memory of the indicated length at the specified address
- read cmdId fep fepId address length
- request to read a chunk of fep memory of the indicated length at the specified address
- read cmdId pram ccdId address length
- request to read a chunk of pram memory of the indicated length at the specified address
- read cmdId sram ccdId address length
- request to read a chunk of sram memory of the indicated length at the specified address
The memory bank is identified by the keywords: fep fepId, sram ccdId, and pram ccdId. A missing memory indicates the bep memory.
address is an hexadecimal or decimal integer indicating the memory address where to start the reading. This value is in the range 0-0xffffffff for fep and bep memory reading, and in the range 0-0xffff for sram and pram reading.
length is an hexadecimal or decimal integer indicating the number of words to read. This value is in the range 0-0xffffffff for fep and bep memory reading, in the range 0-0xffff for pram and sram reading.
Example:
- read 4 0x103d87a0 40
- request to read 40 32-bit words in the bep starting from address 0x103d87a0
- read 1 fep 2 0x10003400 2
- request to read 2 32-bit words in the fep 2 starting from address 0x10003400
- read 2 pram 2 0x2340 5
- request to read 5 16-bit words in the pram 2 starting from address 0x2340
- read 2 sram 4 0x1fff 5
- request to read 5 16-bit words in the sram 4 starting from address 0x1fff
This command reads the identifiers of the patches to remove and outputs a binary stream to the standard output, stdout, which contains the command in the format requested by the ACIS software.
- remove cmdId patch patchBlock
- request to remove the patch list contained in the patchBlock
Example
remove 1 patch { paramName = patches patchId = 1 patchId = 2 patchId = 8 }remove three patches: 1,2,and 8 from the patch list
This command reads the name of the memory block to reset and outputs a binary stream to the standard output, stdout, which contains the command in the format requested by the ACIS software.
- reset cmdId badPixel
- request to reset the bad pixel map
- reset cmdId cc badColumn
- request to reset the Continuous Clocking bad column map
- reset cmdId te badColumn
- request to reset the Timed Exposure bad column map
cc, te, badPixel, and badColumn are keywords identifying the memory to reset. In particular, cc badColumn specifies the Continuous Clocking badColumn map, te badColumn the Timed Exposure parameter badColumn map.
Examples:
- reset 4 badPixel
- reset the badPixel Map
- reset 6 te badColumn
- reset the Timed Exposure badColumn map
- reset 10 cc badColumn
- reset the Continous Clocking badColumn map
This command reads the slotId containing the parameter of the science run to start and outputs a binary stream to the standard output, stdout, which contains the command in the format requested by the ACIS software. This command is also used to start DEA housekeeping monitor and uplink boot.
- start cmdId cc slotId
- request to start the Continuous Clocking science run whose parameters are stored in the specified slotId
- start cmdId cc bias slotId
- request to start the Continuous Clocking bias calculation whose parameters are stored in the specified slotId
- start cmdId dea slotId
- request to start the DEA Housekeeping monitor whose parameters are stored in the specified slotId
- start cmdId te slotId
- request to start the Timed Exposure science run whose parameters are stored in the specified slotId
- start cmdId te bias slotId
- request to start the Timed Exposure bias calculation whose parameters are stored in the specified slotId
- start cmdId uplink file
- request to start the uplink boot using the data stored in the indicated file
cc, te, dea, and bias are keywords identifying the parameter block to which the action is applied. In particular, cc specifies the Continuous Clocking parameter block, te the Timed Exposure parameter block, dea the DEA housekeeping parameter block.
uplink is a keyword identifying the boot mode.
Examples:
- start 22 te 4
- start Timed Exposure science run with the parameters stored in slotId 4
- start 33 cc 3
- start Continous Clocking science run with the parameters stored in slotId 3
- start 44 cc bias 0
- start Timed Exposure bias calculation with the parameters stored in slotId 0
- start 55 te bias 1
- start Continous Clocking bias calculation with the parameters stored in slotId 1
- start 66 dea 2
- start Dea Housekeeping monitor with the parameters stored in slotId 2
- start 77 uplink fileName
- start the uplink boot with the data contained in the fle fileName
This command stops science run or DEA Housekeeping monitor. It outputs a binary stream to the standard output, stdout, which contains the command in the format requested by the ACIS software.
- stop cmdId dea
- request to stop the currently running DEA Housekeeping monitor
- stop cmdId science
- request to stop the currently running science exposure
science, and dea are keywords identifying the task to stop.
Examples:
stop 22 science
stop 33 dea
This command read a binary file, identifies the memory bank where to write the file content, and outputs a binary stream to the standard output, stdout, stdout , which contains the command in the format requested by the ACIS software.
- write cmdId address file
- request to write the binary file content in the bep memory at the specified address
- write cmdId fep fepId address file
- request to write the binary file content in the fep memory at the specified address
- write cmdId pram ccdId address file
- request to write the binary file content in the pram memory at the specified address
- write cmdId sram ccdId address file
- request to write the binary file content in the sram memory at the specified address
The memory bank to write is identified by the keywords fep fepId, pram ccdId, and sram ccdId. A missing memory indicates the bep memory.
address is an hexadecimal or decimal integer indicating the memory address where to start the reading. This value is in the range 0-0xffffffff for fep and bep memory reading, and in the range 0-0xffff for sram and pram reading.
file is the name of the file containing the data to write in memory. The file size is limited by the memory bank where the data should be stored. If the data contained in the file cannot be loaded in one command, their content will be divided into sections and loaded by multiple commands.
Examples:
- write 4 0x00002345 asm
- write the content of the "asm" file in the bep at the address 0x00002345
- write 5 fep 4 0x00000056 bsm
- write the content of the "bsm" file in the fep 4 at the address 0x00000056
- write 6 pram 4 0x0024 csm
- write the content of the "csm" file in the pram 4 at the address 0x0024
- write 7 sram 5 0x0034 dsm
- write the content of the "dsm" file in the sram 5 at the address 0x0034
The following commands will be prefixed by a 4-byte header that sends them to the hardware serial command port of the DPA.
This hardware serial command outputs a binary stream to the standard output stdout, containing the command in the format requested by the ACIS hardware.
- halt bep
- request to reset the BEP processor.
This hardware serial command outputs a binary stream to the standard output stdout, containing the command in the format requested by the ACIS hardware.
- run bep
- request to run the BEP processor.
This hardware serial command outputs a binary stream to the standard output stdout, containing the command in the format requested by the ACIS hardware.
- select EEPROM programming
- request to select EEPROM programmer readout
- select EEPROM telemetry
- request to select software bi-level telemetry.
- select bep bepId
- request to select one of the two BEP processor (0 select BEP A, 1 select BEP B).
This hardware serial command outputs a binary stream to the standard output stdout, containing the command in the format requested by the ACIS hardware.
- set bootModifier off
- request to clear the bootModifier flag
- set bootModifier on
- request to set the bootModifier flag
- set radiationMonitor high
- request to set the radiation flag
- set radiationMonitor low
- request to clear the radiation flag
- set warmBoot off
- request to clear the warm boot flag
- set warmBoot on
- request to set the warm boot flag
The following commands will be sent to the command port of the Power Supply Mechanism Control (PSMC), as specified in the "CTUE Command Format". Each pulse command has two versions, depending on whether it is to be sent to the A-side or B-side of the redundant PSMC hardware. These are identified by the id parameter in the following table, where id must be either "0" for the A-side, or "1" for the B-side.
- close door id
- close instrument door id
- close vent id
- close vent subsystem valve id
- close relief id
- close vent subsystem small valve id
- closeabort door id
- abort the closing of instrument door id
- closeabort vent id
- abort the closing of vent subsystem valve id
- disable daBake id
- disable commands to bakeout heater id
- disable daHeater id
- disable commands to housing heater id
- disable dea id
- disable commands to DEA power supply id
- disable door id
- disable commands to door mechanism id
- disable dpa id
- disable commands to DPA power supply id
- disable pressure id
- disable commands to pressure sensor id
- disable relief id
- disable commands to vent subsystem small valve id
- disable vent id
- disable commands to vent subsystem valve id
- enable daBake id
- enable commands to bakeout heater id
- enable daHeater id
- enable commands to housing heater id
- enable dea id
- enable commands to DEA power supply id
- enable door id
- enable commands to door mechanism id
- enable dpa id
- enable commands to DPA power supply id
- enable pressure id
- enable commands to pressure sensor id
- enable relief id
- enable commands to vent subsystem small valve id
- enable vent id
- enable commands to vent subsystem valve id
- open door id
- open instrument door id
- open vent id
- open vent subsystem valve id
- open relief id
- open vent subsystem small valve id
- openabort door id
- abort the opening of instrument door id
- openabort vent id
- abort the opening of vent subsystem valve id
- poweroff dabake id
- power off bakeout heater id
- poweroff daheater id
- power off housing heater id
- poweroff dea id
- power off DEA power supply id
- poweroff dpa id
- power off DPA power supply id
- poweron dabake id
- power on bakeout heater id
- poweron daheater id
- power on housing heater id
- poweron dea id
- power on DEA power supply id
- poweron dpa id
- power on DPA power supply id
- turnoff dabake
- power off and disable both bakeout heaters
- turnoff dabake id
- power off and disable bakeout heater id
- turnoff daheater
- power off and disable both housing heaters
- turnoff daheater id
- power off and disable housing heater id
- turnoff dea
- power off and disable both DEAs
- turnoff dea id
- power off and disable DEA id
- turnoff dpa
- power off and disable both DPAs
- turnoff dpa id
- power off and disable DPA id
- turnon dabake id
- enable and power on bakeout heater id
- turnon daheater id
- enable and power on housing heater id
- turnon dea id
- enable and power on DEA id
- turnon dpa id
- enable and power on DPA id
ash% buildCmds < myCmdScript | sendCmds | writeCCB | cclient poplar 8000
Fatal Messages:
Various socket and connection error messages to stderr.
Warning Messages:
None
Informatory Messages:
When waiting for a connection, the program writes "Waiting for Connection" to stderr. Once a connection is attempted, the program writes a message indicating from which machine the attempt is being made, to stderr.
filterClient -h emily | psci -v -l run123 -m | sciglue | monitorScience
While monitorScience is displaying fancy stuff on the screen, psci is doing the hard work of unpacking the bias maps and event files. The latter will be written to a series of disk files with names "run123.nrun.nfep.\fRerv.dat\fP", where run123 is a prefix inherited from the -l option of psci, nrun is a "science run index" that is incremented at the start of each science run, and nfep is the index of the particular FEP that generated the events. After psci has generated an end-of-run message, e.g.
stdin: scienceReport[54321,0] run 1 irig 12345:678 exp 2 fep ok ccd ok dea 0 bep 1
indicating that the event files have been written successfully, they may be compared by
diff6 -v run123.1.*.erv.dat
This command subjects the high-level ACIS front end processor software to a series of tests, directed by a script read from file, or, if omitted, from the standard input stream , stdin. All input lines are echoed to stderr, with the following additional output, detailing the interaction between the FEP and the (simulated) BEP:
The only "ctr" is "wakeup" which causes FIOgetNextCmd() to simulate BEP commands arriving while a FEP mode is running.
Fatal Messages:
If the system attempts to write a pixel beyond the end the image memory (due to some internal error, or to a badly formed input image), the program write print the contents of some key FEP register values (from shared memory) to stderr and exit with a -1 exit code.
Warning Messages:
None
Informatory Messages:
If the program would be blocked by the FEP when trying to write an image, rather than discard the image, the program prints a "Dummy Image VSYNC - Sleep 3" message to stderr and then sleeps for 3 seconds. It will then re-attempt to load the image. This will continue indefinitely until either the FEP accepts the image, or until the program is aborted (usually via a Ctrl-C).
As the program loads the image into the FEP, it prints the current image start row, CCD start row and Row Count values used for the load to stdout.
s science telemetry e engineering pseudo-packets p science frame pseudo-packets h DEA housekeeping packets
If omitted, the default is seph, i.e. extract all types of packet.
A script consists of a series of ASCII statements of the form
keyword = value . . .
followed by zero or more object "call-outs" of the form
object row column
which will be described below. The script statements are case-insensitive\(emupper and lower case characters may be freely mixed. Each statement must appear on a separate line, but may be surrounded by any number of blanks and tabs. Any number of spaces or tabs may separate statement arguments.
Null lines, lines containing only whitespace, and lines whose first non-whitespace character is '#', are interpreted as comments, and ignored.
The statements are grouped logically into five classes:
drow * irow + dcol * icol + drowcol * irow * icol
begin node = char
- bias = ival
- Initialize all data pixels (but not overclocks) in this node to the integer value, ival. This serves as a base on which to apply various adjustments.
- dbias = fval
- Adjust all pixels in this node by adding a zero-mean Gaussian random variable of variance fval. This mimics the real variability of CCD pixel values.
- overclock = ival
- Initialize all overclocks in this node to the integer value, ival. This serves as a base on which to apply various adjustments.
- doverclock = fval
- Adjust all overclocks in this node by adding a zero-mean Gaussian random variable of variance fval.
end node = char
begin event = name
- columns = ival
- The width of the values array.
- rows = ival
- The height of the values array.
- values = ival ival . . . ival
- A series of columns\(murows integer values to be added to the CCD pixel image. The values are supplied in row-major order, i.e. the first row values are followed by the second row, and so on. Within a row, the values are in ascending column order.
end event = name
begin blob = name
- angle = fval
- The rotation angle of the blob, in degrees counter-clockwise.
- height = fval
- The Gaussian width of the blob in the column direction, before rotating through angle.
- value = fval
- The additional pixel value of the center of the blob.
- width = fval
- The Gaussian width of the blob in the row direction, before rotating through angle.
end blob = name
Rows = 1024 Columns = 256 Mode = ABCD Overclocks = 4 Seed = 12345678Wedge = 0.001 -0.0025 0.000001
Noop = 4 before VSYNC Noop = 4 after VSYNC Noop = 2 before Oclks Noop = 2 before HSYNC Noop = 2 after HSYNC
Begin Node = A Bias = 230 dBias = 5 OverClock = 190 dOverClock = 2 End Node = A
Begin Node = B Bias = 230 dBias = 5 OverClock = 190 dOverClock = 2 End Node = B
Begin Node = C Bias = 230 dBias = 5 OverClock = 190 dOverClock = 2 End Node = C
Begin Node = D Bias = 230 dBias = 5 OverClock = 190 dOverClock = 2 End Node = D
Begin Event = event_1 Rows = 3 Columns = 3 Value = 0 0 0 0 1500 0 0 0 0 End Event = event_1
Begin Event = event_2 Rows = 3 Columns = 3 Value = 0 0 0 0 1000 500 0 0 0 End Event = event_2
Begin Blob = bloom Width = 8 Height = 16 Angle = 30 Value = 1000 End Blob = bloom
event_1 100 200 event_1 475 891 bloom 25 129 event_2 1001 31
Frame Buffer Specification, ACIS Memo, M. Doucette, MIT, October 27, 1995.
The Coordinate System of ACIS FITS Files, ACIS Memo, J. W. Woo and S. E. Kissel, MIT, December 7, 1994.
genPixelImages reads input commands from stdin and writes images to stdout in a format suitable for transferring to an "Image Loader". This format consists of 16 bit-words containing frame-buffer directives, FEP synchronization codes, and pixel and overclock values. Each image begins with four VSYNC codes and may contain from 1 to 1024 "rows", each beginning with four HSYNC codes. Each row may contain between 4 and 1024 "columns", divided into "nodes" (four in "ABCD" mode, two in either "AC" or "BD" mode), and followed by 0 to 15 pairs of overclocks per node. Note that the fourth, diagnostic, clocking mode generates no pixel values. It is therefore simulated by "ABCD" mode and no separate genPixelImages option is required.
Before generating any output, genPixelImages verifies (1) that the dimension of the images (number of rows, columns, and overclocks) are within ACIS constraints; (2) that the number and position of pixels and overclocks correspond to the image requested, i.e. each row contains the required number of pixels, followed by the required number of overclocks; (3) that each repeatRowBlock command operates on one or more whole rows.
row n col m overclock o mode pixelDefinition
where n, m, and o are integers (m and o must be even) and mode specifies the CCD readout node configuration-ABCD, AC, or BD. These are followed on the same line by pixelDefinition- a series of commands that define the pixels and overclocks that will comprise the image.
The basic commands are
p v
which defines a single pixel with value v (an integer between 0 and 4095), and
c v
which defines a single overclock with value v (also an integer between 0 and 4095). A pixel or overclock value may be repeated by preceding the p or c command by r, e.g.
r n p v
generates a sequence of n pixels, each of value v. r, p, and c commands may be grouped by enclosing them in parentheses and repeated by prefixing the group with a repeatSec command, e.g.
repeatSec i ( r n p v r m c v )
repeats the commands within the parentheses a total of i times. This process continues until one or more full rows have been defined. A group of rows may be repeated with the repeatRowBlock command, e.g.
repeatRowBlock n [ repeatSec n ( r n p v r n p v ) repeatSec n ( r n p v r n c v ) ]
Note that the repeatSec commands are grouped by enclosing them in square brackets. Similarly, repeatRowBlock commands may be grouped by enclosing them within braces, e.g.
row 200 col 1024 overclock 4 ac { repeatRowBlock 50 [ repeatSec 2 ( r 100 p 1 r 100 p 2 r 100 p 3 r 100 p 4 r 100 p 5 r 100 p 6 r 100 p 7 r 100 p 8 r 100 p 9 r 100 p 10 r 24 p 11 c 30 c 31 c 32 c 33 ) ] repeatRowBlock 50 [ repeatSec 2 ( r 100 p 20 r 100 p 30 r 824 p 40 r 4 c 34 ) ] }
The last image must be followed by an end command. Blank lines, and all text between a "#" character and the end of that line, will be treated as comments and ignored.
genPixelImages locates each pixel in the 2-dimensional coordinate system of n rows and m columns defined by the physical CCD image store. Since the pixels are simultaneously sampled by 2 or 4 output nodes, genPixelImages must rearrange the pixel order according to the output node configuration. It also outputs VSYNC codes before each image, HSYNC codes before each row, and, only in AC or BD readout mode, a "null" pixel between each data pixel. It can also be instructed to add "null" pixels before or after synchronization codes, e.g.
row 8 col 8 overclock 4 delay vsync before 3 abcd [ repeatSec 2 ( r 8 p 1 r 4 c 10 ) repeatSec 3 ( r 4 p 2 r 4 p 8 r 4 c 30 ) repeatSec 3 ( r 8 p 3 r 4 c 20 ) ]
If genPixelImages is invoked with the single command go, it instructs the Frame Buffer to keep sending to the FEPs the image or images currently stored in its buffer, until commanded to halt. Alternatively, the image definitions may be prefixed with repeatFile n to repeat the images exactly n times. If this is omitted, the images will be repeated until the Frame Buffer is commanded to halt,
( genPixelImages <<EOF repeatFile 1 row 8 col 8 ac { repeatRowBlock 8 [ repeatSec 1 ( p 1 p 2 p 3 p 4 p 5 p 6 p 7 p 8 ) ] } end EOF ) | putImages
The reported examples show the correspondence between input commands and pixel image represented by them, and illustrate the available command to control the transfer of the image to the "Frame Buffer".
Pixel Pattern
This example shows the use of pixel and overclock patterns with and without repetitions to define pixel image.
row 3 col 4 overclock 4 abcd ( p 100 p 200 p 250 p 200 r 4 c 120 r 4 p 240 r 4 c 130 r 4 p 150 c 100 c 110 c 120 c 130 )Image size: 3x4 + 4 overclocks. Image values row by row:
100 200 250 200 120 120 120 120 240 240 240 240 130 130 130 130 150 150 150 150 100 110 120 130
repeatSec
This example shows the use of repeatSec to define rows.
row 9 col 8 overclock 4 abcd [ repeatSec 3 (r 8 p 40 r 4 c 15) repeatSec 2 (r 1 p 100 r 1 p 150 r 1 p 100 r 1 p 10) repeatSec 1 (r 4 c 8) repeatSec 2 (r 1 p 120 r 1 p 250 r 1 p 120 r 1 p 10) repeatSec 1 (r 4 c 8) repeatSec 2 (r 1 p 120 r 1 p 250 r 1 p 120 r 1 p 10) repeatSec 1 (r 4 c 8) repeatSec 3 (r 8 p 40 r 4 c 6)] endImage size: 9x8 + 4 overclocks per row.
Image values row by row:
40 40 40 40 40 40 40 40 6 6 6 6 40 40 40 40 40 40 40 40 6 6 6 6 40 40 40 40 40 40 40 40 6 6 6 6 100 150 100 10 100 150 100 10 8 8 8 8 120 250 120 10 120 250 120 10 8 8 8 8 100 150 100 10 100 150 100 10 8 8 8 8 40 40 40 40 40 40 40 40 6 6 6 6 40 40 40 40 40 40 40 40 6 6 6 6 40 40 40 40 40 40 40 40 6 6 6 6
repeatRowBlock
This example shows the use of repeatRowBlock to generate images containing multiple equal blocks of rows
row 14 col 8 overclock 2 ac { repeatRowBlock 2 [ repeatSec 2 (r 8 p 10 r 2 c 8) repeatSec 2 (r 1 p 100 r 1 p 150 r 1 p 100 r 1 p 10) repeatSec 1 (r 2 c 10) repeatSec 2 (r 1 p 120 r 1 p 200 r 1 p 120 r 1 p 10) repeatSec 1 (r 2 c 12) repeatSec 2 (r 1 p 100 r 1 p 150 r 1 p 100 r 1 p 10) repeatSec 1 (r 2 c 10) repeatSec 2 (r 8 p 10 r 2 c 8) ] repeatRowBlock 2 [ repeatSec 1 (r 8 p 10 r 2 c 8) repeatSec 2 (r 1 p 100 r 1 p 150 r 1 p 100 r 1 p 10) repeatSec 1 (r 2 c 10) repeatSec 2 (r 1 p 120 r 1 p 200 r 1 p 120 r 1 p 10) repeatSec 1 (r 2 c 10) repeatSec 2 (r 1 p 100 r 1 p 150 r 1 p 100 r 1 p 10) repeatSec 1 (r 2 c 10) repeatSec 2 (r 8 p 10 r 2 c 8) ] } endThe image size: 10x8 + 2 overclocks
The image values row by row:
8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 100 150 100 10 100 150 100 10 10 10 120 200 120 10 120 200 120 10 10 12 100 150 100 10 100 150 100 10 12 10 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 100 150 100 10 100 150 100 10 10 10 120 200 120 10 120 200 120 10 10 12 100 150 100 10 100 150 100 10 12 10 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
Delay
This example show the use of delay to introduce time delays before beginning to image transfer.
row 8 col 8 overclock 4 delay vsync before 3 after 2 abcd [ repeatSec 2 (r 8 p 100 r 4 c 10) repeatSec 3 (r 4 p 200 r 4 p 100 r 4 c 15) repeatSec 3 (r 8 p 150 r 4 c 120) ] endThe image loading is delayed by the insertion of three NULL pixels before and two after the VSYNC code. No delay is introduced between rows.
repeatFile
This example shows the use of repeatFile to send the same file multiple times to the "Frame Buffer".
repeatFile 2 row 22 col 8 overclock 4 abcd { repeatRowBlock 2 [ repeatSec 2 (r 8 p 1 r 4 c 10) repeatSec 3 (r 4 p 2 r 4 p 3 r 4 c 30) repeatSec 3 (r 8 p 4 r 4 c 20) ] repeatRowBlock 3 [ repeatSec 2 (r 8 p 5 r 4 c 33)] } endThe output image is preceded by a keyword requesting the "Frame Buffer" to repeat the loading of the same image twice.
getPackets reads a stream of AXAF-I telemetry frames from its standard input and writes a stream of ACIS telemetry packets and pseudo-packets to its standard output.
getPackets typically receives AXAF-I telemetry frames from SHIM. It extracts ACIS-related information and passes it to its client, which is typically filterServer. getPackets processes only AXAF-I telemetry formats 1 and 2. It accepts but ignores all other formats. It must first identify the current telemetry format -- either 1 or 2. In the former, ACIS science data is being generated at 512 bits/sec; in the latter at 24 Kbits/sec. In both cases, getPackets assembles the serial telemetry from ACIS, locates the individual packets by their synch words and lengths, and writes them to filterServer as a stream of separate logical records.
getPackets also sends filterServer two types of "pseudo-packet", i.e. records whose format mimics genuine ACIS telemetry packets but whose Format Tag codes are distinguished from those used by the instrument itself.
One type, the Science Frame Pseudo-Packet, contains telemetry-generated and ACIS-generated timestamps.
The other, the Engineering Pseudo-Packet, contains ACIS and other AXAF-I engineering data that resides in the non-science areas of the telemetry frames. getPackets determines the content of the engineering pseudo-packet by reading a file at run time. This file specifies the locations in the AXAF-I telemetry frames of the telemetry mnemonics that getPackets will extract and write as engineering pseudo-packets. The FILES section below explains how to specify which file getPackets will use.
The interface between getPackets and its various clients (via the filterServer/filterClient combination) may be described as a single stream of binary bytes, with no timing constraints.
getPackets writes a stream of telemetry packets and pseudo-packets to standard output. These are passed through filterServer to each filterClient, which writes a user-selected sub-set to its standard output. The four packet types that getPackets writes are: "ACIS Science Packets", "ACIS Analog Housekeeping Packets", "Science-Frame Pseudo-Packets", and "Engineering Pseudo-Packets". Each packet consists of a telemetry header followed by application data, as defined in the IP&CL. The header formats and contents are defined in Table 1.
| Packet Header Fields |
Field Length (bits) |
Science or Housekeeping Packet |
Science Frame Pseudo-Packet |
Engineering Pseudo-Packet |
|---|---|---|---|---|
| Synch | 32 | 0x736f4166 | 0x736f4166 | 0x736f4166 |
| Length | 10 | Varying1 | 7 | Varying1 |
| Format Tag | 6 | Varying | 62 | 61 |
| Sequence Number | 16 | incremented by 1 for each packet in the telemetry stream | 02 | 02 |
1
The packet length (number of 32 bit words) varies with the contents.
2
The sequence number of a pseudo-packet is always zero.
The packet length (number of 32-bit words) varies with the contents. The sequence number of a pseudo-packet is always zero.
All fields are written in "little-endian" format, e.g. the packet synch word, 0x736f4166, is written as 4 bytes, 0x66, 0x41, 0x6f, and finally 0x73. The contents of all packets originating within ACIS are defined in the IP&CL. The data portion of the Science Frame pseudo-packet is described in Table 2 and that of the Engineering pseudo-packet in Table 3.
| Field Name |
Source | filterClient Output Format |
Description | ||
|---|---|---|---|---|---|
| Location | Start | Length | |||
| format | Virtual Channel ID |
bit 10 | 3 bits | unsigned int |
Frame format identifier, either 1
(signifying 512 bps) or 2 (24 kbps),
i.e. the AXAF tlm code + 1. |
| majorFrameId | CCSDS Header |
bit 16 | 17 bits | unsigned int |
Virtual Channel Data Unit Major Frame Counter (0 to 131071) |
| minorFrameId | CCSDS Header |
bit 33 | 7 bits | unsigned short |
Virtual Channel Data Unit Minor Frame Counter (0 to 127) |
| irigb | Science Header |
byte 32 | 6 bytes | unsigned short [3] |
Time (msec) from the IRIG-B interface |
| bepSciTime | Science Data | byte 56 | 4 bytes | unsigned int |
Latched version of the BEP science pulse 1 MHz timestamp |
| Next-in-line Data |
TBD | ||||
| Field Name |
Source | filterClient Output Format |
Description | ||
|---|---|---|---|---|---|
| Location | Start | Length | |||
| format | Virtual Channel ID |
bit 10 | 3 bits | unsigned int |
Frame format identifier, either 1 (signifying 512 bps) or 2 (24 kbps), i.e. the AXAF tlm code + 1. |
| majorFrameId | CCSDS Header |
bit 16 | 17 bits | unsigned int |
Major frame counter (0 to 131071) |
| followed by an array of one or more elements, each consisting of the following fields | |||||
| data | variable location within major frame | var | 8 bits | unsigned char |
Engineering data |
| minorFrameId | CCSDS Header |
bit 33 | 7 bits | unsigned char |
Virtual Channel Data Uint Minor frame counter (0 to 127) |
| minorFrameByte | unsigned short |
Byte number in the minor frame (0 to 1024) | |||
The 6-byte IRIG-B timestamp in the AXAF-I minor frame is the result of packing 4 separate bit fields into a 48-bit string. However, getPackets treats the 6 bytes of the IRIG-B timestamp as 3 unsigned 16-bit integers. It copies them into the Engineering Pseudo-Packet and converts them to little-endian format, which is the ACIS standard. Table 4 describes how to decipher the Engineering Pseudo-Packet's irigb field.
| Field Name | Bit Length | Byte | Word |
|---|---|---|---|
| Julian Day | 11 | 0,1 | 0 |
| Seconds | 17 | 1,2,3 | 0,1 |
| Milliseconds | 10 | 3,4 | 1,2 |
| Microseconds (always zero) | 10 | 4,5 | 2 |
Each packet will be written to the getPackets standard output stream as soon as the last data byte that contributes to it is read from SHIM. A Science Frame Pseudo-Packet will be written after the last byte of each complete minor frame that contains a science data area header has been read. An Engineering Pseudo-Packet will be written after the last byte of each complete major frame is read.
... | buildCmds | sendCmds | shim lrctu | getPackets | filterServer ...
The current version is only capable of processing Format 2 telemetry. Its behavior if fed any other format is unknown but is liable to be objectionable.
The current version is implemented by having getPackets fork into 2 processes. One process, the original one as it turns out, reads AXAF-I telemetry and produces pseudo-packets. It also pipes the ACIS telemetry packet stream to the other process, which assembles and writes the ACIS packets. Both processes change their argv[0] environment value to either "axafFrames" or "acisPackets" as appropriate. This fools ps(1) into reporting the new name of each process. However, top(1) reports both as "getPackets."
The output consists of a series of "keyword = value" lines, in which the keywords are derived from the IP&CL field names, translating to uppercase all characters that immediately follow an embedded blank, and then removing the blank, e.g. "command length" is written as "commandLength". The "value" fields are rendered in decimal, with the following exceptions * 32-bit addresses and block IDs are in hexadecimal, prefixed with "0x"; * command tags are displayed as enumerated names, e.g. "CMDOP_LOAD_1D", followed by their decimal value in parentheses; * the timed-exposure "gradeSelection" value is written as a series of 8-character hexadecimal fields.
Each command begins with a header line of the form "name[n] = {", and ends with a matching right brace. Command blocks are separately numbered, starting at zero.
typedef struct { unsigned short expnum; /* exposure number [5] */ unsigned short exposure; /* exposure time (msec) [5] */ unsigned long irigtime; /* IRIG timestamp [8] */ unsigned short nodenum; /* output node index [1] */ unsigned short col; /* column index [4] */ unsigned short row; /* row index [4] */ unsigned short data[9]; /* event data values [4] */ short doclk; /* delta overclock [2] */ } RvRec;
They are written out as decimal numbers, right-justified with blank fill and separated by single blanks. The numbers in square brackets in the above definitions represent the minimum field widths. If the ASCII value of a particular field exceeds this, the remaining fields will be shifted right in the output line to accommodate it. Thus, although most output lines will contain 80 characters followed by a newline, some could be longer.
The Coordinate System of ACIS FITS Files, ACIS Memo, J. W. Woo and S. E. Kissel, December 7, 1994.
On-chip summation is not currently implemented. It is assumed that
all output nodes generate either 256 pixels (ABCD mode) or 512
pixels (AC or BD mode).
If logGet is run with root priviledges, it will listen on port 542 for a connection from the CTUE. If it is run with regular user priviledges, logGet will listen on port 7542. The appropriate port number must be entered in the CTUE's c:\windows\ethernet.cfg file.
logGet adds its own time stamp to each message.
acisEgseHost% logGet
Demitrios Athens, MIT CSR
The output consists of a series of "keyword = value" lines, in which the keywords are derived from the IP&CL field names, translating to uppercase all characters that immediately follow an embedded blank, and then removing the blank, e.g. "command length" is written as "commandLength". The "value" fields are rendered in decimal, with the following exceptions * synch codes, 32-bit addresses, timestamps and block IDs are in hexadecimal, prefixed with "0x"; * command and packet tags are displayed as enumerated names, e.g. "TTAG_CMD_ECHO", followed by their decimal value in parentheses; * the timed-exposure "gradeSelection" value is written as a series of 8-character hexadecimal fields.
Each telemetry packet and embedded command block begins with a header line of the form "name[n] = {", and ends with a matching right brace. Each type of command block and telemetry packet is separately numbered, starting at zero. Embedded arrays of data structures are also numbered from zero, but the index is reset at the start of each array instance.
monitorScience creates a multi-window display, reads the stdout stream from processScience, and writes it into one of the windows.
monitorScience uses colors to signal various conditions: fatal anomalies are shown in red, warnings in blue. The initiation and termination of science or monitor requests are displayed in green. Colors are also used to distinguish decimal numbers (black) from hexadecimal numbers (brown).
Black and brown colors are also used to facilitate the reading of parameter names. In science data windows, they distinguish telemetry packet names (black) from parameter names (brown). In the Dea Housekeeping window, packet header fields are colored brown, and data fields black (see below). In Sw Housekeeping, packet header fields are brown, data fields are black, red, or blue, depending on the type of information displayed.
Normally, window backgrounds are colored "linen", but background of the most recently updated window is colored "white".