40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log  Not logged in ELOG logo
Message ID: 11130     Entry time: Tue Mar 10 20:08:23 2015
Author: ericq 
Type: Update 
Category: CDS 
Subject: cdsRampMuxMatrix Backported to 40m RCG 

I have successfully backported the cdsRampMuxMatrix part for use in our RCG v2.5 system. This involved grabbing new files, merging changes, and hacking around missing features from RCG 2.9. 

The added/changed files, with relative paths referred to /opt/rtcds/rtscore/release/src/, are:

  • M include/drv/tRamp.c
    • New C functions to directly report current ramping value and ramping state 
  • M epics/util/feCodeGen.pl
    • Added if statements to main simulink parser to properly handle the part
  • AM epics/util/lib/RampMuxMatrix.pm
    • New Perl script that writes the frontend code for a given ramp matrix
  • A epics/util/mkrampmatrix.pl
    • New perl script that creates the default MEDM screen
  • A epics/simLink/lib/cdsRampMuxMatrix.mdl
    • Simulink block for the part
  • M epics/simLink/CDS_PARTS.mdl
    • Added block and doc for the part (which is missing an underscore in its definition of EPICS field names)

[A means the file was added, M means the file was modified]

Most of the trouble came from the EPICS reporting of the live ramping value and ramping state, since this depended on some future RCG value masking function. I had to rewrite the C-code writing perl script to define and update these EPICS variables in a more old-school way. 

This leaves us vunerable to the fact that a user/program can directly write to the live matrix element and ramping state, which would cause bad and unexpected behavior of the matrix.

So, when using a ramping matrix: NEVER WRITE to [MAT]_[N]_[N] as you would for a normal matrix. Use [MAT]_SETTING_[N]_[M] and trigger [MAT]_LOAD_MATRIX.

Similary, [MAT]_RAMPING_[N]_[N] is off limits. 

I tested the new part in the c1tst model. There are two EPICS input (TST-RAMP1_IN and TST-RAMP2_IN) that are the inputs to a 2x2 ramp matrix called TST-RAMP, and the outputs go to two testpoints (TST-RAMP1_OUT and TST-RAMP2_OUT) and two epics outputs (TST-RAMP1_OUTMON and TST-RAMP2_OUTMON). You can write something to the inputs from ezca or whatever, and use the C1TST_RAMP.adl medm screen in the c1tst directory to try it out. The buttons turn red when you've input a new matrix, yellow when a ramp is ongoing and green when the live value agrees with the setting. 

At this time, I have not rebuilt any of our operational models in search of potential issues.

I have created backups of the files I modified, such that a file such as feCodeGen.pl was renamed feCodeGen.40m.pl, and left next to the modified file. I am open to more robust ways of doing the backup; since our RCG source is an svn checkout of the v2.5 branch (with local modifications, to boot), I suppose we don't want to commit there. Maybe we make a 40m branch? A seperate repo? 

ELOG V3.1.3-