Open VI Reference LAN Help

Hi!
I have a LAN/TCP connection. On the side A, I have a simple VI, and I would like to call it from side B. How can I do that?
+++ In God we believe, in Trance we Trust +++
[Hungary]

Hi Durnek,
The best is to use the Application Control palette, create a VI server on side A, on side B open a reference to the VI server with Open Application Reference Function, then you can access the VI with Open VI Reference and using the Invoke and Property nodes from the same palette you have access to a lot of information and settings.
Let us know if you have more questions!
Have a good day!
Patricia

Similar Messages

Error 7 occurred at open vi reference in New Report.VI

Hello!
I use the report generation toolkit on LabView 7.0 to create a report in Excel. The program works fine until I make an executable version. I the get the error:
Error 7 occurred at open vi reference in New Report.VI
I use the New Report.VI, Bring Excel to front.VI and Save Report To File.vi
Can you pleace help me!!!

Most likely, you did not include the required libraries in your build script. When building an executable in which you use the Report Generation Toolkit, you must include the _Word Dynamic VIs.vi from _wordsub.llb and _Excel Dynamic VIs.vi from _exclsub.llb as dynamic VIs on the Source Files tab.
Check this article for more info.
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/86256a47004e16d186256a84004cb883?OpenDocument
Daniel L. Press
PrimeTest Corp.
www.primetest.com

Open VI Reference for a Project Library VI

Hi,
my code calls some subVIs by reference by using "Open VI Reference" and "Call by Reference" VIs. Now, "Open VI Reference" expects a path to the VI:
When the SubVIs sit in the same folder as the calling VI, it is easy to simply supply the name of the SubVI. However, I would like to call a SubVI that is part of a project library sitting somewhere else on the disk. I could give the relative path, but this make the code pretty inflexible and if the relative path changes all the paths would need to be ammended. Ideally, I want to utilize the fact that I am using a project library. The help for Open VI Reference states that
vi path accepts a string containing the name of the VI that you want to reference or a path to the VI that you want to reference. If you wire a name string, the string must match the full delimited name of a VI in memory on that target. If you wire a path, LabVIEW searches for a VI in memory that you previously loaded from that path on the same target.
I thought that the underlined path was my ticket and tried something like this:
but this did not work and I got
"Error 1004 occurred at Open VI Reference in MainVI.vi:
Possible reason(s):
LabVIEW: The VI is not in memory.
To load a VI into memory with the Open VI Reference function, a path must be wired for the VI Path input."
Wiring a path is not desirable as per reasoning above. Is there a way around the issue?
Thanks in advance!
Solved!
Go to Solution.

tst wrote:
That should work, but you have to pay attention to something that's stated both in the help and in the error - if you use a string, the only way for LV to know what to access is if that something is already "in memory" (sometimes also referred to as "being loaded"). In the case of standard libraries, that means the VI itself or one of its callers has to be loaded. In the case of classes and XControls, loading the library (as in having it in an open project) should be enough to also load all of its members.
Hm, thanks, I am not advanced enough to know about classes and XControls, but I will check it out. My VIs are part of a library but obviously don't get loaded because, as you said, all their calls are dynamic.
tst wrote:
What I usually do is use a static reference to a VI to get its name, because that ensures that it will be statically linked, included in executables, etc. That might not work for you if you want dynamic loading and then you will need to use some other means.
Hm, this actually gives me an idea! I could add an enable input to all these dynamically called VIs so that the logic runs only when enable is ON; otherwise the VI is called but does nothing. Then I call the VI first statically with enable=OFF just to load it in memory and then proceed with my dynamic call. A little ad-hoc, but should work and serve my purposes, I think.
Thanks!!

Using Open VI Reference to run a VI, on an RT target, with sub-VIs not loaded

