# AAJournal.txt -- Official Change log and journal
#
# Gary: Please feel free to merge in your own change
# records. If you do this, please delete all the stuff
# you don't want from the Documents directory.
#
#
# Format:
# Date and INITIAL the heading for each day. 
# Indent everything within a day.
# Describe all additions and changes to files in the project.
# Move ALL files not part of the project to the /mts/data directory.
# 	This includes all settings and calibration files that
#	arn't updates for the two default files.
#
# Q: Why not put all kinds of data and calibration files in the
#    the project directory?
# A: That is a good question, Grasshopper.
#    For the same reason you don't keep your Microsoft Word
#    documents in the Mirosoft Word applications directory.
#    1) It makes it impossible to restore a backup of the
#       the application without destroying your data files.
#    2) It makes the backups so huge they are impossible to
#       archive.
#    3) Many people will use the wave machine. If they
#	all put their own stuff in the project directory, how will
#	anyone ever clean up the mess?

October 1, 1999 (HVS) 

	Network configuration files on the HP

		/etc/hosts
		/etc/resolv.conf
		/etc/rc.config.d/netconf

	There are two ethernet cards in the machine.

	lan0	For use on the office LAN: "B600"

	lan1	The private LAN for our machine: "GH"

	The lan0 interface has the 10BaseT jack built into
	the motherboard on the processor. The lan1 interface
	jack is on an interface card.

	The bug in b600 found by Paul et. al. was due to the heapBase
	relocation problem. This is fixed in the new AltFaceLink.alt.


	The proposed update will be done in phases:

	Phase I:
	Update alltalk from Linux and views from the PC
	version.

	Install Pauls C-level classes for UpTPC, DownTCP,
	Interface & cycler.

	Combine Brad's lastest b600Proj from PC, using
	MyUnixSystem instead of MySystem.

	Use Paul's RemotePort (a subclass of DownTCP)

	Test this as much as possible at MTS.

	Phase II

	Modify to use Altface & AltfaceLink from PC.
	This can be completely tested at MTS.


	Phase III

	Replace DownTCP with alt version from Tardec.


	Interface

	Replace with ???? (This is not worth doing IMHO...)

*************************
*	France		*
*************************

April 10, 2000 (Monday) (HVS)

	/etc/hosts

		Add brad, gary, & hugh to the hosts file for
		the portables.

		192.9.102.20	brad
		192.9.102.21	gary
		192.9.102.22	hugh

	/etc/rc.config.d/netconf
		Change the lan1 netmask to 255.255.255.0
			(Paul had 255.0.0.0)
		Change the default route to be 192.9.102.1
		This is a temporary change.
		The correct default route should be 192.9.101.13
		when we start using the office lan0 card.
		The parameter is called  ROUTE_GATEWAY[0]

April 11, 2000 (Tuesday) (HVS)

	Update Alltalk on the HP and test with Brad's old
	B600 application.

	Trace the lan cables to the data acquisition machine
	on the carriage:

	On the carriage DAQ:
		
		PCL 121020 (BNC)
		PCL 121012 (BNC)

	On the wall outside the temp control room:

		PCL 120026 (B600)
		PCL 120039 (GH)

	Pilot house boxes:

		PCL 120027 (GH)
		PCL 120011 (B600)

	Pilot house boxes indside microwave rack:

		PCL 120027 (GH)
		PCL 120011 (B600)
	
	Outlet Box in pump room:

		PCL 120062 (GH)

April 12, 2000 (Wednesday) (HVS)

	Try to convert microwave signal in pilot house rack
	to 10Base10 and run the system on this GH link.
	(Failed).

	Next: Try a thick-wire tap to box in pilot house.
	(This is the way it will work when controller is
	moved upstairs.)

	Try to attach the DAQ lan (BNC) to the microwave
	interfaced on the carriage... This doesn't seem
	to work... The carrier lamp goes out when the
	either end (or both) are terminated.

	Assign a temporary IP to the HP print server
	so it can be seen on the GH LAN:
	You do this talking to the server with Telnet.
	If the printer can't talk to anyone for 5 min.
	it reverts to IP: 192.0.0.192.

	Printer network parameters: 
	
		ip:		192.9.102.100
		default-gw:	192.9.102.100
		subnet-mask:	255.255.255.0
		dhcp-config:	0

	To save your changes use quit, to revert
	to prior setting use exit.

	*******************************
	The carriage DAQ machine starts up with a DIO
	line value that starts the wave height gage motor.
	THIS MUST BE CHANGED.

April 17, 2000 (Monday) (HVS)

	Backup the exisiting system.
	Backup tapes are made for
		
		/opt/MTS		This is the controller source
		/opt/wind3		VxWorks
		/home/mts		This is the login account
		/etc/dt			Desktop customizations
	
	-> The file /opt/wind is a symbolic link to /opt/wind3.	
	-> The VxWorks startup script is located in
		/opt/MTS/etc/cc-gh.startup

	Restore the backup and verify that system can be built.
	
	How the desktop customizations work:
	
	All the files seem to be in:
	
		/etc/dt/appconfig/types/C
		
		wave.fp		Defines the whole "Wave Applications" menu.
		
		These are the "PUSH_ACTIONS" referenced in wave.fp:
		
		Wave_Generator.dt
		CC-GH_Console.dt
		Wave_Acquistion.dt
		CA-GH-PF_Console.dt
		Wave_Planner.dt
		Wave_Execution.dt
		Wave_Report.dt
	
	Details about configuring this sack of shit may be found in
	"HP-UX 10.x System Administration" by Marty Poniatowski,
	Hewlett-Packard Professional Books.
	
	configDsp.c
		Modify userClose so it only calls reboot()
	
	Arrives:
		Jerome 
	
April 18, 2000 (Tuesday) (HVS)

	Help Jerome as needed with networking.
	
	Jerome likes to chat with: 
	
		talk sce@cgh

	The 101 and 102 networks now work on the wall.
	Move all the portables & the HP as cgh to
	the b600 network: 192.101

	Update all the /etc/rc.config.d/netconf parameters
	to set up the new network as planned. 

	Note: To administer the HP with a GUI use: sam 
	
	Exchanging files:
	
	An exported NFS directory exists:
	
		/opt/MTS/matlab/exchange
		
		UPDATE: 06/28/00 HVS moved this
		directory to /home/exchange to keep
		the customer out of the b600Proj 
		directory.
	
	The client writes:
	
		iffile.txt
		
	We reply with:

		pqrfile.txt

	Arrived:
		Gerrard Reubeau (20 year vet)
		Thomas Coudray
		
		Entertain Gerrad, Thomas & Jerome.
	
		Jerome fixes the link to the platform!!!
	
	Makefile
		Update to match Brad's PC & fix Unix 
		compiler complaints.
	
	VxSerial.c
		Try Paul's version.
		Add include for <string.h>
	
	/opt/wind/target/h/setjmp.h
		Add include for vxWorks.h
		This is a standard modification we make at
		MTS to avoid collisions with Coops in our
		except.h Paul was unaware of this, so none
		of the exception handling worked properly.
	
	Modify the wave machine's startup script to load
	our new coops...
		
	To talk to the wave controller directly over the
	serial port:
		
		kermit -l /dev/tty0p0 -b 9600 -c
	
	The startup script (recorded here for references)
	
	boot device          : dc
	processor number     : 0 
	host name            : cgh-gh
	file name            : /opt/wind/target/config/mv2604/vxWorks
	inet on ethernet (e) : 192.9.102.15
	host inet (h)        : 192.9.102.1
	user (u)             : mts
	flags (f)            : 0x8 
	target name (tn)     : cc-gh
	startup script (s)   : /opt/MTS/etc/cc-gh.startup

