Various EPICS / LabVIEW Interfaces

1. Various EPICS / LabVIEW Interfaces Alexander Zhukov Beam Instrumentation Group SNS

2. Why one would want LV and EPICS? • Need to add EPICS support (client or server side) to existing instrument controlled by LabVIEW • Develop IOC using National Instruments hardware (cRIO draws more and more attention) • SNS • LANL • Use LabVIEW as multi-platform GUI client • Windows NSTX/PPPL P. Sichta • Linux JLAB Hall D E. Wolin

3. SNS Diagnostics using LabVIEW Total number of LV controlled instruments >300 One instrument = One IOC = One PC Beam Instruments running LV on Windows BPMs BCMs Wire scanners LaserWire stations Video monitors Faraday Cups Emittance scanners … Typical data acquisition rate 1Hz (special DIAG_SLOW event)

4. IOC or CA server? EPICS Way: Records programming Text based or GUI “Do not code, configure” LabVIEW Way: Graphical dataflow programming

5. What options do we have? • Windows shared memory • SNS • National Instruments (with help of Cosylab) cRIO implementation of shared memory (full IOC runs on VxWorks) • LANL • National Instruments CA server shared variable engine extension • Simple Channel Access (SCA) OS specific (exists for Windows and Linux?) • CaLab Windows DLL • BESSY • LabVIEW Native Channel Access for EPICS LANCE • Observatory Sciences • Pure LabVIEW CA (in development) • SNS

6. EPICS shared memory interface* LabVIEW Application (Wire Scanner, BPM,etc) ReadData() WaitForInterrupt() GetIndexByName() Channel Access CreateDBEntry() IOC (database, CA) Shared Memory DLL WriteData() SetInterrupt() DBD and DBD files *ICALEPCS talk by W.Blokland, D.Thompson

7. 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 Tested and relatively reliable solution used for many years at SNS Bad 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 Platform specific (Windows)

8. National Instruments Shared Variables Official NI product (!!!) Ships by default for cRIO with LabVIEW-2010 Has an CA server running behind the scene Dependence on shared variable engine makes it less flexible as desired Additional LV module has to be installed Problems with mass deployment Not portable (no support of Linux or Mac)

9. SNS Pure LabVIEW (8.5+) CA server • Pure LabVIEW implementation using UDP/TCP Vis • Everything within LV – no priority balancing with “alien” process • Supports • ENUM • INT • CHAR • FLOAT • DOUBLE Since last year • Switched to Object Oriented design • No more PV IDs, instead PV object with appropriate for given PV type methods • Naive implementation of standard Map container in LV (no templates/generics in LabVIEW, no standard container support like List, Map etc) • Code became more modular • Local/Remote PV are handled similarly by user API

10. Demo program structure Imitation of MBBI record Server object created, it could be “forked” later Publish Array Put initial value (and publish to CA)

11. Demo server and BOY/CSS as GUI client Special VIs to handle long strings as char[] + JavaScript in CSS

12. One Instrument is running pure CA server in “production” • 16 wires (1 ADC channel per wire) • 500 samples per channel (5MS/s/ch) • 2Hz WF update rate • 10% CPU max • 2 axis motion (slit/harp) • High Voltage control • Two devices hosted in one IOC (4U PC) • Standard scan procedure or custom scans via physics app/script over CA Runs in accelerator network No issues in SNS EPICS environments No anomalous network traffic Seems to be slower than in test network

13. Numbers expected from LV interface • SNS (server side interface) Windows/cRIO/PXI-realtime • ~ 2k PVs • ~ 16 channels x 1k points per second • ~ 30 clients • Under 10 Mbit/s • JLab (client side interface) Linux • 10k PVs • Monitored but rarely updated • LANL • E.Bjorklund’s presentation • Many others want something easy to use to interface small number of channels to EPICS

14. Performance benchmarking • The biggest problem is setting up a test environment and test case • Number of PVs, clients connected, PV update rate, PV (array) size, CPU power form at least 5-dimensional parameter configuration space • Typical numbers: • SNS (pure LV version): one 1k WF at 300Hz/5 clients results in ~ 20% of CPU usage of iMAC with I7 • NI cRIO-9014 (400MHz, 128MB), CA server from NI: 1000 PVs/sec, fastest update rate 2 ms • Generally performance doesn’t seem to be an issue in any of implementation when applied to realistic situations.

15. Summary • Many LV EPICS interfaces exist • There is no ideal one • The need in full featured IOC is the key parameter for selection process • Windows shared memory is still default way at SNS • NI version becomes better • SNS pure LV version is cross-platform and seems to satisfy all needs, but is not finalized yet • One instrument PC-Windows deployed • Three (cRIO) will go in production in Feb 2011 (NI implementation as plan B) • Client side to be ready for testing by December 2010 • If anyone is interested we are ready for accommodating requests since the API is not frozen yet • CA Client is the biggest TODO for nearest future