# Presentation: 676644

## Channel Access Revisited

- 2006
- _[kasemirk@ornl.gov](mailto:kasemirk@ornl.gov)_

## Channel Access

**What is a Channel (Process Variable)?**
**A field in a record. Except when there is no record!**
**What are the properties of a PV?**
**Other fields of the record? Which ones?****What if there is no record?**
**How does CA "find" a channel on the network?**
**Why does it not find your PVs?**
**Why does it find them more than once?**
**How are network interruptions handled?**
**Why does my client fail to reconnect?**

## EPICS Overview

**EDM**

**EDM**

**Client**

**Client**

**Client**

**EDM**

**Server**

**IOC**

**IOC**

**Meter**

**Power Supply**

**Camera**

**IOC**

**Channel Access**

## Internet 101

**The Internet Protocol (IP) consists of UDP and TCP**
**We ignore the very low-level Internet Control & Message Protocol (ICMP).**
**User Datagram Protocol (UDP)**
**Sends a network packet**
**from one port on one computer**
**to one or more ports on one or more other computers.**
**Fast!**
**Checksum: If the packet arrives, it's OK.**
**But not reliable: Packets get lost, arrive out-of-order, arrive more than once.**
**Transmission Control Protocol (TCP)**
**Sends a stream of bytes from one port on one computer to another port on another computer.**
**Reliable: Bytes arrive at the receiver in the correct order.**
**Basically adds serial numbers to UDP packets, ****requesting repeats for missing packages.**
**But slower, and message boundaries get lost:**
**"Hello Fred!" might arrive as "Hel" <pause> "lo F" <pause> "red!"**

## Search and Connect Procedure

**EDM**

**EDM**

**Client**

**Client**

**Client**

**EDM**

**Server**

**IOC**

**IOC**

**Meter**

**Power Supply**

**Camera**

**IOC**

## Search Request

**A search request consists of a sequence of UDP packets**
**Per default: Broadcast to the local subnet.**
**Basically plug-and-play when you get started.**
**Or to IP addresses listed in EPICS_CA_ADDR_LIST**
**Routers do not forward broadcasts!**
**You have to add 'other' subnets or specific IOCs off the local subnet to that environment variable!**
**Starts with a small interval (30 ms)**
**Doubles each time, until reaching 5 second intervals. **
**Stops after 100 packets (~8 minutes) or when it gets a response**
**Wakes again on "beacon anomaly" (details follow later)**
**CA Servers check each search packet**
**Usually connects on the first packet or the first few**
**But non-existent PVs cause a lot of traffic**
**Try to eliminate them**

## Important Environment Variables

**EPICS_CA_ADDR_LIST**
**Determines where to search**
**Is a list (separated by spaces)**
**“****123.45.1.255 123.45.2.14 123.45.2.108”**
**Default is broadcast addresses of all interfaces on the host**
**Works when servers are on same subnet as Clients**
**Broadcast address**
**Goes to all servers on a subnet**
**Example: 123.45.1.255 **
**Use ifconfig –a on UNIX to find it (or ask an administrator)**
**EPICS_CA_AUTO_ADDR_LIST**
**YES: Include default addresses above in searches**
**NO: Do not search on default addresses**
**If you set EPICS_CA_ADDR_LIST, usually set this to NO**

## EPICS_CA_ADDR_LIST

**EDM**

**EDM**

**Client**

**Client**

**Client**

**EDM**

**Server**
**123.45.1.1**

**IOC**
**123.45.2.1**

**IOC**
**123.45.1.2**

**Subnet**
**123.45.2.x**

**Subnet****123.45.1.x**

**Specific**
**123.45.2.2**

**Broadcast**
**123.45.1.255**

**Not Included**

**IOC**
**123.45.2.2**

## Channel Access in One Slide

**CA Server**

**CA Client**

**Process Variables:**

**Channel Access Server**

**S1A:H1:CurrentAO**
**S1:P1:x**
**S1:P1:y**
**S1:G1:vacuum**

**Channel Access Client**

**Who has a PV named “S1A:H1:CurrentAO”?**

**I do.**

**What is its value?**

**25.5 AMPS**

**Change its value to 30.5**

**“****connection request” or “search request”**

**OK, it is now 30.5**

**30.5 is too high. It is now set to the maximum value of 27.5.**

**You are not authorized to change this value**

**Notify me when the value changes**

**It is now ****20.5 AMPS**

**It is now ****10.5 AMPS**

**It is now     ****-0.0023 AMPS**

**“****put” or **
**“****caPut”**

**“****get” or **
**“****caGet”**

**“****set a monitor”**