April 19, 2000 (Wednesday) (HVS)

	Adda.h
		Change the VMEADDA from 0xc000000 to 0xd0000000
		This fixes some change (or non-change) Paul made
		to the vxWorks config files.
	
	/etc/shells
		This file was added so remote ftp will work when
		people are using the newly added bash shell.
		See "man shells" and "man ftpd" for details.
		This fill contains a list of all the valid
		login shells in the system.
		If it does not exist, the man page for ftpd
		lists the default shells. Bash is not one of
		them.
	
	Try the system with all of Brad's changes while
	retaining Paul's UpTCP (in Coops).

	This almost worked, but we had two problems:
	1) The Adda's did not create reliably. Adding
	a vxWorks taskDelay fixed this.

	2) The DspModel.attach method crashed while 
	creating an ActionSequence.

	It appears that floating point return values
	don't work properly with this link.

	We backed up this version of the project and
	will now attempt to remove Paul's built-in
	Downlink in Alltalk and restore the 'standard'
	coops link classes.

	To test:
	
	VAR rf := remotePort['refdly1']
	rf.delay should be a float
	
	VAR sys := remotePort.lookup['sys']
	VAR Sc := remotePort.lookup['StringClosure']	
	VAR sc := Sc.new[sys, #push, 'This is a test']

April 20, 2000 (Thursday) (HVS)

	To test the SerialPort using a single ByteArray write:
	
		*******************
		system.startUnix
		condPort.open[serialPortName]
		condPort.setRate[19200]

		METHOD clear[chas] OF CondPort IS
			Clear communications card.
		BEGIN
			self.sendCmd[chas, 0, 0, writeOp, 0, TRUE]
		END METHOD

		condPort.clear[1]
		********************
	
		This technique found a bug in PaulMessage.c : 
		the messageType array was not initialized for type
		mtByte. How did Paul's version ever work???
	
		Everything seems to work now....
	
	To make vxWorks use rlogin instead of FTP, you must
		have a .rhosts file in the login directory:
	
		~/.rhosts
		This file contains the single line:
			cc-gh
		
		It allows the vxWorks code to rlogin without
		a password. This is an advantage because if you
		use FTP instead, vxWorks will try to download a
		great big symbol table that takes forever.
	
	The Makefile has an anomally with the vxSerial tag.
		There may be some conflict with vxWorks. In any case,
		it was fixed by spelling the tag VXSerial. The file
		name remains the same.
	
	ccghSerial
		I added this shell script to launch the kermit
		terminal session to the vxWorks serial port on
		the wave controller. This makes it possible to
		talk with the wave controller without using any
		of the CDE menus.
	
	Summary: To build the wave machine application from sources:
	
		Go to the b600Proj directory.
		
		Three programs are built by the same Makefile:
			
			bin/vxSerial.o
			bin/coops.o
			AppDsp/Generic
		
		vxSerial.o 
		This the comm port interface between
		the PowerPC board and the on board serial ports.
		It is used for serial communcation between the
		PPC and the 497 and any other serial devices.
		The file must be loaded into vxWorks before
		Coops because it contains calls to the VxWorks
		runtime library that conflict with Coops 
		selectors. By loading it first, these symbols
		are bound to the proper VxWorks RTL entry points.
			
		coops.o
		This is the main image file that contains all
		the Coops classes. On Brad machines, it also
		contains the code to create and interconnect
		all the dataflow objects.
			
		Generic
		This is a host (HP-UX) program that autmatically
		constructs the files generic.h and generic.c 
		from the list of Coops selectors in generic.dat.
		It needs to be in the AppCon directory along
		with generic.dat to work correctly. If you
		need to add a selector, go into the AppCon
		directory, edit generic.dat, and then execute:

			./Generic
			
		Go out one level and do a make.
			
		To rebuild all the Coops and Host modules based on C:
		
			make clean
			make
		
		To update as needed after editing any source file:
			
			make
			
		To update the Alltalk application ccgh.exe :
		
			In the b600Proj directory:
			
			alltalk startup.alt
			system.updateApplication
			EXIT
		
	Normal operation of the system without the CDE menus:
	
		Simply run ccgh.exe in the top level directory:
		
	If things are messed up in the wave controller, you may
	need to reboot the PPC machine. 
	
	Run
		ccghSerial
		
	This will give you a terminal session to the VxWorks 
	environment on the wave controller.
	
	Type <control> X to get a reboot.
	
	Wait for everything to load and then try ccgh.exe again.
	It is very important to exit ccgh.exe by using the quit
	item from the File menu. If you <control> C from the 
	Alltalk console, the target system will have to get a
	reboot before you can run again.
	
	To restore the old wave controller:
	
	The /home/oldMTS directory contains the old controller.
	The current version described here is in /home/mts.
	You need to rename /home/mts to something like /home/newMTS
	and then rename /home/oldMTS to /home/mts.
	
	Next, run the console session to the cc-gh computer and
	quickly interrupt the VxWorks boot so you can edit the
	EPROM parameters.  You need to change the path to the
	startup script so it points to:
	
		/opt/MTS/etc/cc-gh.startup
		
	Software tasks outstanding:
	
	1) Update the WaveDAQ machine.
		I recommend building the DAQ controller out
		of the b600Proj directory. It can be built into
		another /bin image. The Alltalk interface
		can be another .exe at the top level.

		I <strongly> recommend a change in the naming convention:

		b600Proj/wave.exe	The wave controller gui.
		b600Proj/daq.exe	The DAQ controller gui.

		b600Proj/bin/wave.o	The wave controller coops image.
		b600Proj/bin/daq.o	The DAQ controller coops image.

		These changes require editing the Makefile and
		the startup.alt files. To make an 'empty' Alltalk
		application, simply copy b600Proj/Alltalk/alltalk
		to b600Proj/wave.exe or b600Proj/daq.exe
		
		The current names, such as ccgh, cc-gh, cc-gh-pf, etc.
		are utter nonsense and reflect the most profound
		misunderstanding of good software engineering practice.
		Naming the applications after the computer they run on
		is really stupid. How would you like to start Microsoft
		Word by typing zappia2?

	2) Update the TCL remote app reporting scripts.
		This will involve moving the TCL scripts
		and related source files to the new b600Proj
		directory.

	3) Update the menus at the bottom of the screen 
		so they run programs in or below the new b600Proj
		directory. The definitions are in a system directory
		described somewhere above.

	4) Clean up the old /opt/MTS System:
		Make sure you are happy with the new
		software, then delete the /opt/MTS
		and /home/oldMTS directories.

	There is some problem with the login account I don't
	understand. It is important for your .dtprofile to
	execute when you login to define all the paths and
	extra commands we expect to maintain the system.
	Sometimes this shell script does not run: for example,
	when you login remotely.

	To force the .dtprofile script to execute, type:

		source .dtprofile

	This should be fixed so it is more reliable.

April 21, 2000 (Friday) (HVS)

	To switch from the new software and the old,
	1) Switch the /home/mts directory. The mts
	directory to run the application is always
	called /home/mts. When running the new software,
	the old (Paul's) directory is called /home/mtsOld.
	When running the old software, the new directory
	is called /home/mtsNew.

	To rename these directories, become the super user
	and simply rename them:

	Old to new:
		mv mts mtsOld
		mv mtsNew mts

	New to old:
		mv mts mtsNew
		mv mtsOld mts

	Re-login to setup the paths correctly.

	2) Change the vxWorks startup script to point to
	the proper location. This is done by interrupting
	the boot process. Right after typing <control> X,
	hit any key quickly. You can then step through
	the settings by pressing c <return> and then
	skipping through by pressing <return>. When you
	get to the startup script path, type in the whole
	path:

	Old software: 
		/opt/MTS/etc/cc-gh.startup

	New software:
		/home/mts/b600Proj/bin/ccgh.startup

****************************************************
***************************************************

June 21, 2000 (Wednesday) (HVS)

	Recover from flight while Tim & Dale
	do the training class in the lab room.

	Work on the language translator module.
 
June 22, 2000 (Thursday) (HVS)

	Install dynamic language translation.
	Various fixes & improvements were made
	to Translation.alt.

	Work on the Alltalk/Alltalk link between
	the wave generator and the wave acquistion
	programs.

June 23, 2000 (Friday) (HVS)
	
	Backup the current b600Proj and b600qProj.
	The person who named the platform daq application
	"b600qProj" should be punished.

	I renamed the b600Backup directory to "backups".
	I created a directory called "data" to hold all
	the customer and test data files. These need to
	be separated from the application because we are
	running out of disk space and the backups are too
	large to continue.

	PLEASE TELL THE CUSTOMER NOT TO SAVE DATA, CALIBRATION,
	OR SETTINGS FILES IN THE /mts/b600Proj directory.

	An exception would be made for updates to the default
	calibration or settings files.

	DO NOT STORE GLARK OF ANY KIND IN THE b600Proj or
	b600qProj directories. 

	I moved all the glark out of b600Proj into /mts/data.
	I renamed all the existing backups to reflect the date
	they were created. Then I tar/gziped them. 

	Let's try to be consistant about using the backups
	directory and giving the files stored there systematic
	names. You can't rely on the file system to maitain
	the file dates properly.

	Rebuild the entire application to verify the make process.
	It works!
	
	(This is for b600Proj only...)

	Update Alltalk:
		Need to have hpuxModule.c because dl is not the same... 
		Add Paul's special interface code for DownTPC, UpTCP
		and Interface.
		DONE.
	
	Combine Alltalk with Brad's new Gui and the current settings and
	calibration. Test with the old Coops code (recompiled today)
	DONE. It works.
	
	TBD:
		Window titles are not translated back to English.
		Brad's main panel needs a special translation because
		he appends the name of the settings file.

June 24, 2000 (Saturday) (HVS)

	I changed the scripts that run the wave generator and the
	platform data acquisition programs because they ran a
	script without a path name. Only the mts account had
	these scripts in the top level directory, so only the
	mts users could operate the menus.

	I moved the scripts into the b600Proj and b600qProj
	directories and made the paths in the dt scripts
	absolute:

	Changed:
	/etc/dt/appconfig/types/C/Wave_Generator.dt
	/etc/dt/appconfig/types/C/Wave_Acquisition.dt

	Created: (These replace the old scripts)
	/home/mts/b600Proj/waveGenerator
	/home/mts/b600qProj/waveAcquisition

	Paul: How can you have a conscience and name a program
	something like cc-gh or cc-gh-pf?

	Idea: If the applications keep absolute path names
	to the files and directories they need to operate,
	we don't have to set the default directory before
	starting them. In this case, each user would see
	their own home directory when the open/save files
	from the applications. This would encourage them
	not to put them tin the b600Proj directory.

