Each RFM read in the c1mcs model is adding ~7 microseconds to the cycle time. Adding too many pushes it over the 62 microsecond limit.
RFM writes do not have this problem.
The fastest fix was to create a new front end model, called c1rfm, which does nothing but read in the MC1, MC2, MC3 PIT and YAW signals from the c1ioo machine, and then passes them along to the c1mcs model via shared memory, which is fast.
This means the data being sent is 2 cycles slow, one to go over the RFM, and one to go over shared memory. It is running at 16384 cycles/second, so it shouldn't have much impact at the frequencies we use those channels for.
MC_L is still being sent directly to the c1mcs front end code via RFM.
The c1mcs model is running at 30-33 microseconds for CPU time.
The c1rfm model is running at 45-47 microseconds for CPU time.
All 7 channels, MC_L, MC1_PIT, MC1_YAW, MC2_PIT, MC2_YAW, MC3_PIT, MC3_YAW are responding.
The c1rfm model was added to the /diskless/root/etc/rtsystab file on the fb machine so that it automatically starts on the reboot of c1sus.
The USR and CPU time channels for c1rfm were added to the MCS_SLOW.ini file in /opt/rtcds/caltech/c1/chans/daq/ so that the framebuilder records them, namely:
The framebuilder was restarted to take these new channels into account.
Finish implementing and debugging the "round robin" RFM reader so as to not require a seperate model to be doing RFM reads in parallel.
Look into improving read speed by either merging timestamps and data into a single or reading time stamp once every tenth or hundreth cycle, although this at best provides a factor of 2 improvement.
Check to see if RFM card being on the IO chassis or directly in the computer chassis makes a difference.
Get Alex and Rolf to improve RFM read speed.