Mirror Cell Controller

Each primary mirror cell is locally controlled by a real-time computer running VxWorks from Wind River Systems. VxWorks communicates with the cell hardware using serial ports, parallel I/O, and a 12 bit ADC, and it communicates with the Linux TCS software using sockets. Each actuator in a cell is on a serial bus and has a microcontroller running custom-written firmware. Similarly, each hard point in a cell is also on a serial bus and has a microcontroller running custom firmware. The compressed air control uses the parallel I/O to open and close valves. Air pressures and voltages are monitored using a multiplexer in the cell (indexed using parallel I/O) driving the ADC in the VxWorks crate.

See VxWorks commands for commands you can enter on VxWorks.

Power Cycling the crates

The switch used to power-cycle the crate is located at the front of the VME. Use this one if you get into communication problem (e.g., the crate booted before the FTP server following a power outage)

Software

All the software for the mirror cell is in GitHub LBTO repository "pmc". There are four directories there:

Directory	Contents	Build
cell	VxWorks code	Using Tornado, see VxWorks development below
firmware	firmware for actuators and hard points	Using PCW, see Actuator Firmware and Hard point Firmware below
host	Linux software (C++) for cell engineering	On Linux (tcs server), see Host Software below
teststand	Linux software (Java and C++) for the actuator "test stand", or "calibration stand"	On Linux (teststand computer), see Teststand Software below

VxWorks software

We are running VxWorks version 5.5.1, which was current in 2003. We no longer have a support contract. If we want to renew the contract we are required to pay all back costs, and by now it would probably be cheaper to buy new licenses. We have a two seat license for Tornado (only one in use, see below); no license is needed to run the generated executable. Our sales contact at Wind River is Tim Crose (tim.crose@windriver.com, direct 510.749.2316 mobile 510.691.5196). We have Wind River paper manuals for Tornado 2.2 and VxWorks 5.5, and the original installation disks (all in Rm 580D).

Updates to both Tornado (2.2.1) and VxWorks (5.5.1) are on the old Windows VM. What updates does this refer to?

VxWorks development

The VxWorks development environment is called "Tornado"; we have version 2.2.1. It runs under Windows XP (Professional Version 2002 SP3 32bit) in a VM called tornado.tucson.lbto.org . There are instructions on how to install Tornado on Windows Server 2003 with the Installation disks. They should also work for Windows 7. Tornado is licensed software and is keyed to the MAC address of the VM (00:01:02:3E:49:E2). (This was originally the MAC address of a real Windows box, but since the VM can be assigned any MAC address, we used the MAC address of the old box when it was discarded and kept the same license file.)

The Windows XP environment is reached by a VNC session to tornado.tucson.lbto.org (password is the same).

The VM has a shared folder mounted for the /lbt/data/vxworks directory in Tucson that the VxWorks environments read from.

Start Tornado using the icon pinned to the top of the start menu - see TornadoPCTaskBar.png
There are two workspaces: number 0 (named SynergyProcessor0.wsp) is for the older Synergy VCMD processor, and number 1 (named ArtesynProcessor1.wsp) is for the newer Artesyn MVME6100 processor. The code is the same for both processors with a macro (MV6100) defined to distinguish the newer processor.

The workspaces use software kept in an SVN checkout on the VM in: C:\pmc. Use TortoiseSVN from the Windows explorer to checkout to a new directory by right clicking on a directory and selecting SVN Checkout...
See SVNCheckoutToNewDir.png. If you prefer to edit the code on Linux: check it out in Linux, edit, and then check it back in to be built from the VM.
We had to make a separate build (and kernel) for the new processor because we have to use its BSP (see below), a couple of header files had different names, and its real-time clock control was different. All the basic functionality was the same.

The program version number is kept in cell_main.c as two #defines: vmajor and vminor.

Right click on the name LBT_Cell.out to get the option to build the image (see RightClick.png) When an image is made (always called LBT_Cell.out), rename it LBTPMCCPvvv.out (LBTPMC6100CPvvv.out) (vvv is the version number and is currently 520, for 5.20 (vmajor.vminor)) and copy it to the mounted drive /lbt/data/vxworks/ both downtown and on the mountain. /lbt/data/vxworks/ downtown is accessible from the VM as Z:\vxworks\. See XP2.png. (LBTPMCCP is derived from LBT Primary Mirror Cell Control Program.)

The VxWorks kernel is also made in the same workspace, but only has to be remade if kernel parameters change, or kernel functionality needs to be modified. I've only made each kernel once. The file name is kernel (kernel6100) and must be copied to the same directories.

Every VxWorks supported CPU comes with a 'Board Support Package' (BSP). The BSP provides mandatory low level functionality for VxWorks. The BSP is installed under C:\Tornado2.2\target\config\ by the manufacturer provided installation script.

