ALL COMMMANDS MUST BE MADE IN THIS DIRECTORY!
Last updated 2/24/2016

Upon first checking out from svn, compile with the command:
>make ANAGATE=1

Before running, on each fresh login, you must also execute the command:
>source setup

You can also add the line 
>setenv LD_LIBRARY_PATH [path to here]/libAnaGate:\:$LD_LIBRARY_PATH
to your login .tcshrc file to avoid needing to do this every login
***********************************************************
Running baseControl:

	The baseControl executable allows for the user to connect to gluex anagates in the following locations:
		-FCAL (one can connect to one strand on one specified anagate, all four strands on an anagate, or everything)
		-F-Wing Electronics Room at JLab
		-IU Test Setup (SW252)
		
	To run:
		>baseControl [anagate ID]
		
	For example, to connect to the JLab F117 anagate on the left, port A, use:
		>baseControl jlabL A
				
	For a list of all options:
		>baseControl help
		
	Note: on test setups anagate does not automatically know how many bases are connected on a strand.
	It needs to be specified on startup, and can be altered later if need be without restarting the program.
***********************************************************
Base monitoring:

	-To perform monitoring, first start baseControl
	-Select option 8, "Read an ADC"
	-Then select option 9, "Continuously Read Cathode and Temp And Output To File"
	-This will begin monitoring all connected bases, saving data to the file "Monitoring/Monitoring.txt"
	-If the file Monitoring.txt already exists, it will be appended to (you will likely want to rename older files)
	
	-To generate monitoring plots (assuming monitoring file is named "Monitoring.txt"):
	-Open up root
		> .L baseGenPlots.cxx++
		> GenRoot("Monitoring.txt")
		> GenPlotsSingle("Monitoring.txt.root","plotvar","long")
		
	-There seven different DAC values you can plot, which must be input as a string (labeled plotvar above)
		Cathode HV            = "vmon"
		Current               = "imon"
		Temperature           = "temp"
		DAC                   = "dac"
		Medium Voltage Top    = "mvt"
		Medium Voltage Bottom = "mvb"
		 
	-Plots are stored in the directory /plots/plotvar/

Troubleshooting:
	-Make sure that you have specified the true number of bases on the strand. If you see a large number of
	 mismatch errors immediately upon starting
	-If the number of bases 
	 is correct, then check to see if any base is sending far too many messages when polled.
	
	
***********************************************************
Notes on base firmware:
	
	Current version: 1.4
	
	To upload base firmware to a single base:
		-Connect CAN and swim cable to base, and USB dongle to computer.
		-Open RFlasher7
		-Click on Load File, select Combined_all._1.4.HEX (located at ./Firmware/Combined_all._1.4.HEX)
		-Click on "Go!"
	
	To upload to multiple bases in parallel using bootloader mode:
		-Arrange bases in the shape of a pentagram
		-Set bases to bootloader mode
		-Power cycle
		-Select clear
		-Power cycle
		-Select upload
		-Sacrifice a goat, read entrails
		-Power cycle
		-More seriously, this should be done with extreme caution, but may still be useful.
		 Contact Jon Zarling (jzarling@indiana.edu) for more info.
	
	Source code:
		-To view/modify, you need Ride7. To upload you will need Rflasher7.
		 These are both installed on the IU group laptop and computer in SW252.
		-The source code for base firmware consists of three separate project files:
			>1: checks to see whether base is in firmware mode or bootloader mode.
			    Then goes to proper address to execute bootloader or firmware mode code
			>2: Normal operating firmware. Basically stays in a never-ending while loop
			    until a message is received, then executes code in CANMessage
			>3: Bootloader mode. Intended as a way to upload firmware code through CAN
			    messaging system in parallel. Not recommended to upload new firmware.
				
	If you need to install Ride7 or RFlasher7:
		-Contact Dan Bennett (dwbennet@indiana.edu) for the username and login to the 
		 Raisonance website
		-You will need following versions (our license doesn't allow us to use newer versions):
			-Ride7: 7.42.12.0305
			-RKit-STM8: 2.48.12.0338

***********************************************************
Change log


2/24/16:
	-Get CAN IDs function now works properly
	-Adesh told me that "Address a single board" looked like it wasn't working on the FCAL. 
	 It IS working but will give misleading timout errors.
	 When doing this connected to multiple strands it will give a TIMEOUT error on all strands
	 other than the strand where the CAN ID is located. 
	 I've added a warning in baseControl regarding this.
	-Fixed a bug causing plots to be stored in the wrong location
	-Fixed a bug causing monitoring data to not be saved to a text file
	
3/9/16:
Want to address the ambiguity of reading HV monitoring plots. Previously, the monitoring would 
simply run until the process was killed. This meant that if someone was doing anything that would
change the base settings (e.g. restarting) it would continue to monitor. Thus, seeing HV=0 on a plot
was not a definite indication of failure. I do two new things: upon each new monitoring readback 
I first set HV on (but I do not set a non-zero value for HV setpoint) and then check to make sure 
the HV setpoint on each base is >= to zero. If not, then monitoring exits. I've tested this for a 
while at a fast sample rate and it appears to be fine, no unexpected exits.

Specifics:
	-Upon each new round of reading monitoring adc values, sends a HV on command. Does not send an HV
	 setpoint command of any kind
	-Monitoring now exits if any base has a zero HV setpoint. Appears relatively resilient to 
	 incorrect exits due to base messaging issues
	 
	 
3/21/16:
	-Added option to sit in loop and see if bases send messages (but doesn't send any messages).
	 This is intended to check for bases with strange communication issues.
	
3/31/16:
	-Updated to reflect the JLab test stand's move from the EEL building to the F117 electronics lab.
	-Now is able to determine which CAN ID is missing when a timeout occurs. Currently implemented for 
	 monitoring only, "Read an ADC" option will not determine missing CAN IDs at present.
	-I learned that a soft reset of the bases shuts all HV enable bits off (good), but doesn't change
	 HV setpoint value (bad). This means that if a base experiences a soft reset (which I see now can 
	 happen during monitoring if bases are not 100% plugged in), the monitoring code would set HV enable
	 on and read back a non-zero setpoint. The way the firmware is set up, it would not actually set HV
	 to the readback value though.
	-I do two things to avoid this problem. On initial startup, check HV settings. If HV is not enabled,
	 then set HV=0. When monitoring, I send an HV enable on and set HV to 1600 (hardcoded) at the start of
	 every cycle. This should be just fine for test stand monitoring, but will need to be modified if 
	 monitoring the fcal.
	
4/19/16
	-Monitoring now asks for output file name, instead of always using the name "Monitoring.txt"
	-Updated format for connecting to JLab anagates, instructions modified as well.
	-Old scheme for ensuring bases have HV on abandoned. Old scheme was to check to see that HV enable
	 was turned on and to set a constant 1600 V setpoint on every sampling of ADCs. In practice this 
	 appeared to change HV on bits (or at least read them incorrectly). Reasons for this are unknown.
	 New scheme: NO check of HV enable or setting HV. Simply leave red LEDs on and check up on them.
	-Anagate and port number printed when starting a new poll of base ADCs is now correct. Previously
	 it just gave the ip and port for FCAL 1L port A.