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:

Synchronous call: gets the specified TINE device server property
 
Usage : tget <device name> <property> [/s=<size> /f=<format> /t=<timeout>]
        e.g. tget /HERA/HEPBLM/WL105K1 AVELOSS
        or   tget /HERA/HEPBLM/WL105K1 AVELOSS /s=300 /f=float
 
Use quotes "" around device names with spaces
        e.g. tget "/HERA/HEPBPM/WL197 MX" ORBIT.X
 
If you regularly call 'tget' inside a script,
please make use of a 'trepeater' daemon!
 
A timeout other than the default 1000 msec can be specified via the /t option switch
 
 
See also: 'tmonitor', 'tsend' for sending and receiving data
 
 

So typing something like 'tget "/WORKSHOP/MYSERVER/Device 0" Amplitude' 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. To avoid this, 'tget' (as well as some other command line utilities) will address a tine 'repeater' which runs in the background (and will be started if it is not running). 'tget' will acquire the targeted data via the background repeater. If the target data is prefectly reflected there is no latency penalty for doing things this way. Under some circumstances it might be (or seem) desirable to forgo the repeater. This can be achieved by setting the environment variable TINE_USE_REPEATER=FALSE.

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 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 jDDD 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.NET programmers will want to look here.

VB 6 (legacy) 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() This will involve multiple links to different properties (same of different servers) which use the same callback routine and receive a single callback when all 'grouped' links have notified the client engine of an update.
• Have a look at the CM_USEONERROR flag in the access mode of AttachLink() Any link error (link timeout or otherwise) will substitute the designated value for the 'output' data contents. This is a an easy way to visually flag the 'displayed' data as being indicative of an error.
• Have a look at the CM_NETWORK flag in the access mode of AttachLink() Request the data to be sent as a multicast.