The binary release was copied to the above dir, untarred, and thus we will need SCT_DAQ_ROOT=/usera/sctrod/testing_4_2_RC1/SctRodDaq
For the testing of SctRodDaq_4_2_RC1 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.
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_2_RC1/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!!
YOU CAN SHORT CUT TO A VALID CONFIG by untarring config.tgz in installed/config/databases. Note it will not create links but instead create real local copies of the files needed.
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
See the contents of config.tgz for the version of realRod.xml that was used.
(By using the tar file, you should get the cam equivalent of doing:
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 ln -s /usera/sctrod/lester/SctRodDaq/installed/config/databases/UCID_0_0.xml ln -s /usera/sctrod/lester/SctRodDaq/installed/config/databases/ROD_G.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 (unless you used the tar file) 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". Note that there is a bug in the TDAQ implementation: you cannot type an ip address or just any old valid hostname in these fields, you have to return exactly whatever is returned by the "hostname" command run on that computer. That means that SOMETIMES you need the FQDN and sometimes you just need the first word of the hostname! [Aside: this silly process has been removed in tdaq-01-07 - from there onwards one only has to specify the FQDN hostname (hostname -f). Thankfully.]
If try to cd back to $SCT_DAQ_ROOT and then source camSetup.sh 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_2_RC1/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_2_RC1/SctRodDaq/ipc.ref.file"
and also told that:
ERROR : Could not find $CMTCONFIG with value [i686-rh73-gcc32-opt] in /usera/sctrod/testing_4_2_RC1/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_2_RC1/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