Intro to cs 3 0 pre alpha
This presentation is the property of its rightful owner.
Sponsored Links
1 / 21

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


  • 39 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Intro to CS 3.0 (pre-alpha)

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

Discussion


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 http://www.sourceforge.org will be evaluated (future of openG is unclear, sourceforge seems to be o.k.)

Packaging

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"

client

client

client

publisher

data

command

subscriber

subscriber

subscriber

receiver

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

bottleneck

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

Event

DSCTrend with Command Pattern (CS < 3.0)

Central PC

DSC Interface

DSC Engine

Sequencer

RegisterTo "B"

RegisterTo "A"

Update "A"

Update "B"

SetValue "B"

SetValue "A"

Data Acquisition

Timing

AFG

High Voltage

DataAcq. Instr. Driver

Timing Instr. Driver

AFG Instr. Driver

HV Instr. Driver

Front-end PC 1

Front-end PC n

Hardware

Software (Proc)

Software (Lib)

Exp. Specific

General Part

Buy!


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

Event

TrendMsg with Observer pattern (CS 3.0)

Central PC

Sequencer

Update "B"

RegisterTo "A"

Update "A"

RegisterTo "B"

Data Acquisition

Timing

AFG

High Voltage

DataAcq. Instr. Driver

Timing Instr. Driver

AFG Instr. Driver

HV Instr. Driver

Front-end PC 1

Front-end PC n

Hardware

Software (Proc)

Software (Lib)

Exp. Specific

General Part

Buy!


Simple call

Simple Call

old:

or(!)

Caller

Client_node2

Server_node1

Callee

node1

node2

LabVIEW message queue or notifier

LabVIEW TCP/IP

DIM TCP/IP

new:

DimWrapper

Caller

Callee

node1

node2


New communication layer dim

DIM (Distributed Information Management) is a light weight package for information publishing, data transfer and inter-process communication, http://www.cern.ch/dim/.

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)


Improved separation of functions

Improved "separation of functions"

old

new


Summary communication layer

Summary Communication Layer

new

old


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, http://wiki.gsi.de/cgi-bin/view/CSframework/DatabaseTools)

Changes III


Changes iv domain management system dms

http://wiki.gsi.de/cgi-bin/view/CSframework/DomainManagementSystem

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)

http://wiki.gsi.de/cgi-bin/view/CSframework/CSAccessSystem

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


Schedule february 2006

Schedule (February 2006)


Migration procedure

Previously:

Feature freeze

Synchronize all sources

CS team makes sure, that sources are executable

Experiments verify, software is still working

Debug/Patch

(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


Discussion

Discussion


  • Login