EPICS on CompactRIO - PowerPoint Presentation by decree

VIEWS: 119 PAGES: 14

									Running EPICS on NI CompactRIO
       Initial Experience

           Eric Björklund

What is CompactRIO?
                      • Power-PC based Real Time
                        Controller (RTC).
                      • FPGA Backplane
                      • Connected via PCI bus
                      • Designed for harsh

                      • Fast PLC
                         – Sec vs. mSec Response
                      • Programmed in LabVIEW
                        instead of Ladder Logic
                         – Both FPGA and RTC are
                           programmed in LabVIEW
Advantages to Running EPICS IOC on CompactRIO

• Faster and more deterministic data acquisition and control
   – No intermediate ethernet hop (as with EtherIP)
   – Could consider EPICS closed loop control
• Flexibility
   – Application can be partitioned between LabVIEW and EPICS
     whichever way makes the most sense.
• FPGA runs independently from Power PC
   – Critical system functions can survive soft reboot.
  What does it take to run EPICS IOC on CompactRIO?

• Real Time Controller (RTC) is a Power PC (ppc603) running
  vxWorks (6.3)
• vxWorks license not required!
   – NI has permission to distribute the vxWorks header files
• Began working on project in late 2007
• National Instruments, LANSCE, and Cosylab collaboration
• Cosylab Provided:
   – Custom version of cRIO BSP that included NFS and Telnet
   – Shared memory library similar to the SNS LabVIEW/EPICS shared
     memory interface.
• EPICS runs at lower priority (100-199) than LabVIEW (10-100)
 What do you need to run EPICS on CompactRIO?
• EPICS-Enabled vxWorks BSP for the cRIO (Cosylab/NI)
• LabVIEW 8.6.1 (although we use 8.5.1 for our prototype system)
• vxWorks header files (NI can supply)
   – vxWorks 6.3 for LabVIEW 8.5.1 vxWorks 6.6 for LabVIEW 8.6.1
• Configuration files (if you aren’t running the same version of
  vxWorks as the cRIO)
   – We copied the “ppc603_long” configuration files and pointed them
     to the vxWorks 6.3 headers.
       •   CONFIG.Common.vxWorks-cRIO
       •   CONFIG_SITE.Common.vxWorks-cRIO
       •   CONFIG_SITE.linux-x86_64.vxWorks-cRIO
       •   CONFIG_SITE.linux-x86.vxWorks-cRIO
       •   CONFIG_SITE.win32-x86.vxWorks-cRIO
• Shared Memory Library (actually two librarys)
    Shared Memory Library – Two Parts
    The LabVIEW Part                              EPICS Part
•    vxWorks only (no EPICS calls)            •    EPICS Device Support Layer
•    Allocates and manages shared
     memory resources                         •    Interfaces to LabVIEW library for
                                                   access to shared memory resources.
•    Interfaces to LabVIEW through
     “Call Library Function Node” VI’s        •    Built into the EPICS application and
•    Lives on RTC’s non-volatile RAM               loaded over the network with the
     disk.                                         EPICS application code.
•    Automatically loaded when the            •    EPICS database records not
     RTC VI that references it is run.             automatically created (as with SNS
•    Two forms:                                    system)
      –   vxWorks shared library (.out) for
          run-time (munch file works fine)
      –   Windows .DLL for compile time
          (this can be just a stub)
Shared Memory Interface (as seen from LabVIEW)
                                  • Get Command Setpoints from EPICS
                                  • Send Command Setpoints to FPGA

                                  • Get Readback Data From FPGA
                                  • Make Readback Data Available to EPICS
LabVIEW “Driver” (FPGA Code) – 16 Channel ADC
                           • Store packed data in
• Read ADC   • Pack data     buffer to be transmitted   • Store hardware status word
  Channels                   up to the RTC

• Already have one “Proof of Principle” application in
  production (2 binary channels).
• This shutdown we tried our first non-trivial application.
• Replace one accelerator module’s “Industrial I/O” channels
  with cRIO.
   –   12 binary outputs
   –   36 binary inputs
   –   12 analog inputs
   –   5 stepper motor channels
• Replaces two Control Logix crates with one cRIO
• Basic SCADA
   – No closed loop. No exotic timing. But….
   – System must emulate our 1960’s vintage “RICE” system.
     Things We Learned
•   FPGA is faster than Ladder Logic
     – PLC had not been fast enough to implement our “Dual Energy” binary
       channels. cRIO handled them without a problem.
•   FPGAs are not computers
     – Run-time bindings we have come to rely on in
       conventional programming (including LabVIEW)
       can not be done in FPGA
     – This is particularly true of I/O to the cRIO modules.
     – This code can not be implemented with a loop.

•   Three million gates doesn’t go as far as you might think
     – Entire application did not fit on Virtex 2 FPGA
     – Used two cRIOs, one for binary and one for analog/stepper motor
     – Binary I/O took 99% of FPGA (2 slices left).
     – Expect newer models with Virtex 5 FPGA could hold entire application.
Other Things We Learned

• National Instruments and Cosylab were VERY helpful in
  getting us to this point.
Current Status

• Binary I/O cRIO is installed and running in the production
• Ran out of time before startup to install analog cRIO
• Binary I/O cRIO is installed and in checkout
   – Final Bug chased down today……
And then……

• Site-wide fire alarms went off…..
• Stay tuned for further developments:
   – ICALEPCS 2009
   – NI Big Physics Symposium
National Instruments Support for EPICS

• EPICS IOC – LabVIEW integration on cRIO available on

• Native Channel Access (CA) server in LabVIEW
   – Can run on both NI CompactRIO and PXI platforms

To top