Running IOC Core on Windows and Linux

1
Running IOC Core on Windows and Linux

• Dave Thompson
• Wim Blokland
• Ernest Williams

2
Windows

• IOC Core-Channel Access is a more stable
  combination than an Active X server or any user
  program poorly using the CA API.
• Using IOC Core allows use of Epics DB tools and
  better configuration control of PVs exported to
  Channel Access.
• IOC core does not seem to add much overhead to
  the overall application.
• New version supports bi-directional PVs for bo,
  longout, and ao.

3
The concept
LabView Application (wire scanner, BPM,etc)
Shared Memory Interface VIs
LabVIEW Application (Wire Scanner, BPM,etc)
ReadData() WaitForInterrupt() GetIndexByName()
Channel Access
CreateDBEntry()
IOC (database, CA)
Shared Memory DLL
WriteData() SetInterrupt()
DBD and DBD files
4
Implementation With LabView

• LabView and IOC core link to a shared memory DLL.
• Data flows in both directions through the DLL.
• The DLL passes data through a FIFO to decouple
  CPU allocation between the LabView process and
  the IOC Core process, this reduces data loss.
• Shared memory passes both data and processing.
• Time stamps are passed through the shared memory
  with processing requests.
• LabView starts IOC core and passes the startup
  file name on the command line.

5
Database Issues With Shared Memory

• LabView and the IOC Core database expect to work
  from the same shared memory layout.
• The shared memory device support routines create
  the database in shared memory from parameters in
  the .db file.
• Shared memory PVs have name, type and size
  attributes.
• Registry entries set shared memory allocation and
  ring depths.
• The LabView application binds to PVs in the
  shared memory database and does not attempt to
  create them.
• The Epics database can be created by LabView
  based on Vis that interact with the shared
  memory, Epics database tools, or by the SNS
  database RDB tools.

6
Linux

• At SNS we have a few applications running on
  R3.14.1 IOC core on a Linux server.
• NO device or record support implemented except
  standard Soft Channel.
• Running some sequencer programs in the IOC
  program.
• Mostly used as a PV server and a place to put
  calc records and or alarms for summaries.
• We want to have to have the ability to run
  etherIP and the serial devices.

7
Applications On the Linux IOC Core

• Timing Scope application
• Reads PVS out of the timing system and calculates
  gate waveforms relative to other waveforms from
  controls and diagnostics.
• Allows the operators to visualize the timing.

8
Applications

• Status PVs from IOCs and server based processes.
• These PVs are driven by periodic tasks that write
  to the PV via channel access. OPI and archive
  servers monitor the PVS.
• Health of IOCS and archive tasks are collected
• Ping tasks monitor UP status of both IOCs and
  servers.
• No device support, all updates are made by CA
  clients.

9
The setup
CA Client Application On Linux Box
Many PVs from accelerator
PvServer Application On Linux Box
Terminal Server
epicsgt epicsgt dbpr GlobalArchiveEngine1Status A
SG DESC DISA 0
DISP 0 DISV 1
NAME GlobalArchiveEngine1Status RBV 0
RVAL 0 SEVR NO_ALARM
STAT NO_ALARM TPRO 0 VAL 0

User at IOC Shell
10
Startup and operation of the IOC

• We run the IOC as a service in inittab, like a
  getty.
• Inittab keeps it running at all times.
• Startup goes in three stages

• Stage 1 New lines in inittab
• Epics pvServer service on port ttyS1
• S12345respawn/etc/epics/su-tty ttyS1
• Stage 2 su-tty, redirect IO and set user
• /bin/sh
• (stty sane
• su - thompson -c /home/thompson/pvServer/startPvS
  erver
• )gt/dev/1 2gt/dev/1 lt/dev/1

11

• Stage 3 The startup script
• Sets up the EPICS environment
• Sets PATH and LD_LIBRARY_PATH
• Starts caRepeater
• Starts the application in TOP
• Cleans up lingering threads after an exit
• Depends on init to reboot the IOC
• cd TOP
• caRepeater gt/dev/null 2gt1 lt/dev/null
• pvServer iocBoot/iocpvServer/st.cmd
• Kill all threads of the pvServer exit
• for i in /bin/ps h o pid -C pvServer do
• kill -s SIGKILL i
• done

12
Problems and Plans

• Could not get auto save and restore to work,
  problem related to mutex locking?
• Want to implement IOC name to RTDL reset code
  lookup in a sequencer running here (part of the
  timing system).
• Plans to port to 3.14.2 next week.