intro to cs 3.0 (pre-alpha)

1 September 2006 Dietrich Beck, GSI

Intro to Intro to CS CS 3.0 (pre-alpha)3.0 (pre-alpha)

• Summary of CS workshop February 2006

• User Requirements

• Communication Layer

• Changes and Demos

• Migration to CS 3.0

• Discussion


Updated Updated results of workshop February 2006results 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


User Requirements "Old/Existing" Facilities User Requirements "Old/Existing" Facilities and and Provided by Provided by CS CS 3.03.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 "New/Upcoming" Facilities User Requirements "New/Upcoming" Facilities and and Provided by Provided by CS CS 3.03.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


Event basicsEvent basics

• an entity waits for the next event, no polling!

• timeout handling is an important issue

publisher

subscriber subscriber subscriber

client client client

receiver

observer pattern: "one-to-many" command pattern: "many-to-one"

datacommand

example: radio, televisionadded in CS 3.0

example: typical human communicationsole possibility for CS < 3.0


DSCTrend with Command Pattern (DSCTrend with Command Pattern (CSCS < 3.0) < 3.0)

Central PC

Sequencer DSC EngineDSC Interface

Front-end PC 1

Data Acquisition

DataAcq. Instr. Driver

Timing

Timing Instr. Driver

AFG

AFG Instr. Driver

High Voltage

HV Instr. Driver

Hardware Software (Proc) Software (Lib) Exp. Specific General Part Buy! Event

Front-end PC n

SetValue "A" SetValue "B"Update "B"

RegisterTo "B"

DSC (Interface + Engine): Central event manager for trending data– bottleneck– hard to use (need configuration of tags, restore state after crash...)

RegisterTo "A"

Update "A"


TrendMsg with Observer pattern (TrendMsg with Observer pattern (CSCS 3.0) 3.0)

Central PCSequencer

Front-end PC 1

Data Acquisition

DataAcq. Instr. Driver

Timing

Timing Instr. Driver

AFG

AFG Instr. Driver

High Voltage

HV Instr. Driver

Hardware Software (Proc) Software (Lib) Exp. Specific General Part Buy! Event

Front-end PC n

Update "A"RegisterTo "A"

• 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

Update "B"RegisterTo "B"


DimWrapper

Simple CallSimple Call

LabVIEW message queue or notifier

Caller Callee

node1 node2

Client_node2 Server_node1

LabVIEW TCP/IP

Caller Callee

node1 node2

old:

new:

or(!)

callee@node2 callee@node2

callee DIM TCP/IP


New Communication Layer: DIMNew 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.

command pattern

observer pattern

knows node of client and server

arranges connections


New (!) LabVIEW-DIM interfaceNew (!) LabVIEW-DIM interface

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

DIM Wrapper dll/so, GSI LVEvent dll/so, GSI

LabVIEW runtime engine, NI

CS application

• fully event driven, using call back functions with DIM

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

• client and server functionality for commands and services


Improved "separation of functions"Improved "separation of functions"

old

new


Summary Communication LayerSummary Communication Layer

systems per node 1 N

node name important and difficult does not matter

event type of callee important does not matter

singletons only locally across network

TCP performance poor bandwidth limited

dsctrend (-> trendmsg) DSC is bottleneck, slow peer to peer, fast

SCADA integration difficult, backend no, backend

in-task calls < 1ms < 1ms

local calls N/A 1ms

network calls 2-3 ms 1ms

QueueClient/Serv./List. significant overhead N/A

remote connection time 5-10 s < 100ms

pure LabVIEW yes no

old new


Changes IChanges 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- AND observer pattern– CS systems should be designed according to the observer pattern (drastic change)


Changes IIChanges 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 IIIChanges 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 IV, Domain Management System (DMS)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 V, Changes V, CS CS Access System (CAS)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 VIChanges VI

• CSRealTime adjusted– use DataSocket as communication layer– use DIM/DataSocket gateway to link RealTime system to DIM

• ...

• ...


Schedule (February 2006)Schedule (February 2006)

Jan062-3 Feb Feb06 Mar06 Apr06 May06 Jun06 Jul06 Aug06 1st Sep Sep06

1st Oct Oct06 Nov06

15th Nov

Nov06

Dec06

15th Dec

KS-Team

workshop Test

Dim-LV

UserManger

DSC/Tools

Linux/RT

Reserve

Vacation

Sync-Freeze

Integration

3.0 alpha fix

3.0 beta fix

CS 3.0

Usersworkshop

Sync-Freeze

3.0 alpha

alpha test

alpha test

3.0 beta

beta test

beta test

CS 3.0

Jan071-2 Feb Feb07 Mar07 1st April Apr07

1st May

May07 Jun07 15th Jun Jun07 Jul07

15th Jul

KS-Team

stop LV7.1

workshop

port 2 LV8

port 2 LV8

Sync-Freeze

Integration

3.1 alpha fix 3.1 beta fix CS 3.1

Usersworkshop

Sync-Freeze

3.1 alpha

alpha test

alpha test 3.1 beta

beta test

beta test CS 3.1


Migration ProcedureMigration Procedure

• Previously:1. Feature freeze

2. Synchronize all sources

3. CS team makes sure, that sources are executable

4. Experiments verify, software is still working

5. Debug/Patch

6. (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


DiscussionDiscussion

intro to cs 3.0 (pre-alpha)

Documents