Need Expert comment on .exe problem

[ramji]

Dear All ,

Iam using two exe 's . for example a.exe and b.exe

a. exe contains ( one.vi , two.vi , three.vi , four.vi ) and b.exe contains ( eight.vi, nine.vi,ten.vi)  . there are some subvi's which is common in all vi 's . but that subvi's are reentrant.

Now , when iam running a.exe first and b.exe second .... it opening all the application correctly without any problem .

But if i run b.exe first and a.exe second ..... then b.exe opens eight.vi , nine.vi , ten.vi , one.vi ,two.vi  and a.exe opens one.vi, two.vi, three.vi, four.vi .

Problem ( Why iam getting this repetation of vi.)

I made all probability of creating the exe like shutting down the server and making exe , creating exe in laptop and tansfering it to server , but nothing helps .

Regards

Ramji

[pincpanter]

It's not clear to me what you are doing. Can you post your code or give more information?
How are you opening vi's? Dynamically? In sequence?
Generally speaking, two exe should not mutually interfere unless they use the same resources, for example a file or an acquisition board.
Shared resources are always memory (RAM/virtual), CPU time and disk access, but that's all.

Paolo

Message Edited by pincpanter on 05-02-2006 12:23 PM

[ramji]

i have added other vi's in ADD TOP LEVEL VI .

one exe to another exe is not shared by common database , but it was shared by common subvi's.

[pincpanter]

So your exe is loading vi's that it does not contain. At a first glance it seems rather unlikely: are one.vi and two.vi subvi of any among (eight.vi, nine.vi,ten.vi)?
Do they appear into the VI Settings tab while building b.exe? Are you using different bld files or modifying a single bld to obtain the exe?
What's your LV version?
Sorry for so many questions, but all this sounds very strange to me. Posting of the actual code would be very useful.

Paolo

[ramji]

Hello Paolo ,

So your exe is loading vi's that it does not contain ---- this statement is correct , but only when iam running b.exe first and then a.exe.

one.vi , two.vi .... ten.vi having some common subvi's but that subvi's are reentrant.

No iam not find any of the previous vi ( one.vi , ... four.vi ) in vi setting tabs.

Are you using different bld files or modifying a single bld to obtain the exe? --- sorry iam not able to get you.

LV7.1

its very big application ... thats the reason iam not able to post it . moreover the problem iam not finding when i run the application in my laptop .

only when its running in the server in customer plant ... iam finding his problem.

Regards,

Ramji

[pincpanter]

Ok I will try to give a possible explanation, although so many details are missing: One.vi and Two.vi may be dynamically loaded by (eight.vi, nine.vi, ten.vi) or any of their subvi's.
Loading is only possible on the server machine, on your laptop they cannot be found.
I understand that this explanation has many flaws, but I can't figure out anything else.
As a check, try opening (eight.vi, nine.vi, ten.vi) and searching (ctrl+F) "one" and "two" as a text, including subvi's in the search.
Sorry but no more ideas for now.

Paolo

[EdDickens]

I'm not sure I completely understand the problem, but I'm going to throw out some information to see if it helps.

When you build a VI into an executable, it behaves different when it runs.

When you run your two top level VIs from within LabVIEW, the "common" sunVIs will run from the same instance of the subVI on disk because only once instance of a VI can be in memory at a time. Making a VI reentrant still has each call using the same VI from disk, it just loads each instance of the call into a different memory space so they don't share data between calls.

When you build an executable, each .exe file will get it's own copy of the "common" subVIs and each top level will call it's subVIs from within the .exe file and will not share. This is because each instance of an executable will be running in it's own instance of the LabVIEW Runtime engine.

Right now I'm guessing that the problem of it running different on your laptop od server is because you are running in LabVIEW on your laptop and running in teh runtime engine on the server.

Does this sound at all like what might be happening? If not, please try and post some more details so we get this figured out.

Ed

[ramji]

Hello Edwin Dickens,

Yes what you have mentioned is the same what i thought . but how i can avoid this , i.e , opening of other vi when an .exe is executed.

Regards,

Ramji.

[EdDickens]

Let me make sure I understand the problem.

You state that you have two .exe's. "one.exe" contains "a.vi", "b.vi", "c.vi" and "two.exe" contains "d.vi", "e.vi", "f.vi" and they do share some common subVIs, let's say "x.vi", "y.vi", "z.vi".

Now, if you run "one.vi" before "two.vi", everything seems normal. But, if you run "two.vi" first, it is opening up "a.vi" and "b.vi" that should only be opened when "one.exe" is running.

Are these dialog type VIs that open thier front panel when run? What I'm asking is how do you know they are opening.

The only logical explaination is that some where from within "two.exe" they are being called. Try renaming your "two.exe" to "two.llb" and open it with the library manager and see if there is a copy of "a.vi" and "b.vi" inside. If there is, I would think they are either being called from somewhere else that you are aware of, or you could possibly have them included as dynamically loaded VIs in the application builder.

Is there any way you can create a small example that shows the problem so you can post it here? That would help a lot.

Ed

[ramji]

Hello Dicken ,

What you have understood is perfectly what iam facing now .

this problem is happening only in customer server , not in my laptop or any other server .

that was the main reason iam not able to post the vi .

today i tried by making once again new exe's .

on the firsttime it created the problem then i closed all the application and tried again but  on second time   it opened perfectly ..... it means there is no consistency .

thankyou for your valid info .

all vi's are dialog type vi .

Regards,

Ramji