Re: LabView interface to EPICS

[Scott Baily <sbaily@lanl.gov>]

On 9/19/2013 2:26 PM, Emmanuel Mayssat wrote:
> While investigating high-level framework for EPICS, I came across the
> following page
> http://digital.ni.com/public.nsf/allkb/BEF3C387D96E1A0C86257A3600508278
>
> Is any one using LabView with EPICS?
> What are the benefit of such a setup?
> What are the drawbacks?

I use EPICS and LabVIEW together for several different projects.  I have 
never used the setups discussed there.
From what I can think of quickly:
The benefits of such a setup are that NI should be able to support you 
easily if you have problems, and you can do all of your development with 
LabVIEW.
Existing LabVIEW programs can be quickly integrated into the control system.
The drawbacks are:
You do all of your development in LabVIEW.
You don't have a full EPICS database.

There are several other ways of interfacing between EPICS and LabVIEW.

The setup I've used both on cRIO (vxWorks) and win32, is to have a 
shared library that can store and retrieve information from memory. 
Then, I use a full EPICS IOC with device support that calls the shared 
library, and a LabVIEW program that also calls the shared library.
Advantages:
Fully functional EPICS IOC, including EPICS applications.
EPICS database development is done the same as always.
You can divide the workload between EPICS and LabVIEW however you want, 
sort of like interfacing EPICS with a PLC, but more flexible.
Existing LabVIEW programs can be quickly integrated into the control 
system in a standard manor.
No OS specific code (except for mutex and initialization code the shared 
library).
Disadvantages:
Must keep "hardware address list" and any enumerated types that are used 
in sync between EPICS and LabVIEW.
On Win32, LabVIEW must start the EPICS IOC so that they run in the same 
process.
I use to different interface libraries, one is very specific to our 
industrial I/O project, and uses LabVIEW for FPGA development and 
passing data between device-specific EPICS device support and the FPGA.
see:
http://accelconf.web.cern.ch/accelconf/icalepcs2011/papers/thaaust01.pdf

The other uses very generic EPICS device support, and everything is 
either done by LabVIEW or the EPICS database. This is particularly 
useful for diagnostic devices.
> Is LabVIew only only to configure the FPGA?
> Or is LabVIew also used to control the FPGA (I/O), i.e. interact
> with PVs ?

	There are always 2 LabVIEW programs, one generates the VHDL that runs 
on the FPGA.  This code looks essentially like LabVIEW code for a CPU, 
but with a more restrictive set of functions (e.g., no dynamic arrays). 
Also, the technique to obtain the best performance is a bit different.
	For the industrial I/O a very simple LabVIEW program runs on the CPU 
that simply passes data between the FPGA and EPICS via a memory block 
allocated by the shared library. This program only knows about the data 
headers, and thus rarely need to be modified.
	For diagnostic devices, the LabVIEW code really does control functions 
of the kind that might otherwise require state notation language as well 
as analysis functions.

> If that's the case, do you use Labview GUIs that interact with
> multiple EPICS devices or IOCs?
> (That is can labview GUI be used as a replacement for edm/BOY/etc?)

We do not use LabVIEW GUIs in the control system, although it is 
possible to do. Using the EPICS client for LabVIEW that you mentioned, 
one could make a LabVIEW GUI that used channel access to interact with 
PVs. LabVIEW could be used to write custom applications where one might 
otherwise use Java or TCL/TK. This would not be a replacement for 
EDM/Boy/caQTdm, because you'd be changing your LabVIEW program each time 
you changed the GUI.
--
Scott Baily
AOT-IC, MS H820
Los Alamos National Laboratory
Los Alamos, NM 87545
ph: (505) 606-2260

Correspondence