EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: EPICS Meeting Notes from CERN 9-96
From: [email protected] (Bob Dalesio)
To: [email protected]
Date: Fri, 25 Oct 96 15:33:52 MDT
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 5

Attached are the meeting notes from CERN, a list of attendees, a preliminary
agenda for the meeting to be held at TRIUMF and a list of institutions
represented at this meeting.

Please post any corrections. My humble apologies in advance for any errors.
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: mtg9-96
X-Sun-Content-Lines: 894

EPICS collaboration meeting at CERN	09-25-96

09-25-96	Training
Channel Access
Recent Developments

Thursday Morning	09-26-96
*BESSY	Ralph Lange
	BESSY will consist of 4 operator consoles, 30 IOCs and 450
	embedded controllers. Insertion devices will consist of
	10 Hz CANbus and 100 Hz VME position control.

	BESSY specific developments
	The database is defined and kept in ORACLE and CAPFAST
	CANbus implementation of CAL and loCAL
	BESSY graphics server running above CDEV (perhaps available to all)
	Orbit, Optics and Compensations - physics codes are being developed

	Currently, the power supply test stand is running 1 IOC with
	CANbus controlling 5 power supplies.
	RF control via PLC is being validated
	Fiber Optic network is installed
	Microtron and booster installation first quarter of 1997

*PTB	Ralph Lange
	PTB is analogous to NBS (National Bureau of Standards). 
	The activities of these huge institutes at BESSY II will be based on 
	one electro-magnetic undulator and 3 beamlines.

*DESY	Matthias Clausen
	HERA Cryo	- providing a data concentrator and data archiving
	TTF	 	- Cold tuner, cryogenic control, power supplies,
		   	  vibration measurements and compensation, and the
		  	  implementation of the Fermi-lab InterRackMonitor.
	Utility Control	- Water control through Siemens
			  Heating and climatization control through 
			  Profibus PLC's
			  monitoring and data logging
	Safety System	- monitoring and data logging

	15 VME crates (5 dual processors) are operational.
	9 InterRack Monitors are operational.
	4 sun workstations are being used along with 3 Alphas and 15 Xterminals

	DESY developments include:
	Data Logging and a client-server visualization package over CORBA on IDL
	Integration of a PC running IOC core and Windows95 is in alpha test
	WWW tools for management of IOC's and diagnostics of fieldbuses.
	Object Broker used as integration platforms for heterogenious 
	archive sources.
	Oracle based database configuration tool is in use
	Developing tools for running vxWorks command line on UNIX

*ALS	Bill Brown
	IOC with 4 CPUs interfacing over Bit3 to Multibus 1 based system
	Sequencers for I.D. "feed-forward" Beam currennt-energy calc, etc. 
	  run in IOC, inputs and outputs from/to heritage control system as 
	  well as EPICS displays.

	The gateway also provides EPICS interface to PV's in heritage control 
	Developing applications using this interface is moving slowly - but 
	It provides data archiving and snap shots to the ALS system

	8 beamline front-ends using EPICS - GPIB in use here
	We have a hardware mod to NI-1014 GIPB interface which greatly improves
	reliability when used with older GPIB devices.

	Tranverse feedback hardware is interfaced through EPICS

	Slow control for longitudinal feedback in VXI
	One item (twt amplifier) slow control via GPIB thru another ioc, which
	happens to be in the "right place."
	Modbus interface is done through RS232 and used for the EPS system

MPE Garching	Poalo Alto Telescope
	Deformable mirror, instrument and tip/tilt control and laser in EPICS
	3-5 tip/tilt controllers will run 10-100 Hz
	51 control loops will run in the 10-40 Hz range
	dye laser control is 10-40Hz
	Aircraft detection and shutdown of laser from an SGI system
	adaptive optics will be done with one IOC using DSP and MV167

*LBL Gammasphere	Carl Lionburger
	25,000 signals in 21 IOCs (7 VXI crates and 14 VME crates)
	Used for Data acquisition and slow control
	Reliable since Nov. '95
	data acquisition at 4 MBytes.second
	tape control using state notation language
 	Relational database - Informix - for critical manufacturing-derived
	  high-voltage settings and detector configuration information.
	Database Description Language DDL - for database definition
*LBL STAR detector for RHIC
	Now testing subsystems - about 50,000 signals
	Slow control to be done in EPICS
	Gammasphere tape system to be used
	Data acquisition will be done using the state model (but not EPICS)
