KAGRA VIS Operations Manual - Developing models in Simulink

Back to Operation Manual main page

Software running on front end computers is written in Simulink per T080135 AdvLigo CDS Realtime Code Generator (RCG) Application Developer’s Guide.

Simulink models live in the userapps repository, which by convention is checked out as /opt/rtcds/userapps. VIS models can be found at

Only certain computers (k1boot) are configured for building models from the Simulink source - they also have the appropriate release of the rtbuild system linked to as

and rtbuild knows to look in userapps for models.

Models currently running

The most recent rebuild of each Simulink model is archived at one of the following locations and can be accessed from outside the CDS network with ligo.org credentials:

Building models

  1. Get advice from the CDS system manager (Miyakawa-san) on what other parts of the CDS system are likely to be affected. For example:
    1. Restarting a VIS model may interfere with commissioning of the physical suspension, or the ISI that it is on, or the beam path that it is a part of.
    2. Restarting a VIS model may interfere with SEI or ISC models that receive IPC signals from it.
    3. If new channels are to be added, it may be necessary to restart the DAC, which is disruptive to people needing trend data.
  2. Check with users who may be working on the suspension or may be otherwise affected and confirm that it is OK to proceed.
  3. Open a work permit and get all necessary signoffs.
  4. Open a fresh terminal window and log into a build machine (k1boot, etc).

    $ ssh controls@k1boot
  5. Go to the build directory for the most recent release of rtcds.
    $ cdscode % cd /opt/rtcds/kamioka/k1/rtbuild/current
  6. Do a make with the model name less .mdl:

    $ make k1vispr3
  7. Diagnose and correct any errors. If the model depends on IPC from other models that have not yet been compiled, compile those at this point and try again.
  8. Do a make install- with the model name less .mdl:

    $ make install-k1vispr3
  9. Open the CDS Overview screen, and identify the computer that runs the model.
  10. Click on the associated button to open the GDS TP screen for the model.
  11. Also open the main control screen for the suspension.
  12. Let potentially affected users know that the model is about to be restarted and check that this is still OK.
  13. Alert the operator that you are about to restart a model, and which one, so that the alarm generated in the next step does not come as a surprise.
  14. Open a second fresh terminal window and log into the front end that is to run the model and (re)start the model from the newly compiled version.
    $ ssh k1pr0
    $ startk1vispr3
  15. Check that the GDS TP screen and the main MEDM screen for the suspension go white briefly and then recovers after a few tens of seconds.
  16. As soon as the GDS TP screen recovers, click the BURT button.

  17. Check that the line for the model on the CDS Detailed Overview screen goes white briefly and then recovers (this normally takes a few tens of seconds longer to come back than the MEDM screen for the suspension).
  18. Check that the terminal window says that the safe.snap file has been loaded.

  19. If the safe.snap file is not known to be up to date, open a third fresh terminal window (on one of the ops workstations) and, without logging onto anywhere else, load a more recent BURT snapshot, e.g., the most recent hourly backup:

    $ burtrestore k1vispr3epics 09:00
  20. If you have added new channels to the model, check with DGS staff (Miyakawa-san et al.) open yet another terminal window and restart the DAC:
    $ ssh k1dc0
    $ ps -ef | grep daqd
    $ kill nnnn # nnnn=process number of the daqd.dc process as revealed by the previous command
  21. If everything looks OK on the MEDM screen for the suspension, reenable the master switch, the watchdogs and the damping.
  22. On the CDS Detailed Overview screen, press the [DR] button to clear any transitory errors, and debug any that persist.

  23. When all looks OK, close the work permit and do an alog describing the changes.

Inserting SVN revision numbers

Note that Simulink models can have a macro string in a text box which inserts the SVN revision number when the model is compiled, so it can be displayed later and serve as documentation of which revision was most recently compiled (this is usually the one running). See InsertingSvnVersionStringIntoSimulinkModels.