Managed by UT-Battellefor the Department of Energy

Various EPICS / LabVIEW Interfaces

Alexander Zhukov

Beam Instrumentation Group

SNS

2 Managed by UT-Battellefor the Department of Energy

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

Why one would want LV and EPICS?

3 Managed by UT-Battellefor the Department of Energy

SNS Diagnostics using LabVIEWTotal 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 Managed by UT-Battellefor the Department of Energy

IOC or CA server?

EPICS Way:

Records programming

Text based or GUI

“Do not code, configure”

LabVIEW Way:

Graphical dataflow programming

5 Managed by UT-Battellefor the Department of Energy

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 Managed by UT-Battellefor the Department of Energy

EPICS shared memory interface*

Sha

red

Mem

ory

DLL

IOC(database,

CA)

ReadData()

WaitForInterrupt()

GetIndexByName()

WriteData()

SetInterrupt()

CreateDBEntry()

ChannelAccess

LabVIEW Application

(Wire Scanner,BPM,etc)

DBD andDBD files

*ICALEPCS talk by W.Blokland, D.Thompson

7 Managed by UT-Battellefor 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

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 Managed by UT-Battellefor the Department of Energy

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 Managed by UT-Battellefor the Department of Energy

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 Managed by UT-Battellefor the Department of Energy

Demo program structure

Server object created, it could be “forked” later

Put initial value(and publish to CA)

Imitation of MBBI record

Publish Array

11 Managed by UT-Battellefor the Department of Energy

Demo server and BOY/CSS as GUI client

Special VIs to handle long strings as char[] + JavaScript in CSS

12 Managed by UT-Battellefor the Department of Energy

One Instrument is running pure CA server in “production”

Runs in accelerator network

No issues in SNS EPICS environments

No anomalous network traffic

Seems to be slower than in test network

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

13 Managed by UT-Battellefor the Department of Energy

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 Managed by UT-Battellefor the Department of Energy

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 Managed by UT-Battellefor the Department of Energy

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