intro to cs 3 0 pre alpha n.
Skip this Video
Download Presentation
Intro to CS 3.0 (pre-alpha)

Loading in 2 Seconds...

play fullscreen
1 / 21

Intro to CS 3.0 (pre-alpha) - PowerPoint PPT Presentation

  • Uploaded on

Intro to CS 3.0 (pre-alpha). Summary of CS workshop February 2006 User Requirements Communication Layer Changes and Demos Migration to CS 3.0 Discussion. Next CS Releases CS Release 3.0 Stay with LV 7.1 include DIM include all available classes

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Intro to CS 3.0 (pre-alpha)' - darci

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
intro to cs 3 0 pre alpha

Intro to CS 3.0 (pre-alpha)

Summary of CS workshop February 2006

User Requirements

Communication Layer

Changes and Demos

Migration to CS 3.0


updated results of workshop february 2006
Next CS Releases

CS Release 3.0

Stay with LV 7.1

include DIM

include all available classes

CS Release 4.0 with LV 8.1? Release 3.1 with LV 8.20

CS Release 4.0 with LV >8.20 using "object oriented wires" in ~ 2010

LabVIEW built-in SCC -> SubVersion. Deadline March 1st 2006!

Joining OpenG and will be evaluated (future of openG is unclear, sourceforge seems to be o.k.)


Make small packages now -> becomes available with SubVersion (?).

Make dependencies clear!

OpenG Builder and Commander (replaced by commercial product)

have a CS packager and package tool (=> Holger) or use something like "Install Shield".

Christian wants to prepare a MySQLClient.

Invitation to join MARRATECH test phase for remote collaboration (no official decision of GSI yet)

Systec will support a CS based General Sequencer BaseClass hierarchy.

Plan next CS Workshop for February 2007

Updated results of workshop February 2006
user requirements old existing facilities and provided by cs 3 0
object management (singleton (singleton only), node (almost irrelevant), in-use (see "user management"), "HyperProcess", ...)

consistent set-values (if published by the object and subscripted by GUI)

icon generator

user management (first version)

new inheritance tool (improved)

database (configuration tool, class specific entries, ...) (first version)

TCP/IP (performance, node-name, overhead, loss of first event, ...) (intrinsic property)

system recovery, system-alive check, object-alive check (object nets by Alexander)

CS like a water tap

backward compatibility (provided wherever possible. However, CS 3.0 is a major release that gets rid of past misconceptions)


... (some requirements are probably identical to "New" Facilities)