June 26, 2000 (Monday) (HVS)

	Problem: The application has to startup with the
	default directory set to where the .exe is located,
	but we want each user to save their settings and
	data files in their own directory.

	Problem: We want to execute the programs remotely
	without a lot of fussing around with DISPLAY
	variables and directories.

	I changed the Alltalk kernel by adding support for
	the standard unix "-display machine:x.y" option.
	Any user on any machine can now telnet onto cgh
	to their own account and type:

		ccgh -display localhost:0.0
	or
		cagh -display localhost:0.0

	The ccgh and cagh are the names of scripts that 
	run the ccgh.exe or cagh.exe alltalk programs
	respectively. I got rid of the cc-ga and ca-ga-pf
	names because they made Brad and I feel ill when 
	typing them.

	To make remote execution possible, I added to symbolic links
	to the /usr/bin directory. This was needed because rexec
	looks in /usr/bin for remote commands. These statements
	were used to set up the links:
	
		ln -s /home/mts/b600Proj/ccgh /usr/bin/ccgh
		ln -s /home/mts/b600Proj/cagh /usr/bin/cagh

	The customer may execute the wave generator (ccgh)
	or the data acquisition (cagh) from a remote machine
	using these shell commands:
	
	Authorize cgh to create an x display on the user's machine:
	
		xhost +cgh
	
	Execute the wave generator (ccgh) on the cgh machine:
	
		rexec -l username -p password cgh ccgh -display userMachine:0.0
	
	The user must have a shell account set up on cgh.
	If the username matches the user's login name on their own machine, both
	the "-l username" and the "-p password" options may be omitted. In this
	case, the user will be prompted for their remote password.
	
	The userMachine parameter is the IP name of the user's machine, which
	must be known to the cgh machine. If the name is not in the cgh machine's
	/etc/hosts file, the IP number may be used instead.
	
	To run the wave acquisition program use cagh instead of ccgh.
	To run the wave planner, use matlab.

	The user <does not> need any special definitions in their login
	script to make all this work.
	
	The user may also telnet into their own account on cgh. In this
	case they don't need to rexec:
	
		ccgh -display userMachine:0.0
		cagh -display userMachine:0.0
		matlab -display userMachine:0.0
		
	To run directly on the HP, we have provided menus for the customer.
	The ccgh, cagh, or matlab commands will also work from any login shell.
	
	
	I changed the default shell (on the last visit) to bash.
	The login script is called .bash_profile.
	I modified .dtprofile to run .bash_profile when you create
	a shell session on the HP or from a remote telnet account.
	This should fix the weird character delete problems.
	
	TODO: Tell Gary about this change. It must drive him nuts
	not to be able to edit on the console.

	Gui:
	Innumerable changes.
	Should not effect the project structure.
	
June 27, 2000 (Tuesday) (HVS)

	The microwave network for gh works now.
	The microwave network for b600 does not.
	We tried to run the wave controller from a PC running Exceed
	on the platform. It worked but took a very long time to come up.
	The speed seemed to be about 9600 baud. Too slow to be safe
	while pumping oil...

	I installed Samba, a netbios server/client package for Unix.
	This lets the customer get at the /home/exchange directory
	where we keep the files that tell the test where to run in 
	the basin. Samba works with directly with the Microsoft
	networking protocols, so the customer can see their files
	with the regular Network Neighborhood browser.

	UPDATE: The customer decided they liked NFS after all so
	I removed Samba...
	
	The files in /home/exchange were moved out of /b600Proj/Matlab
	because I'm trying to keep the customer out of our project
	directory.

	I also exported an NFS mount point for /home/exchange so
	they can get at the files that way also.

	The installer and associated documents for Samba are in 
		/usr/local/src.
		
	All the man files are installed as well.
	You can fiddle with samba through the web.
	Launch netscape and go to:

		http://localhost:901

	Sadly, entire books have been written about Samba.
	
	TODO: Install the "userDirectory" concept in the
	b600 Gui: MySystem.start should setup the startDirectory
	to where the application is located and the userDirectory
	to where the user's account is located. All the editors,
	settings, data etc. should go into the users account.
	
	**********
	
	The serial port to the position PLC does not work.
	1) The 432 adapter was in the wrong mode (DCE instead
	of DTE)
	2) Brad did not pass the name of the port to scpf.open[name].
	3) The vxSerial2.o module was not downloaded.
	   Both vxSerial AND vxSerial2 must be loaded:
	   SerialFile.c uses vxSerial to talk with the 497.
	   This is standard COOPS stuff.
	   The vxSerial module does not, sadly, allow multiple
	   serial devices so Paul made an identical module
	   called vxSerial2 that has uppercase function names.
	   It opens another serial device that talks to the
	   port.
	   
June 28, 2000 (Wednesday) (HVS)

	The matlab program finds its startup.m file by looking
	though a set of directories listed in the file:
	
		/opt/matlab5/toolbox/local/pathdef.m

	We have added a path to this directory for:
	
		/home/mts/b600Proj/Matlab/
		
	The startup.m file is here.
	
	NOTE: When you edit this file or if you recreate
	any directory in the path to this file, you must
	insure that the permissions will allow new users
	to read the startup.m
	If you add a new user and they can start matlab
	but the waveplanner doesn't automatically start,
	the file permission is probably the problem.
	
	To eliminate the need for special .login or
	.dtprofile files, I put symbolic links for
	ccgh, cagh and matlab in the /usr/bin directory.
	
	The symbolic links for ccgh and cagh point to the
	script files with the same names in b600Proj and
	b600qProj. These scripts set the appropriate
	default directory and then run the proper .exe file.
	
	I don't like naming executable files with .exe on
	Unix but Brad had a fit if we didn't...
	
	The mts account has an invisible .rhosts file.
	This file is there to enable rlogin protocol for
	vxWorks to download to cc-gh and ca-gh-pf. If
	you chjange the host names for these computers
	in the /etc/hosts file, don't forget the entires
	in this invisible file.
	
	I removed Samba because the customer decided they
	prefer NFS to Microsoft's smbfs. I also had problems
	getting Samba to work with the NT workstations on
	the platform. I thing they may have domain controller
	lurking somewhere...

	I gave up trying to figure out Paul's SCPF.c in
	the b600qProj. I rewrote the module and found
	other problems. The vxWorks terminal names for
	the serial ports that come out of the VME box
	are:
		VxWorks		VME

		/tyCo/0		1	(The VxWorks console)
		/tyCo/1		2	(The port to the 497)
		/tyCo/2		3	(For SCPF.c platform position)
		/tyCo/3		4	(Not used.)

	The SCPF documentation states that it wants to be RS422 with
	DTE protocol. We used a small BlackBox module to get this
	conversion. It has a little switch that can be set for
	DCE or DTE. It turns out that it needs to be DCE to work
	with the customer's equipment.

	*************

	This is a Bad Thing(tm):
	We need special, different versions of Alltalk for
	ccgh and cagh. This is because ccgh (the wave controller)
	needs the Interface.c module which is a server that needs
	to bind to a specific TCP/IP port. This port number is
	coded into Interface.c. As a consequence, we can't have
	two copies of this program running at once.

	The cagh doesn't need Interface.c, so it is removed from
	b600qProj/Alltalk.  When you type simply 'alltalk' at
	the command shell, you will get the b600Proj version
	of alltalk. You can't use this to create the 'blank'
	executable for cagh.exe.

	You CAN use the 'wrong' version of alltalk to compile
	the heap for cagh:

	In the b600qProj directory you can type:

		alltalk unixStartup.alt
		system.updateApplication
		EXIT

	This will run the WRONG version of alltalk to compile
	the cagh application. But the cagh.exe file you
	save the heap into will be a copy of the right
	alltalk executable copied (by you) into the
	the cagh.exe file before you compiled the new image.

	You MUST exit before trying to run cagh.
	
