Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017 
<== Date ==> <== Thread ==>

Subject: Re: Pro's/Con's of LabVIEW/EPICS
From: Scott Baily <sbaily@lanl.gov>
To: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Cc: "Wyman, Max D" <wymanm@purdue.edu>
Date: Wed, 06 Jan 2016 14:22:14 -0700
At LANSCE, we're currently running many vxWorks cRIO systems using LabVIEW/EPICS. These systems run actual EPICS IOCs (not just channel access). Most of these use custom EPICS device support that is specific to our "Industrial I/O" FPGA design. Several other systems use a shared memory interface that has the weaknesses Dirk Zimoch mentioned (also it is vxWorks specific). I'm currently working on an updated AsynPortDriver-based interface. This will permit appropriate error propagation, be a cross-platform solution (support both vxWorks and Linux RT cRIOs as well as Microsoft Windows systems). Using AsynPortDriver means that EPICS records can be set to I/O Intr and process on change. I'm also adding LabVIEW User Event capabilities, so that the LabVIEW program can receive events when certain parameters change. I've demonstrated the basic functionality, and I'm currently in the process of refining the interfaces and then I'll add the rest of the datatypes. The key to this process on Windows and Linux RT is to have the LabVIEW program start the IOC so they are part of the same process. I've already worked out how to ssh to the Linux RT system, and connect to the IOC shell. I'm hoping this solution will be able to replace nearly all of the functionality of the various LabVIEW/EPICS interfaces. For older Pharlap-based PXI crates I suppose the only solution would be channel access written in native LabVIEW (unless EPICS is ported to Pharlap). If I were to update the Industrial I/O interface now, I would probably use existing device support with the C API interface to the FPGA, and bypass LabVIEW on the CPU altogether. However our diagnostics team often prefers to write programs in LabVIEW, and then it is necessary to interface with the LabVIEW program running on the CPU rather than directly with the FPGA.

On 12/17/2015 12:50 PM, Wyman, Max D wrote:
> 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


--
Scott Baily
AOT-IC, MS H820
Los Alamos National Laboratory
Los Alamos, NM 87545
ph: (505) 606-2260

Replies:
RE: Pro's/Con's of LabVIEW/EPICS Mazanec Tomáš

Navigate by Date:
Prev: RE: .template and .db files Mark Rivers
Next: Controls engineer positions at Berkeley Lab Bob Gunion
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017 
Navigate by Thread:
Prev: RE: .template and .db files Mark Rivers
Next: RE: Pro's/Con's of LabVIEW/EPICS Mazanec Tomáš
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017 
ANJ, 15 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·