GSE Computer Info
This page is the central location for any information regarding the GSE computers.
Before any work begins, the GSE computer should be configured to ensure all required functionality is available at all times. This section is necessary under the following conditions:
- The computer has never been used for GSE operations before
- It is being used for a different model
Even if none of the above conditions have been met, it may still be a good idea to skim through each item to ensure nothing is missing.
Checking out the data and momagse repositories
The first step is to checkout the appropriate data and momagse SVN repositories. For the most part, you will only want to checkout the data directory for the model that this GSE computer is being used with. For example, if the GSE computer is going to be used with the ETU model, you only need to checkout the momdata/etu directory. Sometimes it is desirable to checkout other data directories so that you can easily look at data from another model. Under no circumstances should you checkout the root momadata directory because there is a ton of unnecessary data and the checkout will take a very long time. The complete momagse directory should also be checked out. All data repositories should be checked out in the ~/momadata directory and the momagse repository should be checked out at ~/momagse. Here is an example file structure after checking out everything:
~/momadata/etu ~/momadata/fm ~/momagse
Configuring the gse.ini
In order to avoid duplicating TIDs, we need to make sure the gse.ini is using the correct TID. Open up the momagse/gse.ini file. Check to see if the Test_ID value is +1 the newest TID in the momdata/<model> directory. Change it if needed.
Configuring the SVN global ignores
In order to avoid listing specific file types, you may want to update the global SVN config file with some useful ignore patterns. This is not a required step but helps reduce clutter when using "svn status". Note that any files that match the listed patterns should not be committed to SVN. For the most part, you should not be manually committing files to SVN anyways and instead should be using the sync_moma_model_data.py script. Common ignore patterns:
*.index.tm* *.metadata* *.tm* .DS_Store
Configuring the 699config.ini file
If this is the first time this GSE computer is ever being used, you may produce a default 699config.ini file a number of different ways:
- Copy from another GSE computer
- Open MOMA Data View which should pop up a dialog to create it -- This is the recommended method
- Run a python script
Please note that the required name is ".699config.ini" (note the period in the front, which will make it a hidden file) and should exist in your home directory. Verify that all of the paths are pointing to the correct location. The data_root key is unique between models, so please make sure it is pointing to the correct location. This should be pointing to the location of the data repository you checked out during the checkout process.
The following GSE applications should be installed (to /Applications), which are all located in momagse/Apps.
- MOMA GSE (momagse.dmg)
- MOMA Rover Sim (mrsim.dmg)
- MOMA Data View (momadataview.dmg)
- Journal Server (journalserver.dmg)
Installing our Python tools
The python tools are used for a number of different things on our GSE computers:
- Provide the suite of python scripts for data analysis such as tmmarker.py, tmfields.py, etc.
- Provide expected value check tools - used for analyzing and verifying our baselines
- Provide the tools for committing our data to Subversion
Ensuring the Computer Time is Correct
- In order to ensure that the absolute time for the generated data is correct, the operator should make sure that the computer's local time is correct.
The model that this computer is going to be used with should be updated to ensure the TID numbers are in sync. Other checked out data directories may be updated if desired.
The momagse checkout needs to be updated to ensure the newest version of the apps, scripts, data interpretations, etc. are being used.
End of operation
Committing the data
You should not be manually SVN committing the data. We have a special python script called sync_moma_model_data.py that should be used instead. This takes care of committing any new data and completing other post-processing tasks.
Cleaning up your workspace
As more and more work is completed on the computer, it is only natural for clutter to accumulate. It is the GSE operator's responsibility to clean up any unnecessary files that were generated for the test(s). Be respectful of other operators.
Other Note and Tips
- If you ever run into conflict issues when SVN updating, either resolve the conflict to the best of your ability or ask someone who is more knowledgeable in the matter.
Fix RS422 Comm Issues
kext stands for kernel extension
You can disable the driver by running the following in the terminal: sudo kextunload -b com.apple.driver.AppleUSBFTDI
There is the possibility that the above command won’t work if it can’t find the driver. You can use the following to see if the FTDI driver even exists: kextfind | grep -i ftdi
This should print out a path to the FTDI driver. The actual driver name is AppleUSBFTDI.kext.
You can also do the following to see if the FTDI driver is loaded and currently being used: kextstat | grep -i ftdi
If the first kextunload command did not work, but the FTDI driver is loaded as indicated by the kextstat command, then you should be able to do this variation of the first command to unload the driver: sudo kextunload “the resulting path returned by the kextfind command”
After disabling the driver, you should move it to avoid it being reloaded.
cd /System/Library/Extensions/IOUSBFamily.kext/Contents/Plugins sudo mv AppleUSBFTDI.kext AppleUSBFTDI.disabled
Then restart the application that uses the driver