June 29, 2000 (Thursday) (HVS)

	Housekeeping day.
	We're having what looks like a hardware failure
	on the HP's video card...

	The HP video is totally fuzzed out and the wave controller
	crashes by having the main panel simply disappear from
	the screen with all the other panels still visible.
	
	We took the HP down, pulled out all the cards, memory
	SIMMS and disk drive and then blasted every part with
	the big air hose. It looked like the inside of your
	vacuum cleaner bag. I dropped the disk drive on my foot,
	but it still works. I limp.
	
	This video works perfectly now. The problem may have been
	heat related because the heat sink fins were packed full
	of concrete dust. The boards and memory SIMMS were also
	dusted with powdered metal grindings.
	
	The system has accumulated a number of flaws and
	misconfigurations that need to be corrected. Several
	"FAIL" indicators go off during the startup scripts
	and the system log file is full of complaints. The
	swinstall shows that some entity installed the operating
	system again and again without doing the proprer upgrade
	sequence.

	The HP system log file is in:

		/var/adm/syslog/syslog.log

	The rc scripts create a log in:

		/etc/rc.log

	Let's make all these files run clean...
	
	The 'Vue' thing that comes last in the rc scripts tries
	to delete a file that isn't there without using the -f
	switch. FIXED.
	
	The X fontserver (xfs) reported an error in the rc scripts.
	I thought this might explain why we get some bad French
	characters on the HP but not on other x terminals so I
	edited:
		/etc/X/fs/config
		
	I removed all the fonts that are not on the system
	and reformated the file so humans can read the names.
	It now boots without an xfs error. FIXED
	The same French letters are still wrong on the
	local display. Maybe we need to use some Euro-font?
	But it works perfectly on my laptop with the same-named
	X11 font.
	
	The DNS reports an error in the rc script.
	This machine is not configured to participate
	as a DNS on the LAN so I turned off the nameserver
	in /etc/rc.init.d/namesvrs. FIXED
	
	The startup process should now report no errors...
	
	In case you need to fuss with them, the rc scripts
	are in:
		/etc/rc.init.d
	
	********************
	
	SCPF.c 
	More protocol dump revisions.
	Trash all of Pauls original code.
	Add new comments.
	
	SCPF.alt
	Revised to remember baud rate and to download by opening
	the port and setting the rate. This is necessary because
	Brad executes unixStart before attaching to the vm.
	He broadcasts #download later so we have to open then.
	
	TODO: 
	Rattle Brad to add constants for the SCPF port name and
	baudRate. Set these up like the other link names.

	When the ccgh crashes (for some reason...) we can't 
	restart because the Interface.c is trying to bind
	to a known port number. The operating system hangs
	on to server ports "for some time" according to the
	bind documentation. As a result, we can't start 
	ccgh right away. 

