db file update and bug fix

[hongran]

Updates for consistency:
1: In the evr-vme-300 substitution file, for the transition board output records, TBUV is changed to RBUV because the objects in the drivers are like RearInput.
2: Added Univ11-15 to the DBus source selection, so that all Univ inputs can be used. Mainly for EVRU and EVRD interface

Bug fix:
1: Fixed the FLNK filed of the Mxc reset enable for hardware input channels
2: Fixed the evm-vme-300 substitution file regarding the bit assignment for the 1 Pps source.

[hongran]

@jerzyjamroz I also took a look at the evm-mtca-300 substitution file and I found the 1Pps source bit assignment was not correct either. FP0 and FP1 are right but the rests are not. I guess no one was actually using other input as the 1Pps sources. Should we correct them in this PR too?

[jerzyjamroz]

@hongran , the documentation gives the reference here:

It means rear does not exist but TB yes.
The Cpp names are legacy but not the records.
I realized that the MTCA .uv file is not updated but it will follow:

In/OutTB0",
In/OutTB1",
In/OutTB2",

[jerzyjamroz]

FP0 and FP1 are right but the rests are not.

@hongran Feel free to contribute the correction.

[jerzyjamroz]

Shouldn't it be:

{"\$(P)InpRear0", "$(EVG):RearInp0", 6, "1"}

?

[hongran]

It should be bit 5. The mbbi value is 0x20, which is bit 5 (0x01 is bit 0).

[jerzyjamroz]

It should be bit 5. The mbbi value is 0x20, which is bit 5 (0x01 is bit 0).

I think it would be nice to group: evgMrmApp/Db/evgTrigEvt.db into mbbo-s like:

1. Mxc + AC + Front
2. Univ0..9
3. Univ10..15
4. Rear0..9
5. Rear10..15 (it would be not used by MTCA).

and evgMrmApp/Db/evgDbus.db using the same concept.

Let me know your opinion.

[jerzyjamroz]

As in the manual: InpRear -> InpTB change suggested.

[jerzyjamroz]

OutTBUV -> OutTB (as in the manual).

[hongran]

@hongran , the documentation gives the reference here: It means rear does not exist but TB yes. The Cpp names are legacy but not the records. I realized that the MTCA .uv file is not updated but it will follow:

In/OutTB0",
In/OutTB1",
In/OutTB2",

Sure. Making it consistent with the manual is good.

[hongran]

@jerzyjamroz There are more record names and mbbo bit strings with name like RearInp in evgMrm.db, evgDbus.db and evgTrigEvt.db. Should we change all of them (Rear -> TB)? I am worried that such changes cause issues in facilities that are using them.

[jerzyjamroz]

I am worried that such changes cause issues in facilities that are using them.

I do not have a clear idea how to approach that, but even your suggestion here:

{"\$(P)OutRBUV00", "$(EVR):RearUniv0", "RBUV 0"}

introduce more confusion with RB (why not OutRear0 but new name? And TB in the DESC).

Well, share your opinion, do you prefer to use Rear?

P.S.
It would be good that all the basic IO-s are named: FP, FPUV, UV, TB, BP.
It is something to think about. Also If we really need to adjust the -Sel strings to the PV names?

[hongran]

I am worried that such changes cause issues in facilities that are using them.

I do not have a clear idea how to approach that, but even your suggestion here:

{"\$(P)OutRBUV00", "$(EVR):RearUniv0", "RBUV 0"}

introduce more confusion with RB (why not OutRear0 but new name? And TB in the DESC).

Well, share your opinion, do you prefer to use Rear?

P.S. It would be good that all the basic IO-s are named: FP, FPUV, UV, TB, BP. It is something to think about. Also If we really need to adjust the -Sel strings to the PV names?

Yes, "Rear" is OK for me, so it is at least consistent with the rest of record names. I will fix the DESC, too. I will fix that commit.
I think as long as the "-Sel" strings have the key words as those in the PV names, I am OK with it.

[hongran]

I just updated the commit to make the naming scheme consistent with the rest of the database.