The Windows path for the compiled object files and the generated image is C:\Tornado2.2\target\proj\LBT_Cell\PPC604gnu\ (C:\Tornado2.2\target\proj\MVME6100\LBT_Cell\PPC604gnu\). See XP1.JPG

Booting VxWorks

The VxWorks controllers are diskless, booting over the network using ftp. The IP address (inet on Ethernet), Boot Host (host inet), Kernel (file name), and Startup Script (startup script) must be programmed into the processors as part of configuring the boot sequence. The boot process first reads the kernel, and then the kernel reads the startup script. The startup script loads the application program (the control program), and starts it. The kernels, scripts, and application programs are in /lbt/data/vxworks/ , which is mounted in VxWorks as boot. The different startup scripts for SX and DX on the mountain are so we can run different applications if necessary. We have never needed the flexibility.

Location	IP	DNS	Boot Host	Kernel	Startup Script
SX downtown	150.135.245.111		web.tucson.lbto.org (150.135.245.16)	kernel or kernel6100	startup or startup6100
DX downtown	150.135.245.112		web.tucson.lbto.org (150.135.245.16)	kernel or kernel6100	startup or startup6100
SX mountain	192.168.18.100	sxvx.mountain.lbto.org	web.mountain.lbto.org (192.168.34.50)	kernel or kernel6100	startupSX or startup6100SX
DX mountain	192.168.18.101	dxvx.mountain.lbto.org	web.mountain.lbto.org (192.168.34.50)	kernel or kernel6100	startupDX or startup6100DX

VxWorks Telnet Access

VxWorks supports one telnet connection which acts as the processor console. The PMCGUIs can start a telnet session, but if the PMCGUI is not available, a telnet session can be started as [path]/telnet <IP>, where [path] is not needed downtown, and is /lbt/tcs_runtime/inetutils-1.9/bin/ on the mountain. The contents of the remote ftp boot host can be listed with ls, and files there can be referenced in commands using just their names. Alternatively, nc (NetCat) can be used (nc 192.168.18.10[01] 23).

Actuator Firmware

The actuator firmware is in firmware/actuator.c. It is built with the PIC-C Compiler, PCW V3, pinned to the start menu (see PICStartMenu.png) in the same VM as Tornado. The project information for each firmware version is kept in /home/cbiddick/Windows/My Documents/PIC/acvvv/ (vvv is the version number, currently 192 for 1.92), so you MUST copy firmware/actuator.c into the appropriate directory under .../PIC/. The program version is kept in two int8 variables, verhigh and verlow. The output "actuator.hex" file must be copied to /lbt/data/vxworks/ on the mountain as "actvvv.hex". The VxWorks cell program can load actuator firmware, once the microprocessor has an initial program. I do not expect new version of actuator firmware will be needed. For example, to download firmware into an actuator on port ppp with address aaa (to find the port and address of an actuator use the show_act(number) command) do

sp act_download, "act192.hex", ppp, aaa

VCAN document T481s00041 has instructions.

Hard point Firmware

The hard point firmware is in firmware/hardp.c and firmware/ad7730r.h. It is built with PCW V4 in the same VM as Tornado and PCW V3. The project information is kept in /home/cbiddick/Windows/My Documents/PIC/hpvvv/ (vvv is the version number, currently 201 for 2.01), so you MUST copy firmware/hardp.c and firmware/ad7730f.h into the appropriate directory under .../PIC/. The program version is kept in two int8 variables, verhigh and verlow. The output "hardp.hex" file must be copied to /lbt/data/vxworks/ on the mountain as "hpvvv.hex". The VxWorks cell program can load hard point firmware, once the microprocessor has an initial program. I do not expect new version of hard point firmware will be needed. For example, to download firmware into a hardpoint with address aaa do

sp hp_download, "hp201.hex", aaa

VCAN document T481s00041 has instructions.

Host Software

There are two programs here, cellCom and cellGui. Their only function is to collect servo tuning data from the cell. We could have built this functionality into the PMC, but this seemed easier. cellCom communicates with VxWorks using the same socket interface as the PMC subsystem (and can run alongside a PMC subsystem), and communicates with cellGui using a shared memory segment (so cellCom and cellGui must run on the same computer). cellCom is built with make -f makecom. cellGui is a QT program built with a makefile (make) generated by qmake (/lbt/tcs_runtime/qt-4.8.5/bin/qmake cellGui.pro). It provides many of the same controls as the PMCGUI, in addition to the servo data collection. The servo data is written to a variety of files, and Dave Ashby has Matlab scripts to analyze them. There are also Matlab scripts to generate plots in host/matlab/

To build cellCom , type gmake -f makecom

To build cellGui, type

/lbt/tcs_runtime/qt-4.8.5/bin/qmake cellGui.pro            (which builds Makefile)
gmake

Teststand Software

Here is the code for the teststand. It is mixed Java and C++. make builds the executables, but you need the PowerDNA package from UEI. A UEI Cube is used as the hardware interface to the teststand load cells and actuator under test. The software group does not operate the teststand.

