These front-ends interface vacuum boards in CIA crates to the control system. Each CIA crate contains one (186) vacuum controller. Each vacuum controller has an ARCNET connection and an interface to the CIA dataway. The controller communicates with the vacuum boards over the CIA dataway and with the front-end that services it over ARCNET. A vacuum front-end provides additional functionality not present on the vacuum boards or controllers, e.g., compuation of the average vacuum and ion guage degassing. The controls department is responsible for both the front-end and the controllers.
Front-end Purpose Location MIVAC control of vacuum in main injector MI60 South PBVAC control of vacuum in pbar AP10 Building VXTSTX testing vacuum front-end and controller hardware and software Linac Annex TEVAC control of vacuum in the tevatron(under construction) MAC room ECVAC electron cooling experiment Wideband building in the pit
Operating System VxWorks Software Architecture MOOC Processor Board Motorola MV2301 (PowerPC) Bus VME Peripherals ARCNET controller, SLD (for T-clock) Physical Network Connection Ethernet Transport Protocol ACNET encapsulated in UDP Application Protocols RETDAT, SETDAT, ACNET AUX
Vacuum controllers - The Vacuum controllers are custom hardware incorporating interfaces for ARCNET, CIA dataway, and serial communications along with an Intel 186 processor. Vacuum controllers execute firmware which is burned into PROMs on the controller.
Vacuum boards - Leon Bartelson
Vacuum controller hardware - Paul Kasley and Tom Zuchnik
Vacuum controller firmware - Jerry Firebaugh
Vacuum front-end - Jerry Firebaugh
Front-end
The front-end code is maintained in CVS on crusher.fnal.gov with the module name miv68k. The 68k suffix is historical; the vacuum FE originally ran on a mc68k board. The miv68k project contains a Makefile which automates the build and release process. The Makefile uses fe.mk to provide release managment functionality. So knowledge of fe.mk's release management procedures is applicable to "vacuum" front-end software. The following procedure is used to build and release a new front-end executable. Note that the "vacuum" front-ends load mooc, acnet, etc., dynamically from the startup script when they are rebooted. So to install new versions of mooc, etc. when changes to FE application code are not also needed just reboot the FEs. The operational front-ends are set to run only the designated stable mooc, acnet, etc.1. Check out the mwirePPC project from CVS and change directory into the working copy of the miv68k project created by CVS.
2. Make your modifications to the source code. If you are creating a new version update the VID in the Makefile also.
3. Issue make in the working directory.
4. The first time, make will detect that no OS executable file is present in the working directory and issue a launch command. You will need to build an OS in the working directory. See the next section for details.
5. Make will build the new front-end executable in your working directory.
6. Your changes can be tested on VXTSTX, which has its boot parameters set to run the Vacuum FE beta/latest code. In order to install a beta, you will need to commit your changes and then do a make beta.install.
9. Reboot VXTSTX and test your modifications. Go back to step 2 as needed.
10. To install your changes on the operational front-ends, which have their boot parameters set to run the Vacuum FE stable code, issue a make promote and reboot them.
12. Do a CVS release on the miv68k project, if you chose.Operating System
The operating system is configured and built on crusher.fnal.gov using Wind River's launch. The configuration for the vacuum front-end is associated with the mv2303 BSP and named fermi-mv2303-vacuum. Launch will build vxWorks and vxWorks.sym in the Wind River's directories. Both vxWorks and vxWorks.sym need to be installed/copied to fecode-bd to install the OS on the front-ends. This configure, build, test, and install process is supported by the miv68k Makefile. The following procedure is used to build and release a new OS configuration. A newly built OS will be installed on fecode-bd has a beta when a make beta.install is done. It will be designated stable when a subsequent make promote is done. To install the new OS reboot the FEs. Note that VXTSTX runs the latest/beta OS, but the operational FEs only run the current stable OS.1. Check out the miv68k project from CVS and change directory into the working copy of the miv68k project created by CVS.
2. Using launch modify, save, and configure a new OS configuration. Exit launch. (You do not need to do a build yet.)
3. Issue make in working directory. Make will detect that the OS configuration file is later than the (non-existent) OS executable file and issue a launch command.
4. Using launch build a new OS executable in the Wind River's directories.
5. Exit launch. The OS files will be copied into the working directory by make. Make will also build the rest of the front-end in the working directory.Individual Front-ends
The differences in the front-ends are handled by having each front-end use its own startup script. The differences in the startup scripts are the comments which indicate the expected boot parameters, setting the prompt, and the configuration, e.g., config_mivac.o, object load. The configuration object has the configuration of the CIA crates attached to the particular front-end. The name of a front-end's script is startup_<the front-end>.cmd, e.g., MIVAC uses startup_mivac.cmd.Vacuum Controllers
The vacuum controller code is maintained in CVS on crusher.fnal.gov with the module name miv186. Unfortunately, crusher does not have the compilers, etc. to build the hex file needed by the Data I/O PROM programmer. The tools to build the hex file, miv.hex, are installed on niobe.fnal.gov. Unfortunately, the Data I/O PROM programmer is not accessible from niobe. So miv.hex must be copied on to a diskette. That diskette will need to be insterted into the Data I/O drive. The Data I/O is attached to penelope.fnal.gov. The PROMs burnt by the Data I/O will need to be installed into the vacuum controller. Give Tom Zuchnik the miv.hex file on a diskette and he will burn the PROMs. Two PROMs are needed per controller.The procedure for building and releasing SWIC controller firmware is as follows:
1. Check out the miv186 project from CVS.
2. Modify the code on crusher. Update the revision information, i.e., sw_ver and sw_rev, in iopmain.c.
3. Copy this code to C:\MIV on niobe.fnal.gov.
4. Issue the command make hcmiv on niobe in the C:\MIV directory.
5. Copy miv.hex onto a disk in A:.
6. Have Tom Zuchnik make and install the two PROMs in a test controller.
7. Test your modifications. Go back to step 2 as needed.
8. Commit your changes to the CVS repository.
9. Release the miv186 project.
10. Have someone install the new PROMs in to all deployed vacuum controllers.
Rollback Support
The code for both the vacuum front-end and controller are in CVS, so rollback is supported through the use of the CVS update command with a date or tag. In addition, the front-end code uses fe.mk which adds additional rollback functionality including automated tagging.
Front-end Boot Parameters
The front-end boot parameters are documented in the comments of the startup script for each front-end.Other Documentation
DABBEL templateARCNET card manual
Documentation on the vacuum controller hardware and wiring prepared by maintained by Paul Kasley
Handwritten notes on ARCNET protocol, etc. prepared by Carl Schumann given to Jianming You
Security, Privacy, Legal