270 likes | 441 Views
TINE Workshop. Don’t panic, we’re making this up as we go along …. Practical Information. desy users vs non-desy users (how to install!) web site: http://tine.desy.de Need to Install (need to be administator): Acopbeans plugin (C:Program Fileseclipse …)
E N D
TINE Workshop Don’t panic, we’re making this up as we go along …
Practical Information • desy users vs non-desy users (how to install!) • web site: http://tine.desy.de • Need to Install (need to be administator): • Acopbeans plugin (C:\Program Files\eclipse …) • Tine windows install -> register some ActiveX controls, etc.
Get you workstation ready! • Start LabView, Visual Studio • And let them both ‘do their thing’
A bit of history • CERN protocol (’70s) • CERN Isolde (1989) • Equipment Modules (early object-oriented) • Continuous development @ DESYsince 1992
Where the layers are… • Hardware interface layer (cdi, ivi, asyn, etc.) • - • Server-side API • TINE • Client-side API • - • RAD tools, classes, components, finished applications (acopbeans, abeans, gumTree, joiMint, css, jDDD, etc.) Database driven versus programming (primitive versus rich clients) Where does hardware support fit in?
Data Links • Try not to think of “get” and “put” • Synchronous • Sounds like I’m talking to a database • Clients establish a “link” which • Specifies a contract (with input and output data, separate access flag) • Can be synchronous or asynchronous (with callback) • Some links can be simply “triggers” (no data transferred when property “reset” is called)
Configuration Database Files • csv files: • vs xml ? • vs anything else ? • tine csv format (Headers give columns) • How much do I want to ‘configure’? • How much do I want to ‘register with API’? • e.g. because I know my device names from another database file.
Csv vs xml ? e.g. fecid.csv e.g. fec.xml
ENS and name resolution • How does a client find a server ? • Comparison to DNS (ping hostname vs tget server) • Not just an IP address ! (server port => system-wide port scheme + port offset) N servers on same computer • flat file(s) on local file system ? (lmhosts) • ENS (multiple -> avoid single point of failure) • Where is the ENS ? • -> cshosts.csv (pointed to by TINE_HOME or working directory) • -> set with API call: • SetNameServerAddress() • -> issue multicast: • FindNameServerOnNetwork(); • GetMyServerAddress();
ENS and name resolution • Address resolution: • check ENS#0 followed by ENS#1, etc. followed by local database cache (also in TINE_HOME). • Release 4.0: client on local host update local database cache • The ENS is also a TINE server. Is the only one that doesn't use an environment (TINE_HOME, FEC_HOME, etc.). It doesn't need to find the ENS ! • NOTE: clients can still find servers without an ENS !!!!!!! • edit your own local database by hand! • Use TINE_STANDALONE = TRUE • Allow ‘network resolution’ on server and client
Concentrate on the Server first • But first a quick tour through the download package! • Then an even quicker look at putting together a coma application. • Test servers. • Put some work in the server up front => life is easy (for everyone) later • Importance of registering property meta information. • Importance of providing data "ready to display" (do the middle-layer logic at the server) • Remember: Others besides yourself will be browsing your server for useful data.
Naming Scheme • FEC name (Front End Controller) • Equipment Module Name (local) • Device Server Name (exported) • Device Names (locations, keywords, tags, numbers) • Property Names (methods, commands) • Aliases • #0 vs. device name • All devices can go by a name or a number • Is ‘device 0’ better than ‘#0’ ? • http://adweb.desy.de/mst/tine/index.html#sectionThreeFold
TINE Naming Chaos • What’s the difference between a FEC, an equipment module, a device server, an export name, and so on? • Aren’t these all the same thing?
TINE Naming Chaos (revisited) • Server host Computer • has IP Address and Operating System • 1 or more FECs (unique name!) • Process with a single Port Offset (for UDP, TCP) and Name (for Pipes) • Manages all the Network I/O, connection tables, scheduling, etc. • 1 or more Equipment Modules (EQM) • Local “managed” name <- hard coded ! • Exported “Device Server” name (unique!) • 1 or more named devices • 1 or more named properties • Device Context Server exports module “BPMEQM” on FEC “BPMFEC” as “BPM” in context “DORIS” Client requests “/DORIS/BPM/NR 3 MO[Orbit.X]” -> “BPMEQM@BPMFEC”
TINE Naming Chaos (one more thing …) • Why not FEC = EQM = Exported Name = “BPM”? • Won’t life be easier? • Multiple instances of a server in the control system ! • e.g. Run the same RF Server on 8 different stations • Same Equipment Module Name (that was the ‘managed name’ and is hard-coded). • Different FEC Names, Exported Names • “ERFEQM@ERFNLFEC” -> “ERF.NL” • “ERFEQM@ERFNRFEC” -> “ERF.NR” • “ERFEQM@ERFOLFEC” -> “ERF.OL” • etc. … • In this case you might want to define a device ‘Group’ called “ERF” and have each of these physical device servers join the group. • Some OSes have a single address space • ever only 1 FEC process • e.g. VxWorks, DOS, Win16, NIOS • “SPSEQM@QPSWFEC” -> “QPSStatus.WEST” • “IXEQM@QPSWFEC” -> “QPSBuffers.WEST” • “TRCEQM@QPSWFEC” -> “QPSTrRec.WEST”
TINE Naming Chaos • Local EQM Name Guidelines … • Use Capitals • Add a ‘EQM’ to local equipment module names if possible • This name is usually ‘hardcoded’ • Java servers will use the EQM class name if otherwise not assigned. • there are only 6 characters available (truncated to 6!) • but this name is not ‘exported’ (no one really sees it). • but it might show up in a directory tree. • You can go into ‘who cares’ mode if you want to … • use “1”, “2”, etc. • Generated names (e.g. /XFEL/PiPrivCmds_piFieldXSEP -> ‘qncx5’ • Just ensure that same module has the same name every time you start the server! • But it’s often better to use something you might remember !
TINE Naming Chaos • FEC Name Guidelines … • Use Capitals • Add a ‘FEC’ to the FEC name if possible. • Can add the ‘port offset’ when similar FECs live on the same host (same IP address). • But: needs to be system-wide unique and • Only 16 characters available! • e.g. • “L2CASFEC” : Central Alarm Server FEC for LINAC2 • “D2VACFEC.4”: DESY2 Vacuum FEC with port offset 4 • “Io83a99aef.1f8”: another DESY2 vacuum FEC (name auto-generated by DOOCS). Yes, it’s true: no one sees this name in a browser, but …
What are the APIs? Server: • buffered server (LabView, MatLab) • Attach(), push(), pull() • Equipment Module API Client: • Static Listener (LabView, MatLab) • Data Links
Server Configuration • Information registered via API • Hard code the exported names ? • Information registered via .csv (.xml) file • Have I got a file system ? • Information registered via discovery • In the end, like getting a file from a repository.
Important Files and where to find them: • http://adweb.desy.de/mst/tine/csvFiles.html
Let’s get started … • Add yourself to the Administrators group • (don’t want to deal with security!) • Windows: • Install Tine (your choice) : • From NetInstall • Try your luck … • From http://tine.desy.de -> download page • Get the windows setup and run it ! • If you’re not on-site at DESY, you’ll have to do this • Linux: • http://tine.desy.de ->download page • Get tineLinux.tar.gz, tineJava.tar.gz • Gunzip and untar them. Run setup and then installAsRoot
First things first (windows): • Let’s first work “inside the box”, i.e. ENS, servers, clients all on your local machine (we can open it up later). • => Your workstation will define a TINE Site! • => You’ll need a running ENS, so start that first • Windows: • Run Setup ! • For convenience open a command prompt and type subst L: %TINE_ROOT% • Go to the directory L:\Servers\SYSTEM\ENS and start the ens.exe executable. • Go to the directory L:\Database and edit (Notepad is okay) the file cshosts.csv so that the first entry either has the loopback address “127.0.0.1” or the real address of your host computer. We’ll change this back to a real, designated ENS (“outside the box”) later.
First things first (linux): • UNIX (Linux): • You should untar the tar ball and run the setup script. This will build everything needed for the TINE install. • Run installAsRoot to put the tine libraries in /usr/lib, the tine includes in /usr/include/tine and several tools in /usr/bin. (If you don’t want to do this, you can leave things where they are, but then the Make files need to be modified to reflect where the libraries and include files are). • You’ll need to edit the cshosts.csv file so that it contains a single ENS entry with the loopback address (“127.0.0.1”). We will change this to a real, designated ENS (“outside the box”) later. • cd to the tine/servers directory and run the makeall script (./makeall). Among other servers, you will have compiled an ENS in tine/servers/ENS/bin. At the moment the executable is called ‘rpcserv’ (you can rename it to ‘ens’ if you like). Start this process.
Second things second: • Find the SineGenerator server and start it. • You should be able to find a server called “WinSineGenerator” for Windows or “LxSineGenerator” for Linux in the InstantClient. • We can monitor a bit of systematics by setting the debug level on the ENS to 1 or 2 and restarting the Sine Server. • Try accessing a few of the properties.
Third things Third • Find and start the Instant Client • This will be under All Programs -> TINE Controls -> Common -> Java -> Instant Client • Install the Java package and run ComaStart to configure simple application which controls the sine generator. • You can have bit of fun with an application builder that does NOT require a framework • (the application builder is part of the application!)
Host checker, etc. … • Now is a good time to try out the host checker … • Go to http://tine.desy.de -> Workshop and begin …
Today’s Schedule • pre-lunch (10:00 -> 12:00) : • short .ppt presentation • Install tine • The 'hello world' equivalent server in C (using the buffered server interface) • - Yes C ! But you can switch over to your favorite language shortly afterwards • Test server with instant client • - first look at transfer modes : TIMER/DATACHANGE, CONNECT/NETWORK • - look at scheduling (and when to use property decoration ".SCHED") • - look at synchronous vs. asynchronous access (more on this when we write our first client application). • Archiving • - View archive data with Instant client • - View archive data with the Archive viewer • post-lunch (13:00 - 16:00?): • Adding write commands + handlers to the server • Security • - users/ipnets @ server level • - @ device/property level • - access locks • - exclusive reads • Alarms (via alarm watch) • - viewing alarms with the Instant client • - Viewing alarms with the FEC Remote panel