�� . �� : http://www.naic.edu/~phil/software/datataking/cima/cima.html
�� : Wed Jun 10 00:52:24 2015
�� : Mon Apr 11 23:47:45 2016
��:
�� : arp 220

datataking_software

Cima gui software

03jun08

Index:

08jun12:Turning on,off alfa bias monitoring:
07jun12:compiling the C code Wapp:
Cima problems:
Things that need to be fixed
Storing program state: frontend
Other cima locations:

07jun12: compiling the C code (Wapp) (top)

Cima includes some C routines. They are under the Wapp/ directory.

Online directories

/home/cima/Wapp: base directory accessible to ao net. (fileserver:/export/FS01/cima)

Bin -> Software/Svnwork .. points at current version in use
Base: holds info that is independant of versions

Make : holds the Make.def that gets added to makefiles.

Software: hold the actual code for editing and binaries for running.

Dual - older version of wapp software. no longer used
Svnwork - current version of software

Progs,Resources,Sources.. normal cmake directory structuree

Code is under Sources, Installs go to Progs

Compiling programs that run on Wapp1-4, or aeroncpu.

The wapp cpus runs linux 2.4. This is because of the locally written 2.4 driver for the edt cards.
A separate copy of /home/cima is copied to wappserv to do these older compiles

wappserv:/data/home/cima:

Libs,Software,Wapp

If you make changes in a wapp routine alfa_mon,alfa_motor you need to copy the Sources/ directories to wappserv

To compile these programs, you need to do it on wapp (as wapp).

SVN storage of info.

Repository location: file:///share/megs/phil/svnrepos/Wapp/Wapp/trunk

added /home/cima/Wapp/Software/Svnwork/Software to this

Working areas:

/home/cima/svn/Wapp - working area of Wapp/Software/Svnwork /Sources
/share/megs/phil/svn/wapp

This has a checkout of the wapp repository info
It also includes all the other directories to be able to do builds

Building the programs:

Offline for testing without messing with online code:

Login to dataview (preferably as phil)
cd /share/megs/phil/svn/wapp
source ../cima/cimahome

this sets CIMA_HOME, CIMA_WAPP so that you can execute programs using these test versions:

Look at Software/Progs/Start/cima for where this gets used.

Linux compile:

cd software/Sources
run_cmake

This compiles into the C code in the correct order
For each directory, the compiled code goes in ./Objects/
Problem:

in Base/Make/make.def I added -m32 to CFLAGS so it would use the 32 bit libraries.
In a number of Makefiles i had to add -m32 to the ld statement. Mainly done via the XXX_LINKS variable.

Sunos compile

cd Software/Sources
run_cmake

this compiles code in the sunous directories (eg Lib_solaris).

Back to dataview

cd Software/Sources

run_cmake install
This copies the compiled code from the Objects/ directories to Software/Progs/.xx

Testing. eg alfamonwin

scp megs2:/share/megs/phil/svn/wapp/Software/progs/Wapp/alfa_mon to /home/cima/Wapp/Software/Svnwork/Progs/Wapp/alfa_mon
You might want to backup the old copy before doing this copy ..

Kill alfa_mon
/etc/rc3.d/S99local.. execute line to start alfa_mon

Back on dataview (or any other linux computer)

cd /share/megs/phil/svn/cima
source cimahome
alfamonwin --a $CIMA_WAPP

CIMA_WAPP will point at svn/wapp/Software so it will get the newer version of wish_exec.

For full online:

Need to copy wapp/Software to wappserv
on wapp do cmake, then cmake install.. i don't think you need to worry about solaris here.

08jun12:Turning on,off alfa bias monitoring: (top)

05jun12: Alfa bias monitoring has been causing glitches in the rf signal. We need to turn off the bias monitoring for pulsar observations with alfa. Details of the monitoring are:

Programs that were modified:

These are in The cim svn repository and in the Wapp svn repository
dirW=/home/cima/Wapp/Software/Svnwork/Sources
dirC=/home/cima/Software/Stable/Software/Sources
dirW:

