New Feature: Adding functionality for V3 electronics calibration

[bdorney]

Description

Adding functionality for new CTP7 RPC modules for VFAT3 functionality.

@evka85, @mexanick, @jsturdy, @cbravo135

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context

New CTP7 RPC modules have been added in: https://github.com/cms-gem-daq-project/ctp7_modules/pull/2/

Right now I've tried to add the following new functions to src/common/rpc_standalone_client/rwreg.cpp:

• vfatSyncCheck(...),
• configureVFAT3s(...),
• configureTTC(...), and
• scanDAC(...)

However I had a couple of questions about this implementation:

• Should we start to partition rwreg.cpp into multiple files?
• In some cases above there were already existing methods, e.g. configureVFATs(...) vs. configureVFAT3s(...) or configureTTC(...) vs. getmonTTCmain(...). It seems since the wisc::RPCMsg object should be a specific RPC module should we keep separate methods as I have done here, or have a single method, e.g. configureVFATs which correctly chooses the right wisc::RPCMsg object? If so on what basis? A flag? Or the CTP7 firmware version (I guess preferred?)
• The script setup.sh doesn't seem to set the computing environment such that this can be compiled. Could I get some advice on this @mexanick?

Finally, what is the way to move forward to use this functionality in our scan routines? Maybe this is a more appropriate discussion in vfatqc-python-scripts; but for the case of ultraThreshold.py I would envision changing lines 91-111 to something like:

    import intermediate RPC library stuff
    cpt7FWVersion = getCTP7FWVersion(...)
    if cpt7FWVersion > LastV2Version:
        call intermediate RPC library which calls `configureVFAT3s(...)`
    else:
        writeAllVFATs(ohboard, options.gtx, "Latency",     0, mask)
        writeAllVFATs(ohboard, options.gtx, "ContReg0",    0x37, mask)
        writeAllVFATs(ohboard, options.gtx, "VThreshold2", options.vt2, mask)

    if cpt7FWVersion > LastV2Version:
        store orig trigger source via call to intermediate RPC library which calls `configureTTC(...)`?
    else:
        trgSrc = getTriggerSource(ohboard,options.gtx)
    if options.perchannel:
        if cpt7FWVersion > LastV2Version:
            call intermediate RPC library which calls `configureTTC(...)`?
        else:
            setTriggerSource(ohboard,options.gtx,0x1)
            mode[0] = scanmode.THRESHCH
            sendL1A(ohboard, options.gtx, interval=250, number=0)

        for scCH in range(CHAN_MIN,CHAN_MAX):
            vfatCH[0] = scCH
            print "Channel #"+str(scCH)
            if cpt7FWVersion > LastV2Version:
                call intermediate RPC library which calls scanDAC(scanData, ...)
            else:
                configureScanModule(ohboard, options.gtx, mode[0], mask, channel=scCH,
                                scanmin=THRESH_MIN, scanmax=THRESH_MAX,
                                numtrigs=int(N_EVENTS),
                                useUltra=True, debug=options.debug)
                printScanConfiguration(ohboard, options.gtx, useUltra=True, debug=options.debug)

                startScanModule(ohboard, options.gtx, useUltra=True, debug=options.debug)
                scanData = getUltraScanResults(ohboard, options.gtx, THRESH_MAX - THRESH_MIN + 1, options.debug)

The final goal being the hardware version is transparent to the user and keeping the output TTree structure identical so no changes to gem-plotting-tools are needed so analysis is immediate.

How Has This Been Tested?

Has not yet been tested. Have a couple of questions.

Screenshots (if appropriate):

Checklist:

• [ ] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.

[cbravo135]

We already have some examples to show you how we have been testing this. Lets meet and discuss the test script Evaldas and I have been using. Some of this work has also been done for you, so wait until we merge the C interface part first.

[bdorney]

Great, I'd like to take a look. I think we should also meet to discuss how we scale up what we are doing this week? e.g. what is the connection between these RPC Modules we've been working, cmsgemos/gempython, and xhal. Maybe @jsturdy could also join us?

[mexanick]

I'm going to close this pull request since we need more then just adding functions to rwreg.cpp and also bc the raised topic should be discussed in the vfatqc repo. @dorney, please create a new issue there. Also you can create a github project where we can discuss required changes in friend repositories.