DAQUSER's WISHLIST
This is a list of things which if ANYBODY (who has time) did, would be very good ...
DEBUGGING IO
DebuggingNewIOTDAQ compatibility stuff
- Migrate our histograms from IS to OH?? If we do this, we get the archiving of all our histograms for free when we upgrade to TDAQ-01-07. For all histograms in OH, will be archived on a regular basis by the use of MDA = Monitoring Database Archieve. Other advantages: could also use the online histogram viewer, the offline "web-based" histogram viewer...
- Apart from efficiency, one of our main reasons not to use OH was it didn't allow arbitrary meta-data, eg how the histogram was produced. Does it now, or do we have a different solution?
- Possible intermediate solution is to write a publisher of previously stored results (ie option to DataDisplayer)
SCT running stuff
- Hard Reset after FullBypass?
- A soft reset is now done after FBT, has this been shown to be insufficient?
- Tim "OnePointGain" scan for off-rod calibration
- Right click on module in "probe data" GUI display should also include (at module level):
- BC reset
- Soft reset
- Reconfigure
PWP - I don't understand why one might want to send BCR or SR to a single module, as this cannot be used to resolve synchronisation errors, it can only make things worse. With regard to configuration, why it any better to configure a single module than it is to reconfigure all modules? (Or maybe the author meant that the single module popup menu should include options to perform these actions to all modules?)
- Right click on a module in "DCS" view should include the ability to set (at module level):
- VVCSEL
- VPIN
- This may require some changes to sct_ddc and will require changes to PVSS. While we're at it, there are a lot of sprintfs in sct_ddc that could be tidied, using %02d instead of two cases, one for numbers <10 and one for numbers >10.
- Read BOC monitoring parameters
- What to do with them? BocMonitoringIdeas
- Read out TIM parameters (inc FFTV counters) in physics mode
- Do something about text buffers
- might be possible to get the GUI to display more of the module variables, such as vthr, trim target, qthr etc graphically... it would have to know how to deal with response curves... (currently getABCDVar is missing from SctApi/ConfigUtility?, but could easily be added (from SCTDAQ))
- Possibly (in lieu of this going into automatic DSP code) put the data read out by GuiComponent?.SctApi.RegReadout? into the main GUI (useful during running, things like timeout, overflows, rod busy)
- Mask off links that cause problems
- After modules are configured, etc, clear link errors in ROD
- There is some suspicion that the AnalysisService ConfigurationInterface? does not receive notification that the configuration has changed.
- Does it look for IS changes? SctApi also needs to listen for configuration changes.
- Clicking on those modules which are not returning Events under probe and putting them into a temporary configuration which then runs RxThreshold on them and figures out what thresholds should be set for them
- NB. Without DSP code change, fewer than all modules on a ROD won't go any faster. But a scan that only changes the appropriate thresholds should be possible.
PWP - not sure that is true. Readout phase will be faster if fewer RODs are in the system, even if the captured data for all streams within that ROD are still read out. Anyway, a viable (and faster) alternative might be for the SctGUI to include an algorithm which reprobes for different RX thresholds, eg 50, 100, 150, 200, 250. If it finds signs of life, we know the module is basically alive and can worry about true optimisation later. Along similar lines, we could have options to try RX delay settings 0, 5, 10, 15, 20 and maybe even SELECT=1...
- Diagnose and fix TxCurrent? test
- Need a hard reset (250ms delay between crates) and quite a long delay (20 secs between bins) and send config at the start of each bin.
PWP - From a quick look, it seems that return codes may have been included in the original DDC code. We may be able to use these - in conjunction with increased timeout values - to implement a crude HR handshake. Still need to consider the multiple crate case though, as I'm sure Chris would point out.
- Diagnose and fix RX delay text
- Sometimes seem to lose contact with module (ROD confused) sometimes after bin changes .... similar to above, but even worse as you lose the clock ..
- Try to make less sensitive to confusion from "single black block in the middle of the data" - talk to NIKHEF directly who see the probnlem
- Plain Probe
- Distinguish "C" from "c" by check of content of config register on module
- Reasonable attempt at this is now in CVS, needs testing
- Distinguish "C" from "c" by check of content of config register on module
- Probe Scan
- Seems not to work when there are a large number of modules in the configuration ... not sure why. Needs to be fixed. Works for small number of modules.
- If this is a time-out issue, it should be fixed in CVS (and MERGE). Needs checking on an endcap run
- Fix the DDC error on start up
- The partition (or segment) configuration tells ddc where to look in PVSS for a data point for alarm communication. What should we give it?
- Trimming?
- ie how to update configurations...
- Fix permissions on the SctApi and sctConf dump files to be readable by all
- OK, directories created by SctApi should now be readable by all
- sctConf dumps, use libxml file creation, can't find permissions...
- Profile SctApi histogram readout. Readout from ROD doesn't take long compared to send to IS.
- RunController errors
- If SctApiCrateServer? crashes, this appears only as an error message from PMG in MRS, and possibly a subsequent cryptic CORBA timeout message
- Part of the reason is that crates are not part of runcontroller tree (maybe they should be segments?)
- One issue here. config-server does a reload of the configuration, which must be completed before the crates start initialiseAll. Currently config_server calls initialiseAll so this is guaranteed.
- Release notes for 01-06 says applications controlled by runcontrollers will appear in the tree, maybe status will be there as well
- The Analysis Rollercoaster
- Don't wait for all the funfair attendees to get to the polar bear before letting the roller coaster loose again. Needs attention in Calibration Controller.
- If the first lot didn't want to see the polar bear, then can start next. Is it only ConfigUpdater? that knows whether it will update config?
- Translation: There may be some scans/tests which don't depend on the results of previous ones, therefore can start before the config has been updated.
I'm afraid the above dosent make much sense to me, but there is a case for refactoring the configuration updating. There are several different things we want to do which are similarish:
- Config + test results -> new config
- Diff configs
- I'm nearly done generating a diff in XML format (in a standalone program). If the configUpdater and COOL conditions were capable of producing something in a similar format this would be useful BJG
- Merge configs
- The idea is to apply a diff to a configuration
- Display the modificiations to the config suggested by the results of the test.
- This goes to COOL, so could be generated from that (in XML)?
The first was orignally done my modifyABCD methods in SctApi, because we didnt want to reload complete configs to the ROD. Now that the API only copies the required sub-set of the config, and the configs are being changed more often, perhaps this could be reconsidered? (What's the alternative?)
- ROD Errors to MRS
- Hopefully now does something reasonable
- Alter the text buffer extraction thread in SctApi to make it grep the returns for the message "ERROR" and send messages that match to MRS.
- At request of Peter the grep has now been changed to a case-sensitive grep for the word "EVENT". Chris (See 1.146.4.28 of crate.cxx)
- The previous code output the first 20 messages in a crate. This is now changed to output any text buffer with the string "version", for records Bruce
- Also tidied up code, does the removal of '\0' do anything?
- We also need to start reading out, saving and maybe parsing the content of the error info struct. This will become especially important if we start to allow scans to continue despite (small numbers of) errors.
- Note that the error info struct does not presently contain info about erros flagged in the ROD event trailer. We may wish to add this before going further down this line.
- CVS SctApi now saves this to a file... a first step
- massacreCommon
- massacreCommon killsCommon on every machine referenced via TDAQ_DB_DATA. Update MiniUtils. Chris
- NB. The implementation works by extending to killCommon some extra functionality whereby you can specify on its command line a list of computers that should be ssh'ed to before executing kill common. So that you don't have to work out this list of computers, a new script 'daqListComputers' works out this list for you from OKS and TDAQ_DB_DATA. So the following are equivalent
massacreCommon killCommon `daqListComputers`
- if you want you can now do
killCommon hostFoo hostBar
- Replace daqListComputers with:
- dal_print_hosts --data oksconfig:$TDAQ_DB_DATA
- Done. Chris
- dal_print_hosts --data oksconfig:$TDAQ_DB_DATA
IGUI stuff
- Defining RODs, expanded mode, edge mode and so on as Resources under RunControl
- Not sure about expanded mode and edge mode, as they're not toggles.
- What should be a resource? RODs? TIM?
- Would be useful to make RODs and the ROS channel they connect to the same resource? or link so both on together.
- Lasers on/off darkness resource??
- Add panel or button to bring up Dave's GUI
- For this need to set up CLASSPATH, add JarFiles? to Segment, or to SW_Repository
- This is now DONE, sort of! Well, I've added a panel which should load provided you update $SCT_ROD_DAQ/start and $SCT_ROD_DAQ/setup.[c]sh ... whether it launches the gui or not probably depends heavily on whether the gui was in the path at the time the IGUI was launched. Oh and you should also update GuiComponents? and compile it! Chris
- Alternative, GuiComponents?.IGuiPanels?.General, but needs CLASSPATH setting up
- Maybe this Panel is where selection of expanded, edge mode etc should go.
Could also add:
- Current run mode according to SctApi (would need to go in IS?)
- Trigger source (ie summary of TIM settings)