Methods at Crate level only
Mostly debug or access to low-level features not used in normal Calibration sequence.
Direct ROD access (Debug only):
short dspBlockDump(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in long dspStart, in long numWords, in long dspNumber);
DataBlock dspBlockRead(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in long dspStart, in long numWords, in long dspNumber);
short dspBlockWrite(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in DataBlock buffer, in unsigned long dspAddress, in long dspNumber);
unsigned long dspSingleRead(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in unsigned long dspAddr, in long dspNumber);
void dspSingleWrite(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in unsigned long dspAddr, in unsigned long val, in long dspNumber);
DataBlock readSlaveDsp(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in short s, in unsigned long add, in unsigned long words);
void printBOCSetup(in unsigned long partition, in unsigned long crate, in unsigned long rod);
sctConf::ABCDModule getABCDModuleRaw(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in unsigned long slot, in BankType bank)
raises(SctApiException);
Debug Options:
void unsetDebugOption(in string opt);
void setDebugOption(in string opt);
DebugOptionList listEnabledDebugOptions();
DebugOptionList listDebugOptions();
void standardRegisterDump(in unsigned long partition, in unsigned long crate, in unsigned long rod);
Low-level primitive access:
void awaitResponse(in unsigned long partition, in unsigned long crate, in unsigned long rod);
DataBlock getResponse(in unsigned long partition, in unsigned long crate, in unsigned long rod);
void createDebugPrimList()
raises(SctApiException);
void addDebugPrimList(in long index, in long id, in long version, in DataBlock body)
raises(SctApiException);
void sendDebugPrimList(in unsigned long partition, in unsigned long crate, in unsigned long rod)
raises(SctApiException);
void sendDebugSlavePrimList(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in unsigned long slave, in boolean await, in boolean response)
raises(SctApiException);
void flashLED(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in unsigned short slaveNumber, in unsigned long period, in unsigned long flashes)
raises(SctApiException);
void echo(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in DataBlock data)
raises(SctApiException);
Only useful with stdout, therefore debug only.
void printABCDModule(in unsigned long mid);
void printABCDRodModule(in unsigned long mid, in BankType bank);
void decodeEvent(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in short sl, in short index, in boolean extFlag, in boolean errorType);
void configureBOC(in unsigned long partition, in unsigned long crate, in unsigned long rod);
BOCMonitorSequence getBOCMonitorArray(in unsigned long partition, in unsigned long crate, in unsigned long rod);
This currently sends a ROD level trigger. There's a different method for a TIM level trigger, which would be at a higher level.
void sendL1A(in unsigned long partition, in unsigned long crate, in unsigned long rod);
Only used by SctApiGUI (I think).
unsigned long getRodSlot(in unsigned long partition, in unsigned long crate, in unsigned long rod);
void testLinkOutSelect(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in unsigned long link);
unsigned long testLinkOutRetrieve(in unsigned long partition, in unsigned long crate, in unsigned long rod);
boolean isRODPresent(in unsigned long partition, in unsigned long crate, in unsigned long rod);
Methods at Top level only
This is how SctApiGUI and expert scripters would get access to above.
getCrate(in unsigned long partition, in unsigned long crate);
Scans and triggers probably kept track of at top level. Need to be careful about giving different crates access to them, sometimes is right thing to do. Would need locking on module list updaters.
Scan createScan();
Scan getDefaultScan();
Trigger createTrigger();
Trigger getDefaultTrigger();
ScanList knownScans();
Translation methods. These are mostly just proxies for configuration server, which was most useful in TApi where it wasn't accessible directly.
But these deal with the SctApi's internal mid numbers...
unsigned long findModuleSerial(in string sn);
string convertToString(in unsigned long mid);
unsigned long findModule(in unsigned short mur, in unsigned short number);
unsigned long findModuleRod(in unsigned long partition, in unsigned long crate, in unsigned long rod, in unsigned long channel);
// pair<INT32, INT32> convertToMUR(in unsigned long mid);
unsigned long findBarrelModule(in unsigned long barrel, in unsigned long row, in short number);
void convertToBarrelModule(in unsigned long mid, out unsigned long barrel, out unsigned long row, out short number);
unsigned long findEndcapModule(in long disk, in long ring, in long number);
void convertToEndcapModule(in unsigned long mid, out long disk, out unsigned long ring, out unsigned long number);
DDC stuff. This mostly doesn't need access to modules. Only exception is setSelect, which currently doesn't update select parameter in module configuration, but should do.
void requestHardReset(in unsigned long mid);
void requestIVCurve(in unsigned long mid, in float start, in float stop, in float step,
in unsigned short delay, in float currentLim);
void setSelect(in unsigned long mid, in boolean value);
void setSelectAllInCrate(in long crate, in boolean value);
void changeRunState(in long state);
// Direct DDC methods (no module translation)
// void ddcGetChannelParameter(in long crate, in long channel, in string dpeName, // out long dpeValue); // Put timeout in here? void ddcSetSingleTimeout(in short timeout);
short ddcGetSingleTimeout();
void ddcSetMultipleTimeout(in short timeout);
short ddcGetMultipleTimeout();
void ddcChangeState(in long crate, in long channel,
in short state); // MultipleTimeout
void ddcChangeStateAll(in long crate,
in short state); // MultipleTimeout
void ddcLoadConfiguration(in long crate,
in short state); // MultipleTimeout
void ddcHardReset(in long crate, in long channel); // SingleTimeout
void ddcHardResetAll(in long crate); // MultipleTimeout
unsigned long ddcGetChannelParameterInt(in long crate, in long channel, in string name); // SingleTimeout
float ddcGetChannelParameterFloat(in long crate, in long channel, in string name); // SingleTimeout
string ddcGetChannelParameterString(in long crate, in long channel, in string name); // SingleTimeout
unsigned long ddcGetCardParameterInt(in long crate, in long card, in string name); // SingleTimeout
float ddcGetCardParameterFloat(in long crate, in long card, in string name); // SingleTimeout
string ddcGetCardParameterString(in long crate, in long card, in string name); // SingleTimeout
unsigned long ddcGetCrateParameterInt(in long crate, in string name); // SingleTimeout
float ddcGetCrateParameterFloat(in long crate, in string name); // SingleTimeout
string ddcGetCrateParameterString(in long crate, in string name); // SingleTimeout
void ddcGetCrateParameters(in long crate, in NameList names, out NameValueList nameValues); // MultipleTimeout
// Also set DDC parameters...
void ddcSetCrateParameterFloat(in long crate, in string name, in float value); // SingleTimeout
void ddcSetCardParameterFloat(in long crate, in long card, in string name, in float value); // SingleTimeout
void ddcSetChannelParameterFloat(in long crate, in long channel, in string name, in float value); // SingleTimeout
Methods that probably need to be at both (and forwarded)
There's probably a distinct difference here between standard ROD scans and TIM scans, which only need crate level control and TTC scans, which need to coordinate among crates (and probably need several other methods on a crate).
These are the only (possibly not even doRawScan) method(s) that need any "intelligence" in the top-level API. Unfortunately, it involves a reasonable amount of intelligence.
void doScan(in Scan thisScan)
raises(SctApiException);
void doRawScan(in Scan thisScan, in long delay, in long width, in boolean configure, in boolean clockByTwo)
raises(SctApiException);
Most of this just needs to be forwarded to avoid the CalibrationController having to know which Crate/ROD it's talking to. If for some reason it knows already, then they don't need to be in the top-level. It doesn't even need to check with the configuration service as the information is encoded in the mid parameter.
Either way, no module configurations need to be stored at a level higher than the crate. All it needs to know is which module is in which crate. I believe there are no cases where a module has its redundant tx pair cross a crate boundary.
ALERT! Actually it turns out that the above statement though it might turn out to be true for the barrel is almost certainly not true for the endcaps, i.e. there will almost certanly be redudancy loops that cross crate boundaries. It is important, therefore, that no non-crate-boundary-crossing assumptions be put into the SctRodDaq logic.
Module configuration methods. Crate-level methods would give error if mid doesn't correspond to "my" crate.
void modifyABCDMask(in unsigned long mid, in DataBlock mask);
void modifyABCDTrims(in unsigned long mid, in CharBlock trims);
void modifyABCDRC(in unsigned long mid, in unsigned long chip, in unsigned short index, in double p0, in double p1, in double p2 );
void modifyABCDVar(in unsigned long typ, in double var);
void modifyABCDModuleVar(in unsigned long mid, in unsigned long typ, in double var);
void modifyABCDChipVar(in unsigned long mid, in unsigned long chip, in unsigned long typ, in double var);
void modifyABCDVarROD(in unsigned long typ, in double var, in BankType bank);
void modifyABCDModuleVarROD(in unsigned long mid, in unsigned long typ, in double var, in BankType bank);
void modifyBOCParam(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in unsigned long channel, in unsigned long type, in unsigned long val);
Get/set/send module configurations:
void getABCDModules(in BankType bank)
raises(SctApiException);
void getABCDModule(in unsigned long mid, in BankType bank)
raises(SctApiException);
void setABCDModule(in unsigned long mid, in BankType bank)
raises(SctApiException);
void setABCDModules(in BankType bank)
raises(SctApiException);
void sendABCDModule(in unsigned long mid, in BankType bank, in unsigned long type)
raises(SctApiException);
void sendABCDModules(in BankType bank)
raises(SctApiException);
void storeModuleConfigurations()
raises(SctApiException);
void configureAllModules()
raises(SctApiException);
These would be better if the data could come directly back from the crate SctApi?
/// Retrieve module configuration data
sctConf::ABCDModule retrieveModule(in unsigned long mid);
BOCChannelList currentBOCSetup(in unsigned long partition, in unsigned long crate, in unsigned long rod);
sctConf::BOCGlobalConfig currentBOCRegisters(in unsigned long partition, in unsigned long crate, in unsigned long rod);
Currently missing from IPC API, but in C++ class:
saveBOCSetup
restoreBOCSetup
TIM access, is this being done completely separately anyway?
void timSetFrequency(in unsigned long partition, in unsigned long crate, in double trigFreq, in double rstFreq);
void freeTriggers(in unsigned long partition, in unsigned long crate);
void stopTriggers(in unsigned long partition, in unsigned long crate);
void timL1A(in unsigned long partition, in unsigned long crate);
void timCalL1A(in unsigned long partition, in unsigned long crate, in short delay);
short timReadRegister(in unsigned long partition, in unsigned long crate, in short value);
void timWriteRegister(in unsigned long partition, in unsigned long crate, in short reg, in short value);
void sendTimTrigger(in unsigned long partition, in unsigned long crate, in Trigger trig);
void sendTrigger(in unsigned long partition, in unsigned long crate, in unsigned long rod, in Trigger trig);
Not used much, but high-level thing so belongs here.
AutoResultList autoConfigureScan()
raises(SctApiException);
Similar, but used internally by histogramming code.
boolean checkAllModulesProbe(in string chars)
raises(SctApiException);
Again, not much intelligence needs to be at high-level, just distribution.
void initialiseAll(in unsigned long runNumber)
raises(SctApiException);
void shutdownAll()
raises(SctApiException);
void status();
void setRunNumber(in unsigned long newRun);
void setScanNumber(in unsigned long newScan);
unsigned long getRunNumber();
unsigned long getScanNumber();
void standardRegisterDumpAll();
High-level API shouldn't really have a list of modules (for coherency), but could amalgamate crates' lists.
sctConf::ModuleList getModuleList();
void lasersOff();
The output from probe currently assumes only one ROD, but could be extended to multiple RODs/crates?
CharBlock probe(in unsigned long partition, in unsigned long crate, in unsigned long rod);
CharBlock probeHarness(in unsigned long partition, in unsigned long crate, in unsigned long rod, in unsigned long harness);
CharBlock probeWithTrigger(in unsigned long partition, in unsigned long crate, in unsigned long rod, in Trigger trig);
CharBlock probeHarnessWithTrigger(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in Trigger trig, in unsigned long harness);
CharMatrix probeScanHarnessWithTrigger(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in Scan trig, in unsigned long harness);
Unsorted
Maybe shouldn't be here (only in TApi)
// Configuration
// void loadConfiguration();
void loadConfiguration(in string filename)
raises(SctApiException);
Where did these come from? They decode raw output to stdout, so best kept to TApi...
void rawData(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in long delay, in long units, in boolean setMask);
void rawDataWithTrigger(in unsigned long partition, in unsigned long crate, in unsigned long rod,
in long delay, in long units, in boolean setMask, in Trigger trig);