**“****post an event”**
**or **
**“****post a monitor”**

**“****put complete”**

**or**

**or**

**CA Client**

## Handling of Network Interruptions

**No Network is up 100%, so CA was designed to handle this:**
**TCP connection closed by server?**
**Notify client code about problem**
**EDM screens turn "white".**
**Client sends new search requests.**
**No data nor beacon from server for 30 sec.?**
**Client  sends “Are you there” query**
**If no response for 5 sec, also notify client code, but TCP connection is kept open to avoid network storms.**
**If server eventually sends data: OK. Otherwise we're waiting until the OS cuts the TCP connection (~hours).**

## Beacons

**Assume all is fine, we are connected, but the data simply doesn't change.**
**How do we know the server is still OK?**
**Assume we searched for a PV, didn't get any response for ~8 minutes.**
**How do we learn about a new CA server starting up which might have the missing PV? What triggers renewed search requests?**

## UDP broadcast packet sent by a CA Server
When it is healthy, each Server broadcasts a UDP beacon at regular intervals (like a heartbeat)
EPICS_CA_BEACON_PERIOD, 15 s by default
When it is coming up, each Server broadcasts a startup sequence of UDP beacons
Starts with a small interval (25 ms, 75 ms for VxWorks)
Interval doubles each time
Until it gets larger than 15 s, then it stays at 15 s
Takes about 10 beacons and 40 s to get to steady state
Clients monitor the beacons
Receive beacons: Server is OK.
Receive new beacons at changing intervals: Beacon anomaly, new CA server, reissue searches.

**When it is healthy, each Server broadcasts a UDP beacon at regular intervals (like a heartbeat)**
**EPICS_CA_BEACON_PERIOD, 15 s by default**
**When it is coming up, each Server broadcasts a startup sequence of UDP beacons**
**Starts with a small interval (25 ms, 75 ms for VxWorks)**
**Interval doubles each time**
**Until it gets larger than 15 s, then it stays at 15 s**
**Takes about 10 beacons and 40 s to get to steady state**
**Clients monitor the beacons**
**Receive beacons: Server is OK.**
**Receive new beacons at changing intervals: Beacon anomaly, new CA server, reissue searches.**

- Beacons

## casw - CA Server Watcher 

**Command-line tool in EPICS base**
**Run "casw -i 2"**
**Prints every received beacon**
**For each CA server, expect one every 15 seconds.**
**Marks anomalies with "*"**
**There should be very few,**
**unless you (re)start an IOC,**
**or a faulty clock on a CA server causes it to send irregular beacons,**
**or some network configuration feature causes beacons to arrive multiple times.****	**** **

## Issues

**CA Client does not connect**
**Check basic network connectivity.**
**Can server and client machines 'ping' each other?**
**Check EPICS_CA_ADDR_LIST if server is on different subnet.**
**CA Client does not re-connect after network issue or IOC reboot**
**Use casw. Does the client computer receive the (anomal) beacons of the rebooting IOC?**
**Check EPICS_CAS_BEACON_ADDR_LIST,_x000c_since routers will not forward beacons across subnets.**
**Check if 'caRepeater' is running on the client.**

## caRepeater?

**Older OSs didn't allow multiple programs to listen to the same UDP port**
**They didn't see the beacons (UDP broadcasts)!**
**caRepeater solves this problem**
**There is one caRepeater process per workstation**
**Clients make a TCP connection to it when they start up**
**caRepeater receives the beacons**
**EPICS_CA_REPEATER_PORT****[usually 5065]**
**.. and forwards them to clients.**

-                  Client Computer

- CaRepeater

- EDM

- probe

- ...

- IOC1

- IOC2

- IOC3

## caSnooper

**... ****is an EPICS extension for displaying CA search requests on the network.**
**Use to cleanup EDM screens or IOCs that keep looking for non-existing PVs**
**because of a PV name typo**
**because PV was removed/renamed for a reason **
**Use to check if you non-resolving CA client actually sends out search requests**
**Run caSnooper in the 'target' subnet to see if the search requests reach there.**
**Pam Gurd is the SNS caSnooper expert.**

## caSnooper output

- Not connected, will be C for connected (hardly ever the case)

- Print top 10 (-p10)

- Check top 10 (-c10)

- machine:port, (can be used to identify source)

- name

- search rate in Hz

- statistics

- Two lines from RunCaSnooper

- individual name, prefix

## CA Environment Variables

