1 / 21

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. Next CS Releases CS Release 3.0 Stay with LV 7.1 include DIM include all available classes

darci
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

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

  5. 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

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

  7. 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!

  8. 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

  9. 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

  10. 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)

  11. Improved "separation of functions" old new

  12. Summary Communication Layer new old

  13. 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

  14. 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

  15. 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

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

  17. 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)

  18. CSRealTime adjusted use DataSocket as communication layer use DIM/DataSocket gateway to link RealTime system to DIM ... ... Changes VI

  19. Schedule (February 2006)

  20. 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

  21. Discussion

More Related