CAEN SY527 Mainframe

From CLONWiki
Revision as of 13:08, 13 April 2011 by 129.57.76.91 (talk)
Jump to navigation Jump to search

Mainframe manual (pdf)

Distribution boards manual (pdf) (A932, A933, A934, A938, A944)

After-repare procedures:

If mainframe or board was replaced, it may be necessary to restore defaul values. It can be done by doing 'tsconnect dccntrl' and typing following commands on vxWorks prompt (ignore upcoming caenet error messages):

dc_set_mainframe1_v0 - restore V0 values in mainframe 1
dc_set_mainframe1_v1 - restore V1 values in mainframe 1
dc_set_mainframe1_i0 - restore I0 values in mainframe 1
dc_set_mainframe1_i1 - restore I1 values in mainframe 1
dc_set_mainframe1_vmax - restore VMAX values in mainframe 1
dc_set_mainframe1_rup - restore RUP values in mainframe 1
dc_set_mainframe1_rdwn - restore RDWN values in mainframe 1
dc_set_mainframe1_trip - restore TRIP values in mainframe 1
dc_set_mainframe1_name - restore channel names in mainframe 1

The same for mainframes 3 and 4.

To restore ALL values for particular mainframe following commands can be used (but it is more reliable to use previous commands and do it value-by-value):

dc_set_mainframe1
dc_set_mainframe3
dc_set_mainframe4

Experts may want to use low-level functions (dchv config files must be in $CLON_PARMS/dchv/vme directory):

dc_set_default(char *file) - set ALL values for channels specified in 'file' which is standard DC config file with extension 'iconf'
set_default(char *file, int code) - the same as previous but set only ONE value specified by 'code' in according to the following:
   code = 0x10 - sets V0
   code = 0x11 - sets V1
   code = 0x12 - sets I0
   code = 0x13 - sets I1
   code = 0x14 - sets VMAX
   code = 0x15 - sets RUP
   code = 0x16 - sets RDWN
   code = 0x17 - sets TRIP
   code = 0x19 - sets channel name

Serial connections to mainframes can be used to monitor mainframes:

 tsconnect caenhv1
 tsconnect caenhv3
 tsconnect caenhv4


WEB on caenet problem:

Error messages from EPICS Device Support Code This assume that you have 3.26a firmware on your CAEN SY527 On this release it is known that there's a bug when we use SY527 from CAEN V288 via H.S.CAENET.

This bug of firmware causes "random periods of no CAENET response from the SY527 system". By this effect you may have error messages from EPICS device support code like

"CAENET Module does not exist when send command add channel=* group=* crate=*", "CAENET Channel or Board not present when send command add channel=*,,," or "Unknown Error Number when send command add channel,,,". and "Update Status Cache error" "Update Param Cache error"

The results of those error is that the cache information for each HV channels are not created properly during iocInit(initilization of IOC). We know that you have chance to make it created properly if you just repeat last setup of channels like total # of HV channels or group ID for each HV channels. But if you change something above error may happen


Reason why error occurs From our experience it is thought that the error caused by bug of SY527 system may happen 'cause there are some conflicts between the infomation on ROM on SY527 and the configuration file(HV.hvc) which define the channel assignment on SY527 and cache information on IOC. In most case "Add channel to Group CAENET Command"(0x50) fails if we modify group ID of that channel. Here you can see the flow chart of CAENET Command during "iocInit". How to solve/avoid error The easiest way to avoid error discribed last chapter is to upgrade the firmware to 3.26d or higher but there are some other solution besides that.


1)Repeat the failed commmand for 10 to 20 times every 500msec We have not tried this but this can surely helps you If you see errors after tried this you may have more serious problem that we cannot help


2)Modify the position of each board(A938AN) This causes the ROM on SY527 which keeps last information about channels being cleared. And of course there's no conflict between information on SY527 and HV.hvc.

3)Format ROM on SY527 We don't say this is a good way to solve error but keep this in mind for emergency.


TOF Online Monitor/Control Person Kunio Koseki, Univ. of Tsukuba Last modified: 12 May 1999