June 30, 2000 (Friday) (HVS)

	I found the debugger, dde, to be quite good.
	Because we segragate the objects and the sources,
	you have to explictly set up the source path when
	debugging Alltalk or other HP program images.
	
	I fixed the problem that made it impossible to restart
	the ccgh wave controller after a crash because the server
	socket was still held up by the system. The fix involves
	setting a socket option called SO_RESUSEADDR on the
	listener sockets after we bind them in Interface.c.
	
	Paul tried to deal with this in UpTCP.c by trying 
	to bind the socket 100,000 times. I removed this
	wretched hack and put in the SO_REUSEDADDR fix.
	
	I found and fixed an awful bug in Alltalk that
	probably caused the crash last week. It had to
	do with error logging, so it may be that the
	application had some kind of error and Alltalk
	crashed trying to make a report. The orginal
	error is probably still there but at least
	we can see what's happening now.

	Documentation updates:
	
	b600Proj/Documents/AAREADME.TXT
	
		The rest of this section:
		
	b600Proj/AppSys
		I added this directory to hold backups of all the operating system files
		we add or change. In theory, we could reinstall HPUX to a clean disk and
		put these files back to restore the system. By restoring out /home/mts
		account we would be back in business. ;-)
	
	b600Proj/AppSys/AASystemChanges.txt
		Explains what all the changed system files are for.
	
	AAUnixHelp.txt
		Unix for Windows people.
	
	AAHPUnixHelp.txt
		Procedures specific to this HPUX system.
		Like how to get at the tape, cdrom or floppy.
		
	AAHowToBuildB600.txt
		How to compile the programs.
	
	AAHowToPowerUp.txt
		How to deal with the pump room controls and
		console power up procedures.
	
	AAHowToRunB600.txt
		How to run ccgh, cagh and the waveplanner from 
		a user's perspective.
		
	AAProjectFiles.txt
		A list of all the b600Proj project files and why
		they are in the b600Proj directory. I would like
		to see this file maintained and I would like to
		trash other files I find in this directory.
		
		Actually, if you do find customer or debugging
		files in b600Proj, please move them to the /home/mts/data
		directory and tell the offending party. If you create
		trash files in this directory, delete them when you leave
		or put them in the data directory.
		
		When the data directory fills up the whole disk, back
		it up to tape and delete all the files.
		Mail the tape to MTS Central Services and tell them
		to archive it in the off-site vault. Or equivalently,
		erase the tape and use it for some other purpose.
	
	***********************
	
	Both cagh and ccgh can now use the same version of Alltalk, so I
	removed the copy of Alltalk in the b600qProj. They both build with
	the same executable copy of alltalk. When you want to update
	ccgh.exe or cagh.exe, take a copy of alltalk from b600Proj/Alltalk/alltalk.
	
	TODO:
	It is possible to specify that an application should start with no terminal
	window in the /etc/dt scripts for the CDE menus. Unfortuately, alltalk hangs
	up when trying to read from stdin. I will try to fix this so you can bring
	up ccgh and cagh without the console window popping up. It is a hazard
	because I've kill the application several times by accidentally putting 
	their associated consoles away.
	
	UPDATE:
	I figured out how to run without the terminal windows. 
	Now you can launch ccgh and cagh with no terminal sessions
	using the CDE menu. This is good for the customer because
	they won't accidentaly kill the application by closing the
	window.

	It is probably better for us (MTS) to get in the habit
	of running cagh and ccgh in the terminal window. (Which
	you do by simply launching a terminal session and typing
	cagh or ccgh. The reason for this is that certain errors
	only appear in the console window and we need this information
	to debug the application. Of course, there are no more bugs
	now...

	IMPORTANT:
	A side effect of the this fix is that the unixStartup.alt
	files now do a stdin.erase when you execute the expression
	system.updateApplication to update the executable. The
	console window doesn't actually disappear at this point,
	but you can no longer execute expressions: You can't type
	EXIT to get out of the application anymore. You have to
	choose quit from the application's file menu.

	IMPORTANT:
	If you start the applicatoin from a console with ccgh
	or cagh, you can't send any commands to Alltalk until
	to re-enable the console by choosing the "Listener" item
	from the Service menu.

	**********************

	I changed the name of Paul's top level /opt/MTS directory
	in preparation for backing it up and deleting it from
	the system. (I think we already have this on tape.)
	It is now called:

		/opt/MTS_BACK_THIS_UP_AND_DELETE

	After doing this I discovered that tcl could not
	be built without fixing some of its internal paths.
	I did these corrections and rebuild our local copy
	of b600Proj/tcl. It failed because three files were
	missing:
	
		downrpc.h
		message.h
		selector.h

	I have looked through every backup tape on site without success...
	They are not complicated files and I (or you) can recreate them
	by studying the code in the existing modules.
	
	In order to get the tcl menus to work again, I put back
	the /opt/MTS directory. Things are in a hacked up state
	now because the menu items are pointing into tcl files
	in the b600Proj/tcl directory and these scripts point 
	back at /opt/MTS stuff. The tcl thing is a mess. 
	
	TODO: We need to get to a point where we can build these
	scripts from sources entirely in the b600Project.
	It would be even nicer to get rid of TCL altogether...
	
	***********************

	Before Brad and I left on Friday p.m.:

	Built all software from scratch and verified that
	it works.
	
	Update all the documents in the Documents directory
	that begin with "AA". These are (currently) the 
	official screed on how to start, operate and
	maintain the software. 

	Please try to run ccgh cagh from console windows rather
	than the nice menus because if problems occur, extra
	debugging info will be listed.

	Alltalk has been compiled with full debugging info
	so it is a little bit slower now.

	IF YOU GET A CRASH running ccgh or cagh, SAVE
	THE core FILE!!! It will probably be in the
	b600Proj or b600qProj directory. You can
	run the nice dde debugger on this file
	and get a ton of information:

		dde /home/mts/b600Proj/ccgh.exe core

	Set the source search path if necessary and you can
	see exactly what went wrong.

	End of Hugh visit.  Friday June 30, 2000

	*****************************************

July 10, 2000 to July 15, 2000 Vist (GWL)

	No software changes other than the July 10 updates from Thoen.

	Application window colors became corrupted on two occasions.
	Changed the number of colors to "most colors" in the HP color
	setup utility. This paramter seems to get reset to the default
	when the system is rebooted. If the "most colors" selection is
	the fix for this problem, this setting needs to be watched very
	carefully. Or, the dependence on this setting needs to be
	removed.

	Tested the Matlab wave calibration software. It seems to work
	in that each iteration was closer to the desired PSD. However,
	the data recorder hangs up some time after the first iteration
	(i. e., on the 2nd, 3rd or 4th iteration). There is know way
	to recover other than quitting and restarting the application.

	The file selection dialog behind the current drive file button
	uses *.drv* as a filter. But, the software generates files with
	names like drv1, drv2, etc. Selecting one of these drv files
	fails with an error message claiming that file "drv0" is not a
	wave height time history file.

July 17, 2000 to July 22, 2000 Visit (GWL)

	No software changes except for "m" files received from Thoen.

	Application colors still get corrupted(regardless of the number
	of colors selection). This really needs to get fixed.

	Tested a fix (from Sparks) for the data recorder hang up. The
	change refered to as "nice try #1" made the problem worse. So,
	the "fix" was removed.

	It was noted that if a drive file with header information missing
	(e. g., one that is still in DOS format) is introduced to the the
	system, subsequent previews of (correct) drive files show Nan's
	for the velocity reference channels. It is necessary to restart
	the application to fully recover. 

July 24, 2000 to July 30, 2000 Visit (GWL)

	Monday - Arrive 8:15 AM. Record the following:

		Lower N2 at 1918.4 psi
		Lower Support at 4.0 psi
		Upper N2 at 216.0 psi
		Upper Support at 435.0 psi

		Upper Flap at -2.3 deg
		Lower Flap at -14.0 deg

		Down Tank Gage 1 at -0.06 m
		Down Tank Gage 4 at -0.06 m
		Down Tank Gage 6 at -0.05 m

		Flap Gage 1 at -0.048 m
		Flap Gage 2 at -0.051 m
		Flap Gage 3 at -0.048 m

		Side seal N2 at 490 psi

	Oil temp light turned green at:

		Inlet #1 = 39.6 C
		Inlet #2 = 37.5 C
		Outlet #1 = 40.1 C
		Outlet #2 = 37.6 C

	Notes on WQ Run #1 AiryMono1H5.des

		At 9AM record tank conditions in file Tank_AiryMono1H5_9AM for 10 seconds.

		First iteration with Iteration Gain = 1.0 but master gain  is at 80%.
		So, ignore this run.

		Change master gain to 100% and iterate three times. Correction seems
		very slow. So, change iteration Gain to 10.0 and iterate two more times.

		Peak error seems to flatten out. Try one more iteration with the
		Iteration Gain at 1.0. Reflections are back at 9:30 AM.

		Set up scope and three digital meters to watch wave gages. After
		3.5 hours, the reflections are gone. So are the cross tanks. Tank
		seigh is down to about 8 mm.

		At 1PM record tank conditions in file Tank_AiryMono1H5_1PM for 4 minutes.
		Reset Wave Calibrator to use AiryMono1H5.drv8 and iterate two more times
		with Iteration Gain = 1.0.It appears that we are as close as we will get.


	Tuesday - Arrive 7:30 AM. Record the following:

		Lower N2 at 1924.5 psi
		Lower Support at 2251.0 psi
		Upper N2 at 176.0 psi
		Upper Support at 234.0 psi

		Upper Flap at 11.2 deg
		Lower Flap at -7.1 deg

		Down Tank Gage 1 at -0.07 m
		Down Tank Gage 4 at -0.07 m
		Down Tank Gage 6 at -0.06 m

		Flap Gage 1 at -0.002 m
		Flap Gage 2 at -0.001 m
		Flap Gage 3 at -0.005 m

		Side seal N2 at 400 psi

	Oil temp light turned green at:

		Inlet #1 = 37.8 C
		Inlet #2 = 40.6 C
		Outlet #1 = 38.5 C
		Outlet #2 = 41.0 C

	Increased side seal N2 to 600 psi. I tightened the little yellow cap
	on the bottom of the small accumulator last night. Need to continue
	to monitor this pressure.

	Restart application to get new temperature units on cooling temp
	status panel entries.

	After moving DT Gage #4 to 9 meters, and re-deploying, it's offset
	is now -0.050 meters.

	NOTE: One hour after doing the balancing act and pushing zero, the
	tank seigh appears to be about 0.015 m. This is determined by monitoring
	Wave Feedback (flap) and Down Gage #4 on the scope(with a 4 minute
	sweep).

	At about 10 AM the GUI became very slow. Response to buttons was
	on the order of several seconds. Eventually, a 497 interlock message
	was logged in the status window. Pushing reset on the main GUI panel,
	lights the reset indicator white. But, I am not able to reset the
	HPU's. CTRL x in the cc-gh window appears to cause some increase in
	network traffic. But, none of the VxWorks logo or happy clam messages
	appear. Cycling power on the 498 console does not change this. Even so,
	I am able to start the application and control the system. Go figure....

	I've changed wavecal.m to use the ratio of the desired to the response
	wave height (rather than the difference) to form the drive scale. Also,
	the scale is applied to the previous scaled drive ( not to the original
	drive file). With these changes in place, calibration of regular waves
	is possible in three to five iterations with an iteration gain of 1.0.

	Ran test with AiryMono1H5.out5 as the drive file. Data was recorded in:

			WAiryMono1H5_1


	Wed - Arrive 7:10 AM. Record the following:

		Lower N2 at 1930 psi
		Lower Support at 2362 psi
		Upper N2 at 213.0 psi
		Upper Support at 380 psi

		Upper Flap at -2.0 deg
		Lower Flap at -9.5 deg

		Down Tank Gage 1 at -0.074 m
		Down Tank Gage 4 at -0.054 m
		Down Tank Gage 6 at -0.061 m

		Flap Gage 1 at -0.033 m
		Flap Gage 2 at -0.034 m
		Flap Gage 3 at -0.027 m

		Side seal N2 at 550 psi

	Oil temp light turned green at:

		Inlet #1 = 37.0 C
		Inlet #2 = 36.5 C
		Outlet #1 = 38.6 C
		Outlet #2 = 36.8 C

	Reran AiryMono1H5.out5 with the data recorder set up as per Zappia's latest
	instructions. Iterated on AiryUF1H5 and reached "convergence" at 6 iterations.
	Have implemented a version of wavecal.m that corrects the previous drive
	spectrum at each iteration. Used this version to iterate on JSMono3H8.
	Because tank conditions get so bad with this high energy test, it is necessary
	to wait at least 5 hours before the next iteration. So, I've not reached a
	conclusion wrt "new" wavecal.m.

	Ran JSMono3H8.out2 and collected data with the data recorder. The file,
	WJSMono3H8_1 was sent to Tim.

	The screen colors became corruoted at about 5 PM. I sent a gif and word doc
	of this to Sparks.

	Thursday - Arrive 7:10 AM. Record the following:

		Lower N2 at 2072 psi
		Lower Support at 2276 psi
		Upper N2 at 224.0 psi
		Upper Support at 326 psi

		Upper Flap at -0.29 deg
		Lower Flap at -6.75 deg

		Down Tank Gage 1 at -0.074 m
		Down Tank Gage 4 at -0.054 m
		Down Tank Gage 6 at -0.061 m

		Flap Gage 1 at -0.052 m
		Flap Gage 2 at -0.054 m
		Flap Gage 3 at -0.048 m

		Side seal N2 at 490 psi

	Oil temp light turned green at:

		Inlet #1 = 35.9 C
		Inlet #2 = 36.9 C
		Outlet #1 = 36.7 C
		Outlet #2 = 37.4 C

	Start to recal down tank gages

		Gage 6 (at 21 m )	old		new
		offset			2.38		3.054
		gain			1.557		1.551

		Gage 4 (at 9 m )	old		new
		offset			1.580		2.0056
		gain			1.385		1.357

		Gage 1 (at 67 m )	old		new
		offset			2.134		2.929
		gain			1.555		1.547

	Start to recal flap gages

		Flap Gage 1		old		new
		offset			1.0659		1.618
		gain			1.262		1.257

		Flap Gage 2		old		new
		offset			2.294		2.33
		gain			1.253		1.223

		Flap Gage 3		old		new
		offset			1.859		2.059
		gain			1.264		1.253


	First attempt to iterate on AiryUF1H8 is not very successful. While waiting for
	still tank, the application colors become corrupted. Must restart application
	at 11:45.

	Continue to iterate on AiryUF1H8. After 5 iterations, H13 is still out of spec
	(des = 0.125 achived = 0.120). I believe this is because wavecal.m uses
	max - min to calculate the achived wave height(H). I intend to rewrite it
	to use Hmean.


	Friday - Arrive 7:20 AM. Record the following:

	Application colors are corrupted. So, it was restarted.

		Lower N2 at 1933 psi
		Lower Support at 2452 psi
		Upper N2 at 229 psi
		Upper Support at 402 psi

		Upper Flap at -1.00 deg
		Lower Flap at -9.31 deg

		Down Tank Gage 1 at 0.074 m
		Down Tank Gage 4 at not recorded before recal
		Down Tank Gage 6 at 0.07

		Flap Gage 1 at 0.081 m
		Flap Gage 2 at 0.056
		Flap Gage 3 at 0.066 m

	NOTE: The offsets above are now all positive. The missing water is back!

		Side seal N2 at 400 psi. I reset it to 700 psi

	Oil temp light turned green at:

		Inlet #1 = 35.9 C
		Inlet #2 = 36.9 C
		Outlet #1 = 36.7 C
		Outlet #2 = 37.4 C

	The red light labled "Defalt Debit" on pump two of cooling unit one comes
	on. I switched over to pump one.

	Will recal wave gages again.

		Gage 6 (at 21 m )	old		new
		offset			3.054		1.84
		gain			1.551		1.538

		Gage 4 (at 9 m )	old		new
		offset			2.0056		.709
		gain			1.357		1.312

		Gage 1 (at 67 m )	old		new
		offset			2.929		1.900
		gain			1.547		1.546

	Thumped the board really bad while starting up. There goes 4 hours
	while I wait for still tank. From now on be more careful:

		1. Set setpoints to current flap positions.

		2. Select and turn on the HPS.

		3. HSM low pressure and let the pressure balancer work.
		   Don't putz with it unless it's trying to get below the
		   precharge.

		4. HSM hi pressure.

		5. Set setpoint span rate to .1 and push zero. It'll
		   take 5 or ten minutes for the board to reach zero.
		   But, you won't introduce a BAFW into the tank.

		Flap Gage 1		old		new
		offset			1.618		.416
		gain			1.257		1.259

		Flap Gage 2		old		new
		offset			2.33		1.429
		gain			1.223		1.232

		Flap Gage 3		old		new
		offset			2.059		1.30
		gain			1.253		1.251

	Gage positions (after deploy) are now:

		Down Tank Gage 1 at -0.003
		Down Tank Gage 4 at -0.0292
		Down Tank Gage 6 at -0.007

		Flap Gage 1 at -0.0113
		Flap Gage 2 at -0.0125
		Flap Gage 3 at -0.008


	I've changed wavecal.m to use H13 of the response time history as the
	iteration criteria. Two more iterations on AiryUF1H8 produced a response
	file with H13 = .1246( desired = .125). Waited two hours and recorded
	AiryUF1H8_1 with the the 13 channels in Tim's email plus downtank gages
	1, 4, and 6.

	First run of AiryMono3H8 with iteration gain of 1.5 produced a response
	with H13 = .54 (desired = 0.8). We'll try again.

	Closer analysis of the AiryUF1H8 shows we need one more iteration.

	Application colors went away at 7:00 PM. Restarted application.


