Python interface additions

[erik-wallin]

Here are a few things that would be convenient to bind to Python, either to use them in the actual run control, or just to have them available from the GUI or in the monitoring.

• ROC->LOAD
• ROC->DUMP
• BIAS control
• DAQ->STATUS
• FAST_CONTROL->STATUS
• The ability to check on the links, e.g. ELINK quality

What more?

[erik-wallin]

If we will also support the ECal in pflib, I suppose pflib::Target will not hold an HCal member anymore, nor should the PyTarget constructor call pflib::makeTargetHcalBackplaneZCU.

Splitting it up into two classes PyTargetHCal and PyTargetECal, inheriting some useful things from PyTarget, could make sense since the interfaces will be so different.

[tomeichlersmith]

So I want to avoid mirroring too much of pftool into Python just to avoid repeating code in two places. I guess I'm assuming that all of the ROC.LOAD and STATUS printouts would happen in the configure function and if more debugging is necessary, the person would "drop down" into a pftool session.

I agree that Ecal support will require refactoring pflib::Target.

---

Notes for future reference

RunControl calls Esa25Root.rc_action('Configure').
Esa25Root.rc_action() calls subsystem.rc_Configure() for each instantiated subsystem (tdaq, ts, tracker, ecal, hcal).
EcalSubsystem.rc_Configure() calls self.EcalBittware.rc_Configure()
EcalBittware.rc_Configure() calls e.g. self.Target.a() self.Target.b() as necessary to perform configuration.
The main thing we need to coordinate right now is basically "What should happen at each run control call"
We currently implement the following calls

rc_Connect()
    Fast Control state gets set to IDLE here
    Check that you can talk to the system
rc_Configure()
    The RunControl object will hold an EcalConfigFile Variable that is a path to the YAML config file
    You will load this config file into your hardware using appropriate pflib::Target calls
    If this is where you bring up your links, check that they are up
rc_RorLatency()/rc_TriggerAlign()
    I don't think ECAL/HCAL needs to do anything here, so no need to implement.
rc_Prestart()
    Run control sets FC state to PRESTART_1
    Perform any final settings or checks before the run begins
rc_Go()
    Run control sets FC state to RUNNING
    Probably no ECAL/HCAL things here. Run has begun.
rc_Stop()
rc_Reset()

[tomeichlersmith]

Yesterday, I looked at including an Ecal and I figured that an Hcal and Ecal can just be specific derived types of Target instead of having Target try to hold them. #255

I have not merged this refactor yet because I'm only like 60% sure it'll work, but I think it makes sense since both Hcal and Ecal have ROCs, ECONs, FastControl, DAQ, Elinks, etc...

Hcal has one extra thing - Bias - which will require the Target to be up-cast into an Hcal but that's not too hard.

If this idea does work, then the interfaces are not that different (except for Bias), its just different how the Targets implement talking to the different ECONs, ROCs, etc... but that is hidden within the different concrete classes that implement an Hcal or an Ecal.

[erik-wallin]

Started work on this in branch iss253. Because the HCal and ECal interfaces are not 100% the same, e.g. with regards to bias and there might be other system-specific differences we want to make, I've made two derived classes PyTargetHCal and PyTargetEcal so PyTarget doesn't have to juggle both. Waiting until your refactoring of Target is done.