*LBL BaBar detector for the SLAC B-factory
	1998 - commissioning begins
	multinational collaboration
	slow control will be done in EPICS
	estimate about 10,000 channels
	Data acquisition and control will be using an OO interface to EPICS

*CEBAF	Chip Watson
	58 VME crates hosting 64 IOCs control 140 CAMAC crates with 1700 modules
	VME, CAMAC, GPIB and RS232 I/O devices in use
	2300 magnets, 630 BPMs, 40 wire scanners 342 RF cavities
	140 Beam loss monitors, beam current and vacuum control
	4 channel BPMs provide up to 10,000 samples/second 
	500 Hz for 20 devices is used in a burst for fast snapshots - this
	completely consumes the IOC - normal operation is 60 Hz.
	80,000 physical I/O signals in 125,000 database records
	over 1,000 operator screens are in use
	Many of the screens are generated from simple programs using a screen
	generation library
	Started conversion of last subsystem - cryo plant - started June 1996
	Cryo demonstrator running reliably - conversion of plant - in 1997

APS	Marty Kraimer
	125 VME crates and 12 workstations are in use for the APS
	170,000 database records are in use
	Industry Pack GPIB controllers will replace the NI1014 VME-GPIB
	Storage Ring BPMs provide fast sampling and data averaging in hardware
	1 non-critical IOC is now running R3.13

*SACLAY/TTF Injector	Jean-Francois Gournay
	TTF injector was done with 4 IOCs using Sun workstations and sundials
	12 and 14 bit ADCs, 12 and 16 bit DACs, 
	Binary I/O and motor control all coming from ADAS
	Omnibyte fast ADC used (2 MHz)
	Fermilab timing system, ORSAY SEM grids and BPMs used
	ESRF video mux used
	Many drivers developed - the stepper motor was the challenge
	Using DCT, MEDM, BURT, KM. SNL clients mainly for the diagnostics data 
	processing and the low level RF loops and optimization procedures

	SACLAY developments include:
		Fermilab-like parameter page
		BURT Graphical User Interface
	Energy measurement is being done for hall A (1 IOC for beam position 
	measurments in the beam arc, 1 IOC for magnetic field measurement of a reference 
	Compton Polarimeter control system planned for 1997
	Saclay is involved in the design of important parts of the LHC 
	for Atlas, the toroid and end caps
	for CMS, the solenoid.
	Saclay will contribute for the control of these subsystems (PLCs, FIP 
	fieldbus and EPICS if this choice is confirmed).

*RGO/WYFFOS	Andrew Johnson
	WYFFOS spectograph delivered to La Palma 1995
	7 moving mechanisms and other I/O
	Required half the man-power of previous instruments done using 
*RGO/ISIS Polarization
	6 moving mechanisms and other I/O
	commissioned July 1996
	Solaris platform and MV147
*RGO/WHT Cassegrain Acquisition and Guidance Unit
	Due Nov. 1997
	16 moving mechanisms
*RGO/ISIS Spectograph
	51 moving mechanisms
	Currently recruiting for staff to work on this
	Could have used EPICS, but decided not to because:
		Handles CCD images - 16K CA limit is a problem
		Customer wanted ability to port to run under Solaris
		Needs to talk to a DRAMA control system
*RGO/Liverpool Telescope & NGAT
	Could have used EPICS, but decided not to because:
		Will be using DRAMA for Telescope Control; we didn't want 
		to include both EPICS and DRAMA in what will be a 
		commercial product.

*RGO/Gemini	Philip Taylor
	15 IOCs
	Project office in Tuscon issues the release
	CAD, CAR, APPLY, and SIR records developed to implement
		command/response, documented at: www.ast.cam.ac.uk/~ajf
	GPS support for BANCOMM unit developed to provide time stamps
	Reflective memory developed for fast deterministic comms
	CANbus support developed

CFHT		Peregrine McGhehee
	3.6 meter optical telescope
	TCS version 4 will employ EPICS
	RS232 interface from EPICS to CAMAC - CAMAC to be replaced with VME
	Serial communciation will be replaced with ethernet
	tcl/TK and X-designer in use
	ALH, MEDM, and CDEV in use
	Portable CA server to be used for interface to Telescope Control System
	20 Hz control will be implemented in the database
	SNL will be used to process command interface
	JAVA and the WWW will be used to export info to remote users
	IOCs are using the SPARC 5 processor
*IAC Canary Islands	Marti Pi
	Integral instrument with 6 motors, 4 calib. lamps and 5 light sources
	Could have been done easily in just 'C' but other systems on the
	William Herschel Telescope uses EPICS - so EPICS was used
	1 sun SPARC 5, 1 IOC (MV147 based), 2 OMS cards, 
	4 axis encoders and a XY240
	Runs Solaris 2.5, vxWorks 5.1, EPCIS R3.12.1
	Database defined in CAPFAST
	EDD/DM, SNL, used
	6 schematics, 10 displays, 6 SNL programs, and 175 records used

*IASA	Stathis Stalliaris
	2 stage, cascade racetrack microtron
	Sparc5 host running 3.12.2 of EPICS
        1 IOC (MVME167) controls the e-gun
	1 (FIC8234) for all other control.
        VME modules in use: XVME-566 (Xycom), VMIVME-3115 (VMIC) and
                             VMIVME-4105 (VMIC)
	Trying to use GPIB to CAMAC (NI-1014)

*MIT Bates	Coles Sibley
	No progress in the port to EPICS. Limited personell to implement
	conversion, with priorities going toward hardware upgrades and 
        accelerator operation.

*Laboratori del Sincrotro de Barcelona	Josep-Antoni Perlas
	Proposed for the end of 1997
	2.5 GEV ring, 250 M circ ring, 250 mAmp
	Will use a standard model architecture
	Choosing between UNIX and PCs/NT
	Plan to use OO technology - not clear yet if this is CDEV
	Magnet lab under construction - will be a test bench for software
	Plan to fully exploit commercial products
	Decision on controls approach due first quarter of 1997

Darmstadt		Simone Richter
	130 MeV Super Conducting Recirculator
	Currently uses X-term, workstations and a know server through
	one LSI-11 machine and 1 68020
	There is a very limited resource for this system
	The existing system needs to continue to function - during the upgrade

Platforms for the Input/Output Controller (IOC)
PC	Kay Kaesmir (BD presented)
	IOC Core - the database and server are operational on a Pentium 100 MHz
	Channel access server changes required for byte ordering
	Performed about 8,000 records per second using 50% of the CPU (=MV167)
	Will initially work with DESY on Industry Pack support
	Intend to include support for Allen-Bradley Industrial I/O
*SinglePC	Matthias Clausen
	Running Windows '95 and vxWorks in a single Pentium is tested
	Goal to run vxWorks development under Windows NT and use PC as target
	Runs IOC Core from Kay on PC target
	No benchmarks yet
	Development of I/O support for Industry Pack through CDI
	NOTE: that PCs get expensive when each software package is licenses
	separately - perhaps PCs are not the best approach for large facilities
SPARC 5		Peregrine McGhehee
	Channel access server changes needed for buffer alignment
	Port took 2 weeks
	6x faster than the MV167 (040)
*Power PC port	Chip Watson
	In progress
	No benchmarks yet
(Side note - A port to the Baja board was completed at Cal Tech by)
( Dave Barker - [email protected]				  )

*Port from vxWorks to LnyxOS	NASA Langley (CW presented)
	IOC implemented as 1 process
	tasks become threads
	symbol table routines are completed
	making a thread for the shell like commends for EPICS utilities
	started May '96 - expect completion for single thread by the end of 1996
	expect a full port (using pthreads and full POSIX compliance) June '97
*IRM Internet Rack Monitor - Matthias Clausen 
(IRM is developed at Fermilab by Mike Shea)
	DESY has EPICS support
	MV162 CPU
	64 AI 1Khz each, 14 bit, 512 samples storage/ channel
	8 AO
	64 DIO
	Front Panel display
	Other IP modules available
	available from biRa and Omnibyte $3000 without CPU.

Portable channel access server	Jeff Hill (GC presented)
	Available on the AOT-8 WWW site under papers and presentations.

*Gateway	Jim Kowlakowski/Jeff Hill (MK presented)
	The gateway is intended to provide a single connection to the IOC
	and allow many clients to connect to it.
	This will be used to give access to APS control system parameters
	to beamlines through a workstation with 2 ethernet connections.
	These functions are important as each channel access client now
	creates a large buffer in the IOC and the servicing of the client
	monitors done on the IOC - uses some of the CPU bandwidth. The
	gateway limits the number of connections and the number of monitors
	This will also be used for multiple clients running on a single
	workstation to share their connection to the IOC.
	When a process variable (PV) is connected (this is typically a field of
	a database record), the gateway first checks if it is already open.
	PVs remain open for a specified time after all connections to it are 
	The gateway optionally uses a user specified port.
	Implementation on a single machine optionally uses the loopback driver.
	Access security is by PV - a file containing a list of allowed PVs is 
	supplied (with wildcards).
	Name alias is supported in the gateway - allowing a similar function
	to that in CDEV, where higher level codes can hide the database 

*CDEV	Gei Chen / Chip Watson
	CDEV is currently running on UNIX and VMS
	Applications using CDEV - StripTool, XACT (Coorelation Plot), tcl/TK,
	zplot, and the BESSY graphics server.
	ALH from APS will be complete soon
	DM is under discussion for conversion to CDEV.
	CDEV services currently include: Channel Access and ACE
	CDEV interfaces are used on EPICS installations, SLC at SLAC, and

*Channel Access Issues	Jeff Hill (BD presented)
	This was a review of some of the issues that need resolution in channel
	Provide a caching client - reduces buffer size on IOC and traffic to
	those clients that are only going to cache the value anyway (display
	managers are the ebst example of this)
	Provide local name resolution from a local history or name server to
	reduce the network traffic, IOC load, and connect time for particularly
	large applications or overloaded IOCs.
	The portable server also needs to be ported in vxWorks. It needs to be
	caefully checked to insure that it is thread safe in this port.
	The portable server needs to replace the existing database server.
	Large array support is required. Only 16K byte arrays are currently 
	Provide multi-priority channel access connections. This would support
	a more graceful degradation when closed-loop control is being done over
	the channel access protocol.
	Periodic monitors that are sent on frequency - not deadband - would
	be useful, especially in archiving. Perhaps this is a database issue.
	Event monitors - where many monitors are posted on a change that is
	unrelated to the channels being posted.

	Issues I missed:
	C++ client side API
	Compress the existing protocol
	Provide a channel access server for any C/C++ variable in any given 
	Indexed array access

EPICS 3.13 features	Marty Kraimer
	Only ASCII databases are loaded
	Add/delete of record types and record instances underlying support done
	Base now has it's own config file
	DCT is no longer supported (replacements available for ORACLE and TKL)
	The original ASCII format is not support
	sf2db (short form to database) now generates the new ASCII format
	Menu definitions now generate a .h file for code use of the enumeration
	database addresses can now be displayed and changed during operation
	addresses links can be forced to be channel access links
	record with ca links can process on monitor notification

*Oracle DCT	Matthias Clausen
	A Relational Databaseis preferred for large sets of records
	Configuration data as well as managerial information is kept
	Any platform with Oracle Forms can be used to define the database
	Tasks will be run on the IOC to save changed parameters into ORACLE
	Generic records/ record groups and forms are on the way

*Bumpless Reboot - discussion
	Several methods of performing bumpless reboot were discussed. Before
	describing the methods it should be mentioned that where ever possible
	output devices should be able to retain their value through a reboot
	and device/driver support shouild be able to read the output value
	during iocInit. The following discussion is for where this is not 
	possible. The methods below are also useful for retaining parameters
	that operators are likely to change during operation - like motor speeds
	and gain settings.

	The first method describes is support developed by Bob Dalesio within
	the last year. It was embellished at SLAC by Carl Lionberger
	and also by Tim Mooney in APS/XFD. It works as follows:
		A task is started on the ioc. 
		It is just a normal Channel Access Client.
		It accepts, from a file, a list of PV names. 
		It sets monitors on each PV.
		At a specified interval when changes occur, a file is written
		At iocInit the file is read and the values written to the PVs.
	The disadvantage here is that large data sets cause a lot of network
	traffic when the actual changes are sparse.

	Another method uses the disable fields in a record. Output records come 
	up disabled. A BURT restore is performed after iocInit and then a BURT 
	restore that enables the records.

	Some one suggested that there should just be the ability to ask that all
	puts from Channel Access be saved. A drawback to this approach is that 
	it can lead to saving far too much information.

	There was also a discussion of restoring magnet settings
	because of the problems of hystersis. BESSY I had tool and wanted to 
	know how to do this with epics.
	Both LANL and CEBAF described special records they created.

PC Port	Kay Kaesmir (BD presented)
	IOC core running on the Pentium is complete
	Channel access DLL from LBL (Chris Tomassi) in use
	Makefiles on windows NT currently build IOC core and common libraries
	Makefile changes need to be reintegrated into the EPICS distribution

Device Support in EPICS	Marty Kraimer
(AKA module_types.h)
	Module_types.h should go away
	historically defaults for address space came from module_types.h
	the problem is that vme short address space is limited
	now these defaults in module_types.h can be overridden at ioc load
	Some alternatives for integrating devicesL
		1) Put configuration parameters in the startup file
		   but each device will be an undocumented special case.
		2) Provide a record type for the device
		   but this is more complicated to set up - however,
		   status and configuration fields are then available through
		   channel access.
		3) Device configuration tool that is easy, flexible, and 
		   provides reports -
		   but this doesn't exist and may be too complicated
	The issue is that many devices have very different configuration
	parameters. Attempting to generalize this problem, may just make
	all I/O look like the worst. To date, we have been flexible -
	but not uniform.

Displays - what should be used
	The future of PCs, JAVA and commercial tools need to be considered
	when considering the future data visualization in EPICS.
	It is clear that MEDM and DM will not merge. There is parellel effort
	being put into both of them to provide an improper set of features in
	LANL is currently looking to develop a new visualization package that
	runs on the PC under windows NT - should this also run under UNIX?
	Performance, flexibility, and look and feel are the issues that have
	kept any one package from emergin as the standard.
	Some working groups on this could be helpful to help set some direction

*Strip Tool	Janet Anderson and Chris Larrieu (CW presented)
	Supports a large number of pens for strip chart recording
	Drag and drop channels onto the recorder
	only displays one scale at a time - presently
	CDEV wildcard list is supported
	Users sets and saves configuration
		x interval, sample interval, re-draw interval, all graph info, 
		curve info
	Currently in use at 1 Hz with about .001 second variance between samples
	Users manual distributed with source
	Number of channels is compile time settable (10 out of the box)
	Some planned enhancements:
	  + Postscript output for printer rather than low-res window dump.
	  + Expression evaluation --plot expressions rather than absolute
	  + better axis scaling (log scales, more intuitive tic marks).

*Correlation Program	Sally Scahffner (CW presented)
	Configuration and data acquisition is done using XACT
	experiments are pre-configured experiment 
	The user can then analyze the data him/herself or use a separate Matlab 
	program to analyze the data.
	The user can configure 0, 1, or 2 variables to step 
	and up to 1000 variables to measure (sample) after each step. 
	Variables are typically EPICS channels accessed through cdev. 
	The user configures the size of the step and the rate of stepping
	(by specifying time delays before or after each step or measurement 
	The user can also specify a script to run before and/or after each step 
	or measurement cycle.
	The speed of the system is dependent on the time delays and the number 
	of measurement variables. The actual processing is minimal so the 
	limiting factors are channel access, the network and cdev.

	The program produces a binary data file. A Matlab formatted file is
	also produced that the user can take into Matlab to analyze
	him/herself. There is also a Matlab program available which will allow
	the user to plot any variable (step or measurement) against any other
	variable if 0 or 1 step variables were used. If 2 step variables were
	used, the Matlab program will allow the user to select any measurement
	variable to plot as a surface against the two step variables. The
	limitation on the canned program is that it only handles about 50 
	CDEV wildcard supported

*GUI for Physics Applications	Thomas Birke
	This system gives a GUI (e.g. Buttons, StringEditor, 3D-Diagram...) to 
	any (Physics) application with moderate coding effort that would 
	immediately work on a system with completely different graphical 
	capabilities: with the graphic server ported to NT the unmodified 
	application would have a native NT presentation.

	API exists, usable by any application (physics, control panel ...)
	Independant of graphical system (we use Motif, could be NT, vt100)
	Different levels of presentation control (e.g. data viewer embedded)
	An Interpreter application provides tcl/Tk like functionality

	Uses scripting commands through an interpretter for control panels and
	glue between other applications

	User has no knowledge of underlying graphical paradigm only the API

	Results in Physics applications need to do little for a GUI ~5% code
	MEDM is still used for synoptics
	documentation is still embryonic

	2D diagrams with several thousands of data points in less than a second
	Latency of monitors in an interpreted control panel is increased 
	considerably compared to medm screens (but still `acceptable').

*Alarm Handler developments Janet Anderson (MK presented)
	view active alarms only feature
	current alarm history window
	group/channel property window
	global alarm acknowledgment implemented
	log file is optional circular
	Run Unix script on change to specific alarm severity
	Macro substitution and include file available soon

NT-based visualization		Kay Kaesmir (BD reported)
	Studying the options for data visualization on the PC:
	X-term of DM or MEDM from a UNIX box
	As an x-term, the PC visualization is not native and would need a UNIX

	Visual Basic - slow but easy to get running

	Data into EXCEL

	Visual C++
	We are building a more extensive prototype with visual C++
	as this has the performance advatage over most.

CANbus - why are there 3
	CANbus is an emerging instrumentation standard in Europe for multidrop 
	I/O. The three largest installations in Europe are all supporting it.
	The CAN protocal is very simple. A CAN message consists of 8 bytes.
	The first byte contains a message number. Bus arbitration and error
	detection is done automatically by the CAN interfaces. Each node 
	receives all messages and selects which message numbers it want to 
	CANbus bandwidth is 1Mbit over 40 meters.
	Bandwidth reduces by 50% every 100% increase of length
	Bandwidth is 66Kbits over 4 KM
*CANbus-RGO	Andrew Johnson
	IP Carrier support is implemented as a driver
	IP modules are done as driver + device support
	Using the Greenspring VIPC310 and VIP610 with any CPU, or
		the MV162 with on-board IP
	Using the TEWS TIP810 Canbus IP module
	Data for many input records combined in single CAN msg
	Asynchronous record processing, allows CAN RTR polling
	I/O Interrupt scan available on both inputs *and* outputs
	Used	1IP	5nodes	250signals	UKIRT
		1	6	240		Gemini metrology
		4	160	2300@5Hz	Gemini primary mirror
	Also in use at LBL
	CAN Driver is EPICS independent
	Documentation at http://www.ast.cam.ac.uk/~anj/epics
CANbus-DESY	Gabor Csuka
	Uses the Common Device Interface (CDI) from DESY
	Supports parellel access to the CAN bus for multi-CPU support
	Support scan on change and periodic scanning
*CANbus-BESSY	Ralph Lange
	Supports the CAL-CAN protocol
	Implements a limited set in lowCAL
	BESSY data transmission layer is EPICS independent
	Primary device is a 16bit power supply controller 
	Multicast is used for feedforward compensation
	Multi-Protocol support (lowCAL, download ...)
	Queue + Cache + Busy/Retry + Watchdog Functionalities

The DESY solution is built on their CDI and determines their need to have the
driver to be different. There is some possibility that the RGO and BESSY
solutions could find some commonality and merge.

*Profibus	Matthias Clausen
	Token passing protocol used by all PLCs in Germany
	Supports autoconfiguration
	Configuration of line speed and timeout and station delay
	There is a IP interface to Profibus
	This will be ported to the PC
		the protocol is complicated
		not easy to use for in-house developments
		limited number of permanent connections supported

*Archiving	Matthias Clausen
	Archive system supports continuously archive of data
	(Years of data have been taken already)
	channel access monitors are used for vector data
	archive records are used to buffer data locally to the IOC
		avoids data loss when the workstation is not available
		provides statistical data reduction & higher speed local buffer
	secondary buffer on the workstation to reduce disk access
	waveforms are archived using monitors and writing to seperate disk
	Currently archiving 3,000 signals (3 Kbytes/month/channel)
	Uses 15% of a slow ALpha running VMS
	Runs on VMS and UNIX

*Archiving	Chip Watson
	Designed a client/server model for distributing archive data to
	a viewer and analysis tool

	Want to support: periodic, save set, deadband, statistical, 
	triggered, and software logic analyzer style archiving

	Meta data will need to stay with data stream in a special buffer

	Server converts to client data requests

	Support data aging

	GUI to use network components

	Provide archiving solutions in an incremental way using some existing
	pieces and trying to integrate the DESY viewer and LANL frequency
	archiving approaches

*Archiving Requirements @ BESSY	Thomas Birke
	BESSY II Schedule:
	1)	Equipment installation                  *Now*
	2)	Commissioning                           Jan 98
	3)	Operational sequences                   Mid 98
	4)	User service mode of the light source   Jan 99
	5)      ...

	During phases 1)-3) we hope to come along with AR/ARR. Only in phase 4) 
	reasonable effort can go into the development of a new archiver.

JAVA and WWW		Chip Watson
	CEBAF is developing a JAVA binding for CDEV
	JAVA will significantly reduce the network traffic
	There will be a C++ CDEV gateway that runs on the web server
	CEBAF will build on APS work to provide a Java applet that accepts ADL
	(ADL is the ASCII format for displays used by MEDM and readable by DM)
	Looking for some subset of functionality by Christmas

WWW - work at Argonne
	IMplementing an operator log via WWW tools
	This is currently done using CGI scripts

*WWW-Tools	Matthias Clausen
	WEB pages for the diagnostic of IOC performance data
	Diagnostic of fieldbuses connected to the IOC
	Java for dynamic update of i.e. CPU load
	A WEB-based message logging system for logging operator messages
	  different pages for entering messages
	  pages for searching for messages

CERN Evaluation		Fabien Perriollat
	CMS - the goal is to find a common system for the LHC experiment
	that is to be operational 2005.
	A first answer is expected by the Jan. 1, 1997.
	So far, one person from ATLAS has been investigating EPICS
	Whatever decision, a future review will be required to revalidate it
	For these detectors, archiving 1Gbyte per second will be the special
	requirement for Data Acquisition
	A thanks for the warnings and comments on the slow controls issues

Distribution of Software, Docs, Web Pages, and Help
	The software needs to be kept somewhere that is password protected
	Perhaps this is done seldom enough to keep it at Argonne
	Documentation can be put on any machine in the open
	CERN has the highest speed connection to all others

	There are training tapes from Argonne.
	Argonne hosts training occassionally - and is open to having others join
	Los Alamos provides training on a contract basis
	Royal Greenwich Observatory will provide training on a contract basis

	Installation Support
	Labs are specified as the site for support for each platform
	This list could be extended to provide sites in the same time zone

	A document on the WWW lists the author of each EPICS tool
	The author is avilable to provide some support
	tech-talk is a mail exploder that is used for trouble reports / help
	tech-talk has a web browser with a search engine

	Current Developments / suggestions
	There is no timely management of these

	Do not spend lots of time banging your head against the wall
	e-mail someone and at least get a pointer to the answer

	There is a need for a high level document that describes EPICS to the

	A roadmap for documentation would be helpful

	A web site for suggestions for each tool would be useful

Next Meeting
	The next EPICS collaboration meeting will most likely be held in
	conjunction with the PAC conference in Vancouver this spring.
	Sessions may be held in parellel.
	Tentative Agenda Items:
	Day 1: Training:
		?other topics of interest - detailed or high level?
		Writing Drivers
		Database applications/discussion
		Using the portable channel access server
		Writing a channel access client
	Day 2: Status Presentations:
		?other topics of interest?
		New Client Tools 
		CDEV update
		Insight into new difficulties?
	Day 3: Discussions/Designs
		Archiver design/status 
		WNT-port design/status
		bumpless reboot design/status
		Channel Access direction/status

	A second European meeting will be held in about a year
Augustus, Andre	
Baribaud, Guy			[email protected]		CERN-ECP
Barillere, Renaud		[email protected]	CERN-ECP
Bellato, Marco			[email protected]		INFN
Birke, Thomas			[email protected]			BESSY
Brarda, Lois
Brown, Bill			[email protected]		LBNL
Burckhart, Helfried		[email protected]	CERN-PPE
Burkimsher, Paul		[email protected]		CERN
Campmany, Josep			[email protected]		LSB
Clausen, Matthias		[email protected]		DESY
Csuka, Gabor			[email protected]		DESY
Dalesio, Bob			[email protected]		LANL
Dohan, Don			[email protected]		PSI
Fernandez-Carreiras, David	[email protected]		CERN-ECP
Follath, Rolf			[email protected]		BESSY
Gazis, Evangelos		[email protected]		NTU, Athens
Gougnaud, Francoise		[email protected]			CEA, Saclay
Gournay, Jean-Francois		[email protected]	CEA, Saclay
Hammonds, John			[email protected]		IPNS, APS
Heubers, Wim			[email protected]			NIKHEF
Holstenberg, Hans-Christoph	[email protected]			MPE
Johnson, Andrew			[email protected]		RGO
Jones, Robert			[email protected]		CERN-ECP
Kraimer, MArty			[email protected]			APS, ANL
Lange, Ralph			[email protected]			BESSY
Lionberger, Carl		[email protected]		LBNL
Lussignol, Yves			[email protected]		CEA, Saclay
Maltezos, Stavros		[email protected]		NTU, Athens
Mcgehee, Peregrine		[email protected]	CFHT
Montarou, Gerard		[email protected]	LPC, Blaise Pascal Univ.
Meyers, David			[email protected]		CERN
Perlas, Josep			[email protected]			LSB
Perriollat, Fabien		[email protected]		CERN
Pi, Marti			[email protected]			IAC
Rahmani, M. Hosein		[email protected]		IASA, Athens
Rettig-Labusga, Siegfried	[email protected]		DESY
Richter, Simone		[email protected]	IKP, Darm.
Ryabov, Yuzi			[email protected]		Petersburg NPI
Schoener, Michael		[email protected]		DESY
Sibley, Coles			[email protected]		MIT Bates
Singhoff, Volker		[email protected]		DESY
Stilliaris, Stathis		[email protected]		IASA, Athens
Taylor, Philip			[email protected]		RGO
Urbschat, Peter			[email protected]		DESY
Vankov, Ivan			[email protected]		INRNE, Bulgaria
Watson, Chip			[email protected]		TJNAF
Zurek, Marian			[email protected]			FP&NT Cracow, Poland
APS - ANL	Advanced Photon Source, 	
		Argonne National Laboratory, 	
		Illinois, USA

IPNS - ANL	Intense Pulsed Neutron Source, 	
		Argonne National Laboratory, 	
		Illinois, USA

		Berliner Elektronenspeicherring-Gesellschaft fur 
		Berlin, Germany

CEA - Saclay	Tesla Test Facility, CEBAF Hall C, Atlas, CMS
		Centre d'Energie Atomique
		Saclay Cedex, France

		Geneva, Switzerland

		Geneva, Switzerland

CFHT		Canada-France-Hawaii Telescope
		CFHT Corporation
		Hawaii, USA

DESY		HERA Cryogenic Control, Tesla Test Facility, Facility Control
		Deutches Elektronen Synchrotron
		Hamburg, Germany

		Cracow, Poland

IAC		Integral Project - Pending Decision for a 10 meter segmented telescope
		Instituto de Astronfisica de Canarias
		Tenerife, Canary Islands, Spain
IASA		Racetrack Microtron
		Institute of Accelerating Systems and Applications
		Athens, Greece

IKP		130 MeV Super Conducting Recirculator
		IKP Darmstadt
		Darmstadt, Germany

		Istituto Nazionale di Fisica Nucleare
		Padova, Italy

		Institute for Nuclear Research and Nuclear Energy
		Sofia, Bulgaria

LANL		EPICS Project Group
		Los Alamos National Laboratory
		New Mexico, USA

LBNL		Advanced Light Source, BaBar Detector, STAR Detector, 
		& Gammasphere Detector
		Lawrence Berkeley Laboratory
		Berkeley, California, USA

		LPC Blaise Pascal University

		Laboratori del Sincrotro de Barcelona
		Barcelona, Spain

MIT - Bates	Bates Linear Accelerator
		Massachusetts Institute of Technology
		Middleton, Massachusetts

MPE		Paolo Alto Telescope
		Max-Planck-Institut fur Extraterrestriele Physik
		Garching, Germany

		Amsterdam, The Netherlands
		Petersburg Nuclear Physics Institute
		National Technical University
		Athens, Greece

PSI		Swiss Light Source - Test Stand
		Paul-Scherrer Institut
		Zurich, Switzerland

RGO		William Herschel Telescope
		Royal Greenwich Observatory
		Cambridge, England

TJNAF		Continuous Electron Beam Accelerator (formerly CEBAF)
		Thomas Jeffereson National Accelerator Facility
		Newport News, Virginia

Navigate by Date:
Prev: Re: CapFast enhancements Nick Rees
Next: R3.13 Update Marty Kraimer
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: CapFast enhancements Nick Rees
Next: R3.13 Update Marty Kraimer
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·