Table of Contents
This plugin provides the basic APIs for accessing live control system data, i.e. read process variable samples from front-end computers. Its emphasis is on fairly straight-forward access to individual PVs, using a listener for received updates.
The org.csstudio.vtype.pv plugin defines
the API for accessing PVs, an extension point to implement
such PVs, and a PVFactory to access available
implementations.
Typical usage looks like this:
// Create PV
PV pv = PVPool.getPV("some_pv_name");
// Register listener for updates
pv.addListener(new PVListenerAdapter()
{
@Override
public void valueChanged(final PV pv, final VType value)
{
System.out.println(pv.getName() + " value changed to " + value);
}
});
// Fetch most recent value
System.out.println(pv.read());
// Write a value
pv.write("6.28");
// Stop using the PV
PVPool.releasePV(pv);
The VType-derived data objects contain
not only a basic value, i.e. number or string,
but also a time stamp, status/severity information
and in most cases meta data.
The meta data provides information for display tools:
value range, alarm limits, units, or strings that represent the states
of enumerated PVs.
The plugin org.csstudio.vtype.pv defines an interface
for accessing live control system data.
The archive engine for example uses that library for subscribing to value updates from PVs
that you want to archive.
The utility.pv plugin also contains implementations
for EPICS Channel Access, EPICS pvAccess, local PVs and simulated PVs.
To associate PVs with an implementation, a prefix is used,
for example
sim://sine for a simulated PV “sine” or
ca://fred for a Channel Access PV “fred”.
The plugin has a preference setting to specify a default
prefix, which is usually set to the control system protocol.
In that case, simply specifying a PV name of fred
will also select ca://fred.
EPICS Channel Access is the original EPICS Version 3 protocol.
Note that the Channel Access settings like the CA server address list
are configured from Eclipse properties defined
in the plugin org.csstudio.platform.libs.epics.
The libs.epics settings also include the subscription mode:
The EPICS implementation attempts to read the DBR_CTRL_...
meta data for each PV once on connection.
EPICS IOCs will fill the meta data based on certain record
fields like EGU, PREC, HIHI, depending on the record type.
The PV plugin then subscribes to the DBR_TIME_... type of the channel.
This way the full meta data of the channel is known and can be returned
with each value, while the network traffic for the subscription updates
is reduced to the essential time, status and basic number or string.
This procedure is quite common for EPICS client tool, but has the
disadvantage that runtime changes to the meta data will not be noticed
unless the client disconnects and then re-connects, since the full meta
data is only obtained upon channel connection.
Check the EPICS CA address list. Try to access the same PV
with the EPICS caget command-line tool.
Compare the EPICS_CA_ADDR_LIST environment variable used by the
command-line tool with the CSS preference for the address list.
Channel Access uses a
caRepeater
to monitor beacons from CA servers.
If you run CSS without a CA repeater, you might see error messages
failed to start executable - "caRepeater" Cannot find the file
This error means: You have not started a CA repeater on the computer where you run CSS. In practice, CSS will work just fine most of the time. In case of network errors or IOC reboots, however, it might not re-connect to some PVs after the network or IOC problem should have been resolved until you re-open the affected tools.
In an operational control room setup, you should assert that all computers launch an instance of the EPICS caRepeater on bootup.