This BinaryRelease was copied to the above dir, untarred, and thus we will need SCT_DAQ_ROOT=/usera/sctrod/testing_4_1/SctRodDaq
For the testing of SctRodDaq_4_1 at Cambridge it was necessary to edit the exampleSetup.sh file. Here is a diff of the changes I needed to make the setup appropriate for Cambridge, and here is the resultant camSetup.sh script.
As a result of realising that two of the changes were embarrasing (the default values of DF_INST_PATH and TDAQ_INST_PATH suggest old outdated versions) and that the CMT_CONFIG variable was misleadingly set to dbg rather than opt, which are the libraries that are released with the BinaryRelease?, I later went back and changed these in the release, so what you download NOW should not need these three variables to be changed. You will still need to edit the tag in installed/config/databases/DaqSoftware?.data.xml as described below if you are a BinaryRelease? user, but you will be prompted to do so even if you have not been reading these instrucations, and the developers.
It was also necessary to do:
cd /usera/sctrod/testing_4_1/SctRodDaq export SCT_DAQ_ROOT=`pwd` mkdir $SCT_DAQ_ROOT/scratch mkdir $SCT_DAQ_ROOT/saved_data
prior to the first sourcing of the script or else the SCT_SCRATCH_DIR and SCT_PERSISTENT_DIR variables are reset by the startup scripts to /tmp!!
I also had to make a link to an existing known-good hardware configuration file valid for Cambridge:
ln -s /usera/sctrod/lester/SctRodDaq/installed/config/databases/realRod.xml $SCT_DAQ_ROOT/installed/config/databases/realRod.xml
Here is the contents of the realRod.xml that was used.
Related to the above, I also had to do:
cd installed/config/databases ln -s /usera/sctrod/lester/SctRodDaq/installed/config/databases/module09.xml ln -s /usera/sctrod/lester/SctRodDaq/installed/config/databases/module28.xml ln -s /usera/sctrod/lester/SctRodDaq/installed/config/databases/module53.xml ln -s /usera/sctrod/lester/SctRodDaq/installed/config/databases/module56.xml ln -s /usera/sctrod/lester/SctRodDaq/installed/config/databases/20220040200245.xml ln -s /usera/sctrod/lester/SctRodDaq/installed/config/databases/20220330200262.xml
but I only realised that I had to do this after being confused for a long while by a scan-time error message saying "No modules to scan". I have recommended that the ConfigurationService (or whatever reads the realRod.xml file in) should send a warning to MRS if there are missing include files.
At this stage,
$SCT_DAQ_ROOT/installed/config/databases/Hardware.data.xml
still does not exist, and must be created from
$SCT_DAQ_ROOT/installed/config/databases/Hardware_template.data.xml.
This was easy enough to do and only consisted of changing "blahHost" to "pcei" except for "sbcHost" which became "vme3".
If try to source and then "./start" at this point you are told:
10/2/05 18:13:39 :: ERROR [IPCUtil::resolveInitialReference] cannot open reference file "/usera/sctrod/testing_4_1/SctRodDaq/ipc.ref.file": No such file or directory 10/2/05 18:13:39 :: ERROR [IPCUtil::resolveInitialReference] Invalid reference format "" in url "file:/usera/sctrod/testing_4_1/SctRodDaq/ipc.ref.file"
and also told that:
ERROR : Could not find $CMTCONFIG with value [i686-rh73-gcc32-opt] in /usera/sctrod/testing_4_1/SctRodDaq/installed/config/databases/DaqSoftware.data.xml this may mean that you cannot start due to problems with igui I suggest you modify the tag in /usera/sctrod/testing_4_1/SctRodDaq/installed/config/databases/DaqSoftware.data.xml to i686-rh73-gcc32-opt
which is a nice new message inserted by Alan. The tag is changed as required easiliy enough. The initial reference can I think be ignored, as I sourced anyway and found that the initial file was created automatically for me.
Having done the above, the setup script may be sourced, and you may "./start".
Having done all of the above, I found it was possible to start up the software and do a full characterisation sequence.
Note: Possible bug? Failure to initialise crate or vme on first occasion since power on ...
It seems there may be a bug of unknown origin causing ROD initialisation to occur on the first (and only the first) time since crate power-on:
(10:55:01) lester: I have noticed with 4.1 (10:55:07) lester: (probably also with head) (10:55:50) lester: that initialising the vme bus seems to fail on the very first occasion (since the crate has been turned on, that is) but not on any subsequent occasion. (10:56:14) alan: Interesting (10:56:25) alan: I've seen similar problems. (10:56:42) lester: Under normal running you get the (10:56:45) alan: which DF are you using for initialising VME? (10:56:54) lester: (10) (10:57:16) lester: normally you get the (10:57:26) lester: "Sucessfully initialisaed VME interface" message, (10:57:31) lester: 5 second pause (10:57:43) lester: "ROD initialissed" (10:57:46) lester: 5 second pause (10:57:52) lester: and then other things happen (10:58:02) lester: What happens ()instead) on first power on seems to be (10:58:15) lester: the last 5 second pause becomes a very long one (10:58:18) lester: (more than 5 seconds) (10:58:27) lester: and then something corba (or IPC) (10:58:33) lester: times out on a CORBA transient
The above thread (problems with initial power on) has been copied to ProblemWithInitialPowerOn