User Requirements "Old/Existing" Facilities and Provided by CS 3.0
user requirements new upcoming facilities and provided by cs 3 0
... (some requirements are probably identical to "Old" Facilities

performance (faster, more PVs) (intrinsic property)

persistency database

recipe database

backward compatibility (of future versions)







... there is a lot more, we don't know about

User Requirements "New/Upcoming" Facilities and Provided by CS 3.0
event basics
an entity waits for the next event, no polling!

timeout handling is an important issue

Event basics

command pattern: "many-to-one"

observer pattern: "one-to-many"











example: radio, television

added in CS 3.0

example: typical human communication

sole possibility for CS < 3.0

dsctrend with command pattern cs 3 0
DSC (Interface + Engine): Central event manager for trending data


hard to use (need configuration of tags, restore state after crash...)


DSCTrend with Command Pattern (CS < 3.0)

Central PC

DSC Interface

DSC Engine


RegisterTo "B"

RegisterTo "A"

Update "A"

Update "B"

SetValue "B"

SetValue "A"

Data Acquisition



High Voltage

DataAcq. Instr. Driver

Timing Instr. Driver

AFG Instr. Driver

HV Instr. Driver

Front-end PC 1

Front-end PC n


Software (Proc)

Software (Lib)

Exp. Specific

General Part


trendmsg with observer pattern cs 3 0
DSC (Interface + Engine): becomes obsolete in many cases (SCADA Backend only)

Easy usage:

no need for pre-configured tags

re-connection between client and server provided by observer pattern

Dramatic (and enforced!) change in the way how-to design and implement software


TrendMsg with Observer pattern (CS 3.0)

Central PC


Update "B"

RegisterTo "A"

Update "A"

RegisterTo "B"

Data Acquisition



High Voltage

DataAcq. Instr. Driver

Timing Instr. Driver

AFG Instr. Driver

HV Instr. Driver

Front-end PC 1

Front-end PC n


Software (Proc)

Software (Lib)

Exp. Specific

General Part


simple call
Simple Call









LabVIEW message queue or notifier









new communication layer dim
DIM (Distributed Information Management) is a light weight package for information publishing, data transfer and inter-process communication,

Originally, DIM has been developed at Delphi/CERN.

Today, DIM is one of the backbones for many experiments at CERN, including all four LHC experiments.

Maintained at CERN and available via GPL. Thanks to C. Gaspar et al.

New Communication Layer: DIM

knows node of client and server

arranges connections

command pattern

observer pattern

new labview dim interface
fully event driven, using call back functions with DIM

uses "native" DIM libraries (no re-write)

client and server functionality for commands and services

New (!) LabVIEW-DIM interface

CS application

LabVIEW runtime engine, NI

LVEvent dll/so, GSI

DIM Wrapper dll/so, GSI

DIM dll/so, C. Gaspar, CERN (dedicated CS patch)

changes i
Directory structure slightly changed (Explorer)

Categories: independent of directory structure, "Main", "Contributed", "User", ...

Packaging: independent of directory structure

Simplicity: CS core depends only on LV Full Development System

example: DSCIntProc is no longer part of the core system

Number of options reduced => command line parameters instead of ini-files

example: only access database via SQL server and not via SQL VIs

exception: BaseProcess: Read SQL data only, if "data in" of constructor is not "".

Communication layer is DIM:

"CS is based on DIM"

"DIM is the core of CS

CS systems MUST be designed according to command-ANDobserver pattern

CS systems should be designed according to the observer pattern (drastic change)

Changes I
changes ii
Each CS system publishes system specific information (CSStart, DimTree)

Each object publishes object specific information (DimTree, "CSObj.constructor") as DIM-Services and no longer via the DSCEngine.

Typical name for a service: OBJECTNAME_PROPERTYNAME

A DIM service may exist only once in a DIM domain

Singleton functionality enforced within a DIM domain

Violations are followed by instant and severe punishment!

LabVIEW DSC is no longer "required", ("BaseProcess.i attribute", "update number tag" etc., "BaseProcess.thread.vit->set event error").

Changes II
changes iii
Improved inheritance: number of VIs in folder "Inheritance" reduced (Explorer)

Format of event definition changed (BaseProcess.ProcEvents)

Eliminate Flatten/Unflatten String VIs

Format of event data changed (SuperProc.ProcCases)

Only generic data types supported (CoreLib.byte array to data, BaseProcess.create event)

DSCTrend events no longer supported by BaseProcess (and DSCIntProc!)

Instead: TrendNot and TrendMsg Events (GOG.create trend events, GOG.ProcCases, CAEObj.unfold trend data)

CS objects communicate via DIM only

SCADA Backend needs to connect to DIM only (DB and Tag Tool, DIM/DSC Tool,

Changes III
changes iv domain management system dms

Remote process management on Windows and Linux platforms

Management of a "CS Domain"

defines node of CS systems

defines names of CS systems

defines command line parameters of a CS systems

Three main components (demo)

DMS Server (once per CS domain, administrator access only)

DMS Client (once per node and user, to be started upon login)

DMS Viewer (just a program...)

Recommendation (Windows): All to be stored on a local disk

Allows update of binaries of one node independent of other nodes

Independent of network or file servers

Changes IV, Domain Management System (DMS)
changes v cs access system cas
Locking of objects via a "accessID"

Implemented in CAEObj class

When sending an event, the accessID of the sender is part of event data

A receiver object accepts an events only , if the accessID matches its own

Locked objects form a group

the number of groups practically unlimited

all objects in one group have the same accessID

every object in a group can send events to all other object in the same group

A group is organized in a hierarchical top-down tree.

the accessID is inherited from top object of a tree

the structure of the tree is defined by a CSAccessServer (one per CS domain)

Changes V, CS Access System (CAS)
changes vi
CSRealTime adjusted

use DataSocket as communication layer

use DIM/DataSocket gateway to link RealTime system to DIM



Changes VI
migration procedure

Feature freeze

Synchronize all sources

CS team makes sure, that sources are executable

Experiments verify, software is still working


(Repeat steps 2-5 trough alpha, beta and "released version")

"Wanderbaustelle" more appropriate?

Migrate one experiment first with full man-power (volunteers?)

Result: one experiment using CS 3.0 (release version)

Then, start migration of other experiments using release version

Migration Procedure