A prototype TINE scope server is in the making, but would basically only server as an 'interface' from which real scope servers would inherit. Existing scope servers tend to be written in languages (LabView, VisualBasic) that would not benefit from such an interface anyway. Thus the priority here is at the moment 'small'.
Tantamount to providing a TINE scope server is providing a requisit set of scope 'properties'. Such servers will no doubt provide a number of other properties related to its specific purpose (e.g. a real scope server will have properties such as "HorzOffset", "VertOffset", "HorzScale", "VertScale", "Impedance", "Gain", etc.). The TINE Scope Trace Viewer is not interested in controlling a scope server or changing settings. It needs only to know how to best display scope traces including all relevant information.
A scope trace property will then provide a scope trace and be accompanied by a set of parallel 'decorated' properties which the scope trace viewer will need in order to function properly.
For instance, if the scope trace property is called "Trace", this will be registered so as to provide a 'spectrum' type array (AT_SPECTRUM) of some length. In addition then, there must be a property providing specific trace information called "Trace.INFO". This must provide TINE Tagged Structure registered as "TraceHS" with the general form:
typedef struct TraceHdrStruct { char ChannelName[DEVICE_NAME_SIZE]; // channel name char ChannelDesc[256]; // channel description UINT32 format; // tine data type UINT32 size; // array size UINT32 preTrigger; // number of points prior to trigger float xscale; // horizontal scale float xoffset; // horizontal offset char xunits[UNITS_SIZE]; // horizontal units float ymax; // vertical maximum float ymin; // vertical minimum char yunits[UNITS_SIZE]; // vertical units char reserved[256]; // reservered for future use } TraceHS;
Much of the information in the header might be registered as 'static' information of the property. However, in the general case, the settings contained in the header can be rather dynamic. Thus the scope trace viewer maintains a persistent link to the header information as well as the trace in question.
In addition, a property Trace.SCH or Trace.SCHED can optionally be provided to deliver the scope trace at the hardware triggered rate.
A property Trace.REF can optionally provide a reference trace.
A property Trace.SEQ can optionally provide a trace sequence (as a double array of trace sequences for multiple channels). And a property Trace.NSEQ can provide the number of traces in the sequence.
A property Trace.XAXIS can optionally provide a horizontal axis if not trivially determined by the horizontal scale and offset information in the trace header.
As an example, consider the exported trace properties from /Linac2/BeamLossMonitors (a LabView server):
Trace properties are not required to be specifically called "Trace", as can be seen in the trace property set shown below for /Linac2/PiaScope (a Visual Basic server):
The trace viewer configurations maintained by the archive system (see the section on the archive database manager) is configured precisely with such designated trace properties from scope servers (i.e. without decorations: 'Trace' says it all).
The scope trace viewer makes use of this systematics. Using the scope trace viewer then becomes a matter of selecting the desired scope trace from the managed list.
The comparison tab also shows a set of pre-defined comparison configurations:
