-
Notifications
You must be signed in to change notification settings - Fork 2
Patch or hotfix an IOC
To deploy a new IOC to an instrument, or patch an existing one, different levels of care need to be taken depending on what has changed
You do not usually need to deploy a new GUI, in fact it is best to avoid this as you may update other OPIs unintentionally, introducing changes that need updates to IOC that you are not deploying. So go for the minimal change approach if possible:
- keep existing GUI build on instrument
- the directory you will be updating on the instrument will be of the form
C:\Instrument\Apps\Client_E4\plugins\uk.ac.stfc.isis.ibex.opis_1.0.0.4670\resources
and if from your local machine then from somewhere likeC:\Instrument\Dev\ibex_gui\base\uk.ac.stfc.isis.ibex.opis\resources
- copy across just the new/changed OPIs and leave everything else as is
- If adding a new IOC, then you may need to manually edit
opi_info.xml
to add new OPI to ibex list. Do not copy across a newopi_info.xml
as it could refer to things that are not present.
again, change the minimum possible, don't copy a whole tree from the jenkins build server unless you need to. It is usually safer to use a clean jenkins build from kits$
as a basis unless you are really sure your local build is consistent. If you do not need to update the IOC EXE
file in ioc/master
you can probably just copy across the new db files or st.cmd changes etc. Note that we often edit files in e.g. a YYYApp\Db
and YYYApp\protocol
and they get deployed to a top level db
and data
when make is run, IOC normally load these top level ones but copying both sets is safe just in case.
An IOC EXE from ioc\master\MYIOC\bin\windows-x64
depends on DLL files etc in support
and these may change after a developer dependency update to our EPICS repositories, so just copying an EXE from usual EPICS_CLEAN jenkins will not work (c++ libraries expose functions from DLLs, these may change with a new version of e.g. EPICS base or asyn). If you are sure that the dependencies on the build server and instrument were the same, you can just copy a new EXE, but it may be safer to copy a static build of an EXE across as that includes all these DLL dependencies inside the EXE and so is self contained (if a lot larger). If you copy an EXE you should also copy the ioc's dbd
file from the same build e.g. for INSTETC ioc this is copying INSTETC/dbd/INSTETC-IOC-01.dbd
file as well as the INSTETC/bin
EXE files.
So for a new IOC do the following:
- copy the new
support
directory from theEPICS-CLEAN
jenkins build to the instrument e.g.support\stanford_sr400_photon_counter
- copy the
ioc
directory fromEPICS-CLEAN
jenkins build to the instrument e.g. copy all ofioc\master\SR400
- copy the just the ioc EXE files from the
bin
of theEPICS-STATIC-CLEAN
build to replace those you copied fromEPICS-CLEAN
e.g. replace files on instrument inioc\master\SR400\bin\windows-x64
with the files fromEPICS-STATIC-CLEAN
jenkins directoryioc\master\SR400\bin\windows-x64-static
(this will just be replacing exe, if a DLL is present in the original instrument directory don't worry about it) - copy the dbd files i.e. copy all dbd files in
ioc\master\SR400\dbd
fromEPICS-STATIC-CLEAN
jenkins to equivalent location on instrument computer e.g. toc:\instrument\apps\EPICS\ioc\master\SR400\dbd
. We need to copy dbd files as they relate to EPICS records in DLLs that are embedded. We can't copy all of theEPICS-STATIC-CLEAN
tree as some bits have the wrongEPICS_HOST_ARCH
embedded (as in windows-x64-static). So we need to do this hybrid approach.
- on windows you cannot replace an EXE file if it is in use
- The list of IOCs to start is produced by a
start_ibex_server
and it also builds the list of ioc macros that the GUI reads. So you will need to runstart_ibex_server
for a new IOC or changed macros, and may have to restart the GUI after this too.