Hardware

We support two VxWorks processor boards.

VCMD VxWorks Processor

This processor is being phased out because there is no support for it anymore.

We have a paper manual for the VCMD (Cougar 10) in Rm 580D.

Configure the side, mirror, and simulator settings using the front panel switch according to VCAN T481s00041.

To configure the VCMD boot sequence, connect to its console serial port using the Synergy breakout serial cable. Connect connector "A" on the breakout to the labeled VCMD RJ45 to 9-pin serial adapter using an RJ45 network cable. (See VCMD.JPG. The adapters and cables are in Rm 580D.) Connect the 9-pin adapter to a computer serial port. Run your favorite terminal program (9600 baud, 8 data bits, no parity, 1 stop bit), and boot the board. After SMon boots, wait for the on-board VxWorks kernel to boot. Stop the boot process when indicated by pressing any key. Use the "c" (change) command to configure the boot sequence. A new IP address will not take effect until a reboot. VCAN document T481s00041 has detailed instructions. There is a copy of the boot parameters in files /lbt/data/vxworks/Boot_parameters.txt downtown and /lbt/data/vxworks/Boot_parameters_DX.txt and Boot_parameters_SX.txt on the mountain.

If you have network access to the processor and the cell control program is running (i.e., you can talk to VxWorks using the PMC), open a telnet session (see above) and use the bootChange command to configure the boot sequence. It has the same prompts and answers as the "c" command described above.

MVME6100 VxWorks Processor

A factory new board must have a boot rom VxWorks program installed. See VCAN document T481s00041.

Configure the side, mirror, and simulator settings using the internal (on the board) switches according to VCAN T481s00041.

To configure the MVME6100 boot sequence, connect to its console serial port using an RJ45 network cable connected to the labeled MVME6100 RJ45 to 9-pin adapter. (See MVME6100.JPG. The adapters and cables are in Rm 580D.). Connect the 9-pin adapter to a computer serial port. Run your favorite terminal program (9600 baud, 8 data bits, no parity, 1 stop bit), and boot the board. After the on-board VxWorks kernel boots, stop the boot process when indicated by pressing any key. Use the "c" (change) command to configure the boot sequence. A new IP address will not take effect until a reboot. VCAN document T481s00041 has detailed instructions. There is a copy of the boot parameters in files /lbt/data/vxworks/Boot_parameters_6100.txt downtown, and /lbt/data/vxworks/Boot_parameters_6100_DX.txt and Boot_parameters_6100_SX.txt on the mountain.

If you have network access to the processor and the cell control program is running (i.e., you can talk to VxWorks using the PMC), open a telnet session (see above) and use the bootChange command to configure the boot sequence. It has the same prompts and answers as the "c" command described above.

Actuator Control Board

Each actuator has a custom designed control board using a PIC18F252 microprocessor. The initial programming has to be done "on the bench", after that new versions of the firmware can be loaded using the VxWorks cell program. Mike Gusick in the Engineering group is the contact for burning the initial firmware.

Hard Point Control Board

Each hard point has a custom designed control board using a PIC18F2520 microprocessor (not a typo. This is a newer processor than the actuator 252, and required a newer version of the PCW software to support it). The initial programming has to be done "on the bench", after that new versions of the firmware can be loaded using the VxWorks cell program. Mike Gusick in the Engineering group is the contact for burning the initial firmware.

Notes for Porting the VM (Nov-2017)

Stephen ported to a new XP WM:

The workspace files have been modified to use "C:\pmc" for the paths. Check out from SVN into that directory. Or, just update into that directory.

Workspace files are in the Tornado area C:\Tornado2.2\target\proj

To build the actuator or HP HEX file, create a new directory using the new version number (e.g., ac200), modify actuator.c in firmware directroy for new version number, copy to newly created dir (ac200) Bring up PIC C Compiler (PCW) open actuator.c from ac200 directory choose compile

Installed winmerge and tortoiseSVN so we can check out directly to this machine - don't have to rely on it being in someone's home
added the workspace files to the repository

We should try again for Windows 7. Updated the IT to request that, we'll see... (6887)

Copied the file bootrom.bin from /home/cbiddick/data/tftp to the tornado VM into the TFTP-Root directory that SH set up as the tftp root. That makes it accessible for downloading on the VxWorks board. Found that this file is available already on the VM in C:\Artesyn\MVME6100\BSP. Rather than copy this whole directory to the tftp root, I just kept the one file, in an MVME6100 sub-folder on the windows machine.
Need to update the PMC Reference Manual with this info since it says how to load VxWorks (T481s00041t).

Attached all the Artesyn documents from CB's home directory in Artesyn, below in the Attachments table.

Added a page to describe the whole system since there are so many pieces to it. See TornadoWindowsVMEnvironment

-- %USERSIG{ChrisBiddick - 2017-09-13}%

---