GenSAA Tips and Tricks

SOLUTION:

• I showed only one time by doing the following:
• I set up the display so all 3 time sources were displayed complete with titles.
• I selected an image from the data driven image palette (any one will do) and I changed the foreground and background colors to dark-blue (the background color of the window) and resized the image to completely overlap the time widget and title of one of the time sources. Make sure you keep the image raised above the time and label widgets.
• I copied this new image two times and placed them over the two remaining time formats.
• Finally, I attached behaviors to the images so they would hide when the time source they were covering were selected and show otherwise based on a user defined time source fact. For example, the image covering the spacecraft time widget would have behaviors attached something like the following: (if Parm_Time_Source = spacecraft then Hide Image)
  (if Parm_Time_Source != spacecraft then Show Image)

SOLUTION:
This technique is similar to the previous one except I needed to determine in clips which stars were valid/invalid and put that information in inferred variables. I then used the inferred variable to hide or show the images covering the star information on the display.
NOTE: In the ST and DSS FOV display when the HUD received data that was bad for some reason, I set the X and Y values of the data to -99 so they would be plotted off the FOV.

SOLUTION:
I was lucky with this one because I was dealing with three (or more) mnemonics. This occurred when I was dealing with IRU X, Y, and Z mnemonics, so I needed three mnemonics to show all the possible time source combinations.

I picked mnemonics for each time format (ex. I selected the X IRU mnemonics for spacecraft time, the Y IRU mnemonic for ground receipt time, and the Z IRU mnemonic for the local GMT time.) In the Data Manager I requested the time formats along with the raw or converted data for these mnemonics. For instance for the X IRU mnemonic I requested Raw data under CVT Component and Spacecraft under Time Tag (using the Data Details panels). I specified what type of information I wanted from the mnemonic in the following way:
(X IRU mnemonic MISSION value) for the data and
(X IRU mnemonic spacecraft-GMT data) for the spacecraft time
(local-GMT would specify local time and ground-GMT would specify ground receipt time)
NOTE: time widget automatically displays the time data from widgets.

SOLUTION:
When you do a verify and you get an error and you don't know what widget it pertains to:

• write down the widget id (something like GR_Name_014)
• do an export to ASCII in the WorkBench and look in the *.asc file that is created for the x and y position of that particular widget id
• create a drawable (I used a rectangle) and under geometry set its x and y position to the x and y position of the unknown widget. The drawable will move to the position of the widget with the problem.

SOLUTION:
Ungroup the widgets.

SOLUTION:
On a HP I used the vueicon editor to create the images I needed to use, and saved them as .bit files. To get these images into the image palette I have to change the .ges file to point to the directory that contained these images. (line 5 of the .ges file, the third directory path specified.) Once I did this I needed to copy over the GenSAA.xbm to that image directory, because GenSAA wants all the images in the one directory. If the new images don't appear in the image palette in the WorkBench you will need to do a Rescan under Options.

NOTE: GenSAA 3.02 Runtime will crash if bitmaps used in the GenSAA application are missing from the image directory.

SOLUTION:
This problem was solved two different ways:
1) if you are displaying mission data of a CVT type then - change line 235 of the rungrt script to include /%N after etc. The line should now look like: else XUSERFILESEARCHPATH = $ROOT_GEN/etc/%N:$HOME...
2) if you are displaying inferred or non_CVT type data then - I added behavior rules to the widgets that would change the color and size of the widget borders if limits

SOLUTION:
I didn't resolve this problem in the XTE HUD. The only way I thought I could resolve it was to select colors that wouldn't clash with TPOCC warning colors. Colors like gray and slate gray would probably be more appealing.

SOLUTION:

• select the widget you want from the palette and drag it to your WorkSpace
• make all the changes you want to make to that single widget (color, font, size, etc)
• duplicate your modified widget as often as you need.

SOLUTION: Use the Geometry selection under the Utilities Menu on the UIB. You can type in the exact x and y position, height, and width for any widget.

SOLUTION:

• place the widgets close together
• the widget should all have the same colors and sizes so they look related
• draw a thin rectangle around the grouping to delineate these widgets from other widgets , and lower the rectangle so that it doesn't cover up anything.
• add a text widget as a title for this group

SOLUTION:
For every coordinate pair you want to plot you will need a rule like the one below. The (AssertFact "DSSY Control I") will cause the previous values that occupied DSSY and DSSX to be erased.

NOTE: If you are having difficulties getting the minimum and maximum values for the x and y axis to display properly, use the Graphic Object Resources panel and set the xScaleHi, xScaleLo, yScaleHi, and yScaleLo resources to the values and you want.

SOLUTION:

1. Think about your use of bind, assert and AssertFact. The bind command will bind a value to a variable. It's scope is limited to the rule in which it was invoked. (Once you leave the rule the value is meaningless). Binds are sufficient for internal computations that are only needed inside one rule. The assert command will assign a value to a variable and add that fact to the fact list. A fact asserted with assert is available to all rules in the rule base. Asserts are perfect for internal computations that are needed in more than one rule, but are not needed for display. The AssertFact command does everything assert does but also sends the fact through the socket to the User Interface. The Data Manager needs to have all variables asserted with AssertFact listed in the Inferred (or UserDefined) data list. The scope of AssertFact is the entire GenSAA application. To create the most efficient expert system you will need to decide which command has the most appropriate scope for each assignment you'll make.
2. Think about the structure of your rules. It is more efficient to have many short rules with few conditions than to have one long rule with many conditions and nested "if"'s in the actions. Smaller rules also have the additional benefit of being easier to maintain and reuse.
3. Every condition in a rule must be evaluated to true before CLIPS will put that rule on the agenda. As soon as CLIPS encounters a condition that is false it will stop its evaluation of that rule's conditions and go on to the next rule. Therefore, it is more efficient to place conditions that are more likely to fail at the top of the list. (I tried to place user parameters at the top and mission variables at the bottom of the list.)

SOLUTION:
Use a TSTOL script file keeping the following in mind:

• CVT types need to be assigned three fields (raw, converted, and status). Raw is usually an integer, converted is float, and status is numerical.
• the following are some status values used during HUD testing:

1. 0x800 Valid converted values (hex)
2. 0X0 Valid converted value within limits (hex)
3. 0xl Valid converted value exceeded high TPOCC warning (hex)
4. 0x2 Valid converted value exceeded low TPOCC warning (hex)
5. 0x3 Valid converted value exceeded high TPOCC error (hex)
6. 0x4 Valid converted value exceeded low TPOCC error (hex)

SOLUTION:
You need to first convert the string to numerical values:

then you'll need to convert the numerical values into seconds.

--or-- You can use this function in place of the previous two rules.

TIMETAG-TO-SECS - Function to convert time in timetag format to seconds format. Timetag format is received from GenSAA TimeTag facts - the format is YYDDD.HHMMSST. Seconds format is the integer number of seconds since January 1, 1970.

Sample call:

This deffunction can be called from the RHS of a rule that is triggered by the receipt of a GenSAA TimeTag fact. (This rule was tested with CLIPS 6.0)

SOLUTION:

1. edit the clp file and make a global change from one decom process to the another.
2. edit the mis file and make a global change from one decom process to the another.
3. bring up the WorkBench and under the UIB use the String Substitution command to replace the data sources decommutation name of all the widgets receiving mission data from the old mnemonic#decom_name to the new mnemonic#decom_name. NOTE: this step must be performed last.

SOLUTION:
I created an Assign_Defaults rule that triggered off the initial-fact to assert all the default values. This rule looked something like this: