CS Workshop, February 2006
Results
The presentations given at the workshop can be found at the bottom of this page.
The results of the workshop are summarized
here.
Invitation
Dear Colleagues,
we, the
experiment control system group @
GSI, would like to invite you to a workshop dedicated to the
CS framework. Please feel free to forward this information to other colleagues.
The main idea behind this workshop is to bring the users and developers of
CS together to discuss about the present status and future developments.
So far,
CS is in use at a couple of experiments and facilities. Lots of features and classes have been added over the past years. The design and base classes of
CS have proven to work and are basically used unchanged for quite some time.
We feel that it is just the right time for such a workshop for two reasons. First, the advent of
LabVIEW 8 has triggered some discussion on how to improve or even redesign the
CS framework. Examples for new features in
LabVIEW 8 are the so called
network variables, a project manager supporting real libraries with
private namespace, ... . Second, quite a few
CS users demand features like better scaling to a larger number of process variables, access control, security, locking of sub-systems... - just to name a few examples.
We propose to have this workshop at GSI on
February 2 2006, Thursday, 09:00 to 18:00 (evening: dinner)
February 3 2006, Friday, 09:00 to 15:00.
It would be nice if you could provide us with some suggestions about the topics you would like to be informed about and and/or the topics you would like to discuss. Please let us know, if you intend to come to the workshop or not.
Agenda
Maybe it is a good idea to contribute to the
CsWishList to enable us to derive a concrete agenda.
Thursday, February 2nd 2006
Zum Storchen Restaurant
Darmstädter Str. 25
64291 Darmstadt
Tel. 06151 933129
Map
Friday, February 3rd 2006
Possible topics to discuss:
- Integration into LabVIEW 8
- Project Manager
- Packaging, OpenG Toolkits,
- Name space for VIs
- Directory structure
- "Subversion" as source code control system
- Event Mechanism
- Change to "environment variables" (LV 8)?
- Change to DIM (www.cern.ch/dim)?
- Format for ProcEvents method
- Format of "call cluster"
- Scaling to larger systems
- SCADA backend
- Number of process variables
- Locking of sub-systems
- Access control
- Consistency of "Set-Values" (for distributed GUIs)
- Persistency
- Database
- Suitable configuration tools
- Name of database can be set in constructor of BaseProcess class
- Application Layer
- Object Nets
- Petri Nets
- Proxies
- Partitioning
- Groups of objects
- "SuperProc" class as factory for objects of any class
- Licensing
Preparation of Discussion Topics
- Status & Problems
- At the Moment BaseProcess Classes must have a Database entry, to work. Thats annoying in many cases. What about using a default setting for classes with no Database entry? Or a wire at the constructor named: "use Database entry from Instance ..." instead of using the unflexible vi "Truncate name for SQL"
- If the "Super-Load Process" would transform to a "Super-Load Object" and a "Data-in" would get available, the Super could be used as a Object Factory
- We have had some bad errors with wrong grammar in the Proc-Events (other bahavior in the .exe than in the source code). In Mind that the ProcEvents have "theoretically" no use, and only are another source for errors, we would like to discuss about deleting them from the CS. A consequence would be, that a Object getŽs all Events, sent to it. Is that really so bad?
- By using a Asynchronous call two extra strings are added to the Call Cluster. So my question is: Is anybody using these asynchronous calls? If no, i would think about having a smaller call cluster, to make CS more confortable, and more easy to understand.
- Requirements
- Device Layer
- Application Layer
- Operating Layer
--
HolgerBrand - 19 Jan 2006