WP 3731, 3727

We upgraded H1 from RCG 2.6.1 to 2.6.2. We took the opportunity to build the H1.ipc file from scratch to clean out unused IPC channels. All models were rebuilt and restarted. In order to install new mbuf drivers we rebooted all front ends as well as restarted their models many times over the course of the day. Errors found in the restart/reboot scripts were fixed. The DAQ was restarted several times in the late afternoon when we upgraded the original h1dc0 to have two gigabit ethernet receiver cards (making it the same as the h1dc1 test system which we installed on Saturday). The new h1dc1 is powered down and acting as a backup concentrator machine.

Alex upgraded h1fw0 and h1nds0 to be the same as the h1fw1 system (upgraded Sat 23 feb). This includes new frame-cpp and framed channel status string.

New code was installed on h1seih23 to conform with the wiring drawings. An adc timing problem was seen, so that system is not running at the moment, we'll take a look tomorrow morning.

IPC problems with h1sustmsy were discovered, the SUS and SEI teams have resolved that issue.

The PSL models would not compile due to recent common parts changes, for the moment we reverted back to older versions of the common parts which are consistent with our H1 models. We'll hand this over to team-PSL to upgrade their system at  later time.

We tested "front end restarts not invalidating other front ends data" (fixed by giving each front end its own mx stream end point), and could not reproduced this error.

We tested pressing the "DAQ Reload" button on a variety of front ends and could not reproduce model crashing or front end lock outs which were seen before 2.6.2.

We discovered a left-over EPICS 40 char name limit in or 3.14.10-epics-long state notation compiler, this was extended to 60 chars.

In summary: all front ends are now running 2.6.2, the original h1dc0 data concentrator is running with the extra 10gigabit ethernet port, front ends have their own end-point for mx stream daq data transfer.