- Overview
- NDPluginDriver
+ - Guidelines and rules for plugins
- NDPluginStdArrays
- NDPluginFile
- NDPluginROI
@@ -109,6 +110,43 @@
EPICS record type |
+
+ |
+ Information about this plugin |
+
+
+ |
+ NDPortNameSelf |
+
+ asynOctet |
+
+ r/o |
+
+ asyn port name |
+
+ PORT_NAME_SELF |
+
+ $(P)$(R)PortName_RBV |
+
+ stringin |
+
+
+
+ NDPluginDriver
+ PluginType |
+
+ asynOctet |
+
+ r/o |
+
+ A string describing the plugin type. |
+
+ PLUGIN_TYPE |
+
+ $(P)$(R)PluginType_RBV |
+
+ stringin |
+
|
asyn NDArray driver doing callbacks |
@@ -154,23 +192,6 @@
longout
longin
-
-
- NDPluginDriver
- PluginType |
-
- asynOctet |
-
- r/o |
-
- A string describing the plugin type. |
-
- PLUGIN_TYPE |
-
- $(P)$(R)PluginType_RBV |
-
- stringin |
-
|
Callback enable, minimum time, and statistics |
@@ -212,8 +233,8 @@
BLOCKING_CALLBACKS |
- $(P)$(R)CallbacksBlock
- $(P)$(R)CallbacksBlock_RBV |
+ $(P)$(R)BlockingCallbacks
+ $(P)$(R)BlockingCallbacks_RBV
bo
bi |
@@ -364,6 +385,22 @@
longin |
+
+ |
+ N/A |
+
+ N/A |
+
+ r/o |
+
+ Third dimension of NDArray callback data |
+
+ N/A |
+
+ $(P)$(R)ArraySize2_RBV |
+
+ longin |
+
NDPluginDriver
@@ -449,6 +486,29 @@
|
ai |
+
+ |
+ Array attributes |
+
+
+ |
+ NDAttributesFile |
+
+ asynOctet |
+
+ r/w |
+
+ The name of an XML file defining the PVAttributes and paramAttributes to be
+ added to each NDArray by this plugin. The format of the XML file is described
+ in the documentation for
+ asynNDArrayDriver::readNDAttributesFile(). |
+
+ ND_ATTRIBUTES_FILE |
+
+ $(P)$(R)NDAttributesFile |
+
+ waveform |
+
|
Debugging control |
@@ -471,5 +531,46 @@
+
+ Guidelines and rules for plugins
+ The following are guidelines and rules for writing plugins
+
+ -
+ Plugins will almost always implement the processCallbacks() function. This function will be
+ called with an NDArray pointer each time an NDArray callback occurs. This function will normally call
+ the NDPluginDriver::processCallbacks() base class function, which handles tasks common to all plugins,
+ including callbacks with information about the array, etc.
+ -
+ Plugins will generally implement one or more of the writeInt32(), writeFloat64() or writeOctet() functions
+ if they need to act immediately on a new value of a parameter. For many parameters it is normally
+ sufficient to simply have them written to the parameter library, and not to handle them in the
+ writeXXX() functions. The parameters are then retrieved from the parameter library with the getIntParam(),
+ getDoubleParam(), or getStringParam() function calls when they are needed.
+ -
+ If the writeInt32(), writeFloat64() or writeOctet() functions are implemented they must call
+ the base class function for parameters that they do not handle and whose enum value is less than
+ the value of NDPluginDriverLastParam, i.e. parameters that belong to a base class.
+ -
+ Plugins will need to implement the drvUserCreate() function if they have additional parameters beyond
+ those in the asynPortDriver or NDPluginDriver base classes.
+ -
+ Plugins may never modify the NDArray that they receive in the processCallbacks() function. The reason
+ is that other plugins may be concurrently operating on the same NDArray, since each is passed the same
+ pointer. This means also that when getting the attributes for this plugin that
+ asynNDArrayDriver::getAttributes(pArray->pAttributeList) must not be called with the NDArray passed to
+ processCallbacks(), because that will modify the NDArray attribute list, and hence the NDArray that other
+ plugins are operating on. Plugins such as NDPluginROI and NDPluginColorConvert create new NDArrays via
+ NDArrayPool::copy() or NDArrayPool::convert() (which copy the attributes to the new array)
+ and then call getAttributes(pArray->pAttributeList) with the new array. The NDPluginFile
+ makes a copy of the attribute list from the original NDArray before calling getAttributes(), but does not
+ need to make a copy of the NDArray because it does not modify it.
+ - Plugins must release their mutex by calling this->unlock() when they do time-consuming operations.
+ If they do not then they will not be able to queue new NDArrays callbacks or obtain new parameter values.
+ Obviously they must mot access memory locations that other threads could modify during this time, so they should
+ only access local variables, not class variables (which includes the parameter library).
+ -
+ If plugins generate new or modified NDArrays then they must call doCallbacksGenericPointer()
+ so that registered clients can get the values of the new arrays.
+