Static screenshot of live-updating status display.
From a bash shell on any pubnet RHEL 5 host, start the 7 live-updating status displays by using this script. The opening process takes about 15 seconds to make EPICS Channel Access connections.
From the csh shell on RHEL 5, type "bash" (without quotes) to open a bash shell, then run the previously indicated script command.
The status screens are also accessible from the Firefox, Chrome, Opera or Safari browsers directly from hyperlinks. In order to see live updating EPICS PVs, users need the EPICS Channel Access Plug-in 1.2.0. Instructions on plug-in installation should pop-up automatically.
The local SLAC expert on the CAML display of live EPICS data in browsers is Matt Boyes of the Controls Department. Thanks to Matt for his help with the project.
Documented by relatively complete and up-to-date user guide.
How to restart the Feedback SIOC called sioc-esb-fb00:
EPICS_DIR=/afs/slac/g/testfac/rhel4/epics /afs/slac/g/testfac/setup/procserv/startIOC.sh sioc-esb-fb00
Easy way to tell from the shell if Feedback SIOC is running:
[alison@ar-chaiken planning]$ grep FB ~/.bashrc alias testFB="EPICS_CA_SERVER_PORT=5070 EPICS_CA_ADDR_LIST='134.79.48.11 134.79.51.65' caget SIOC:ESB:FB00:TOD" [alison@ar-chaiken notes]$ testFB SIOC:ESB:FB00:TOD 11/04/2010 15:39:53
How to restart the Matlab license manager on nlcta-opi03:
rm -f /var/tmp/lm_TMW.vd1 rm -f /var/tmp/lm_TMW.dat rm -f /var/tmp/lm_TMW.ld /home/nlcta/matlab/etc/lmstart setenv LM_LICENSE_FILE 27000@nlcta-opi03 /afs/slac.stanford.edu/package/matlab/linux/2007b/bin/matlab
The Matlab sources for the Feedback are at /afs/slac/g/testfac/cvs/support/NLCTAff_matlab.
Local SLAC expert: Diane Fairley
The soft IOCs for the LLRF controls of X-Band Station 3 are almost identical to their LCLS counterparts. The main difference is that I have disabled the PAC "calibrate" feature that, according to Ron Akre, was never supported in hardware. The PAC sources are in the normal AFS tree at /afs/slac/g/testfac/rhel4/epics/R3.14.8.2-lcls2/iocTop/stn3Pac/stn3Pac-R1-0-0 and the PAD sources are at /afs/slac/g/testfac/rhel4/epics/R3.14.8.2-lcls6/iocTop/stn3Pad/prod.
Here are some commands that, from a bash shell on RHEL4 or RHEL5, will open a view of the PAD IOCs:
/afs/slac/g/testfac/rhel4/epics/R3.14.8.2-lcls6/iocTop/stn3Pad/development/stn3PadApp/srcDisplay/viewPAD031_bash /afs/slac/g/testfac/rhel4/epics/R3.14.8.2-lcls6/iocTop/stn3Pad/development/stn3PadApp/srcDisplay/viewPAD031_bash
Easy way to tell from the shell if PAC03, PAD031 and PAD032 are running:
[alison@ar-chaiken ]$ testPAC03 EIOC:ESB:PAC03:UPTIME 31 days, 05:17:41 [alison@ar-chaiken planning]$ grep PAC03 ~/.bashrc alias testPAC03="EPICS_CA_SERVER_PORT=5068 EPICS_CA_ADDR_LIST='eioc-esb-pac03' caget EIOC:ESB:PAC03:UPTIME" [alison@ar-chaiken ]$ testPAD031 ESB:XBSTN3:K5:031_SLOWADC0 -272.955 [alison@ar-chaiken planning]$ grep PAD031 ~/.bashrc alias testPAD031="EPICS_CA_SERVER_PORT=5068 EPICS_CA_ADDR_LIST='eioc-esb-pad031' caget ESB:XBSTN3:K5:031_SLOWADC0" [alison@ar-chaiken ]$ testPAD032 ESB:XBSTN3:K5:032_SLOWADC0 -272.973 [alison@ar-chaiken planning]$ grep PAD032 ~/.bashrc alias testPAD032="EPICS_CA_SERVER_PORT=5068 EPICS_CA_ADDR_LIST='eioc-esb-pad032' caget ESB:XBSTN3:K5:032_SLOWADC0"
The log files for these EIOCs are in /nfs/slac/g/cd/ioc/. I didn't put them there intentionally, and in fact tried several methods to induce the log files to appear in /nfs/slac/g/testfac/esb/eioc-esb-pa*/log but some script ignored my environment variables and stuck them there anyway.
Local SLAC expert: Kukhee Kim
The PACs and PADs are controlled by an APC Switched Rack Power Distribution Unit to which users interface via an IOC called NLCTAiocManager:
NLCTAiocManager is a basically unmodified version of LCLS' iocManager SIOC running on ilc-esb09. How to invoke NLCTAiocManager:
/afs/slac/g/testfac/rhel5/epics/R3.14.11/iocTop/NLCTAiocManager/development/NLCTAiocManagerApp/srcDisplay/showACswitchStatus_bash
How to restart the NLCTAiocManager IOC on ilc-esb09 using procServ set up by Zen:
[alison@ilc-esb09 ~]$ EPICS_DIR=/afs/slac/g/testfac/rhel5/epics /afs/slac/g/testfac/setup/procserv/startIOC.sh sioc-esb-stn3
Easy way to check from the shell prompt if NLCTAiocManager is running:
[alison@ar-chaiken ]$ testSTN3 SIOC:ESB:STN3:TOD 10/29/2010 14:49:22 [alison@ar-chaiken planning]$ grep STN3 ~/.bashrc alias testSTN3="EPICS_CA_SERVER_PORT=5068 EPICS_CA_ADDR_LIST='134.79.48.13 134.79.67.255 134.79.51.255' caget SIOC:ESB:STN3:TOD"
Local SLAC expert: Sonya Hoobler
For the rumored pco.edge camera, I have worked hard to make the menable driver for the Silicon Software microEnable IV framegrabber card work on RHEL 5. According to Nimesh Juthani of Cooke Corporation, a version of the mEIV with custom firmware will run the pco.edge camera. Thus SLAC does not have the option of using the pco.edge with a framegrabber for which we have existing EPICS support. While others have gotten the microEnable card working with real-time Linux, the sticking point in our case, at least in part, is that the RHEL5 OS I tried to use has an older kernel (2.6.18 versus 2.6.27 in the example) with a slightly different API. The Northwestern example linked above describes work with an older framegrabber (the microEnable III) for which Silicon Software made prebuilt rpm packages available. Thus the NWU student did not patch and compile the driver itself, as I have done. (He patched the Linux kernel itself.)
At some level, the menable driver is working, as this loading of it into the RHEL 5 kernel shows:
[alison@ar-esa03 menable_linuxdrv_3.9.12_4.0.1]$ sudo gmake load make INSTALL_MOD_PATH= INSTALL_MOD_DIR=extra -C /lib/modules/2.6.18-194.17.1.el5/build M=/opt/menable_linuxdrv_3.9.12_4.0.1 modules_install make[1]: Entering directory `/usr/src/kernels/2.6.18-194.17.1.el5-x86_64' INSTALL /opt/menable_linuxdrv_3.9.12_4.0.1/menable.ko DEPMOD 2.6.18-194.17.1.el5 make[1]: Leaving directory `/usr/src/kernels/2.6.18-194.17.1.el5-x86_64' su -c "modprobe menable" lsmod | grep menable menable 82200 0 grep menable /proc/modules menable 82200 0 - Live 0xffffffff8818f000 (U) tail -10 /var/log/messages Oct 29 16:53:13 ar-esa03 sudo: alison : TTY=pts/2 ; PWD=/opt/menable_linuxdrv_3.9.12_4.0.1 ; USER=root ; COMMAND=/usr/bin/gmake load Oct 29 16:53:14 ar-esa03 kernel: PCI: Enabling device 0000:04:00.0 (0100 -> 0102) Oct 29 16:53:14 ar-esa03 kernel: ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 169 Oct 29 16:53:14 ar-esa03 kernel: menable 0000:04:00.0: microenable IV VD4-CL card will be called menable0 Oct 29 16:53:14 ar-esa03 kernel: runtime_base is 0x40000 Oct 29 16:53:14 ar-esa03 kernel: In me4_query_dma, d is 0. Oct 29 16:53:14 ar-esa03 kernel: menable menable0: 0 DMA channels detected (lo 0 hi 0) Oct 29 16:53:14 ar-esa03 kernel: 2nd time in me4_query_dma, d is 0. Oct 29 16:53:14 ar-esa03 kernel: men->num_dma is 0 ls -l /dev/menable* crw------- 1 root root 253, 0 Oct 29 16:53 /dev/menable0
The driver loads with modprobe without error and creates the special character file /dev/menable0 that user programs can employ to receive DMA buffers from the framegrabber. The /sys files needed by the kernel's driver interface are also correctly created. The runtime_base address is correct. Unfortunately, the function me4_query_dma does not detect any DMA channels when the driver loads. I'm not sure what the source of the problem is, but it's likely to be changes either to the workqueue or IRQ handler that I made in order to get the driver to load under 2.6.18.
Userspace programs will use ioctls to retrieve images from the camera. In order to learn to use the ioctls, I started writing programs to exercise them. The menable sources with my test programs and results are in /afs/slac/g/testfac/rhel5/support/menable
Recommendation: the time investment to get the menable driver working with the as-yet-unavailable pco.edge camera cannot be justified without several more software support staff. I suggest purchasing a GigE or Camera Link camera that is compatible with a framegrabber that has existing software support. For example, consider using PCDS's unixCam IOC with the existing edt_unix framegrabber module.
Local SLAC experts on edt_unix and unixCam: Bruce Hill or Sheng Peng
My contributions are at /afs/slac/g/lcls/epics/modules/Bx9000_MBT/devl-chaiken/ but since Zen has a better approach to control using aSyn, no one should use them in the future in NLCTA.