**CA Client**
**EPICS_CA_ADDR_LIST**
**EPICS_CA_AUTO_ADDR_LIST**
**EPICS_CA_CONN_TMO**
**EPICS_CA_BEACON_PERIOD**
**EPICS_CA_REPEATER_PORT**
**EPICS_CA_SERVER_PORT**
**EPICS_CA_MAX_ARRAY_BYTES**
**EPICS_TS_MIN_WEST**
**See the Channel Access Reference Manual for more information**

**CA Server**
**EPICS_CAS_SERVER_PORT**
**EPICS_CAS_AUTO_BEACON_ADDR_LIST**
**EPICS_CAS_BEACON_ADDR_LIST**
**EPICS_CAS_BEACON_PERIOD**
**EPICS_CAS_BEACON_PORT**
**EPICS_CAS_INTF_ADDR_LIST**
**EPICS_CAS_IGNORE_ADDR_LIST**

## What is a PV (Channel)?

**Whenever there's a CA server out there which decides to respond to a search request, that's a PV!**
**iocCore responds to "{record}.{field}" searches if**
**the {record} is for a record on this IOC,**
**and the {field} is an accessible field of that record,**
**or it's the pseudo-field "RTYP" (record type).**
**So (almost) every field of every record is a PV.**
**But you can implement your own CA server based on the CAS library (for C++), and then you decide when to respond!**
**This used to be important when iocCore only ran on vxWorks, so the 'portable' CAS lib was used to serve data from Linux, Win32, VMS, ...****Now it's probably better to implement device support and run iocCore.**

## Channel Properties

**Each channel comes with properties:**
**Value**
**of type string or double or int or ...**
**Scalar or array**
**Time stamp**
**Up to nanosecond precision**
**Severity code**
**OK, MINOR, MAJOR, or INVALID**
**Status code to qualify the severity**
**OK,  READ error, WRITE error, at HIGH limit, ... **
**units, suggested display range, control limits, alarm limits.**

## Client interface to properties

**The available properties are fixed.**
**One cannot add a new 'color' property.**
**The request types are fixed.**
**"DBR_..." types.**
**Available:**
**Just value.**
**Value with status and severity.**
**Value with status, severity and time stamp.**
**"Everything:" value, units, time, status, limits, ...**
**Not available:**
**Custom combinations like value with units.**

## Records & Fields  vs. Channels & Properties

**A CA client asks for the properties of a channel.**
**The implementer of the CA server decides how to answer.**
**The iocCore implementation maps the fields of a record to the properties of a channel.**
**Details are in the source code for the respective record type. Not always predictable or meaningful!**

## Example: AI record "fred"

**PV "fred" or "fred.VAL"**
**value property of channel = VAL field of record.**
**Type double, one element (scalar).**
**time property ****	****	****= TIME field**
**status ****	****	****	****= STAT**
**Severity****	****	**** ****	****= SEVR**
**units ****	****	****	****= EGU**
**Precision****	****	****	****= PREC**
**display limit low, high****	****= LOPR, HOPR**
**control limit low, high****	****= LOPR, HOPR**
**alarm limits ****	****	****= LOLO, LOW, HIGH, HIHI**
**Makes a lot of sense.**
**EDM can display the value together with units, formatted according to the precision, as e.g. "12.37 volts".**
**StripTool can use display limits for initial Y axis range.**

## Example: AI record "fred"

**PV "fred.SCAN"**
**value property of channel = SCAN field of record.**
**Type enumerated, values: "Passive", "1 second", ...**
**time property ****	****	****= TIME field**
**status ****	****	****	****= STAT**
**Severity****	****	**** ****	****= SEVR**
**units ****	****	****	****= EGU**
**Precision****	****	****	****= 0**
**display limit low, high****	****= 0, 65535**
**control limit low, high****	****= 0, 65535**
**alarm limits ****	****	****= 0, 0, 0, 0**
**Makes some sense, but**
**Units don't really apply to the SCAN field.**
**It's value range is really limited by the available SCAN choices, not 0..65535.**

## Points to remember

**In 99% of the cases, CA "just works"**
**If not, check EPICS_CA_ADDR_LIST**
**If that's not it, there could be a subnet/router issue with UDP search broadcasts and beacons.**
**Channel/property and Record/field are different things!**
**This decouples the CA clients from the IOC database and its record types, allowing EPICS collaborators to share CA client tools for vastly different records and databases.**
**But also means that CA clients have no idea about records nor fields.**
**EDM doesn't know that there might be a "readback" AI that goes with a "setpoint" AO record.**
**The archiver archives channels and their properties, not a whole AI or motor record.**
**Important properties for dealing with waveform data is definitely missing (sample rate, type of data).**

## Acknowledgements

**Material and ideas have been copied from**
**Ned Arnold (APS)**
**Ken Evans (APS)**