J. Kissel

While in the systems meeting today, we'd wondered if the PSL IO Chassis had any spare DAC channels available for use with the newly planned ISS 2nd loop upgrade (see D1600175). Though a PSL DAC channel list is available (see T1200092), it's not really organized to nicely answer the question. As such, I've gone through the PSL front-end simulink models in an attempt to better answer the question. In summary, there are 11 spare DAC channels, some of which are grouped in such a way that they might have independent AI chassis spigots such that installation of new channels for the proposed upgrade to the ISS Second Loop electronics should be easy. 

There are 4, 16 channel DAC cards in the PSL IO chassis. 
On DAC 0 (card_num=0), which is nominally the ISS DAC card, there are no spare channels.
On DAC 1 (card_num=1), which is nominally the FSS DAC card, there are SIX spare channels.
On DAC 2 (card_num=2), which is nominally the PMC DAC card, there are FIVE spare channels.
On DAC 3 (card_num=3), which is nominally the DBB DAC card, there are no spare channels.
Note I say that these DAC cards "nominally" associated with a given function and/or top-level front-end model, but there are many other instances (namely SEI and SUS models) where not only are there multiple DAC cards in a given model, but there even instances where different models share (obviously different channel on) the same DAC card.

The spare channels are specifically (where channel counting starts from 0)
DAC_1_8
DAC_1_9
DAC_1_10
DAC_1_11
DAC_1_13
DAC_1_14

DAC_2_0
DAC_2_12
DAC_2_13
DAC_2_14
DAC_2_15

I attach a full list of the DACs channels identified by their channel names (which hopefully is a good enough proxy for their use). I would attach screenshots of the models, but the output ports are labelled too poorly at the top level for it to be helpful.

PS. This is the first time I've had to look at these PSL models: 
- There are lots of wasted channels (many cases of EPICS records being fed into full filter banks -- likely just to get a fast-channel test point -- the need for which I don't understand). Cleaning this up would likely make a non-negligible impact on the model speed. Admittedly, only DBB model is running close to its limit using ~70% of clock-cycle for computation.
- the labelling of input and output ports makes following signal paths very difficult
- the use of buses and tags would greatly improve the readability of the diagrams
In short, it appears that these models just haven't taken advantage of any of the modern RCG features and experience to improve efficiency and legibility.