Building CMLOG for NLCTA/PEPII

Contents

  1. CMLOG Build Details

  2. Supported CMLOG VxWorks Build Configurations

  3. How to build and release CMLOG for Solaris

  4. General notes on build and release for IOC's

  5. How to build CMLOG for VxWorks(Tornado 1.0.1)

  6. How to build CMLOG for VxWorks(Tornado 2.0.2)

  7. How to test CMLOG on an IOC

 

1. CMLOG Build Details

There are 2 CMLOG Build areas, one at /afs/slac/package/cmlog/prod and the other at /afs/slac/package/cmlog/new. Here are the requirements met for building CMLOG.

Building of CMLOG for all platforms should be done on slcsun1.

Build Details for /afs/slac/package/cmlog/prod:

Tool Version Required Version Used
VxWorks Tornado 1.0 Tornado 1.0.1(VxWorks 5.3.1)
Solaris n/a SunOS 5.8
GNU compiler n/a none
GNU make n/a GNU Make version 3.79.1
SunWS CC Compiler n/a SunWS 6U1 CC

Build Details for /afs/slac/package/cmlog/new:

Tool Version Required Version Used
VxWorks Tornado 2.0 Tornado 2.0.2(VxWorks 5.4)
Solaris n/a SunOS 5.8
GNU compiler n/a none
GNU make n/a GNU Make version 3.79.1
SunWS CC n/a SunWS 6U1 CC

back to top

 

2. Supported CMLOG VxWorks Build Configurations

CMLOG  is supported and used for the following VxWorks configurations.

For more information on VxWorks Board Support Packages(BSPs), please see the VxWorks at SLAC page.
For more information on EPICS, please see the EPICS at SLAC page.

EPICS Vers. Tornado Vers. BSP Model CMLOG gmake target* : Create symbolic link:
R3.13.1 1.0.1 VXI CPU-030 niCpu030 niCpu030 -
R3.13.2 1.0.1 MVME166 MVME166 mv167 mv166
R3.13.2 1.0.1 MVME167 MVME167 mv167 -
R3.13.2 1.0.1 MVME177 MVME177 mv167 mv177
R3.13.2 1.0.1 MVME2700 MVME2700 ppc mv2700
R3.13.6 2.0.2 MVME167 MVME167 mv167 -
R3.13.6 2.0.2 MVME177 MVME177 mv167 mv177
R3.13.6 2.0.2 MVME2400 MVME2400 ppc mv2400
R3.13.6 2.0.2 MVME2700 MVME2700 ppc mv2700

*: This column refers to the target for the "gmake [target]" command, when entered from the CMLOG root directory.

back to top

 

3. How to build and release CMLOG for Solaris

1. Log onto slcsun1 as yourself.

2. Change directory to /afs/slac/package/cmlog.

3. Create a new CMLOG directory in vol3/ and copy your modified files into the appropriate directories from your test area.

4. In your new CMLOG directory, execute the following command:

slcsun1:~> source mySetenv

5. Once this is done, enter the following command:

slcsun1:~> gmake solaris (this can take up to 30 minutes to complete)

6. Change directory up to /afs/slac/package/cmlog and change the 'prod' symbolic link to point to your new CMLOG directory.

7. Deliver the bins and libs using the standard PEPII/NLCTA Unix Development Environment(UDE) commands: gmake{tst,dev,new} ext/cmlog

Here is an older page on releasing with a little more detail.

back to top

 

General notes on building and releasing for IOC's

Here is an older page on releasing with a little more detail.

