Frig Device VME Access Dennis J. Nicklaus May 1999 This is OBSOLETE. It was only for the 2300s that were temporarily installed at PR and P1 It is kept here only in case somebody else wants to do something similar in the future. With the new PowerPC Frig software, it is possible for the front end PowerPC from one Frig system to access the reading of a device which is connected to a second Frig system Power PC front end. The communication is over the VME bus, so the two PowerPCs must be in the same VME crate. This of course implies that they are for the same sector. So it's not any frig frontend talking to any other frig frontend anywhere. This cross-VME device reading is currently supported only by the following devices: Thermometry, Engine, and ADC. This note describes what a user has to do to utilize this feature. Briefly, on the front end which is conventionally connected to the device, you must issue a special command telling that front end to make a device's reading available over the VME bus. You issue a separate command for each device and channel you want to export to the VME bus. Then, you must create a database device which reads out the special VME read-out device on the remote front end. That new VME read-out device can then be used in loops, etc. on the remote front end. EXAMPLE EXPORT: Suppose we want to make a P1 device readable by PR across the VME bus. The first step is to login (e.g. with telnet) to the front end computer which is conventionally connected to the device we want to read out. % telnet frigp1 username: frig password: -> "->" is the vxworks shell prompt. Be careful what you type here. You are directly connected to the front end computer. You don't want to do something bad. The command to make a device readable over the VME bus is: request_vme_export OID, INT_CHAN, VME_CHAN, MAX_CHANS_THIS_OID where OID is replaced with the "oid" of the device being exported, INT_CHAN is the channel number being exported, VME_CHAN is the VME channel you will access this reading from, and MAX_CHANS is the maximum number of channels you will export from this class of device. So suppose we want to make the P1 device A:P1TI63 available to the vme bus. To find out it's OID and INT_CHAN number, you have to look at the database (e.g. with D80), and look at the SSDN of the Reading property. In this case, for A:P1TI63, the Reading SSDN Is: 0A0D/00FB/0005/0331 which breaks down as follows: ^^-- Slot number ^^-----Channel number ^^--------typecode (5 means it is an ADC) ^----------186 node number (not needed for this discussion) ^^^^-------------OID (fb hex = 251 decimal. ADCs range from 250-259 ^^------------------Acnet node for Frigp1 (D=13) ^^--------------------Acnet trunk for Frigp1 (A=10) The typecode for Engine devices is 2, and is 6 for Thermometry devices. Engine OIDs will be 100-149, and Thermometry OIDs will run from 260-269. So now, we select a VME channel that we want to make the A:P1TI63 reading available through. It is through this specific channel that the other processor will read the reading. Just for example here, I will select the vme_channel=7. You can specify any VME channel from 0 (zero) to 99, but only use each VME channel once. The MAX_CHANS_THIS_OID parameter is simply the maximum number of channels you will ever export (on the VME bus) for that OID. Typically an OID corrsponds to one card in the Frig I/O or thermometry crate. You can keep it small if you KNOW your use of this feature will be limited, or you can make it big (like 100) to alllow for future expansion. I'll select 10 for this example. So now we can fill in the whole command: request_vme_export 251, 3, 7, 10 You can issue this command directly to the shell, or you can add it to the front end's startup script, or you can get it added to the set of ROM-based parameters that the front end reads when booting. (details on that later). IMPORT: Now we turn our attention to the readout of the device. You must create a database device which points to the appropriate VME channel for Reading. Examples exist for the test Frig front end. One such example is Z:NFVME2, which reads out VME channel 2. For our example here, lets say we are creating the device on the FRIGPR node. We have to make it read out of VME channel 7 since that's what we used in the request_vme_export call above. If you create the device through D80, you only need to worry about the Summary and Reading fields to get the device set up. Nothing else (like setting, control,... are supported on the front end.). Let's call this example device A:PRVME7. The SSDN for this device must look like the following. It is slightly different than for the other Frig devices(but more like std. MOOC devices). 0A03/0333/0000/3307 ^^-- Channel number (VME channel, 7 in our example) ^^-----33=must VME device type class. Always must be 0x33. ^^^^--------unused, leave at 0. ^^^^-------------0x0333 = the OID for for a VME readout device. Always! ^^------------------Acnet node for FrigpR (3) ^^--------------------Acnet trunk for FrigpR (A=10) For the other parameters of the reading block and PDB (size, units, scaling, etc.) it should look the same as teh device you are reading out since it is really just a copy of that device's reading. (e.g. default data size=4, primary transform=16). Now if you look at A:PRVME7 and A:P1TI63, you should see the same reading for both. You can repeat the process, issuing multiple request_vme_export calls and creating additional devices as long as you have VME channels left. You must make sure you are consistent with the MAX_CHANS parameter within the same OID. You are allowed to specify, for example, 10 MAX_CHANS for one OID, 5 for another, and 50 for yet another. Other Caveats The reading over the VME bus is truly a reading of a copy of the device's acnet reading. The copy is updated everytime the original device is read out (from an Acnet parameter page, a Frig Loop, an alarm scan, or whatever). If nothing is reading out the original device, the VME reading copy will NOT be updated and you may see a "stale" value from the VME channel copy. So if you are going to put a VME channel copy (e.g. A:PRVME7 above) into a loop on frigPR, you need to make sure it gets updated. To comply with good sampling, you ought to make sure the original (e.g. A:P1TI63) is read out at twice the rate of the VME copy. So for instance, you might set the PR loop reading A:PRVME7 to run/read every 10 seconds (.1 Hz), and create another loop (perhaps just a dummy loop) on FrigP1 that reads out A:P1TI63 every 5 seconds (.2 Hz) to ensure that the VME copy is always current. FLASH ROM The Power PCs have some FLASH Rom which is used to retain parameters about that Frig system. When the parameters (and program code) are stored in the ROM, it allows the front end to boot even when the network is unavailable. Currently, the parameters that get saved in the ROM are: Everything from the defaults files Arcnet node number IP Slot which holds the Arcnet card for this processor Results of all the request_vme_export commands which have been issued. To re-write the parameters into FLASH ROM, you can do the following: reFlashDef defaults_filename, arcnetNode, arcIPslot That will read the defaults from the file defaults_filename, and copy everything to the FLASH ROM appropriately, automatically also picking up the results of any request_vme_export calls that have been made since it booted. A typical use is: 1. First cd to the directory where the defaults files are!! 2. -> reFlashDef "prfrig.dat",0x6c,0 Note those request_vme_exports will be cumulative, so if you boot and read all the defaults out of FLASH ROM, then issue more request_vme_export calls, with your next write to FLASH, you will include those vme export requests read from FLASH when you booted PLUS any additional ones. Reading from FLASH is typically done by the load_all_defs_flash command in the front end startup script. If you decide you don't want your old VME Export requests anymore and they have been saved to FLASH, you will have to change the startup script so that it does NOT perform the load_all_defs_flash (FLASH readout), then issue any new request_vme_export calls that you DO want, then re-write the flash as instructed above. MORE ON DEFAULTS FILES Loading the parameters from FLASH at boot time is also a lot faster than reading the Ascii defaults files. In the old 386 Frig system, there was a system whereby the Frig defaults loader looked at both a binary and an ascii version of the defaults files. It would try to load the newer (from the file time/date stamp) of the two. There is no such checking of file dates here. There are only ascii versions of the files. If you wish the faster and more independent booting with the FLASH ROM files, you must remember to re-write FLASH any time you update the Ascii defaults files. (And then reboot.) OBSOLETE OBSOLETE OBSOLETE OBSOLETE OBSOLETE OBSOLETE OBSOLETE OBSOLETE