Accessing Your Server

You might want to have a quick look at the PowerPoint presentation before proceeding.

There are several ready-made client applications which you can immediately use to access the test server you made in the first part of the workshop tutorial. You have already used one, namely, the "Instant Client" which lets you browse the control system and access and test not only your server but any server in the control system. The Instant Client will only let you access one server and one property at a time, however. You can of course call up multiple instances of the Instant Client using "Options" -> "New Client".

Command Line tools

You should probably become familiar with the bevy of available tine command line tools. At the command line (on Windows, open up a "DOS" box) type 'tget'. You should get a resonse message something like:

Usage tget <device name> <property> [<size> <format>]
      e.g. tget /HERA/HEPBPM/WL197MX ORBIT.X
      or   tget /HERA/HEPBPM/WL197MX ORBIT.X 10 float

So typing something like 'tget "/WORKSHOP/MYSERVER/Device 0" Temperature' should return the multi-channel array of temperatures (beginning with Device 0). Note that since there's a blank in the device name (unless you changed it!), you have to enclose the <device name> string in quotes, otherwise 'tget' will try to interpret the string following the blank as the property!

Note:

'tget' is sometimes useful in scripts, but note that under normal circumstances, 'tget' is a client application which does not remain resident. That means that each call will normally access the ENS to find the accress of the device server you wish to contact, then contact the device server, obtain and display the results, and then terminate. So the normal address caching that would take place in a client application which remains resident does not have a chance to take place. Thus if you place 'tget' in a tcl script which calls it at one hertz, then you go through all of this once per second. And if you run your tcl script on several stations, it will be once per second per station. In such cases it is a good idea to run an instance of 'tineRepeater' without any arguments in the background. 'tget' will first look to see if an instance of 'tineRepeater' is running and if so it will forward the request to the repeater, which will obtain the address (once!) and start a static listener in the background. So the tcl script can make its synchronous calls to 'tget', but it will always access the data via a named pipe from 'tineRepeater'.

Analogous to 'tget' is 'tmonitor' which starts a data link to the device and property in question and doesn't stop until you type 'quit' or 'cntl-C'. You might want to have a look at some of the other available tools in the command line section.

The Multi-Channel Analyzer

We'll cover some of the other generic tine client applications as we go along. It is worth mentioning at this stage the usefulness of the "Multi-Channel Analyzer". At the moment, this is available only as a Windows application, although a java version is under way. You can start this in Windows, by going to the start menu, selecting "Service Controls" -> "System Tools" -> "Multi-Channel Analyzer". If you do this, it will only offer whatever has been pre-configured in the application's startup files. But it is easy (well, sort of easy) to add your own entries.

Let's see if we can make it display your "Temperatures" from your test server. If you've got a "DESY" install of the tine control system (you probably do), the Multi-Channel Analyzer application actually starts from the directory L:\bin.hera\spectrum (do ask why! - it's historical). The Web install puts it in a more sensible location, but just go to the directory L:\bin.hera\spectrum\configs and have a brief look. There are lots of (you guessed it) .csv files.

The one annoying thing about .csv files is that they are not inherently hierarchical. To achieve anything like a hierarchy, you have to have .csv entries which are the file names of other .csv files. Keeping this in mind, do the following:

Make a new .csv file called (this is important) config_user.csv, which sould look something like:

MACHINE, CONFIGFILE, MACHINEFILE
WORKSHOP, config_Workshop.csv, Machine_HERA.csv

The name here is important, since the Multi-Channel Analyzer will look for this otherwise optional file when it starts. Basically we're going to tell it to offer another "Machine" called "WORKSHOP" whose points of interest will be contained in a file called 'config_WORKSHOP.csv'. As an aside, it will plot the HERA machine parameters in another panel (since the MACHINEFILE is 'machine_HERA.csv') so that we will be able to see if our random generated temperatures correlate with the HERA machine parameters (they shouldn't).

Now make another .csv file called config_WORKSHOP.csv, which is also a simple file and should look like:

FILENAME, DESCRIPTION
WORKSHOP.csv, Sine Generator Temps 

This basically specifies all of the configurations relevant to 'machine' WORKSHOP. So we have only put in one configuration and it's called "WORKSHOP.csv", so let's make this last file in the 'hierarchy'. It should look something like (the entry in the "SERVER" column depends on what device server export name you gave your server):

CONTEXT,SERVER,PROPERTY,TAG,DESCRIPTION,HSTSERVER,HSTPROPERTY,ARCSERVER,ARCPROPERTY,APPEND,HIGH
WORKSHOP,WKSineGen,Temperature,,Sine Generator Temperatures,,,,,,

When you have done this, you can start the Multi-Channel analyzer from the start menu (don't worry, your new .csv files won't be overwritten by the application launcher).

It will likely come up showing the HERA Absorber temperatures. You can have a look at these if you like, but you'll probably want to see what your server's data looks like. It is instructive to see some of the other data sets offered by the Multi-Channel analyzer (everything from BPMs to Dipole Temperatures to PSC Currents) if for no other reason that the shear volumn of data which lends itself to being displayed in this way.

Go to "Options" -> "Select Machine" -> "WORKSHOP". If your server is the only one configured (and it is running !) it should show up in the top display. (The HERA beam parameters will show up in the bottom most display as a history trend with a depth given by the "Live Time Window". If you click on any of the histogram lines, the history trend of the module you clicked on will be added to the middle display. (Provided, of course, that you are keeping a history of the Temperatures -> check your historty.csv file).

You can right-click over most of the display controls to get context-sensitive menus for allowable display options. Check it out! This was a client application you didn't have to write!

The Client API

Okay, let's do some "nuts and bolts". That is, let's examine some of the fundemental client API calls, as well as transfer modes.

To begin with, we'll write a simple non-GUI client application which accesses your test server and writes out reponses as a text dump, either at the console, or if you are a Visual Basic enthusiast, in a text box (okay, that's a GUI).

If you want to ignore the "nuts and bolts" then putting together configurable client applications, which 'read' the desired behavior from an application database and then connect control points to displayers, might be the way to go. With these kinds of applications, you don't program at all. On the other hand, you end up with a primitive application which can display data and change settings, but otherwise is extremely difficult if not impossible to massage or filter the data in anyway prior to display. It is also difficult if not impossible to react on some event in one displayer (say a click in a chart) and take decisive action in another displayer (e.g. use the timestamp obtained in the click to retrieve a history snapshot to display somewhere else). To do these sorts of things, you need to program (or you'll be jumping through some rather exotic hoops).

Tine lends itself to primitive application builders such as DOOCS DDD or JoiMint as you might expect, but we'll be looking at rich clients in what follows. And to do that we'll have to have a look at the basic tine client-side API.

Java programmers will want to look here.

C programmers will want to look here.

VB programmers will want to look here.

LabView programmers will want to look here.

Exercises:

• get and display a sine curve and the amplitude;
• set the amplitude
• Have a look at the CM_GROUPED flag in the access mode of AttachLink()
• Have a look at the CM_USEONERROR flag in the access mode of AttachLink()
• Have a look at the CM_NETWORK flag in the access mode of AttachLink()