Releasing to IOCs (James's March 2005):
==================

Very simple but tedious.

1. Do a gmake for each Board Support Package(BSP)(mv167, mv177, ppc,
etc.) in your CMLOG build area. You should have O.mv177, etc.
directories in your bin and lib directories.

2. In the AFS IOC bin area, you will copy three files(libcmlog.a,
cmlogClientD, cmlogVxLogMsg) to each BSP directory,  for each version of
EPICS. Start from /afs/slac/g/cd/soft/ioc and work your way down. You're
doing a MANUAL copy from your CMLOG build dirs to these files(You used
to be able to gmake them into this area ... that broke when the release
procedure changed. I don't know if there is one in place now). You
should also find out which BSPs/EPICS versions are relevant and which
ones are not(RonC and Steph can help with that).

2.5 Ask someone if you can boot a development IOC to see if they pick up
the new binaries. You can load a simple test(like the ones in the CMLOG
Examples dir) after the IOC has finished booting. You might want to have
the IOC do an NFS mount to your working dir so that you can load a test
from there. It's a line change in the file
/afs/slac.stanford.edu/g/cd/soft/ioc/all/users.cmd. Kristi used to be in
charge of that. I don't know who is now. Lazmo might be able to help.

3. You will repeat the same release procedure for files on NFS(gtw00).
But instead, use FTP to get the files from AFS, and rename the old files
to [name].old first so that they can be mv'ed back in case something
breaks.

3.5 Ask an operator if you can boot an IOC to make sure that the release
worked.

4. You're done!!!

 

4. How to build CMLOG for VxWorks(Tornado 1.0.1)

1. Before you do anything, please comment out any cmlogSetup or epicsSetup scripts that are being sourced in your .login or .cshrc.

2. Log onto slcsun1 as yourself.

3. Change directory to /afs/slac/package/cmlog/prod (Tornado 1.0.1)

4. Once you are at this path, execute the following command:

slcsun1:~> source mySetenv

That should take care of setting up the environment to build for each VxWorks platform under Tornado 1.0.1.

5. Verify that the following environment variables have these settings:

CMLOG=/afs/slac.stanford.edu/package/cmlog/prod
WIND_MSTR=/afs/slac.stanford.edu/package/vxworks/master/tor-1.0.1
WIND_BASE=/afs/slac.stanford.edu/package/vxworks/devel/tor-1.0.1/cd
WRAPPER_ROOT=/afs/slac.stanford.edu/package/cmlog/prod/C++/SACE-4.0
VX_VW_BASE=/afs/slac.stanford.edu/package/vxworks/devel/tor-1.0.1/cd/target

This can be easily done by entering "printenv" at the command-line prompt.

6. You may do a clean build by executing the "gmake clean" command, but it may not be necessary for building for only one target.

If you do a "gmake clean", remember to:

If you do not do a "gmake clean", skip to the next step.

7. Type "gmake [build target]" for each platform you would like to build. The build target is specified for each BSP in the fourth column of chart one.

8. Check for the existence of the following objects:

/afs/slac/package/cmlog/prod/bin/[target]/cmlogClientD
/afs/slac/package/cmlog/prod/bin/[target]/cmlogVxLogMsg
/afs/slac/package/cmlog/prod/lib/[target]/libcmlog.a

If you are building for a BSP that uses a symbolic link, please verify the existence of the symbolic link to the target directory in the bin and lib directories. See column 5 of the chart in Section 1.

9. Once you have completed your build for each desired platform, change directories to /afs/slac/g/pepii/ctrl/dev/epicsApp/src/db enter the "gmake" command. This will move the CMLOG files to where they will be picked up by the IOC.

11. Repeat Step 9 for /afs/slac/g/cd/soft/ioc/R3.13.2/commonApp/src/db.

12. Test on a development IOC for each platform you have built. Refer to Section 4 of this document.

back to top

 

5. How to build CMLOG for VxWorks(Tornado 2.0.2)

1. Before you do anything, please comment out any cmlogSetup or epicsSetup scripts that are being sourced in your .login or .cshrc.

2. Log onto slcsun1 as yourself.

3. Change directory to /afs/slac/package/cmlog/new (Tornado 2.0.2)

4. Once you are at this path, execute the following command:

slcsun1:~> source mySetenv

That should take care of setting up the environment to build for each VxWorks platform under Tornado 1.0.1.

5. Verify that the following environment variables have these settings:

CMLOG=/afs/slac.stanford.edu/package/cmlog/new
WIND_MSTR=/afs/slac.stanford.edu/package/vxworks/master/tor-2.0.2
WIND_BASE=/afs/slac.stanford.edu/package/vxworks/devel/tor-2.0.2/cd
WRAPPER_ROOT=/afs/slac.stanford.edu/package/cmlog/new/C++/SACE-4.0
VX_VW_BASE=/afs/slac.stanford.edu/package/vxworks/devel/tor-2.0.2/cd/target

This can be easily done by entering "printenv" at the command-line prompt.

6. You may do a clean build by executing the "gmake clean" command, but it may not be necessary for building for only one target.

If you do a "gmake clean", remember to:

If you do not do a "gmake clean", skip to the next step.

7. Type "gmake [build target]" for each platform you would like to build. The build target is specified for each BSP in the fourth column of chart one.

8. Check for the existence of the following objects:

/afs/slac/package/cmlog/new/bin/[target]/cmlogClientD
/afs/slac/package/cmlog/new/bin/[target]/cmlogVxLogMsg
/afs/slac/package/cmlog/new/lib/[target]/libcmlog.a

If you are building for a BSP that uses a symbolic link, please verify the existence of the symbolic link to the target directory in the $CMLOG/bin and $CMLOG/lib directories. See column 5 of the chart in Section 1.

9. Once you have completed your build for each desired platform, change directories to /afs/slac/g/cd/soft/ioc/R3.13.6/commonApp/src/db enter the "gmake" command. This will move the CMLOG files to where they will be picked up by the IOC.

10. Test on a development IOC for each platform you have built. Refer to Section 4 of this document.

back to top

 

6. How to test CMLOG on an IOC

1. Find an IOC that is not in use and then change directory to /afs/slac/g/cd/soft/ioc/[ioc name]. Ensure that all of the IOC boot links are as they should be. Link the startupE to the generic NetInit file(usually linked to by the startupNE file). Also, be aware of which version of EPICS you will be loading onto the IOC. You can do this by looking at the "base" symbolic link in your IOC's folder. It should be pointing to  ../../ref/epics/[R3.13.2 or R3.13.6]/ioc/.

2. Log onto a development IOC (after making sure that no one else is using it) and reboot.

3. Load the following lines from the VxWorks shell:

       cdvwx-> < /common/baseCode.cmd      

This will set up some necessary EPICS symbol definitions needed by cmlogVxLogMsg.

4. Next, load the following CMLOG executables in this order. You may execute these lines by hand or in your own load script.

        cdvwx -> ld < /bin/cmlogClientD
        cdvwx -> ld < /bin/libcmlog.a
        cdvwx -> ld < /bin/cmlogVxLogMsg

5. Next, start the CMLOG processes on the IOC. You must start them in this order. You can use the following commands and parameters to start the processes:

        cdvwx -> taskSpawn( "tCmlogDaemon",100,0,20000,cmlogClientD )
        cdvwx -> taskSpawn( "tCmlogLogMsg",100,0,10000,cmlogVxLogMsg )
        cdvwx -> taskSpawn( "tCatchall_Throttle",250,0x08, 5000,catchall_throttle )

6. Once all the processes have been loaded and started, you may run any type of message logging/spewing program to test throttling. To help you get started, you should look at the CMLOG  User Guide and the CMLOG SLAC Throttling User Guide.

back to top


Author: 11-Mar-2003 by jsilva
This page created using Microsoft FrontPage.

Last Updated: 18-Jan-2005 by Ron MacKenzie