Includes/alfashm.h

took one of the filler bytes at the end and changed to monitorOn (0,1)
alfa_mon sets this depending on whether bias monitoring is on or off
this gets broadcast on alfashm . alfamonwin uses this to tell if monitoring is off or on.

Wish_linux/tk_alfa.c

added monitorOn to alfa shm.

Utilities/alfa_mon.c

this is the program that does the monitoring.
Added commands MON ON , MON OFF

alfamonwin can send this commands to alfa_mon to request monitoring to be on ,off

If monitoring is turned off, alfa_mon doesn't bother to query alfa bias . It still does the other status requests (amps on,off, temps...etc).
alfa_mon sets alfashm.monitorOn to 0,1 on every broadcast of alfashm.

Makefiles:

I updated a bunch of the cmake Makefiles to include -m32 so we could compile things on dataview and get 32 bit binaries.
I probably should have edite /home/cima/Base/Bin/Make.def to add CFLAGS= -m32

dirC:

ALFA/alfa_instrument_control.tcl

Added status Bias Mon on/off
added buttone so turn on ,off biasmon

ALFA/Makfile

added -m32 to compile on dataview

To compile,install the program

alfa_mon.c

this runs on aeroncpu which is a linux 2.4 kernel. so we can no longer compile on dataview (2.6)
Use 2.4 computer (mikael or mofongo)

compile (cmake) alfa_mon.c
install (cmake install)
Then need to scp to wappserv:/home/cima/Wapp/Software/Dual/Progs/Wapp/alfa_mon

--> note that the 2.4 wapp code is still under Dual, not svnwork.. look at alfa_mon_start to see this.

Cima problems: (top)

fixed azimuth drift pattern close to the ao lattitude does not behave as expected.

Things that need to be fixed

150606: lo's used for 10Ghz upconverter

for xband, if freq is < say 9 ghz is will use a lo side lo to upconvert to 10 ghz.
But the mixer only works with freq > 2Ghz.
Fix: for xband always use highside lo when mixing up to 10Ghz . esp with xband..

Storing program state frontend: (top)

Program state is stored in tcl global associative arrays (hashes). An incomplete list is:

global variable	description
alfa	alfa receiver
auto	auto observing
calib	calibration scans
colors
corr	interim correlator setup
fonts
iflo	setup iflo
load	loading configuration from disc
menu_buttons	holds info on menus. hash key starts with $name which is the cima name for the menu.
menu_valid_value	holds valid menu values (menubuttons.tcl
mock	mock spectrometer
obsmode	observing mode
obs_status	observing status display?
paths
point	telescope pointing
prefs	user preferences
Receivers	receiver setup
save	saving configuration to disc
setup	to hold interative modifications
user
wapp	wapp spectrometer

Interactively modifying state:

To let users interactively update state variables the data is moved from the state variable to the setup() variable:

Copy state hash (eg mock()) to setup() hash.

All the keys,values of mock() copied to setup()
set mock(trace) no to disable tracing during this move.

Interactive menus modify values in setup($keys)
When done, the program copies the setup($keys) back to mock($keys)

set mock(trace) no to disable tracing during this move.

To allow for changes from within the menus:

the menu buttons, entries, selections modify the setup($keys) values
A variable trace is set on each key in setup() for writes to setup()

trace_variable setup($key) check_mock_configuration

checks all the setup($key) variables each time anyone is modified.

trace_variable setup($key) check_current_mock_variables $w

this check to see if there are any differences between setup($key) mock($key)

Things to watch out for:

some menu selections vary depending on other variables.

You need to update the menu selection options since the program verifies that each selection is a valid menu value.

check_menu_option setup($key) $status (procedures.tcl)

goes through and makes sure that values in setup($key) are valid menu button values.

valid_menu_value $setup($key)

see if global variable menu_valid_value() contains $setup($key)

set_up_menu() (menubuttons.tcl)

set_menubutton() loads the values when menu defined.

change_menu_list() can be used to modify the values after the menu is created.

home_~phil