All the cryo systems (A through F sectors,PBar, and FrigSY,LB,RB) has been converted over to VME Power PC based control systems. At each sector, all the houses (e.g. all of F0, F1, F2, f3, and F4) are consolidated into one VME Power PC System, having acnet and IP nodes FrigA, FrigB, FrigC, FrigE, and FrigF (and FrigSY and FrigPR). All these nodes are functioning properly and are receiving TCLK.
The Frig nodes, A-F and SY, PBar, are booting from FLASH memory and have their defaults files and configuration info stored into FLASH memory.
The vxWorks+Frig Application code that is currently in the FLASH was built on nova using vxWorks 5.4 (Tornado 2).
You can also reboot them by visiting the node (they are at the 0 buildings) and push the reset button on the front of the processor card, or cycle power.
If needed, the FrigF vxworks console is connected to CNS16 via
a serial line at F0. Use
CNS16> set host/dt tta2:
to start the serial connection. (you may need to unplug the serial
line, then do the set host, then plug in the serial line to get
it started).
I think this is now fixed, but for completeness sake: There once was a bug somewhere in the Acnet software which can cause a key part of the software to fail at boot times, sometimes. The "iprcv" task is what crashes, which means there is no ACNET communications when this happens. I have only seen this crash happen after a cold reboot, from power going off on the VME crate. It seems to be especially common at FrigF, for some reason. So, if you cycle the power on the Frig node, and notice it does not come up properly, you might have to telnet into the node and reboot it again. That is the best way to clear the problem.
While the Frig nodes don't read their defaults files over the network at
each reboot, these files are needed in case one wants to make changes to part
of the defaults files.
These files are maintained on fecode-bd.fnal.gov in:
~vxworks_boot/vxworks_boot/fe/frig/defaults
If you want to change the defaults files, you need to make the changes
to the files in that directory. So if you generate new defaults files
from F13, for example, you'll need to ftp them into that directory.
To generate new loops defaults files, I have a program on my vax account at
usera:[nicklaus.loop]loopdef.c
which generates a new LOOP defaults file for a specified house.
You run the program, then enter the house name, e.g. A2.
It then reads the current settings of all the loops for that house
and writes them out (to stdout) in the format of a loops default file.
It works much better than the F8 defaults file writing stuff if
you just want to re-write a whole new file.
I also have command scripts there to generate whole sets of new files.
Again, after making the new file, you must copy it to the defaults
file directory on fecode-bd.
The defaults files are also version controlled via CVS. So after you make the changes in the defaults files directory, you should commit the changed files to cvs.
After you change the defaults files, you need to get the new contents
loaded into the FLASH.
You do this by the following:
Or you could login to the front end and execute the following:
The startup scripts for each system are also in the frig directory of fecode-bd. These startup scripts have names like X.login, where X indicates the sector name, typically one of a,b,c,d,e,f. These are very important, and there are differences between them, depending on how many houses each sector has, where the IP cards are installed, etc. Once again, these startup files are not currently used at boot time since we are booting out of FLASH. All the variable values in these files have been stored into FLASH. These startup files are still useful if we need to recreate the settings ever, though.
The other hardware each system needs is listed below. Nearly all of it has required some custom modifications to adapt it to Frig usage. Again, there should always be spares available in the test lab.
Also, the address jumpers on the Greenspring cards must be set properly, and the addresses selected must agree with the addresses set in the X.login startup script. The typical configuration, I usually set it up as follows. For the 1st Greenspring card, which is going to hold the IPUCD, I set the A16, I/O Address using the E3-E7 shunts, to select address 6000. This is the default factory setting, illustrated here. These jumpers are right between the P1 and P2 connectors.
You also need to set the E21-E21 shunts to select the A32 memory address space to use the IPUCD. These jumpers are behind the P2 connector. On the Greenspring card which has the IPUCD, make sure that the E1.A32 shunt is in to enable A32 addressing. Then set the E20-E21 shunts to the address that you also have selected in the .login file. I usually set the 4 most significant shunts on, and leave them off the 4 lower pairs, as illustrated in this figure.
For the second Greenspring IP carrier card, which only has Arcnet IPs, not IPUCD, I typically set the A16 space to select address C000 (by taking the shunt at the bottom of the E1-E3 figure and moving it up 2 pins, leaving the lower 2 pairs unconnected). It doesn't matter what you set the E20-E21 shunts to for A32 address space, as long as it is different than what you have on the first carrier card. I typically just leave E20-E21 at their default settings.
Once the carrier cards are set to go, you must put the IP cards in each carrier. There is one IPUCD for the each system. I usually put it in Slot A of the carrier card. That way you don't have to figure out any offsets, etc. to find out where the IPUCD memory is, you just use whatever the A32 jumpers are set to. Then Arcnet IP cards go in slots B,C, and maybe D (always D, if there are 6 houses in the sector, such as B, D, and E). The second carrier card only takes at most 3 Arcnet IPs. It doesn't typically have its interrupt levels re-wired, so slot D of that carrier card would interrupt at VME level 7, which we would like to avoid.
There are two documents you might need to maintain this front end.
Contact: Dennis Nicklaus