July 31, 2000 to August 5, 2000 Visit (GWL)

	Monday - Arrive 7:15 AM. Record the following:

		Lower N2 at 1910 psi
		Lower Support at 6.0 psi
		Upper N2 at 216.0 psi
		Upper Support at 539.0 psi

		Upper Flap at -7.9 deg
		Lower Flap at -14.0 deg

		Down Tank Gage 1 at -0.016 m
		Down Tank Gage 4 at -0.029 m
		Down Tank Gage 6 at -0.017 m

		Flap Gage 1 at 0.092 m
		Flap Gage 2 at 0.105 m
		Flap Gage 3 at 0.101 m

		Side seal N2 at 590 psi

	Oil temp light turned green at:

		Inlet #1 = 39.6 C
		Inlet #2 = 37.5 C
		Outlet #1 = 40.1 C
		Outlet #2 = 37.6 C

	Impossible to get board out of the end caps. One or both go unstable as soon
	as we try to move the lower flap(even 0.1 deg). After three hours, I disabled
	all of the yaw and warp controllers and brought the board to zero. Then reset
	the force balance controller reset autorities to 0.5 instead of 10.0. System
	seems stable force balance feed backs are:


		Upper yaw = -2.0 kN-m
		Upper warp = -.7 to +.8 kN

		Lower yaw = .4 kN-m
		Lower warp = -.8 to +.6 kN

	Do I save these settings, or not? We'll see.

	Run of AiryUF1H8.drv7 with iteration gain = 1.05 produces much too big
	response. Also, delay time for data recorder is calculated to be 4.5 sec.
	This is way wrong. We almost missed the entire wave train. This is a bug
	I've introduced. I. e., the delay period is not recalculated when restarting
	iterations( i. e., selecting a drive other than drv1 to start). This is fixed.

	Several more iterations on AiryUF1H8. I give up. It looks pretty good. Run
	one more AiryUF1H8 test and collect data in WAiryUF1H8_1. Run AiryMono3H8
	twice. Looks good after three iterations.

	Major leak in pump room. Will email KL jpg's and try to get some advice.


	Tuesday - Arrive 7:15 AM. Record the following:

		Lower N2 at 1932 psi
		Lower Support at 2361 psi
		Upper N2 at 185.0 psi
		Upper Support at 539.0 psi

		Upper Flap at 4.7 deg
		Lower Flap at -7.0 deg

		Down Tank Gage 1 at -0.015 m
		Down Tank Gage 4 at -0.032 m
		Down Tank Gage 6 at -0.015 m

		Flap Gage 1 at 0.007 m
		Flap Gage 2 at 0.000 m
		Flap Gage 3 at 0.001 m

		Side seal N2 at 490 psi

	Oil temp light turned green at:

		Inlet #1 = 39.6 C
		Inlet #2 = 37.5 C
		Outlet #1 = 40.1 C
		Outlet #2 = 37.6 C


	No answer from KL about oil leak in pump room. So, I put a bucket under it.
	I eventually tightened the leaky plug. That stopped the leak for now.

	Ran AiryMono3H8 and collected data into WAiryMono3H8_1. Ran AiryMono3H2 with
	an iteration gain of 2 for the first pass. Than ran once more with a gain
	of 1.0 and got very good results.
 
	NOTE: The application colors go away at least once a day now.

	Wed - Arrive 7:15 AM. Record the following:

		Lower N2 at 1995 psi
		Lower Support at 2298 psi
		Upper N2 at 188 psi
		Upper Support at 287 psi

		Upper Flap at 4.6 deg
		Lower Flap at -4.4 deg

		Down Tank Gage 1 at -0.0146 m
		Down Tank Gage 4 at -0.0382 m
		Down Tank Gage 6 at -0.0132 m

		Flap Gage 1 at 0.0009 m
		Flap Gage 2 at 0.007 m
		Flap Gage 3 at -0.0033 m

		Side seal N2 at 400 psi I reset this to 700 psi.

	Oil temp light turned green at:

		Inlet #1 = 39.6 C
		Inlet #2 = 37.5 C
		Outlet #1 = 40.1 C
		Outlet #2 = 37.6 C

	Ran AiryMono3H2 and aquired data in WAiryMono3H2_1. But, I will redo this
	with lower channels selected in the data recorder not the upper's. This
	is also true with AiryMono3H8. Also redo AiryUF1H2 because it does have
	lowers instead of the uppers.

	Iterated 4 times on AiryMono4H5. Looks good. Actually, one more iteration
	was required. Then carefully pick analysis region.


	Thursday - Arrive 6:50 AM. Record the following:

		Lower N2 at 2221 psi
		Lower Support at 2300 psi
		Upper N2 at 238 psi
		Upper Support at 323 psi

		Upper Flap at -1.16 deg
		Lower Flap at -3.59 deg

		Down Tank Gage 1 at -0.0144 m
		Down Tank Gage 4 at -0.0372 m
		Down Tank Gage 6 at -0.0152 m

		Flap Gage 1 at -0.016 m
		Flap Gage 2 at -0.022 m
		Flap Gage 3 at -0.025 m

		Side seal N2 at 600 psi.

	Oil temp light turned green at:

		Inlet #1 = 39.6 C
		Inlet #2 = 37.5 C
		Outlet #1 = 40.1 C
		Outlet #2 = 37.6 C

	First try at AiryKin4H5 sends upper flap into positive end cap with such
	force that I'm afraid something is broken. Now I cannot move the board.
	In high pressure, all I can hear is the sound of pressure being relieved
	somewhere in one of the actuators. But, pilot pressure does stay above
	2900 psi.

	Preview shows the displaceplent reference to be greater than 10^27 for both
	flaps. Wish I had done this first.

	Now system totally loses connection to the 498. Cold start everything. I. e.,
	cycle power on the 498 and reboot the HP(shutdown -r now).

	Restart the system after several aborted attempts.

	NOTE: Don't try to bring the board out of the endcaps with master gain at
	100%.

	I have previewed the AiryKin4H5 out1 file several times. All of the ref's
	now seem OK. I don't know what was wrong with the system before. Something
	about the history of operation will sometimes produce eratic behavior
	from the ref gen.

	AiryKin4H5.des is the the wrong height( 0.3549 instead of 0.5000). So, this
	test is wasted. There goes another 3 hours out the window.

	Ran two iterations with correct AiryKin4H5. Looked real good. After waiting
	three hours for still tank, the system went hard over again when I tried
	for one more iteration. After waiting for 2 more hours, I tried two more
	iterations. But, the tank is not still enough. I'll have to try again
	tomorrow.

	The MCC computer works. I ran the application on it. It's real slow. I. e.,
	it's not good to have the status logger open when trying to control the
	system.

	Tried to get the printer server on the B600 net. It seems to have a GH
	IP address. Will look at this further tomorrow.



	Friday - Arrive 6:50 AM. Record the following:

		Lower N2 at 2111 psi
		Lower Support at 2325 psi
		Upper N2 at 214 psi
		Upper Support at 334 psi

		Upper Flap at -0.424 deg
		Lower Flap at -5.067 deg

		Down Tank Gage 1 at -0.0148 m
		Down Tank Gage 4 at -0.0377 m
		Down Tank Gage 6 at -0.0187 m

		Flap Gage 1 at -0.021 m
		Flap Gage 2 at -0.031 m
		Flap Gage 3 at -0.021 m

		Side seal N2 at 550 psi.

	The original wave height of 0.35 m for the AiryKin4H5 IS the correct value.
	Yesterday was a total waste of time.

	The good news is that we get within spec after two iterations today
	(before 8:30 AM).

	Added wavesegstats.m. It calculates stats over a specified section of the input
	time history. This is so wavecal can iterate on Hmean calculated over the
	duration of a regular file not including the taper regions.

	Using the above, we get AiryMono6H5 in spec in two iterations.

	Ran AiryMono3H2.out2 to get WAiryMono3H2_1 with the 13 lower channels and
	three down tank gages. Also ran AiryMono4H5.out5 to get WAiryMono4h5_1.


