update docs

This commit is contained in:
Michael Davidsaver
2018-03-06 01:02:08 -05:00
parent a22399fdf4
commit 272b4fb9cb
4 changed files with 78 additions and 9 deletions

View File

@ -86,15 +86,15 @@ A full list of `info(Q:group` options.
record(...) {
info(Q:group, {
"<group_name>":{
+id:"some/NT:1.0", // top level ID
+meta:"FLD", // map top level alarm/timeStamp
+atomic:true, // whether monitors default to multi-locking atomicity
+id:"some/NT:1.0", # top level ID
+meta:"FLD", # map top level alarm/timeStamp
+atomic:true, # whether monitors default to multi-locking atomicity
"<field.name>":{
+type:"scalar", // controls how map VAL mapped onto <field.name>
+type:"scalar", # controls how map VAL mapped onto <field.name>
+channel:"VAL",
+id:"some/NT:1.0",
+trigger:"*", // "*" or comma seperated list of <field.name>s
+putorder:0, // set for fields where put is allowed, processing done in increasing order
+trigger:"*", # "*" or comma seperated list of <field.name>s
+putorder:0, # set for fields where put is allowed, processing done in increasing order
}
}
})

View File

@ -38,7 +38,7 @@ PROJECT_NAME = pva2pva
# could be handy for archiving the generated documentation or if some version
# control system is used.
PROJECT_NUMBER = 0
PROJECT_NUMBER = 1.0.1-DEV
# Using the PROJECT_BRIEF tag one can provide an optional one line description
# for a project that appears at the top of each page and should give viewer a

View File

@ -5,11 +5,13 @@
@section qsrv QSRV
QSRV is a network server using the PVAccess protocol which
@ref qsrv_page is a network server using the PVAccess protocol which
runs inside an EPICS IOC process and allows clients
to make requests to access the Process Variables (PVs)
within.
Configuration of @ref qsrv_group_def.
@subsection qsrv_build Building
To build the latest from version control

View File

@ -45,6 +45,73 @@ record(ai, "rec:Y") {
This group, named "grp:name", has two fields "X" and "Y".
@subsection qsrv_group_sym Group PV semantics
@code
$ pvget grp:name
grp:name
structure
epics:nt/NTScalar:1.0 X
double value 0
alarm_t alarm INVALID DRIVER UDF
time_t timeStamp <undefined> 0
...
epics:nt/NTScalar:1.0 Y
double value 0
alarm_t alarm INVALID DRIVER UDF
time_t timeStamp <undefined> 0
...
@endcode
@subsection qsrv_group_ref Group PV reference
@code
record(...) {
info(Q:group, {
"<group_name>":{
+id:"some/NT:1.0", # top level ID
+meta:"FLD", # map top level alarm/timeStamp
+atomic:true, # whether monitors default to multi-locking atomicity
"<field.name>":{
+type:"scalar", # controls how map VAL mapped onto <field.name>
+channel:"VAL",
+id:"some/NT:1.0",
+trigger:"*", # "*" or comma seperated list of <field.name>s
+putorder:0, # set for fields where put is allowed, processing done in increasing order
}
}
})
}
@endcode
@subsubsection qsrv_group_map_types Field mapping types
@li "scalar" or ""
@li "plain"
@li "any"
@li "meta"
The "scalar" mapping places an NTScalar or NTScalarArray as a sub-structure.
The "plain" mapping ignores all meta-data and places only the "value" as a field.
The "value" is equivalent to '.value' of the equivalent NTScalar/NTScalarArray as a field.
The "any" mapping places a variant union into which the "value" is placed.
The "meta" mapping ignores the "value" and places only the alarm and time
meta-data as sub-fields.
The special group level tag 'meta:""' allows these meta-data fields to be
placed in the top-level structure.
@subsubsection qsrv_group_map_trig Field Update Triggers
The field triggers define how changes to the consitutent field
are translated into a subscription update to the group.
The most use of these are "" which means that changes to the field
are ignored, and do not result group update.
And "*" which results in a group update containing the most recent
values/meta-data of all fields.
It may be useful to specify a comma seperated list of field names
so that changes may partially update the group.
*/