Summary of Work at SLAC

October 29, 2010

Prepared by Alison Chaiken

NLCTA Synoptic Display

Static screenshot of
 live-updating display
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.

NLCTA Transverse Feedback

Matlab plot of BPM data
Static screenshot of Matlab real-time plot of live-updating NLCTA BPM data

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/ sioc-esb-fb00

Easy way to tell from the shell if Feedback SIOC is running:

[alison@ar-chaiken planning]$ grep FB ~/.bashrc
[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
setenv LM_LICENSE_FILE 27000@nlcta-opi03

The Matlab sources for the Feedback are at /afs/slac/g/testfac/cvs/support/NLCTAff_matlab.

Local SLAC expert: Diane Fairley

LLRF for X-Band Station 3

PAD031 edm view
An EDM for PAD031 that is started up with viewPAD031_bash

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:



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

Automated power cycler for PAC and PADs

The PACs and PADs are controlled by an APC Switched Rack Power Distribution Unit to which users interface via an IOC called NLCTAiocManager:

Switched Rack Power
 Distribution Unit Controller IOC called NLCTAiocManager
NLCTAiocManager screenshot.

NLCTAiocManager is a basically unmodified version of LCLS' iocManager SIOC running on ilc-esb09. How to invoke NLCTAiocManager:


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/ 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

Local SLAC expert: Sonya Hoobler


FACET Documents index here

FACET camera timing
FACET Camera Timing

FACET timing hardware
FACET timing hardware overview

FACET camera servers
Initial camera servers plan; doesn't show needed EVR card

menable driver for Silicon Software microEnable IV framegrabber

menable driver methods
Organization of Silicon Software's menable driver

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

Beckhoff programming

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.