@jerzyjamroz @gabrielfedel Any more suggestions before we can complete this PR?

@hongran , sorry for the long time to answer. I tried to test this branch on our system but I got these errors:

ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp0-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp1-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp2-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp3-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp4-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp5-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp6-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp7-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp8-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp9-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp10-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp11-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp12-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp13-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp14-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp15-Sel

@gabrielfedel I think it is due to the configuration of the mtca card. I am checking the config struct:

 struct Config {
        const char *model;
        unsigned numFrontInp,
                 numUnivInp,
                 numRearInp;
    };

The config for mtca is

static const evgMrm::Config conf_mtca_evm_300 = {
    "mTCA-EVM-300",
    3,
    16,
    0,
};

Could you revise the config for the mtca card? According to the manual, the mtca EVM has 1 front panel input, 0 UNIV input (on front panel), 8 I/O ports on the back plane, and 10 input ports on the transition board. The current setting 3 FP input, 16 UNIV input and 0 rear input seem not correct.
(BTW, though there are no UNIV inputs for both VME and mTCA cards, we should have the number of UNIV inputs 16 to handle the EVRU and EVRD interfaces. The pulse outputs from the EVRU and EVRD are internally wired to the UNIV input ports.)

I also noticed that the code does not differentiate back plane ports and transition board ports. Currently the "Rear" ports are treated as transition board ports.

The db file I made was for the VME board which has 16 transition board inputs, but the mtca has 0 in the current config. That's why you saw the errors. Since the number of records for the ports are hard-coded in the evgInput.db, evgTrigEvt.db and evgDbus.db files, it is difficult to make them fit for both VME and mTCA. Any suggestions?

@hongran , sorry for the long time to answer. I tried to test this branch on our system but I got these errors:

ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp0-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp1-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp2-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp3-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp4-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp5-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp6-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp7-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp8-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp9-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp10-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp11-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp12-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp13-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp14-Sel
ERROR: Device pvt field not initialized : TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp15-Sel

@gabrielfedel @jerzyjamroz Hello, have you got a chance to take a look at my last reply? Any suggestions on resolving this issue? If it creates too many hassles to make a db file that fits all cards, I can make a new db file specifically for vme-300, and we can take more time to discuss how to handle this in the future. I would like to have the code we used at APS reconnected to the upstream branch as soon as possible, before we go too deep into operation, and I still have quite a few updates to push. If this PR is merged, it will be easier for me to handle the rest of PRs.
Thanks!

Hi @hongran , sorry for the long time again.

So what you pointed out from the MTCA EVM is really not corrected:

static const evgMrm::Config conf_mtca_evm_300 = {
    "mTCA-EVM-300",
    3,
    16,
    0,
};

I will double check that, but I think we could handle this in another MR.

One of the reasons it has been so long for my answer was because I was looking into what would be the best way to solve the different dbs for MTCA and VME. So my suggestion is the following:

You try to keep the existent db's compatible with MTCA (as they are now), and you will include new db's that will "patch" the existent ones for VME. For example for evgDbus.db, you can create the evgDBusVME.db that could have:

record("*", "$(P)Src-Sel"){
    field(UNSV, "INVALID")
   field(FLNK, "$(P)SrcItlk-SQ_.PROC PP")
}

record(seq, "$(P)SrcItlk-SQ_") {
....
}

You can use the "*" to overwrite the existent records, and include new ones. Then you will include these new db files on the substitution of the VME. The important is that the new db files come after of the existent ones, so the records with "*" will overwrite the existent ones.

Does that makes sense ?

Hi @hongran , sorry for the long time again.

So what you pointed out from the MTCA EVM is really not corrected:

static const evgMrm::Config conf_mtca_evm_300 = {
    "mTCA-EVM-300",
    3,
    16,
    0,
};

I will double check that, but I think we could handle this in another MR.

One of the reasons it has been so long for my answer was because I was looking into what would be the best way to solve the different dbs for MTCA and VME. So my suggestion is the following:

You try to keep the existent db's compatible with MTCA (as they are now), and you will include new db's that will "patch" the existent ones for VME. For example for evgDbus.db, you can create the evgDBusVME.db that could have:

record("*", "$(P)Src-Sel"){
    field(UNSV, "INVALID")
   field(FLNK, "$(P)SrcItlk-SQ_.PROC PP")
}

record(seq, "$(P)SrcItlk-SQ_") {
....
}

You can use the "*" to overwrite the existent records, and include new ones. Then you will include these new db files on the substitution of the VME. The important is that the new db files come after of the existent ones, so the records with "*" will overwrite the existent ones.

Does that makes sense ?

Yes. I will give a try and update this MR.

@hongran , I have done the review and it looks it works ok except the fact I didn't test that physically with MTCA RTM.

Few things:

1. DbusXSrc2-Sel FrontInp2 - I think it is better to use Front2 so it follows.
2. PpsInp1-Sel UnivInp11... - better to follow Univ11,12,13,14,15
3. PpsInp1-Sel RearInp0 - so Rear0.

The solution with the extension of mbbo is a bit dirty. Designing a more generic thing to handle mbbo 64 selections would be nice.

Please let me know what you think.

@hongran , I have done the review and it looks it works ok except the fact I didn't test that physically with MTCA RTM.

Few things:

1. DbusXSrc2-Sel FrontInp2 - I think it is better to use Front2 so it follows.
2. PpsInp1-Sel UnivInp11... - better to follow Univ11,12,13,14,15
3. PpsInp1-Sel RearInp0 - so Rear0.

The solution with the extension of mbbo is a bit dirty. Designing a more generic thing to handle mbbo 64 selections would be nice.

Please let me know what you think.

@jerzyjamroz and @gabrielfedel , I just realized that the records (like TD-TEST:Ctrl-EVM-1:TrigEvt0TrigSrcRearInp0-Sel) are hard-coded in eftTrigEvt.db. If we keep it that way there is no way to make a db file that works for both the mTCA and VME cards, since there are 16 transition board channels for VME while there are 10 for mtca. Besides the mbbo records, I also need to extend many records like this. I think it is better to make separate db files for vme-300 cards.

If you agree with separate db files, I will push a commit to the MR and make sure the existing db files are the same as those in the master branch except the mutual exclusion mechanism.

Ran Hong

@hongran :

1. $(s=:) - you do not need to add it to the new .db records. It only covers the legacy and if something is new, it is not in use by the community.
2. I think this PR is acceptable for now, check the PR update: fix: db-vme300-dev branch hongran/mrfioc2#1 I would merge everything and then prepare new PR-s with the proposal.
3. It would be nice to find a more universal way of handling the super long mbbo-s. If no ideas, then splitting the .db files might be an option.

@hongran :

1. $(s=:) - you do not need to add it to the new .db records. It only covers the legacy and if something is new, it is not in use by the community.
2. I think this PR is acceptable for now, check the PR update: fix: db-vme300-dev branch hongran/mrfioc2#1 I would merge everything and then prepare new PR-s with the proposal.
3. It would be nice to find a more universal way of handling the super long mbbo-s. If no ideas, then splitting the .db files might be an option.

I have merged your PR. Thanks for making the changes. Now the number of I/O ports are the same, so I don't need to make new db files for now. After I have other contributions in the queue merged, I will come back to this issue and probable we can come up with new ideas.