From MdsWiki
| Revision as of 18:07, 17 March 2009 (edit) Manduchi (Talk | contribs) ← Previous diff |
Revision as of 18:16, 17 March 2009 (edit) Manduchi (Talk | contribs) Next diff → |
||
| Line 22: | Line 22: | ||
| Based on the type information, MDSplus will then run the constructor of the device, which will in turn build the device-specific subtree. Therefore, the minimum required development for integrating a new device type in MDSPlus is the development of the device constructor. <br /> | Based on the type information, MDSplus will then run the constructor of the device, which will in turn build the device-specific subtree. Therefore, the minimum required development for integrating a new device type in MDSPlus is the development of the device constructor. <br /> | ||
| - | Other methods will carry out the specific device functionality. For example, an ADC device will likely define an INIT method, which will read the information associated with that device instance and will then initialize the Hardware device, and a STORE method, which will be called after the ADC has been triggered, and which will read sampled data and store them in the appropriate data items of the device subtree. | + | Other methods will carry out the specific device functionality. For example, an ADC device will likely define an INIT method, which will read the information associated with that device instance and will then initialize the Hardware device, and a STORE method, which will be called after the ADC has been triggered, and which will read sampled data and store them in the appropriate data items of the device subtree.<br /> |
| + | Typically, in addition to the data items describing the device configuration and the acquired data, an action node associated with each device method is defined in the device subtree. In this way, device methods will be called in the automated sequence based on the action data stored in the pulse file (see the previous section on how setting an automated experiment sequence).<br /> | ||
| + | In order to call the appropriate device methods (and constructor), MDSplus uses a naming convention, bu appending the name of the method to the name of the device type. It is possible to develop the device support routines in native C language, but in this tutorial we shall describe how using scripting languages to develop device methods. Using scripting languages has the great advantage of hiding the internals of MDSplus in the development of MDSplus, and this is the current approach in device support development. The native MDSplus scripting language of MDSplus is TDI | ||
Revision as of 18:16, 17 March 2009
Developing MDSplus Devices
Why Using MDSplus Devices
This section will cover in detail MDSplus devices, an important feature for customizing MDSplus to any target experiment.
So far, we have used MDSplus to store and retrieve data from pulse files, and to set-up automated sequences of operations to be performed during the experimental phases. If this were all the functionality of MDSplus, a lot of work would be required to build a real-world data acquisition system because every hardware device involved in the system would require the development of ad-hoc code for set-up and data retrieval. A software layer for integrating the device in the system would then be required for every kind of used device. If the same device were used somewhere else, however, it would be nice to avoid developing new stuff from scratch by re-using existing code.
In order to ease re-using device-specific code, MDSplus provides a framework for integrating device-specific functionality into the system. Once integrated, the device support code becomes part of the MDSplus system, and can be promptly re-used elsewhere.
This section will explain in detail how define a new device in MDSplus and how to integrate the support code for in the framework so that it can be re-used not only in the same system, but also by every other MDSplus user.
After a first introduction explaining the general concets of MDSplus devices, we shall use a simple test case: a simulated Transient Recorder and will show in details all the steps which are required to integrate such a device.
General Concepts
Every hardware device used in data acquisition requires some associated information. For example, a generic ADC device may require:
- HW Address: the hardware address of the ADC device;
- Sampling frequency: the sampling speed;
- Post Trigger Samples: the number of samples taken after a trigger
In addition to setup information, sampled signals will then be read from the device and stored in the pulse file. In MDSPlus all the information associated with a given device will be stored in a subtree of the pulse file. A different set of nodes, organized as a subtree, will be defined for every device declared in the pulse file, but the structure of such subtrees will be the same for all the devices of the same kind. Borrowing some Object Oriented terminology (we shall see that there are several similarities between objects and MDSplus devices), we define a device instance as the actual set of data items organized in a subtree and bringing all the information associated with the device, and a device type (or class), as the description of the way device specific data are organized, as well as the set of operations (methods) which are defined for that kind of device.
In order to add a device instance to a pulse file (this operation is typically carried out when we are editing the experiment model to be used afterwards in the pulse file creation), it is neccessary to provide to MDSplus the following information:
- The path name of the device subtree root;
- The type of the device.
Based on the type information, MDSplus will then run the constructor of the device, which will in turn build the device-specific subtree. Therefore, the minimum required development for integrating a new device type in MDSPlus is the development of the device constructor.
Other methods will carry out the specific device functionality. For example, an ADC device will likely define an INIT method, which will read the information associated with that device instance and will then initialize the Hardware device, and a STORE method, which will be called after the ADC has been triggered, and which will read sampled data and store them in the appropriate data items of the device subtree.
Typically, in addition to the data items describing the device configuration and the acquired data, an action node associated with each device method is defined in the device subtree. In this way, device methods will be called in the automated sequence based on the action data stored in the pulse file (see the previous section on how setting an automated experiment sequence).
In order to call the appropriate device methods (and constructor), MDSplus uses a naming convention, bu appending the name of the method to the name of the device type. It is possible to develop the device support routines in native C language, but in this tutorial we shall describe how using scripting languages to develop device methods. Using scripting languages has the great advantage of hiding the internals of MDSplus in the development of MDSplus, and this is the current approach in device support development. The native MDSplus scripting language of MDSplus is TDI