I've been using Open VI Reference and Call By Reference Node to remotely run VIs on my RT controller. I
usually wire string data to the vi path input, but this
requires the VI to be in memory. I understand (from LabVIEW help) that I can wire a path to this terminal and specify a VI that is
not in memory, but is on the disk. NI has an example that
confirms my understanding. I get errors when I attempt to do the same
with VIs that have sub-VIs; I suspect that the problem is that
the sub-VIs aren't in memory and that the top-level vi doesn't know where to
look for them (because the paths aren't specified). All of the sub-VIs are on the RT system (in the same directory), they're just not in memory.
Is there a way to get LabVIEW to look for sub-VIs on the disk? I don't want to rely on using a startup application and rebooting to get my VIs into memory.
Thank you,
Jim Carmody
Software Engineer
G2 Technologies
www.g2tek.com
Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice

Hi Jim,
It sounds like you are going about calling VIs remotely the correct way. It would be very helpful if you could post the errors you are receiving. I also wanted to know if you saw the note at the bottom of the article that says your VI library must contain everything your top level VI calls.
Eric A.
National Instruments
Distributed I/O Product Support Engineer

Open vi reference conversion from Labview 6 to Labview 2014

Is there a way that someone can help me convert this VI written in Labview 6.1 so that I can work en EXE in Labview 2014.
I succed to open this vi from 6.1 to 2014 but it does not run. The open vi reference those not work in exe program. Someone know how I can replace that function...
Thanks!
Solved!
Go to Solution.
Attachments:
to convert 2104.zip ‏17 KB

Error 7 is File Not Found. So your dynamically called VI is not in your executable.
In the build spec for the executable in your project, there is a section for "Source Files". On of the options for the VIs is "Always Include".
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Open VI Reference Error 1000

Here is the problem:
I am opening a VI (we will call SubVI) through "Open VI Reference" and running the VI in parallel with the VI (MainVI) that I am opening it from. When I run the MainVI using "Run when Opened", I get a Error 1000 and the SubVI freezes. I break out using ctrl-period. Then I start it up from within LabVIEW and the Error 1000 does not appear. Does anyone have an idea of what is going on? Thanks.

I'm a bit unclear as to what your setup is. I suggest you post an example which will help clear it.
As a guess, error 1000 means "The VI is not in a state compatible with this operation". If the subVI is the one set to be run when opened, maybe calling it dynamically is what causes the problem.
Try to take over the world!

Open VI Reference Cant find Control

Unless...
Starting from the beginning, I am running LV2009. I am opening a reference to a functional global VI running on a remote computer to get the value that is in its' front panel indicator. I have two problems. The first is that when I use a string containing the VI name, it will not find the VI. When I use the full path to the VI, the Open VI Reference works fine. Annoying, but doable, as I only have about six FG to read and they are all saved in the same folder.
Second problem, and the real reason for the post: I can get all control values as a variants without trouble by using Ctrl Val. Get All Method. But when I try to name a control in the (Ctrl Val. Get) Method, I get an error saying control can't be found.
SO, I used property nodes to get the label text and checked to see if any were equal to the name of the control I am trying to read. It came up negative. So I created a list of the labels off of the Label. Text property node, and there sits the name I just checked for. So I copy and paste this back into the constant that is wired to the Control Name input on the Ctrl. Val Get Invoke Node, and no error. What the ??? So then I delete the text that I pasted into the constant and retype and it still runs fine.
I checked and rechecked enough to know that I was not typing the name in wrong, but now it works fine. I can close the VI and reopen it, works fine. Type in the name again. Still works fine. Any thoughts?
Solved!
Go to Solution.

deskpilot wrote:
Unless...
Starting from the beginning, I am running LV2009. I am opening a reference to a functional global VI running on a remote computer to get the value that is in its' front panel indicator. I have two problems. The first is that when I use a string containing the VI name, it will not find the VI. When I use the full path to the VI, the Open VI Reference works fine. Annoying, but doable, as I only have about six FG to read and they are all saved in the same folder.
Second problem, and the real reason for the post: I can get all control values as a variants without trouble by using Ctrl Val. Get All Method. But when I try to name a control in the (Ctrl Val. Get) Method, I get an error saying control can't be found.
SO, I used property nodes to get the label text and checked to see if any were equal to the name of the control I am trying to read. It came up negative. So I created a list of the labels off of the Label. Text property node, and there sits the name I just checked for. So I copy and paste this back into the constant that is wired to the Control Name input on the Ctrl. Val Get Invoke Node, and no error. What the ??? So then I delete the text that I pasted into the constant and retype and it still runs fine.
I checked and rechecked enough to know that I was not typing the name in wrong, but now it works fine. I can close the VI and reopen it, works fine. Type in the name again. Still works fine. Any thoughts?
A trailing space in your original constant fits that problem description.
May be helpful...
If you know the data type of the data you are reading using the val prpererty node, you can use the "TO more specific" node to cast your refences to the proper type. After doing so your val will not be a variant and you can use the standard LV operators to work with the data.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Open VI Reference asking save option

Hello,
I am opening a VI reference to analyze the state of the VI and closing it back and repeating this process for the bunch of VI's in a folder.
While closing the VI reference, it is throwing save dialog box for the some of the VI's, after closing the dialog only it is analyzing the next VI. To stop this behaviour I have set the Open VI reference Option to 0x20, but still it is coming. Please Give me some way to prevent this.

Are there any additional dialogs?
My assumption is, that those VIs are deriving from older LV versions and are not masscompiled to the current version you are using. Therefore, if you open the VI, LV developement environment will automatically recompile them, which will change the VI. So when unloading the VI, the developement environment will ask you to save unsaved changes (recompilation) of the VI......
Using the parameter 0x2 for opening the VI reference only effects the loading (supress the search dialog for subvis, do not mistake that with the "Browse for SubVI" dialog!), not closing the reference.
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Open vi reference by string in executable

Hi all,
Scenario: A top-most vi (main.vi) calls two subvis (subvi1.vi and subvi2.vi) separately such that they run in parallel. subvi1.vi has a front panel that appears when called, subvi2.vi does not.
subvi2.vi uses Open vi Reference to get a reference to subvi1.vi. It then uses this reference in a loop and continually polls the property FrontPanel.IsFrontmost to determine if the front panel of subvi1.vi is frontmost. When it is frontmost, it performs certain actions. When it isn't frontmost - it doesn't.
This all works great in the development environment, but as soon as I build this 'scenario' into an application I get the following error:
subvi2.vi is generating the reference to subvi1.vi using the string "subvi1.vi" as an input to the path terminal of the Open vi Reference function. Why does this cause problems in a built executable?
P.S. Clearly this scenario is actually a part of my much bigger project, hence I don't have any simple vi's to attach
Message Edited by Thoric on 04-27-2009 01:06 PM
Thoric (CLA, CLED, CTD and LabVIEW Champion)
Solved!
Go to Solution.
Attachments:
crash.jpg ‏28 KB

Thoric wrote:
Norbert B wrote:
Thoric,
it's disturbing that LV is crashing on your system due to this error. What version of LV do you use?
LV 8.6.1 at least (i don't know which version was the first one) creates the following error:
LabVIEW: Open VI Reference no longer matches VIs in memory by filename. A filename is no longer sufficient because the full name of a VI now includes any owning libraries.
This error occurs even in the developement system.
I asume that the crash itself is created by handling of invalid references.
hope this helps,
Norbert
Norbert,
I am using LV 8.6 (not 8.6.1). I am using strings to identify vis, not paths. I believe the error you are encountering only relates to using paths for referencing vis.
If your assumption is correct and my crash is due the handling of invalid references, then I need to generate a path to the vi, rather then using it's name. But generating a full (non-relative) path might be tricky? If within subvi2.vi I use the 'current vi's path' function and strip it to determine the executable path, then add subvi1.vi, should that get me the path to subvi1?
THis really depends on how you did your build. If VI1 ends up as dynamic file vs part of the app, the paths will be different. Easy enough to check. Look at where your exe is and figure out if VI1 is there in the support/dynamics. If not it is probably inside the exe to the path would then be "My.exe.VI1.vi".
But I am speculating thats the issue so try to get more info.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Open VI Reference

I have built an application with LabVIEW 7.1 and I randomly get Open VI Reference errors whey I dynamically load VIs. The application I created loops on a series of VIs, dynamically loaded them as they are called. The problem is that I randomly get the Open VI Reference errors even after executing a series of evens for 85 times. That means the dynamically load vi worked 85 times prior to getting an error.
Attachments:
Error 1124.jpg ‏202 KB

I think it will be impossible to help you without seeing your code, but I would start with some code that will document what happens when this error occurs (what path you're using to call the VI and so on). That will make it much easier for you to troubleshoot.
Additionally, you can try searching this site for the error. If you go to the top of the page and put 1124 in the search box, you will get several results (like this, for example).
Try to take over the world!

"Open VI Reference" Option "Prompt user to find missing subVIs"

I am using "Open VI Reference" to dynamically load a VI. For the "option" control of the "Open VI Reference" node, I pass "0x10" or "10" in hexadecimal, which supposedly "prompt user to find missing subVIs." Nevertheless, I don't get a prompt message dialog when I intentionally pass an invalid or missing VI path. Instead I just get an Error Code 7. What does this option "Prompt user..." suppose to do?

Make sure you set the properties on the integer input into the “options” control to the “Open VI Reference” to be a Hexadecimal format (right-click on the “options” control input, select Format and Precision…, then select Hexadecimal). Now, if you re-run your VI and wire in a VI with a missing subVI, the Open VI Reference will appear with a dialog that will prompt you to browse to the missing subVI. This is exactly the same message LabVIEW displays when it attempts to open a VI and cannot find its subVIs.
I’ve attached a simple example program to demonstrate. Enter the path to the “number extractor.vi” as the VI to open. You should see a dialog prompt appear asking for the “Search 1D Array – Complete.vi”.
Hope this helps!
Attachments:
openVIRefExample.zip ‏20 KB

Open VI reference freezes

Open VI reference seems to run in the user interface thread. If you open a user dialog all the open vi reference functions halt until the dialog has been closed (even though they run in paralell loops etc, no data flow explanation).
MTO

> Loading and holding the references at startup is the solution I
> suggested to the developer who ran into this, for some reason I've
> never discovered this limitation myself. So it's not a big problem,
> but one (too) easily overlooked.
>
True, this limitation has been there since LV5. It is a temporary
ordering of things that resolves itself as soon as the modal VI goes
away, so it very rarely affects an application.
> We do however more and more develop application where there are
> parallell independent (should be that is) operations going on all the
> time, and this seems to introduce problems that are not always what
> one would expect. The memory leak described in the following is one
> example:
>
This looks a bit like a sneaky way of asking me to look at your "memory
leak" problem. I modified it a bit, changed the delay to 20ms instead
of 50, and made the button be a switch instead of latched, so I could
just let it clone all by itself. Running it in a normal version of LV,
I let it create and then I'd delete. All total, I created and destroyed
about 300 VIs, and the memory on my LV for OSX would go up a few megs,
then back down, then back up bit. I then tried it with a debug version
where I can look at the amount of memory that LV thinks it has allocated
at any point in time.
My quick diagnosis? It isn't a leak, but the extra memory usage is due
to fragmentation. Basically this stems from the fact that loading a VI
means bringing quite a bit of stuff into memory. To do this LV asks the
OS for some allocations. When tearing down the VI, LV frees the
allocations, if it didn't, this would cause a leak.
But, just because allocations are freed doesn't mean the system will
show them as free to give to another app. Here is why. If a program
asks for one byte, the OS will add one page of memory to the app -- that
is 4096 bytes. If the app asks for another byte, the OS doesn't have to
do much, it returns one of the 4095 reserved bytes that belong to the
app. After the 4096 bytes are used, the OS will give the app another
page for 9192 total. Interestingly, if the app starts deleting bytes,
the OS will only be able to take back a page and make it available for
other apps when no allocations are on that page. So leaving the first
byte allocated and say the 5000th byte allocated are enough for those
two bytes of allocation to use up 9192 bytes of memory.
This effect is caused by fragmentation, and it is there largely because
memory is cheap, so the OSes don't do any compaction. 4096 bytes on
even a 64Mb machine is a tiny drop in the bucket, so the OS trades space
for time and wastes memory to increase performance.
So, this isn't a guarantee that this isn't a leak. You did the right
thing in reporting it, and another person in R&D will spend more time to
verify that there isn't a leak, especially in the new AutoClose Refnum
feature. But my quick diagnosis is that as the app loads up a new VI,
some of its lists and arrays grow and are moved to some of the new pages
leaving behind holes. When the VI leaves memory, some of the pages
can't be freed because even though the arrays and lists have shrunk
back, they stay on the new pages. After a few of these chaotic
operations take place, an equilibrium is reached and the app will stop
growing. The pattern it takes, and the amount it grows is highly
dependent on the OS and the heap manager in use. So, on OSX mine may
only grew 3M, whereas one version of windows may grow 4M and another
10M. At any point, it is largely out of LV's control and isn't a true leak.
I hope this helps.
Greg McKaskle

Error 1003 occurred at Open VI Reference in Dist Copy Non-VI Files.vi- Dist Build LLB Image.vi- Dist Build App Image.vi- Build Application.vi

When trying to build an application using labview 7.1 and windows XP, I get the error
Error 1003 occurred at Open VI Reference in Dist Copy Non-VI Files.vi->Dist Build LLB Image.vi->Dist Build App Image.vi->Build Application.vi
I've tried the crtl-shift-run as well as a mass compile and I still get the error.
Any ideas?
Thanks,
Mike

Hopefully this thread, or this KB article might help.
It seems like this could come from a lot of things, but there's suggestions in those which might lead you in the right direction
Message Edited by Day on 09-22-2006 02:07 PM

LV 8.2.1 Error 66 or 1379 occured at open Application Reference. A LV 8.2.1

Hi,
LV 8.2.1 Error 66 or 1379 occured at open Application Reference. A LV 8.2.1
Using:
Application access an other LV application on an remote PC with Vi-Server Technology. (Based on MS OS Windows XP SP2 with all patches ...)
With LabVIEW 8.2.1 it is not possible (exactly: with one PC it works, with other PCs, (identical regarding configuration of LabVIEW-Components), the described errors occured ...
There is no problem with LV 7.1.1. ( If the VI-Server Configuration of the .exe will be done within the .ini -File...)
The differences between LV 7.1.1 are in the .ini-File of the application regarding the the access-List property.
Error 66 occures if ther is no entry in the access-List property.-> OK.
Error 1379 occures if i will use the copy of the LV .ini-File acl-property with allowed access from all clients (*) or special clients defined with IP-Adress ... -> BUG
The same behaviour is described in 2 threads in the discussion forum ..., but in my application/configuration the workaround acl.configuration: "allow access from all clients" will work only with one PC ?
So what is the solution ?
At this moment i gol back to LV 7.1.1, but this is surely not the solution ....
Thanks for help ....

Hi!
I have also found following discusion in the forum.
But the the problem for Error 1379 lies in LabVIEW 8.2.1 and VI Server.
This is a know Bug. This Bug should be fixed in a future version.
The problem is that the IP address in the could not be resolved into a machine name.
Workaround:
This program works in 7.1 so the only option right now is to use 7.1 instead of 8.2.1.
Plamen
Message Edited by Support on 10-31-2007 08:59 AM
National Instruments Germany
Application Engineer

Cisco E900 ports 1990/tcp and 5916/tcp open on the LAN. Cannot close them.

Hello,
I just bought a Cisco Linksys E900 wireless router. Can someone explain to me why the router (192.168.1.1 on my case) has ports 1990/tcp and 5916/tcp open on the LAN?? I cannot find a way to close those ports.
Just do a simple:
telnet 192.168.1.1 1990
or
telnet 192.168.1.1 5916
and you'll see those ports are open.
1990/tcp = Cisco STUN Priority 1 port
5916/tcp = I have no idea
Every client on the LAN (wired and wireless) can connect to those ports on the router. I do not want that to happen. It is unncessary and it is just not secure. I only want the router to have port 443 open on the LAN for the web mgmt interface. I do not want any other unncessary port open.
It would be great to have a response from Cisco directly.
Thank you for your time.

JohnT66 wrote:
Thank you for your response.
The router is already updated to the latest firmware (1.0.04 Build 1).
I had to do the update as soon as I opened the box because the default firmware had an incredible serious bug: after setting up the web management interface on the LAN to work over SSL, it was impossible to access the interface because of an SSL bug in the router. The bug is in the release notes of the firmware... that alone says a lot about the very very poor quality of this router.. you can't have that kind of bug in a finished product....
I was able to close port 1990/tcp by disabling WPS in the router, although doing so was pure luck since the router's UI is terrible..
5916/tcp is still open.. since I was able to close 1990/tcp I don't think this is a defective router.. I cannot return a router to the store just because it leaves a port open, the store, sadly, will not take it back... so please Cisco, can you help with this? this product is faulty, it doesn't work as expected, it's your responsability.. please help
Reset the router manually then reconfigure the settings.

Open VI Reference LAN Help

Similar Messages

Maybe you are looking for