Jump to content

Strange "rendezvs" and "semaphor" project dependencies


Jim Kring

Recommended Posts

[status: Reported to NI]

Related to the post, here, I have isolated the steps to reproduce the problem.

Steps to Reproduce

1) Open a new project

2) Add a new VI to the project

3) Place "Create Rendezvous.vi" (.\vi.lib\Utility\rendezvs.llb\Create Rendezvous.vi) and "Create Semaphore.vi" (.\vi.lib\Utility\semaphor.llb\Create Semaphore.vi) on the Block Diagram of the VI.

4) Save the VI to some location on disk.

5) Close the VI's front panel (which will unload it from memory).

Observed Results

Two new items, "rendezvs" and "semaphor", appear in the project's "Dependencies" list.

Expected Results

I do not expect these new items, "rendezvs" and "semaphor", to be in the Dependencies list. They are not VIs or project libraries. Rather, they are the names of the LLB files where these two VIs are located (respectively).

Link to comment

QUOTE(Aristos Queue @ Oct 29 2007, 06:25 PM)

I looked inside semaphor.llb and found sort of what you're talking about, but not exactly. It looks to me like the file is Semaphore Refnum, not semaphor.

post-2992-1193754342.png?width=400

EDIT: The situation is the same in rendezvs.llb: The file is Rendezvous Refnum, not rendezvs.

This interests me because I've seen a dependency called systemexec in some of my projects that I can't trace to anywhere:

post-2992-1193754883.png?width=400

Is it another instance of the same thing?

Link to comment

Hm... then I don't have any clue why those are showing up. I thought it might be some weirdness with the lack of file extension (that shouldn't be an issue, but with LV so Windows-centric sometimes the cases that we used to handle well that are more common on Mac get missed; seems that's not the case this time).

Link to comment

QUOTE(Aristos Queue @ Oct 29 2007, 06:25 PM)

I'm pretty sure that these are the names of the respective LLBs and that these names don't show up anywhere else in LabVIEW.

QUOTE(Justin Goeres @ Oct 30 2007, 07:28 AM)

...

This interests me because I've seen a dependency called
systemexec
in some of my projects that I can't trace to anywhere:

post-2992-1193754883.png?width=400

Is it another instance of the same thing?

Yes, I think so. Actually, I've got loads of similar strange dependencies. For example, I have also have a dependency called mscorlib (which no extension) which seems to come from the fact that the code is calling into the mscorlib.dll .NET DLL. And, when I'm calling other .NET DLLs, these show up as root-level dependencies with no file extension.

Link to comment

I've done a little bit more experimenting and found another quirk. Please see the attached sample project.

Download File:post-17-1194298015.zip

1) Open the "DotNetTest.lvproj" project.

2) Note that there is nothing in the "Dependencies" node of the project.

3) Open the Front Panel of "DotNetTest.vi"

4) Note that "System" appears in the "Dependencies" node of the project.

5) Close the Front Panel of "DotNetTest.vi"

6) Note that "System" disappears from the "Dependencies" node of the project.

post-17-1194298087.png?width=400

Comments:

"DotNetTest.vi" calls into the "System" .NET assembly (System.dll), which is part of the .NET framework and is in the Global Assembly Cache (C:\WINDOWS\assembly). I do not understand why this appears in the dependencies list as a VI and why it only appears in the dependencies list when the VI is in memory and disappears when the VI is not in memory.

And, here's some more info:"rendezvs", "semaphor", and "systemexec" are the names of Code Interface Nodes (CIN) that are called by the Renzezvous, Semaphore, and System Exec VIs.

For example, these are the names as they appear in the output of the VI Server Application method "Linker:Read Info From File".

post-17-1194298600.png?width=400

Thanks,

-Jim

Link to comment
  • 2 weeks later...

QUOTE(Jim Kring @ Nov 5 2007, 04:37 PM)

I've done a little bit more experimenting and found another quirk. Please see the attached sample project.

Download File:post-17-1194298015.zip

1) Open the "DotNetTest.lvproj" project.

2) Note that there is nothing in the "Dependencies" node of the project.

3) Open the Front Panel of "DotNetTest.vi"

4) Note that "System" appears in the "Dependencies" node of the project.

5) Close the Front Panel of "DotNetTest.vi"

6) Note that "System" disappears from the "Dependencies" node of the project.

post-17-1194298087.png?width=400

And, here's some more info:"rendezvs", "semaphor", and "systemexec" are the names of Code Interface Nodes (CIN) that are called by the Renzezvous, Semaphore, and System Exec VIs.

For example, these are the names as they appear in the output of the VI Server Application method "Linker:Read Info From File".

post-17-1194298600.png?width=400

That was my first guess starting to read this thread and I'm pretty sure you hit the nail on the head. The Dependancies scan in the project is almost certainly using the "Linker:Read Info From File" but probably only when loading a VI. This function is very fast in returning all relevant dependancies including CINs, external code libraries and such so it makes sense to use it instead of trying to do something in LabVIEW itself which would be WAAAAAY slower.

I'm not sure it makes sense to show the CIN as a dependancy as it is really already embedded in the relevant VI and as such there is no physical file on disk that could be mapped to this item. So probably the filtering of the items should have taken out CINs or otherwise it should at least use a different icon.

Rolf Kalbermatter

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.