Frig PPC Front End Instructions

This page gives you directions on how to build the code and misc. other files required by the Frig VME front ends with Power PC processors. This web site has also a more extensive list of Frig documents.

Updated Sept. 15, 2001

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).

Emergency Maintenance Instructions are here

Control Issues

You can use F17 to reboot these new frig nodes.

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.

Defaults Files

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 in:
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
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.

Hardware Issues

The Frig nodes all run on Motorola MVME2400 Power PCs. There should always be one which can be used as a spare in the Frig test area in the Linac annex lab area. To use it as a spare, you will have to change it's boot parameters so that it thinks it is the IP and acnet node that you are using it to replace.

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.

This configuration selects address 0x16000000 for the base A32 memory address when used with the 2400 board. This is NOT the factory default setting. And this does NOT match up with the how the VIP616 documentation says these shunts ought to select an address. Only when used with the 2400 do I see this deviation from the VIP616's documentation. I experimented and found that this jumper setting gives the 0x16 address selection.

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.

Other Issues

There are two documents you might need to maintain this front end.

Contact: Dennis Nicklaus

Security, Privacy, Legal