Fix usage of lcls-twincat-general / duplicate GVL_Logger symbols

[klauer]

Downstream libraries which include both lcls-twincat-general and lcls-twincat-pmps result in duplicate symbols for GVL_Logger which breaks IOC generation.

Unclear as to the exact fix; this needs some research.

Duplicate symbols:

$ pytmc summary --symbols plc/plc-kfe-vac/plc-kfe-vac.tsproj  |grep GVL_Log
    GVL_Logger.TCPADS_MAXUDP_BUFFSIZE : UDINT (3072800 32)
    GVL_Logger.TCPADS_MAXUDP_BUFFSIZE : UDINT (19932800 32)
    GVL_Logger.cLogHost : STRING(15) (3072896 128)
    GVL_Logger.cLogHost : STRING(15) (19932608 128)
    GVL_Logger.fbRootLogger : LCLS_General.FB_LogMessage (3073728 26944)
    GVL_Logger.fbRootLogger : PMPS.LCLS_General.FB_LogMessage (21634560 80896)
    GVL_Logger.iLogPort : UINT (3072144 16)
    GVL_Logger.iLogPort : UINT (19932512 16)
    GVL_Logger.sIpTidbit : STRING(6) (3073024 56)
    GVL_Logger.sIpTidbit : STRING(6) (19932736 56)
    GVL_Logger.sPlcHostname : STRING(80) (3073080 648)
    GVL_Logger.sPlcHostname : STRING(80) (19952480 648)

Note that the above symbols are allocated twice on the PLC at different locations.

Short-term hack to allow this bad behavior in pytmc:

pytmc db --allow-errors ...

[slacAWallace]

Pinging this issue to see if it's still a problem. I'll close this tomorrow if I don't get a response.

[klauer]

I believe it is just being ignored, unless you provided a fix directly to @ghalym.

[ghalym]

I haven't encountered this issue again, even when not using the --allow-errors.

[klauer]

Any idea what was the resolution? Cleaning/rebuilding .tmc files?

[ghalym]

Not sure, I actually thought that was resolved in either a new pmps or general lib release.

[klauer]

@slacAWallace reports resolving this in https://github.com/pcdshub/lcls-twincat-pmps/pull/45 . Can you include details here @slacAWallace?

[slacAWallace]

Credit where it's due, @ZLLentz realized the answer first.

Turns out pinning references in libraries referenced by a project will cause TC to build the tmc including resolutions for each referenced version of a type.

Ie. PMPS 0.7.0 built with a fixed reference to general 2.3.4, @ghalym builds the GATT with PMPS 0.7.0 and general set to 0.0.0, and gets duplicate tmc entries.

A potential fix might be to use the namespace tag included with these symbols to resolve the one pytmc should build a PV for. It is a workaround because TC gives no indication which symbol you're actually addressing by name with ADS. So at some point TC is making a decision to ignore one of those symbols...

I think this also explains another weird TC issue we run into sometimes where it will claim a type is not equal to itself during a build. It's a super weird thing to see because it looks like, 'STRUCT_A Is not Equal to type STRUCT_A' and you're left wondering about the nature of this universe. It does start to make sense though when different libraries are attempting to use the same type (by name), with actual differences between the types across the different referenced versions. A more direct error message about a resolution conflict would make TC better.

[slacAWallace]

As an example: Severity Code Description Project File Line Suppression State Error Type 'FB_LREALFromEPICS' is not equal to type 'FB_LREALFromEPICS' of VAR_IN_OUT 'fbBYKIK_Rate' KFEArbiter C:\Users\awallace\Documents\Source\lcls-plc-kfe-arbiter\Arbiter\KFEArbiter\POUs\CurrentBPUpdate.TcPOU 3

[klauer]

(Great work, @ZLLentz 👍 )

I see - that makes sense.

If we can find a programmatic way to check for this, I'd be happy to include it in pytmc. Perhaps we could at least just include the list of library references in the summary webpage to aid in debugging 🤷‍♂️

[ZLLentz]

Does this also imply that if you load two versions of a library, you will have two instances of their library globals that don't talk to each other? This seems like a situation ripe for confusing bugs in PLC land too.

[ZLLentz]

RE: finding it in pytmc, it should be theoretically possible since pytmc already notices that there are duplicate entries. When one of the failures occurs, one of the entries will have a additional namespace section in the tmc file that has a screwy-looking path on it with at least one library name.

[slacAWallace]

Does this also imply that if you load two versions of a library, you will have two instances of their library globals that don't talk to each other? This seems like a situation ripe for confusing bugs in PLC land too.

This is exactly what I mean by at some point TC decides which one to use and doesn't tell us. Big ol' shrug here.

[klauer]

OK, I'll make a preliminary issue referencing this one in pytmc.