Executable of Custom Teststand UI cannot load LV module of certain lvlib in Runtime Engine

[stefanha]

Hello and sorry for the vague title,

I am facing a very weird behavior of a LabVIEW code module not being able to be loaded from a Teststand sequence in very specific circumstances.

I tried to narrow down the root cause with the following tests:

- The issue only occurs when I run the TS sequence in our executable TS user interface.
When I run the sequence in the TS sequence editor or the LabVIEW version of the TS user interface, there is no issue.

- The issue only occurs when I call the VI with the setting "always run in runtime engine".

- The issue only occurs when the VI is part of a specific library. When I move the VI out of the library or even into a different library, there is no issue.

- There are more than 20 different VIs being called from the same "faulty" library in the same way without any issue.

- The difference between this VI and all the others originally was, that the VI had a different setting for the "prefered execution system" being user-interface, because the DLL called inside required this setting in order to work. But even after setting it to "same as caller" like the other VIs, the error persists.

- I have made the front panel and block diagram of the VI completely empty. The issue persists.

This is the content of the error log file:

Header: { VI Path : C:\temp\Test.vi }

VI error :

Unknown error type found in the LabVIEW Debug Log. Please refer to the log file from TestStand for more information

The following VIs are broken:
C:\temp\Test.vi

Raw Log :
HEADER: {

AppName: GAMAT_GUI

EditorVersion: 20.0.1 32-bit

AppModDate: 11/02/2021 11:36 GMT

AppPath: C:\Projects\StandardSW\gamatgui\Exe

OSName: Windows 10 Enterprise 2016 LTSB

OSVers: 10.0

OSBuild: 14393

}

{

mode: "VI_BROKEN";

callSite: "SetVIBad";

timestamp: "2021-11-08T17:34:07.329813";

vi: { name: "DataApi.lvlib:Test.vi"; path: "C:\temp\Test.vi";}

callchain: [];

callers: [];

}

{

mode: "VI_BROKEN";

callSite: "VirtualInstrument::SetOrClearBadVILibrary - now VI is bad";

timestamp: "2021-11-08T17:34:07.330814";

vi: { name: "DataApi.lvlib:Test.vi"; path: "C:\temp\Test.vi";}

callchain: [];

callers: [];

misc: { flags: 0x2002200; compilerError: 7; }

}

{

callSite: "TOP_LEVEL_BROKEN_LOAD_begin_report";

timestamp: "2021-11-08T17:34:07.331817";

}

{

mode: "VI_BROKEN";

callSite: "VILinkObj::SetSelfErrorsCORE - VI is bad";

timestamp: "2021-11-08T17:34:07.331817";

vi: { name: "DataApi.lvlib:Test.vi"; path: "C:\temp\Test.vi";}

callchain: [];

callers: [];

misc: { viflags: 0x2002200; viflags4: 0x0; viflags6: 0x2000000; }

actualCallSite: "TOP_LEVEL_BROKEN_LOAD_report";

}

{

callSite: "TOP_LEVEL_BROKEN_LOAD_FINISHED";

timestamp: "2021-11-08T17:34:07.331817";

startTimestamp: "2021-11-08T17:34:07.329813";

numberOfVIsLoaded: 1;

numberOfBadVIs: 1;

numberOfFailedLoadVIs: 0;

secondsSpentReporting: 0.000381596;

}

Any help is appreciated.

Best regards,

Stefan

[Anand_Jain]

Hi, 

Couple of questions:

1. Do you still get this error if you build the UI with the advanced option - "Use LabVIEW 8.x file layout" disabled? If that is the case, then you might have a duplicate VI of the same name that is already being loaded by the RTE. 

2. Do you get this error with the default shipping UI?

Regards, 

Anand Jain

NI

[stefanha]

Hi and thanks for taking your time.

1. I have checked and the "Use LabVIEW 8.x file layout" option was already disabled in the build configuration. However I created a fresh "Test.vi" with empty block diagram and front panel, added it to the library and faced the same behavior. So I don't think a duplicate VI name is the issue.

2. Unfortunately all default shipped UI's are 64-bit only. But after creating a fresh test sequence with only the "Test.vi" inside and recompiling it in LV 64-bit, I could successfully load and run the test sequence in the simple UI.

After compiling it back to LV 32-bit and trying again to run that test sequence in our UI, the issue came up again.

[stefanha]

I was finally able to figure out the root cause for the issue, thanks again to your hints.

The issue occured when I was putting the VI into a LV library which the UI Exe was also using. But during the time of the build, this VI of course was not part of the library.

Apparently this behavior cannot be handled by the RTE. I'm assuming because it would mean two different versions of a LV library with the same name, so it is a namespace issue after all?

In order to avoid the issue I only see two options, both of which are not really satisfying:

1. Rebuild the exe whenever a VI was added to any library the UI also uses

2. Not to use any common sources in the UI and instead create a copy of everything into the UI project.