TKernel is the TINE Kernel (singleton) class, whose static methods are used to manage the TINE engine. More...
Static Public Member Functions | |
| static double | GetDataTimeStamp () |
| Provides the last established data timestamp. | |
| static Int32 | InitializeServer () |
| Initializes the TINE server engine. | |
| static double | MakeDataTimeStamp () |
| Makes a data timestamp according to the current system time. | |
| static Int32 | RegisterDeviceName (String eqm, String devName, Int32 devNr) |
| Assigns a device name to the specified device number. | |
| static Int32 | RegisterFecInformation (String fecName, String defaultSubSystem, String defaultContext, String fecDescription, String fecLocation, String attachedHardware, String responsible, UInt16 portOffset) |
| Assigns a FEC Name and descriptive information to the server process. | |
| static Int32 | RegisterPropertyInformation (String eqm, String prpName, TDataType dtOut, TDataType dtIn, UInt16 accessMode, UInt16 arrayType, UInt16 rowLength, String prpDescription, Int32 prpId, String redirectionTarget) |
| Assigns pertinent information for the specified property. | |
| static void | SetDataTimeStamp (double timestamp) |
| Sets the intrinsic data timestamp to the value given. | |
| static void | StartServices () |
| Required call for the TINE engine to function property. | |
TKernel is the TINE Kernel (singleton) class, whose static methods are used to manage the TINE engine.
| static double tine::TKernel::GetDataTimeStamp | ( | ) | [inline, static] |
Provides the last established data timestamp.
A call to getDataTimeStamp() immediately following a call to ExecLink() or within a callback routine will yield the data timestamp of the call. Note: This call is not thread-safe. Synchronous data acquisition on two different threads could conceivably interfer with the value returned from this routine. A thread-safe way of obtaining the data timestamp associated with a call is to use the .dTimestamp field of the DTYPE object for synchronous calls such as ExecLink() or ExecLinkEx() or to use getCurrentDataTimeStampFromCallbackId() or getCurrentDataTimeStamp() (which take a link identifier as input parameter) for asynchronous links.
| static Int32 tine::TKernel::InitializeServer | ( | ) | [inline, static] |
Initializes the TINE server engine.
This method MUST be invoked for the TINE server engine to function property. Should be called prior to the start of the main TINE server engine. Any deviations from default system parameters should be made before server initialization. This might include server settings which fix the size of the local connection table entries, the maximum date transport size, etc. Note that InitializeServer() will begin allocating space for its connection tables, so modifying these values away from their defaults will have no effect after InitializeServer() has been called. Also, if the FEC Name is given by calling RegisterFecName() then this should also preceed a call to InitializeServer().
| static double tine::TKernel::MakeDataTimeStamp | ( | ) | [inline, static] |
Makes a data timestamp according to the current system time.
| static Int32 tine::TKernel::RegisterDeviceName | ( | String | eqm, |
| String | devName, | ||
| Int32 | devNr | ||
| ) | [inline, static] |
Assigns a device name to the specified device number.
Many servers handle instances of a given device type, such as a set of vacuum pumps, beam position monitors, magnet power supply controllers, etc. It is frequently very efficient to code in terms of device numbers which might be an index into an array, but to specify modules in calls by their human-readable names. For such purposes a device name can be assigned to a number at initialization via a call to RegisterDeviceName() (alias: RegisterModuleName()). An alternative is to provide a startup database file 'devices.csv' containing a cross-reference for numbers and names. Internally, a hash table is maintained for fast lookups inside equipment module routines.
| eqm | The local equipment module name (maximum 6 characters in length) For example: "BPMEQM". |
| devName | Up to 64 characters device name to be assigned |
| devNr | The device number associated with the device name specified. |
| static Int32 tine::TKernel::RegisterFecInformation | ( | String | fecName, |
| String | defaultSubSystem, | ||
| String | defaultContext, | ||
| String | fecDescription, | ||
| String | fecLocation, | ||
| String | attachedHardware, | ||
| String | responsible, | ||
| UInt16 | portOffset | ||
| ) | [inline, static] |
Assigns a FEC Name and descriptive information to the server process.
Servers must be assigned to a Front End Computer (FEC), which for many operating systems corresponds to a process running on the computer rather than the computer itself (meaning there can in some cases be more than one servers with different 'FEC' names running on the same computer. There can be several device servers attached to the same FEC (i.e. sharing the same address space), so the FEC name is a distinct quantity from the device server name (see RegisterExport()), and this name must also be system-wide unique. The call RegisterFecInformation() supercedes RegisterFecNameEx() and RegisterFecName() and differs from them in that it accepts 'Context' and 'SubSystem' as parameters, both of which will be applied to all device servers attaching to the same FEC name. The FEC name can also be (and frequently is) registered via the presence of an 'fecid.csv' startup database file.
| fecName | The FEC name indentifying the Front End Computer and to which all registered equipment modules are bound. |
| defaultSubSystem | The subsystem to which attached device servers belong. Note that the subsystem (unlike context) is itself not part of the name space, although the name space can be queried for device servers belonging to a subsystem. This information is now deduced automatically from the library build. |
| defaultContext | A 32-character string giving the context of all registered equipment modules. (earlier versions of TINE truncated at 16 characters). |
| fecDescription | A 64-character desciption of the FECs server duties. A 'subsystem' can be associated with ALL equipment modules found on the FEC by prefixing the description with a subsystem tag. This information will be parsed by the Equipment name server and used for sub-system specific queries. For example, the associate the FEC "HEPHF" with the subsystem "RF", the description field might be "[RF]Hera Proton HF Control". |
| fecLocation | A 32-character string giving the phyical location of the FEC. |
| attachedHardware | A 32-character brief description of the IO hardware found on the FEC. |
| responsible | A 32-character string listing the developer(s) responsible for the FEC. Note: The Equipment Name Server will allow the removal of FECs and associated equipment modules to the user(s) specified here. |
| portOffset | The 'Port Offset' to be applied to the FEC. This parameter plays an important role where more that one FEC is to run on a machine running an operating system using virtual memory. In such cases 'Front End Computer' is a misnomer, since "FEC" really refers to a process running on the computer to which one or more equipment modules are bound. For operating systems where all processes run in the same address space (such as VxWorks, MS-DOS, Win16, NIOS) there is in fact only one such processes managing all requistered equipment modules. For systems using virtual memory (such as Linux, Solaris, HP-UX, Win32, etc.), you can have many such processes running independently of one another. Since each such process must listen on a unique set of server ports, you must see to it that all such FEC processes are registered with a unique 'Port Offset'. |
| static Int32 tine::TKernel::RegisterPropertyInformation | ( | String | eqm, |
| String | prpName, | ||
| TDataType | dtOut, | ||
| TDataType | dtIn, | ||
| UInt16 | accessMode, | ||
| UInt16 | arrayType, | ||
| UInt16 | rowLength, | ||
| String | prpDescription, | ||
| Int32 | prpId, | ||
| String | redirectionTarget | ||
| ) | [inline, static] |
Assigns pertinent information for the specified property.
Servers export their behavior through Properties, which can be thought of as 'properties' in the Object Oriented sense with Get and Set methods. That is, any read or write access for a given property will call into the associated equipment module and be handled there. The general behavior of the property (including descriptions) can be specified with this call. Properties can also be (and frequently are) registered via the presence of an 'exports.csv' startup database file. Note: Properties which are overloaded can and should be registered more than once with the appropriate characteristics supplied in the registration call.
| eqm | A local equipment module name (maximum 6 characters in length) For example: "BPMEQM". |
| prpName | Property name in question (up to 32 characters, preferably 16 or less). |
| dtOut | Atemplate data object giving the default format size, and structure tag (if any) of the output data set to be returned by the server to the caller. |
| dtIn | A template data object giving the default format size, and structure tag (if any) of the input data set to be supplied by the caller. |
| accessMode | the data 'access' (e.g. CA_READ or CA_WRITE) accepted by the server. This parameter can be used to coerce client-side links into using preferred link attributes. For example, by applying the CA_NETWORK flag (CA_READ|CA_NETWORK) to the access, asynchronous NETWORK (i.g. multicast acquisition) will be enforced at the client side. Applying the CA_XREAD access flag will likewise allow exclusive READ access regarding the registered property (i.e. the same security rules applied to CA_WRITE will be in force for READ acquisitions, either permanently - no CA_READ flag, or temporarily in case of an applied access lock - if both CA_READ and CA_XREAD are applied). Applying the CA_SAVERESTORE flag will apply the internal save-and-restore logic to the registered property (restoring the last property settings upon server startup, and saving any changed property settings). |
| arrayType | Data 'array type' (AT_SCALAR, AT_SINGLE, etc.) associated with the returned data. |
| rowLength | if > 0 gives the row length of the returned array data. This is most relevant for double arrays, where the number of rows is then given by the output data size divided by the row length. |
| prpDescription | The 64-character description of what the property reads or writes. |
| prpId | The property identifier to be associated with the property name returned in calls to GetPropertyId() |
| redirectionTarget | A redirection string, if the property is to be redirected to another server. Most properties are not redirected, and this parameter is usually NULL. If used, it will be parsed according to device server/device name (device property), where the 'device name' and 'device property' are optional. If 'device name' is not present, all devices will be redirected to the specified device server. If 'device property' is not present then the identical property name as registered will be redirected to the device server specified. If on the other hand, the device property is present in the string to be parsed, then the property registered will be redirected to the device server specified as well as to the device property specified. |
| static void tine::TKernel::SetDataTimeStamp | ( | double | timestamp | ) | [inline, static] |
Sets the intrinsic data timestamp to the value given.
This call is typically used inside an equipment function to set the data timestamp associated with the request being made. For instance, when the data are taken from the hardware IO loop, a call to makeDataTimeStamp() is made to get the current system timestamp. Then when a request for data is made the caller can know the precise time of data acquisition. If this routine is not called, then the current system time will be used to stamp the data.
| timestamp | The timestamp to be associated with the next data set. |
| static void tine::TKernel::StartServices | ( | ) | [inline, static] |
Required call for the TINE engine to function property.
On a multithreaded platform (e.g. all .NET implementations) loops around _SystemCycle(). In a single thread environment,e.g., MSDOS blocks the main process.
1.5.8