Static VI Reference causes failure

[kdCMC]

Good day,

my application consists of an exe (labVIEW 2014) and a 'self-made' library (labVIEW 2014), both using many other lvlibs.

The failure (own defined error when detected that MODBUS initialization hasn't been done) is caused (in my opinion) by not executing a static vi reference.

The failure happens in the exe, before the library is loaded.

Both exe and library are using the same MODBUS lvlib.

I builded the library with the MODBUS lvlib in the NI program files branch.

I have 2 PCs to build & test. (So both PCs have the NI lv2014 Dev environement installed).

The failure doesn't occur when i build the exe with the MODBUS lvlib incorporated in his own project, not in the NI program files branch and on 1 specific PC.

On the other PC, i can't fix so that the exe is properly build (build succeeds; although having conflicts (not solvable...; properly build means that the exe executes withiout this failure)).

Same conflicts (not studied all of them) on the PC with properly build exe, even more conflicts...(i managed to get only 1 conflict on the not properly build pc...; on the properly build pc, it sees green of conflicts)!

when it is a lvlib, i can open it with lv and view the vi's incorporated after build, with an exe, i can not.

Can anyone put me on the right track to approach this problem, so that i can understand why it alwyas fails when build on that one PC?

It's not dll hell as with Windows, but lvlib hell. (I once solved similar cases with referencing into proper lvlibs and not to vi's under program files... ??)

warning: rather complicated, not for beginners. Sorry. I will not be able to delvier all sources...

thx.

[Sam_Sharp]

You really need to post something to show what's going on - I can't really understand what you're trying to do / how your project is structured / how you are calling the VIs etc. If you can at least post some screenshots of your project structure / build specification / how you're calling the VIs that would help.

You're saying you 'builded the library', which I'm assuming is the .lvlib...but then you still refer to a .lvlib - .lvlib is not a compiled file...it's just a collection of source files. If you're building it, are you talking about packed project libraries - .lvlibp files? That makes your .lvlib (+ the source files / dependencies) into a single .lvlibp file which you can then load/call in your application.

Edit: Chances are, your problem isn't caused by a static VI reference - they actually tend to make sure that everything you need is included in the executable without having to manually add the VI to 'always included' in the build specification. 

[kdCMC]

Good day Sam?

i would like You to give a kudo, just for accepting the challenge to solve this riddle.

i attached some screenshots in the hope You have something to start with.

i'm not using packed libraries. (not intentionally; You should be able to verify that in the screenshots)

the lvlibs ('self made') it concerns about are the MODBUS ones...

a static vi reference (not yet in the screenshots) references a vi in the modbus lvlib. in my opinion, my error appears when that static vi doesn't execute or not loads, or whatever...

mysteriously, on one pc, if i  build there, it works.

i'm now trying to compare with microsoft procesmonitor. perhaps i will also search for a NI tracer??

regards.

[Sam_Sharp]

Are you getting any errors generated in your software when it fails or tries to call the VI? It looks like you are calling the VIs dynamically...but from the sounds of it you also have a static VI reference - this probably means that LabVIEW is trying to load the file from disk but it already exists in memory because of the static VI reference. Is your modbus service library actually an .lvlib file or is it just an autopopulating folder? Most experienced LV devs will probably tell you to turn off auto-populating!

There is a tool called the Desktop Execution Trace Toolkit - you can use it to determine any errors that are generated (and perhaps not reported) in your application as well as debugging things like VI calls. You might find it useful to figure out what is going wrong.

Are you compiling to a .dll or to an executable? I don't understand why you're putting these files into an LLB inside a DLL?!

It sounds like there might be some sort of namespacing issue - VIs (e.g. SubVIs/dependencies) that get pulled into the executable have a different name/path once compiled into the executable.

[mikeporter]

You keep talking about errors, but I don't see errors. What errors are you getting? When do you get them?

Mike...

[kdCMC]

thanks, handfull of good tips, i will try them out or at least, i can try them out if i have time. thx. will keep this thread up to date.

[kdCMC]

Hey,

the error i get is a 'self made' error that tells us that a service was notstarted. this service is started in a static vi.

regards,

koen.

[kdCMC]

Good day,

after comparing with microsoft processmonitor, i found out 2 things till now:

1. see attached png file: lvClassInstance could not be created, possibly due to access restrictions??? don't know for sure this....

2. seems to be some problem with finding the "modbus service" (which matches my problem...) (see attached png (2).

3. I changed a build setting which was different between my 2 compared build systems on the different PCs (sse attached docx)

      After clicking ok, labVIEW warned me about missing items. I copied again my backups to the location, reloaded the project and then, it was ok to build or press ok (no missing items)

still my problem persists, still path not found for both modbus libraries in the process monitor.

don't know why i should not use auto population.

didn't use desktop execution trace toolkit yet, i perhaps will in the near future.

i have an exe which uses "dll"s, which are in fact just llb's. (previous creators used this convention, don't know why)

regards,

koen.

[kdCMC]

My problem is in my opinion equal to the "not solved" labVIEW thread '

<userlib> files not being found in built applicatio​n

'

i also just tried to use Desktop execution trace tookit, but while my problem occurs when starting the exe (not when started and taken action and also not when executed inside the labVIEW develop environement !!), i'm not able to use that tool.

remark to the above labVIEW forum thread: i have also other lvlibs into userlib, i'm used to work like that, and had no problems.

[rolfk]

Your app tries to call CreateFile on a path that points inside the executable file. While this path can be a valid path for a LabVIEW function that expects a VI file to load it definitely is completely nonsense to pass to the Windows CreateFile() API. You will have to investigate what part of your application tries to access the file like this. Most likely the app somewhere determines a VI path and then tries to Open it with File IO VIs.

It may be a red hering, meaning that it is some internal LabVIEW function that tries to access this path and then falls back to some other mechanisme if that fails but if it is something done in your application through the VI diagram it is definitely wrong. While I'm sure there exist reasons to not upload the source code it is pretty impossible to debug this without some actual project that exhibits this particular problem.

You will either have to debug this mostly on your own or call in some professional help who is knowledgeable about how LabVIEW executables need to be build and how to reference VI hierarchies that are located within that executable.