August 7 to August 13, 2000 Visit (GWL)

	Monday - Arrive 7:15 AM. Record the following:

		Lower N2 at 1909.5 psi
		Lower Support at 7.2 psi
		Upper N2 at 233.2 psi
		Upper Support at 194.8 psi

		Upper Flap at -12.3 deg
		Lower Flap at -14.0 deg

		Down Tank Gage 1 at -0.026 m
		Down Tank Gage 4 at -0.043 m
		Down Tank Gage 6 at -0.026 m

		Flap Gage 1 at -0.012 m
		Flap Gage 2 at -0.012 m
		Flap Gage 3 at -0.012 m

		Side seal N2 at 400 psi. I reset it to 700 psi.
		
	Ran AiryMono2H5.des and got good results after two iterations. Took data for the
	WAiryMono3H2_1, WAiryMono4H5_1, WAiryUF1H2_1, and WAiryMono3H8_1.
	
	Ran several iterations on JSMono3H8.des. Even with an iteration gain of 1.0,
	it converges really slowly. Will try something more drastic(i . e., iterGain = 2.0)
	tomorrow.
	
	The data recorder hung up during one of the JSMono3H8 iterations. I failed to get
	the info Sparks has requested. I forgot the window that launches the ccgh
	is not automatically a listener. One must select listener from the services pulldown.
	
	Tuesday - Arrive 7:15 AM. Record the following:
	
	The colors are corrupt. So, I did a cold restart of the HP. This happens at least once
	a day mow.
	
	NOTE: I tried running the application from the MCC and the colors went out to lunch on
	      that monitor(which, is the brand new one) also. Whatever is wrong, is wrong 
	      everywhere.

		Lower N2 at 2199.5 psi
		Lower Support at 2315 psi
		Upper N2 at 229.2 psi
		Upper Support at 332.8 psi

		Upper Flap at -1.34 deg
		Lower Flap at -4.11 deg

		Down Tank Gage 1 at -0.007 m
		Down Tank Gage 4 at -0.028 m
		Down Tank Gage 6 at -0.011 m

		Flap Gage 1 at -0.019 m
		Flap Gage 2 at -0.024 m
		Flap Gage 3 at -0.014 m

		Side seal N2 at 650 psi
		

	Ran AiryMono2H5.drv2 to collect WAiryMono2H5_1. Then ran four more JSMono3H8 iterations.
	The PSD of the response lays right on top of the desired PSD. The stats are not so good.
	
	Finally got around to putting the July 12th updates on the platform computer. Smoke test
	seemed to indicate they work.
	
	Made a change to the "Zero" button callback so that it loads the pressure balance set
	points with the appropriate "zero" values(i. e., 270 psi for the upper and 2280 psi for
	the lower).
	
	The stats for JSMono3H8 were changed. So, we ran the first iteration. Should have used
	a bigger initial iteration gain. Response was really small.

***************************************************
September 11, 2000 (Monday) (Hugh, site visit with Tim and Brad)

	b600Proj-09-11-00.tar.gz
	b600qProj-09-11-00.tar.gz
		
		These backups were created to preserve the 
		software as it was when we arrived.

	The /home volume where our application and user directories live was
	completely filled. I increased the size by 1Gig.
	
	Documents/AAHPUnixHelp.txt
	
		Added a section on how to change the size of logical volumes.
		
