we, the experiment control system group
, 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.
Maybe it is a good idea to contribute to the CsWishList
to enable us to derive a concrete agenda.
Thursday, February 2nd 2006
Friday, February 3rd 2006
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.
- Device Layer
- Application Layer
- Operating Layer
-- Main.Dietrich, HolgerBrand
- 02 Jan 2006