The following are a rough sketch of the order of operations for restarting a SUS front-end's IOP process with the goal of recalibrating the 18-bit DACs.

- Request the relevant ISC manager guardians to go to the DOWN state

- Request the SEI manager guardian of which ever chamber's ISIs that will be affected by the suspension front-ends you're going to kill to OFFLINE

- Request the SUS guardian that will be affected to SAFE (don't forget about the TMTSs, HAUXs, or HTTSs!)

- If there are changes in the SDF system for any affected SUS, then understand the changes and capture them if necessary

- Have the CDS OVERVIEW screen, and every affected SUS and IOP GDS_TP screen open 

- Log onto sus front end you wish to recalibrate, kill all user models
jeffrey.kissel@opsws8:~$ ssh controls@h1susex
controls@h1susex ~ 0$ killh1susetmx
controls@h1susex ~ 0$ killh1sustmsx
	This will (obviously) make the given SUS go white on every screen its EPICs variables are displayed, but (not-so-obviously) this will start to inflict IPC errors on every other model that gets IPC channels from what you just killed, AND the user and independent software/hardware watchdogs for the SEI system will begin to trip (that's why we brought them to OFFLINE before getting started).

- Restart iop front end process
controls@h1susex ~ 0$ starth1iopsusex
Notes:
	- The command line control wil return well before the recalibration is complete. It's not finished!
	- The GDS_TP screen of the IOP process will show EPICs channels, but stay red, and look like it's hung up.
	- Eventually -- after ~10-20 [sec], it kicks on
	- HOWEVER there will be IPC, AWG, and WD errors reflected in the CDS STATE WORD, and all of the DACs will show some red lights.
		- The IPC, WD, and DAC errors are normal, it's just because 
			- the IOP doesn't have any user models using the DACs yet, hence the DAC errors
			- the SWWD IOP, and USER DACKILLs are tripped, hence the WD errors
			- The IPC isn't coming from the user models yet, hence the IPC errors
		- The AWG error occurs because with the auto-calibration routine, the process takes much longer to get started, which is for what the auto-start for awgtpman is looking. As such, you need to start the awgtpman process by hand:
			- Still on the front-end machine, cd to where the awg start up scripts live,
			controls@h1susex ~ 0$ cd /opt/rtcds/lho/h1/target/gds/awgtpman_startup/
			and run it the relevant IOP model's startup script
			controls@h1susex ~ 0$ ./awgtpman_h1iopsusex.cmd

- Verify that the auto-calibration procedure completed for all DACs on the front end
controls@h1susex ~ 0$ dmesg | grep AUTOCAL
[   48.862194] h1iopsusex: DAC AUTOCAL SUCCESS in 5134 milliseconds 
[   54.012818] h1iopsusex: DAC AUTOCAL SUCCESS in 5134 milliseconds 
[   59.163412] h1iopsusex: DAC AUTOCAL SUCCESS in 5134 milliseconds 
[   64.315072] h1iopsusex: DAC AUTOCAL SUCCESS in 5133 milliseconds 
[   69.467638] h1iopsusex: DAC AUTOCAL SUCCESS in 5134 milliseconds 
Notes: 
	- A failure looks like this:
	controls@h1susb123 ~ 0$ dmesg | grep AUTOCAL
	[6643697.827654] h1iopsusb123: DAC AUTOCAL SUCCESS in 5134 milliseconds 
	[6643702.976255] h1iopsusb123: DAC AUTOCAL SUCCESS in 5133 milliseconds 
	[6643708.553386] h1iopsusb123: DAC AUTOCAL SUCCESS in 5134 milliseconds 
	[6643714.130498] h1iopsusb123: DAC AUTOCAL SUCCESS in 5134 milliseconds 
	[6643719.278911] h1iopsusb123: DAC AUTOCAL SUCCESS in 5133 milliseconds 
	[6643724.427687] h1iopsusb123: DAC AUTOCAL SUCCESS in 5134 milliseconds 
	[6643729.576295] h1iopsusb123: DAC AUTOCAL SUCCESS in 5133 milliseconds 
	[6643734.724703] h1iopsusb123: DAC AUTOCAL FAILED in 5133 milliseconds    <<< A Failure!!
	One (hopefully) gets rid of a failure by restarting the IOP front-end process again.

- Start the IOP's awg tp manager process by hand, if you haven't already
controls@h1susex ~ 0$ cd /opt/rtcds/lho/h1/target/gds/awgtpman_startup/
controls@h1susex ~ 0$ ./awgtpman_h1iopsusex.cmd
This will flip the AWG light from red to green.

- Start USER models
controls@h1susex ~ 0$ starth1susetmx
congrols@h1susex ~ 0$ starth1sustmsx
Notes:
	- These should start as normal, no need to kick-start awg by hand or anything.

- Find SWWD / HWWD screens, and reset the SUS and SEI watchdogs to clear all the IOP DACKILLs. 

- Reset all affected SUS and SEI USER watchdogs. This should finally clear the error in WD bit of the CDS STATE WORD.

- Hit the "Press All Diag Reset Buttons" button on the CDS OVERVIEW screen, or in the (non-front-end command line)
jeffrey.kissel@opsws8:~$ press_all_diag_reset_buttons.py
Notes:
	- This should clear any remaining IPC errors reported on the CDS STATE WORD for SUS IOP and the SEIs. If it doesn't (i.e. the come back after a second) investigate.
	
- At this point, there should no longer be any errors reported by the CDS STATE WORD, *except* for saturations, say if the optical lever happens to be saturating one of its quadrants because the SUS is still misaligned. Of course, if taken advantage of the recalibration time to make model changes that require a DAQ restart, there will be a DDC error. Anyways, again, investigate if you still see errors your don't understand. 

- Bring the SUS back to the ALIGNED state via guardian.

- Bring the SEI managers back to FULLY_ISOLATED (or ISOLATED_DAMPED if you're playing with the beam splitter.)

You win!