September 12, 2000 (Tuesday)

	Alltalk/source/DownTCP.c
	I found a coding error in this module that corrupted the Alltalk heap.
	This only occurs when an image is restored when starting an application
	like ccgh.exe. This may explain why Paul preferred to start ccgh by
	compiling all the Alltalk source code from scratch each time.
	
	It is possible, although not likely, that this error also caused the
	screen corruption and erratic uplink behavior. (Update: It didn't.)

	I updated ccgh.exe as well.
	
September 13, 2000 (Wednesday)

	/etc/X11/X0screens
	I reset all the parameters to the default EXCEPT I disabled
	the HP color recovery feature.
	
	The xdpyinfo shows that options for backing-store and
	save-unders are enabled. Perhaps these features are
	fragmenting the available server memory?

	Another possibility is that the screen saver is being
	activated with a non-default colormap.

	The book "Graphics Administration Guide" on page 3-21
	has a section: "The default colormap management scheme".
	It describes a fault called "Technicolor" that might
	be what we are seeing...
	
September 14, 2000 (Thursday)

	Color problem fixes that didn't work:
	
		TrueColor vs PseudoColor
		Color Recovery On/Off
		Screen Saver On/Off
		Various shared memory sizes

		Because none of these changes helped, I restored
		everything to the system defaults with SAM. 
		Easier to remember.

	CoopsCom/PaulFork.c
	
		I modified the lock action in forkCycle in
		an attempt to fix the lost upward message problem.
		(Update: 9/16 This appears to have succeeded...)

September 15, 2000 (Friday)
	
	altLink.c	 The Matlab -> Alltalk interface
	Uplink.alt 	 Alltalk Uplink 
	UplinkServer.alt Server for multiple concurrent Uplinks
	Downlink.alt 	 Client for other Alltalk programs

	This bunch of files lets Alltalk programs talk to each
	other with complete transparency. All valid alltalk
	message can be sent between remote programs as if they
	were local message expressions.

	It also lets Matlab talk to Alltalk with the
	same protocol.
	
	We are still testing these features so they are not
	installed on cgh yet...

September 16, 2000 (Saturday)

	So far no lost upward messages...
	The color problem persists with every combination of settings.
	No reply from "Eddie" at HP yet.
	
	I suspect the TrueColor visual is being managed like a 
	PseudoColor visual. This causes us to run out of slots,
	but if that is true, why does it take so long? 
	
September 18, 2000 (Monday)

	Debugging the Link protocols...
	On the HP I notice errors being reported on the VxWorks console:

		interrupt: uninitialized IBC interrupt level a

	These occur about once every 15 minutes. It may be because 
	Tim has the box partially taken apart. I don't remember
	seeing these on our last trip.
	
September 19, 2000 (Tuesday)

	Tim & I (hugh) spend most of the day in the pit replacing
	the Parker block valve for the static support with on that
	has a seal. This turns out to be Difficult.
	
September 20, 2000 (Wednesday)

	Worked on the new Links all day.
	Change the protocol to use demand connections so we
	can have one complete cycle with parameters.
	
	New files:
		Node.alt
		Link.alt
	
September 21, 2000 (Thursday)

	We install the new links on the HP.
	They work, but not reliably. It looks like
	a socket buffer overflow is not being detected
	properly.
	
	(The new link stuff with Node and Link are
	replacements for Paul's UpTCP.c)
	
	UpTCP.c has been removed from Alltalk.
	All the Matlab mex files and shared libraries
	are now rebuilt to drive the new links with
	altLink.c instead of downtcp.c.
	
		b600Proj/Matlab/api	Has the new stuff
		b600Proj/Matlab/paulApi	Has the old stuff
	
	The new Makefile is automatic and will install the
	mexhp7 files and the libAltLink.sl in the proper places.
	
	
September 22, 2000 (Friday)

	Good news:
		The screen color problem is fixed.
	Bad news:
		The data recorder failed due to corruption of
		an upward message. I think this has been the
		problem all along, but the listener window
		is usually disabled after restoring the app
		by running ccgh, so we never saw the messages.
		
	=> When debugging, it is imperative to go into service mode
	and enable the listener window using the "Listener" menu item.
	Running ccgh from a console window will leave the listener disabled
	if it was disabled in the saved image. The system.updateApplication
	disables the listener so the app will work when launced from the
	CDE menu.
	
	Here is what came up after the upward message failed:
	
		(FileRecorder 0x401D2854)        Object.out
		(FileRecorder 0x401D2854)       Object.$doit
		(FileRecorder 0x401D2854)       Object.send
		(RemotePortUnix 0x401257AC)     RemotePortUnix.update
		(RemotePortUnix 0x401257AC)     Object.$doit
		(Listener 0x40076EA0)   Listener.read
		(FileRecorder 0x401D2854) does not understand "out"

	Overnight, about 90 console error messages were reported from the PPC:
	
		interrupt: uninitialized IBC interrupt level a

	The selector field of the upward message probably should have been
	#notify.
	
	When the upward message fails, the polling event in RemotePortUnix
	doesn't get to execute #resume, so upward messages are stopped.
	
	I put in a dreadfull hack to keep the remote port running after this
	kind of error. This should be removed when we get this problem 
	figured out. In the RemotePortUnix.update method, I added a recoveryEvent
	that runs if decoding or sending the upward message fails. This
	recovery event runs a method called #recover that restarts the 
	polling event.
	
	I suspect an error in DownTPC.c on the workstation side or possibly 
	UpTCP on the ppc side. This is Bad. After debugging socket programs
	on the HP all day, I'm starting to realize that extraordinary 
	things must be done to make the sockets work on the HP. This is
	why Paul had to do strange things in his UpTCP. Socket programs
	we have run for years on the PC or Linux do not work on the HP.
	Evidently HP knows how to make them work...
	

September 23, 2000

	There were two problems with upward messages.
	The first problem happened because the forkCycle did not have
	a proper critical section around the list manipulation. This
	is what we all saw on previous visits. This is now fixed.
	Now we see the upward message arrive, but sometimes with a
	corrupted message. This happens when the global variable
	messageSelector is not protected during an interrupt. 
	
	I found an unbalanced asmUnlock and asmTaskUnlock in PaulLink
	that randomly broke all system critical sections. This allowed
	messageSelector to be corrupted.
	
	PaulLink.c
		I found a dreadfull bug in here: asmUnlock and asmTaskUnlock were called
		with no corresponding asmLock and asmTaskUnlock. This was the problem!
		(I think...)
	PaulFork.c
		I already modified this a few days ago to handle the list
		properly during interrupts.
	
	These things have not yet be tried:
	
	PaulUplink.c
		Candidate: asmTaskLocking in Transmit around Message allocation.
	PaulUpTCP.c
		Candidate: asmTaskLocking in executeMessage around mtGetMessage.
		Candidate: We probably should lock around the whole message execution...

	*****

	I fixed the ca-gh-pf console menu item.
	I was running kermit instead of telnet to reach
	the platform computer. I updated the backup of
	b600Proj/AppSys/etc_dt.tar (This is made with
		tar cf etc_dt.tar /etc/dt
	The /etc/dt directory contains all of the menu
	configuration stuff. You have to restart the whole
	damn machine to see these changes. 

	Settings
	I added a new directory, b600Proj/Settings to hold all the .set files that are
	worth keeping with the project.
	
	/home/mts/data
	This is the directory where UFO data files go. I moved a bunch of .dat files
	out of the project directories, so I you lost something please look there.
	

	****
	
	We cannot quickly replace Paul's link with our standard UplinkPPC stuff
	because we have no way to replace the supervisor DLL we use on the PC.
	In the long run, we should use a new coops Uplink that works with
	Node.alt. No time on this visit so I will continue beating on the 
	Paul stuff to fix the corrupted upward message.
	
	Update on upward message corruption:
	It still happened with the 'dreadfull bug' removed, so now I will try 
	the candidates listed above. 
	
	The problem is due to the value of messageSelector changing due to
	an interrupt of some kind.
	
	In PaulFork.c, forkCycle does a send. This runs send in Class.c which
	puts the message selector in the global var methodSelector. All real
	clock interrupts preserve the value of methodSelector and we know
	that our stuff works on non-Paul systems.
	
	In the case of an upward message, the send in forkCycle will be directed
	to a host object. This will end up in PaulLink.c, which uses methodSelector
	in the procedure linkForward. After this everything is deterministic.
	
	So methodSelector is corrupted along the path from forkCycle send to
	linkForward.
	
	Experiment 1:
	I bounded the forkCycle loop with asmTaskLock and asmTaskUnlock.
	The theory is that interrupts are not doing the damage, but rather tasks.
	
	THIS SEEMS TO HAVE WORKED!

September 24, 20000 (Sunday)

	The data recorder worked correctly all night. I believe we have the
	upward message problem solved:
	
	When the PaulUplink detected an incomming message, it did a series
	of synchronous reads on the socket. In the mean time, the real time
	code occasionaly posted a fork, which signals the fork cycle process
	to start. Fork cycle can be interrupted by the steps that momentarily
	block and unblock as the synchronous reads occur in PaulUplink. This
	corrupts the global variable methodSelector. 
	
	The repair was to serialize forkCycle with respect to the PaulUplink
	task. This was done by using asmTaskLock/Unlock around the message
	handler and around forkCycle. The forkCycle also has asmLocks used
	to insure correct locking with respect to the Coops clock tics.
	
September 25, 2000 (Monday)

	Data recorder ran all night and most of today without errors.
	The Node and Link modules handle communication between
	CAGH, CCGH and Matlab and seem robust.
	
	*************
	Outstanding software issues:
	
	The CCGH application must be started before CAGH or a socket link
	error is reported. This will be fixed on the next revision.
	
	We still see the occasional "interrupt: uninitialized IBC interrupt level a"
	on the ccgh console. This message come from the Raven chip driver
	in the vxworks BSP. We have the sources, so I'm sure we can work this
	out with Mr. Rosenow.
	
*****************************************************************
*	See AAJournalBKT.txt for Brad's updates to the GUI	*
*****************************************************************
*	END OF VISIT, Tim, Hugh & Brad September 11-25, 2000	*
*****************************************************************


*****************************************************************
*	Start OF VISIT, Tim & Pete Lebens November 7 - 21, 2000	*
*****************************************************************

November 15, 2000 (TJZ) 

	Found an error with the way Alltalk handles changing limits in scroll bars. 
	Telephoned Brad and he sent me a fix to Knob.alt.  I installed it and rebuilt 
	Alltalk.  Didn't fix the problem. 
	
	Fixed the IBC interrupt that is coming from VxWorks on the PowerPc. Did this by 
	following Jim Rosenows directions in vxWorks IBC document.  The only difference 
	from the document was that there were errors after I put in the new EPROMS.  After
	I made the suggested software changes, the errors went away, the system booted up
	properly, and we did a little celebration jig.
	
	Verified that the caghpf was working properly by hooking my laptop to the caghpf 
	serial port using the serial cable marked "PPC Serial Debug Cable".  This cable 
	hooks directly to the console access panel Serial connector and the laptop. Port
	setting were 9600, no parity, 1 stop bit, no flow control.  Made a new 
	AAHowToDebugCAGHPFSerial.txt file explaining the procedure.
	
November 16, 2000 (TJZ)
	Turns out that I didn't need to rebuild Alltalk to fix the Knob problem, all I 
	needed to do was rebuild the applications by following the AAHowtoBuild B600.txt 
	file in	the Documents directory.
	
	

*****************************************************************
*	Start OF VISIT, Dale & Bonnie Dec 4 - 13, 2000	  	*
*****************************************************************

Installed software updates for the Wave Height Controller and TCL changes for the message 
to carriage computer.
Painted the tank wave probe guide vanes to prevent further corrosion. 
Put epoxy on termination of mylene wire 
the tank gages and small bead-ball on carriage gages.
Put new relay isolation into the vent sump pump and installed new level switches.
Checked all accumulator nitrogen pre-charges using new gage setup, then updated list.
Installed new EPROM for HPU PLC, then changed several lamps that had burnt out.
Drained approximately 2 gallons of glycol from one cooling circuit so that operating 
pressure is about 1.5 Bar.
Replaced hinge bolts in lower support struts (twice).
Verified that tank gage position temposonic worked, then hung wave gages into the tank.
The DNC people can to test the network connection to the carriage, including the messages
from CGH. Passed most tests, but at the expense of slowing the system response to a sluggish
crawl. Screen updates were 5 seconds, and most buttons required holding at least 1 second. 
Re-booted the HP after they left, and now things run reasonable with screen updates at 0.5 sec.
Found the carriage computer will work through the network connection, acquired a data file of 
one wave gage (testing/regular/handwaves). Did not get to iterate but the file shows it could 
be done.
The DI/O for the carriage probes is WRONG, so Stow will put the probes down and Deploy will raise
them. Nothing seems to stop the process, so they raise until the cable slips on the drive pulley.
Got the computer table moved up to the "real" control room. They do not have a key so nothing else
will move until next month.
Put floor dry sand into bases of safety chains around pump to help keep them standing upright.
Cleaned temp control room.
Installed update to AddaTempo from Brad. All 9 tempos are working, only a slight
offset change after the update fix.
Made backup per Tim instructions.
Took pictures of pit and pump room hardlines.

*** DNM 14-12-2000 ***

