<?xml version="1.0" encoding="UTF-8"?>
<!--
@file netvarconfig.xml Example NetShrVar driver configuration file. Loaded at IOC boot time in @link st.cmd @endlink via e.g.
@author Freddie Akeroyd, STFC ISIS facility, UK (freddie.akeroyd at stfc.ac.uk)
$LastChangedRevision$:
$LastChangedBy$:
$LastChangedDate$:
$HeadURL$:
-->
<netvar
xmlns="http:
xmlns:xsi="http:
xsi:schemaLocation="http:
<!-- this name will be mapped (via
NetShrVarConfigure()) to an asyn driver port name that can then be specified in an EPICS db record -->
<section name="sec1">
<!--
<param> defines as asyn driver parameter "name" that can be specified in an epics record to access data.
"access" is a comma separated list of how the shared variable is accessed:
R (reader), BR (buffered reader), SR (single reader), W (writer), BW (buffered writer)
"type" is the asyn parameter type - single values need not be identical to the shared variable type, but
must be compatible (i.e. numeric if shared variable is numeric). Array types must match
in data type size, but need not match in signedness (EPICS does not have
unsigned types). Valid values are: int32, float64, boolean, string, float32array,
float64array, int8array, int16array, int32array - see @link NetShrVarConfig.xsd @endlink
"netvar" is the path to the shared variable - you can use / rather than \
"fval" and "tval" are only used for boolean type, they are the strings to be displayed for false and true values
"field" is only used for a structure type network shared variable, it indicates the structure element to access.
-->
<param name="cont1" type="float64" access="BR,BW" netvar="
<param name="icont1" type="int32" access="R,W" netvar="
<param name="ind1" type="int32" access="R,BW" netvar="
<param name="ind2" type="int32" access="SR" netvar="
<param name="strcont1" type="string" access="BR,BW" netvar="
<param name="bool1" type="boolean" fval="off" tval="on" access="BR,BW" netvar="
<!-- a timestamp parameter is a string with the timestamp, however if TSE=-2 the the update time of the variable
is equal to the value of the timestamp rather than when the shared variable was updated
the shared variable type it redrences should be an array of unsigned 64bit integer -->
<param name="tstamp" type="timestamp" access="R" netvar="
<!-- an ftimestamp if like a timestamp but a float64 of seconds since epics epoch -->
<param name="ftstamp" type="ftimestamp" access="R" netvar="
<!-- if we specify a "ftimestamp" or "timestamp" type variable in the ts_param option, then this parameter will be used
to set the timestamp on the shared variable. The ts_param must refer to a parameter name already
defined earlier in the XML -->
<param name="arrayU16" type="int16array" ts_param="ftstamp" access="R,W" netvar="
<!-- if we specify with_ts we mean the 128bit timestamp is embedded in the first few array elements. So for a double
array this is two elements. This should be a straight cast i.e. no conversion, see example.vi
I am not sure of we will get endian issue, but as double and int64 are same size this may get
sorted out automatically -->
<param name="arrayDble" type="float64array" access="R,BW" with_ts="true" netvar="
<!-- CVI is not able to read a labview waveform data type, so a variant or structure/cluster must be used instead in labview
and a network variable of type variant created in either case -->
<!-- fields in a structure need to be indexed by number not name, this is the cluster order index
if you use "reorder controls in cluster" option for cluster in labview, you can see the
field index to use, index starts at 0
The whole shared variable structure updates at the same time, so you do not need to subscribe to
it for every item that reads a field. For example both struct_dt and struct_Y refer to the same
network variable (but different fields) so only one item referring to the shared variable
(struct_dt in this case) needs to subscribe (access="R") and the other will get updated at the same time.
when a structure field is written via a epics PV it is necessary to read the whole structure, update field, write back.
this means that if two PVs referring to different fields in the same structure are written to simultaneously there
is potential for one overwriting the other with an old value.
You can also use ts_param to refer to a structure member to be used for PV timestamp. As the whole structure
shared variable is read at the same time, this may provide better synchronisation between timestamp and
data - you can refer to a separate shared variable outside the structure, but you may not be guaranteed the
variable for this timetamp is always updated in sync with the data variable.
-->
<param name="struct_dt" type="float64" access="R" netvar="
<param name="struct_ta" type="ftimestamp" access="" netvar="
<param name="struct_Y" type="float64array" access="" ts_param="struct_ta" netvar="
<param name="struct_extra" type="float64" access="R,W" netvar="
<param name="struct_extra_array" type="float64array" access="R,W" netvar="
</section>
</netvar>
1.8.5