From MdsWiki
| Revision as of 08:33, 18 March 2009 (edit) Manduchi (Talk | contribs) ← Previous diff |
Revision as of 08:36, 18 March 2009 (edit) Manduchi (Talk | contribs) Next diff → |
||
| Line 26: | Line 26: | ||
| In order to call the appropriate device methods (and constructor), MDSplus uses a naming convention, in which the name of the method is appended to the name of the device type. It is possible to develop the device support methods in native C language, but in this tutorial we shall use a scripting languages to develop such methods. The use of a scripting languages has the great advantage of hiding the internals of MDSplus in the development of device methods, and this is the current approach in device support development. <br />The native MDSplus scripting language of MDSplus is TDI (briefly described in the previous sections), but here we shall use Python for the implementation of the test case device. Python has been recently integrated in MDSPlus: it retains all the advantages of TDI, but provides a much more complete and rugged scripting environment. We expect therefore that python will be used extensively in MDSplus. MDSplus currently supports Python implementation of device methods with the only exception of the device constructor which has still to be written in TDI.<br /><br /> | In order to call the appropriate device methods (and constructor), MDSplus uses a naming convention, in which the name of the method is appended to the name of the device type. It is possible to develop the device support methods in native C language, but in this tutorial we shall use a scripting languages to develop such methods. The use of a scripting languages has the great advantage of hiding the internals of MDSplus in the development of device methods, and this is the current approach in device support development. <br />The native MDSplus scripting language of MDSplus is TDI (briefly described in the previous sections), but here we shall use Python for the implementation of the test case device. Python has been recently integrated in MDSPlus: it retains all the advantages of TDI, but provides a much more complete and rugged scripting environment. We expect therefore that python will be used extensively in MDSplus. MDSplus currently supports Python implementation of device methods with the only exception of the device constructor which has still to be written in TDI.<br /><br /> | ||
| In addition to the constructor and the other methods for interacting with the hardware device, a method will provide the a device specific graphical forms for entering the device configuration in jTraverser. A device configuration is represented by a set of data items which are written in the experiment model and then used during data acquisition. It is possible to write configuration data using jTraverser browsing the device subtree and putting the appropriate value into each data item. However such operation would be lengthy and tedious (very often device subtrees define tens or hundreds of data items). It would be much better to let jTraverser activating a specific form displaying device configuration data in the most appropriate graphical layout, so that data can be easily entered by users during the configuration of the device. <br /> | In addition to the constructor and the other methods for interacting with the hardware device, a method will provide the a device specific graphical forms for entering the device configuration in jTraverser. A device configuration is represented by a set of data items which are written in the experiment model and then used during data acquisition. It is possible to write configuration data using jTraverser browsing the device subtree and putting the appropriate value into each data item. However such operation would be lengthy and tedious (very often device subtrees define tens or hundreds of data items). It would be much better to let jTraverser activating a specific form displaying device configuration data in the most appropriate graphical layout, so that data can be easily entered by users during the configuration of the device. <br /> | ||
| - | This can be achieved by developing a '''Setup''' method, which is then called by jTraverser when requested via the Popup "Setup Device" option. | + | This can be achieved by developing a '''Setup''' method, which is then called by jTraverser when requested via the Popup "Setup Device" option. [[Image:DevicesTutorialSetupDevice.gif]] |
Revision as of 08:36, 18 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 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 necessary 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 execute the constructor method 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, to 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 to configure an automated experiment sequence).
In order to call the appropriate device methods (and constructor), MDSplus uses a naming convention, in which the name of the method is appended to the name of the device type. It is possible to develop the device support methods in native C language, but in this tutorial we shall use a scripting languages to develop such methods. The use of a scripting languages has the great advantage of hiding the internals of MDSplus in the development of device methods, and this is the current approach in device support development.
The native MDSplus scripting language of MDSplus is TDI (briefly described in the previous sections), but here we shall use Python for the implementation of the test case device. Python has been recently integrated in MDSPlus: it retains all the advantages of TDI, but provides a much more complete and rugged scripting environment. We expect therefore that python will be used extensively in MDSplus. MDSplus currently supports Python implementation of device methods with the only exception of the device constructor which has still to be written in TDI.
In addition to the constructor and the other methods for interacting with the hardware device, a method will provide the a device specific graphical forms for entering the device configuration in jTraverser. A device configuration is represented by a set of data items which are written in the experiment model and then used during data acquisition. It is possible to write configuration data using jTraverser browsing the device subtree and putting the appropriate value into each data item. However such operation would be lengthy and tedious (very often device subtrees define tens or hundreds of data items). It would be much better to let jTraverser activating a specific form displaying device configuration data in the most appropriate graphical layout, so that data can be easily entered by users during the configuration of the device.
This can be achieved by developing a Setup method, which is then called by jTraverser when requested via the Popup "Setup Device" option. 