Managed by UT-Battelle for the Department of Energy LabVIEW Channel Access Implementaion Alexander Zhukov SNS

2Managed by UT-Battelle for the Department of Energy SNS diagnostics We have 200+ devices running on Windows-based IOCs  Beam Current Monitors  Beam Position Monitors  Wire Scanners  Laser Wire  Timing fanouts  and more… The hardware is controlled by LabVIEW (6.1 – 8.5)

3Managed by UT-Battelle for the Department of Energy EPICS shared memory interface* Shared Memory DLL IOC (database, CA) ReadData() WaitForInterrupt() GetIndexByName() WriteData() SetInterrupt() CreateDBEntry() Channel Access LabVIEW Application (Wire Scanner, BPM,etc) DBD and DBD files *ICALEPCS talk by W.Blokland, D.Thompson

4Managed by UT-Battelle for the Department of Energy What is good and not so good? Good  You have full IOC and everything that comes with it (including record processing)  All EPICS tools will work by default Not so good  Can we move on Linux (probably yes, but more effort needed)?  cRIO (could be done as we saw, but not easy)  Need to support 2 infrastructure for EPICS IOC and for LabVIEW program (we can work around, but the bundle is still a little bit ugly)  Deployment is complicated: one has to make sure that 2 different parts (and processes) are behaving

5Managed by UT-Battelle for the Department of Energy What do we actually need?  Not an IOC but CA server (since IOC is used for talking CA only)  To Host about 2000 PVs  To to connect to ~50 CA clients  To provide ~ 10Mbit/s of data transfer  To be compatible with all platforms LabVIEW runs on (Windows,Linux, MAC, compactRIO, LabVIEW RealTime)  We never use record processing Why not implement the CA protocol in LabVIEW? Is it possible? Is it fast? Will it really be “compile once, run everywhere?

6Managed by UT-Battelle for the Department of Energy Pilot project Assess possible CA implementation in LabVIEW  No Repeater  No beacons (do we really need them btw?)  Support UDP channel search  Support two CA types (FLOAT and LONG)  Support DBR_STS and DBR_TIME  Support put/get/monitor

7Managed by UT-Battelle for the Department of Energy Server Structure  Launch UDP listener (for search requests)  Launch TCP listener (for new VC connections)  Launch several “threads” for communication  Launch one (or several) “threads” for message processing  Three queues responsible for data transfer and data locking  VC can be in either processing state or in communication state  “Records” are guarded differently

8Managed by UT-Battelle for the Department of Energy Demo program structure Create PV Put initial value (and publish to CA) Get value from CA Publish Array

9Managed by UT-Battelle for the Department of Energy Linux running CA server

10Managed by UT-Battelle for the Department of Energy Mac OS running CA server (Blokland) CA Server running on Macintosh, display through CAML in Safari

11Managed by UT-Battelle for the Department of Energy NI cRIO running CA server (Blokland)

12Managed by UT-Battelle for the Department of Energy TODO  Full CA types support  Develop simple API (that will be applicable to both local PVs and remote PVs, connected through CA client) and FREEZE them  Support all possible type conversion  Error management (external error logger?)  Performance improvement (we are optimistic here since in works OK for our needs with no optmisation already)  CA client!!!

13Managed by UT-Battelle for the Department of Energy Summary  It worked!  We are able to satisfy our requirements  We were able to get 160Mbit/s (running on PC)  We will proceed and try to have full working version at mid-fall