Re: Pro's/Con's of LabVIEW/EPICS

[Paul Sichta <psichta@pppl.gov>]

Max,

We are running the NI-provided "CA server" on an sbRIO platform,  It is working but I have come across a number of quirks (and work-arounds),, about which NI and I have recently started a dialogue.

We have integrated regular LabVIEW systems with EPICS in  a number of ways over the years.  In our case the interface generally is a few 10's of  PV's at a slow rate.

-ps

On Fri, Dec 18, 2015 at 3:38 PM, David Vine <dvine@lbl.gov> wrote:

Hi Dirk,

I looked into this a little and found this presentation (link below, pg 20) from NI which claims alarm conditions are supported when running the EPICS channel access server under windows with the Labview DSC module. Alarms aren't implemented in on RT architecture.

I should say I've never attempted to interface NI and EPICS so I can't say if the above is true but I am interested in doing so.

ftp://ftp.ni.com/pub/devzone/tut/cots_epics_ni.pdf

Best,
David

On Fri, Dec 18, 2015 at 12:18 AM, Dirk Zimoch <dirk.zimoch@psi.ch> wrote:

Hello Max,

The one point that always annoyed me with LabVIEW/EPICS integrations is the lack of error propagation. While both, LabVIEW and EPICS have their own sophisticated system to propagate errors between records and VIs respectively, usually only the value is passed between the two worlds.

I examined in particular the cRIO implementation of running EPICS and LabView side by side on the same system. Data passing is done with a shared memory region which is accessed by both sides with their own scan rates. Unfortunately there is no synchronization mechanism which would allow to trigger one side when the other one has new values. There is no space for error states, no space for time stamps. Only data. All of this would have been straight forward to implement. All the necessary API functionality is there. It has just not been done.

Looking into the details of the "EPICS-VI" implementation reviles that the VI handles error input, but in an inadequate way: Instead of passing the error, it simply skips to copy new (invalid) data to the shared memory. Thus when a device breaks, EPICS will happily read the last good value. And EPICS will put a current time stamp on the old data. Thus there is no way to see the problem in EPICS.

It has been a few years that I looked at this solution. So it may be that the situation has improved meanwhile. But I was so disappointed that I lost any interest.

Dirk

On 17.12.2015 20:50, Wyman, Max D wrote:

Hello,

I’m investigating the pro’s/con’s of a hybrid LabVIEW/EPICS system for
the control and DAQ on PRIME Lab’s accelerator. We’ll be adding a second
ion source (and requisite controllers) so it seems like a good time to
make such a migration if it seems beneficial.  Currently we use a suite
of LabVIEW applications for control/DAQ of a dozen NI cRIOs, a handful
of NI GPIB-ethernet controllers, and two NI PXI chassis as our
input/output controllers.

In particular, I’m curious to talk to anybody who’s ever migrated a
system from pure LabVIEW to a LabVIEW/EPICS hybrid or who currently runs
an EPICS system involving controllers similar to ours (the NI cRIOs, PXI
crates, and GPIB-ENET controllers).

Thanks,
Max
-----------------------------------------
Max Wyman
PRIME Lab, Purdue University
wymanm@purdue.edu <mailto:wymanm@purdue.edu>
765-496-6894