IOC Deployment and Troubleshooting

This repo contains instructions for Session 2 of the Practical Beamline Controls Training.

Warnings

This training was designed to be completed using an APS-maintained Red Hat Enterprise Linux (RHEL) computer.

• The instructions and solution branch assume that synApps was deployed on a path beginning with /APSshare, which is incorrect for non-APS computers.
• There will be additional errors when the IOC runs due to missing synApps modules. The instructions do not address these errors.
• It is assumed that the non-APS computer already has the necessary prerequisites for building EPICS base.

Outline

1. Setup
2. Deploy a new IOC
3. Add simulated motors to the IOC
4. Deploy the motorVMC (Virtual Motor Controller) module
5. Add virtual motors to the IOC
6. asyn troubleshooting

Quickstart

The external quickstart script is much less useful on non-APS machines.

To use the script, do the following:

$ curl -O https://git.aps.anl.gov/practical_beamline_controls_training/session_2/instructions/-/raw/external/scripts/quickstart.sh
$ chmod a+x quickstart.sh
$ ./quickstart.sh

Then copy and paste the output from the script into the terminal and proceed to step 1.2.

FAQ

Will I need to execute any cd commands that aren't explicitly documented in the instructions?

No. You should only change directories when instructed to. If you find yourself tempted to execute a cd command that isn't documented, resist that urge; it will cause later commands to fail.

Why isn't mkioc used to create the training IOC?

mkioc renames files and directories (references to xxx are replaced with the desired IOC name). This makes it impossible to have a solution branch in the git repo that works for everyone.

How does the training IOC differ from one created with mkioc?

There will be fewer build errors when building an IOC created by mkioc.

The training IOC required some customization to allow the IOC's prefix to be overridden:

• st.cmd.Linux sources override.iocsh, which overrides the default IOC prefix, xxx:, without requiring settings.iocsh to be edited.
• the caQtDM (and MEDM) start scripts open my-xxx.ui (and my-xxx.adl) instead of xxx.ui (and xxx.adl)
• A newPrefix.sh script was added to simplify the creation of override.iocsh, my-xxx.ui and my-xxx.adl

Should I deploy beamline IOCs based on the training IOC?

No. Just use mkioc.

Can I complete this exercise on a computer other than an APS-maintained RHEL computer?

Yes, in theory, but it requires building a local copy of EPICS base and a subset of synApps. It is likely other problems will be encountered.

Why does the solution branch use ~ instead of /home/beams/USERNAME in the solution branch?

The solution branch uses ~ instead of /home/beams/USERNAME in paths because it was the only way to make the solution branch build for everyone without requiring files to be edited.

The use of ~ is highly discouraged; only absolute paths should be used in RELEASE files. A negative side effect of using ~ in the path to MOTOR_VMC in the IOC's RELEASE file, is that MOTOR_VMC doesn't appear in the IOC's envPaths file. This wasn't a problem during the training becase the IOC doesn't load anything from the motorVMC module at runtime.

The solution branch

The use of the solution branch is not recommended for non-APS computers.

When an APS computer is used, both the xxx and motorVMC repos have a solution branch with tags for each step that:

• allows you to run all the commands in this training without editing a file in a text editor.
• enables jumping to a specific section

Note: the motorVMC module is only modified in section 4, so the only tags it has for later sections are 5.1 and 6.1.