LabVIEW 8.6.1 Project causes slow Open VI Reference

I have an odd problem with "Open VI Reference.vi".
Case 1.
Open LabVIEW project containing "Main.vi"
Open "Main.vi"
Run "Main.vi"
Execution of "Open VI Reference.vi" take about 2,000ms
Case 2.
Open "Main.vi" - No LabVIEW project open
Run "Main.vi"
Execution of "Open VI Reference.vi" take about 100ms
I converted the project to 8.5 and the problem goes away. I don't have any machines with 8.6.0 to test if this is an issue with 8.6.1 only.
Has anybody else seen something like this?
Solved!
Go to Solution.

Good catch on the type def. It turns out that this is also key to the problem. I cleaned up my example VIs, removed the Type Defs and OpenG VIs. When I ran the cleaned up VIs the problem went away. So, I added a simple type def back to my called VI and the problem was back.
You misunderstand the reason for including gmath into the project. This has nothing to do with the time to load the project from disk. The problem is slow execution of "Open VI Reference.vi" when opening VIs that contain TypeDefs that are in large projects. By including gmath I was able to create a large project without attaching extra VIs.
Open Reference Test - No Project: 11 ms
Open Reference Test - small Project: 105 ms
Open Reference Test - large Project: 753 ms
Code in Zip file is LV2009
Message Edited by Gleichman on 08-21-2009 06:36 PM
Attachments:
Open Ref Test - II.zip ‏62 KB

Similar Messages

Slow open a shared worksheet remotely

Problem:
very slow to open a shared worksheet in excel 2010 remotely. locally open is not a problem. I don't know why?

Hi Marseugene,
If this issue is occurred by a *.xlsx file or other files? Did you enable the Share Workbook option for you workbook? And if only you get this issue, or other users also have this problem?
There are articles about excel opens slowly over network, please refer to these links:
https://support.microsoft.com/en-us/kb/2570623
http://blogs.technet.com/b/the_microsoft_excel_support_team_blog/archive/2011/09/29/office-file-validation-causes-slow-opening-of-excel-files-from-network.aspx
It seems that Office File Validation (OFV) causes the issue, you can download and install the Office 2010 File Validation update to help you solve the issue.
https://support.microsoft.com/en-us/kb/2553065
If the issue still exists, you can refer to these articles above and try the workarounds to help you solve your problem.
Or if your issue was caused in wireless net network, please read this article:
https://support.microsoft.com/en-us/kb/2807742
The workaround about this kind of issue is to delete the custom views that you do not need. Then, clear the Print settings check box under the Include in personal view heading in the Share Workbook dialog box. Or, use Excel Services and Microsoft SharePoint
instead of the Share Workbook option.
And the issue also might be related to Internet Explorer performing a search of network drives and your local area network and any disconnected network drives or LAN search issues will hang the loading of your Excel spreadsheet. Here is how to stop Excel
2010 from browsing your LAN / Network drives when you open an Excel spreadsheet on your local hard drive:
Start Internet Explorer
Go to "Tools" menu
Go to "Internet Options"
Go to "Security" tab
Go to "Local Intranet"
Click on "Sites" button
Uncheck "Automatically detect intranet network"
Please try these methods and let me know if they work, I am glad to help and forward to your reply.
Regards,

Open VI Reference to a LabVIEW executable.

Hello,
I haven't done this for a while and it's not working like expected. I'm trying to "Open VI Reference" from executable A.exe to B.exe. I'm trying to get a control value from B.exe in A.exe. Can someone send me an example?
Right now I'm at this stage: I have A.exe running as a LabVIEW executable. I'm trying to "Open VI Reference" to A.exe from LabVIEW development without success. Not sure what I'm doing wrong.
Don't hesitate to ask more info if you need some.
LabVIEW 2012, Windows 8.1.
Thanks,
Michel
Solved!
Go to Solution.

Bob_Schor wrote:
Once you have an Executable, does it matter that the underlying Development system is LabVIEW, rather than (say) Visual Studio, or Matlab? I suppose you could write an application that "knows" to, for example, listen to a TCP/IP port and interpret/execute commands, but that doesn't sound like the question being asked.
BS
LabVIEW-built executables still run as VI's in the RTE, though. Their identities have not been abstracted away into one single object or anything, and they still have name-based VI server access.
You can configure a build specification to include almost nothing, and require the VI files to be present in expected locations (i.e build specification's data or support directories). By default, all items in an executable application build specification are set to be put in the same location as their caller, which results in most things going into the .exe file, internally referenced in a directory-esque form like crossrulz mentioned, "MyExecutable.exe\MySubVI.vi".

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!

IMovie '09 Project Won't Open, Causes iMovie to Crash

A few days ago, an iMovie project that was fine if a little slow because it was large suddenly started to freeze when I added or tried to edit some audio, forcing me to force quit iMovie. Now today every time I open iMovie and try to open the project, the little rainbow ball pops up and everything in iMovie freezes, forcing me to force quit it again. I removed the project from iMovie and made more space on my computer and iMovie worked fine, but it started acting up again when I put the project back in. I'm worried the project may be corruputed somehow, especially because this is something I worked hard on for a long time now. I've heard there are ways to fix it, such as putting it through TextEdit or Word for Mac, but the project won't open in those programs. (And before you say it, yes I SHOULD have saved a previous version of it in Time Machine, but I didn't.) If there's a way I can fix this project without losing anything, please let me know!

http://www.justanswer.com/mac-computers/48x8b-working-project-imovie-completed.h tml
This helped me. I had a similar problem.

Opening 2 projects causes end of FCP session.

I would like to use my 6 TB archive project to import files into another project via browser in FCP into timeline. Working on a new project, deciding to open the archive project causes messages as: *out of memory* and *handler error*, that´s the end of session.
Starting the big archive project first will work fine. WHY ???
I am asking because it is very uncomfortable starting the big archive project each time, not knowing wether I need it or not, cause it takes 9 minutes to start it.
Thanks for trying to understand my problem.
gerolini

That is a very large project file. Keep in mind that for FCP to be fast and responsive, it must load all the media, every transition and filter and all the sequences into active RAM. I would guess that you've pushed the application to its limit.
Is there any reason for this huge project? Could you break it down into sub-projects? Throw away old and outdated sequences and render files?
If I was in your lederhosen, I'd copy the file a number of times, in a way that made sense to you. Then, in each copy, get rid of things that do not pertain to your chosen "subject." For example, I'd name one sub-project Munich and delete everything that has no relation to Munich. And another "Trip to Brazil" and in that one delete Munich and everything else not related to Brazil.
Does that make sense? It might seem like a good idea to put EVERYTHING in one project file for ease of access, etc-- but if you've pushed the software to the limit, you are gaining exactly nothing.
Good luck.

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!!

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

I'm using acrobat pro in my project after debuging the project and after opening a certain number of PDF files I receive the message: the maximum number of files opened has been reached, you have to close some files to continu.even doing that, I steel rec

I'm using acrobat pro in my project after debuging the project and after opening a certain number of PDF files I receive the message: the maximum number of files opened has been reached, you have to close some files to continu.even doing that, I steel receive the same message.Some one can tel what to do please? Thanks

Hi Memalyn
Essentially, the bare issue is that you have a 500GB hard drive with only 10GB free. That is not sufficient to run the system properly. The two options you have are to move/remove files to another location, or to install a larger hard drive (eg 2TB). Drive space has nothing to do with SMC firmware, and usually large media files are to blame.
My first recommendation is this: download and run the free OmniDiskSweeper. This will identify the exact size of all your folders - you can drill down into the subfolders and figure out where your largest culprits are. For example, you might find that your Pictures folder contains both an iPhoto Library and copies that you've brought in from a camera but are outside the iPhoto Library structure. Or perhaps you have a lot of purchased video content in iTunes.
If you find files that you KNOW you do not need, you can delete them. Don't delete them just because you have a backup, since if the backup fails, you will lose all your copies.
Don't worry about "cleaners" for now - they don't save much space and can actually cause problems. Deal with the large file situation first and see how you get on.
Let us know what you find out, and if you manage to get your space back.
Matt

Photoshop Elements 7 Stop Project Bin from Opening

Is there any way to stop the project bin from opening. It takes screen space I need on my laptop and also slows it down. I am using XP. Thanks for any help.
Gail

Hi,
See there is triangle in the middle of line above Photo-bin. Click on that and Photobin will collapse. Even when you move th cursor to uppar line cursor type changes to resize, so you can click and move it down upto the limit you want.
Hope it will solve your problem

Embedding a Captivate 7 SWF into a Captivate 7 project causing error "R6025".

Good day,
I am wondering if anyone else has encountered this issue and how it was resolved (if at all).
Recently, one of our clients contacted us to request we resend a source file (originally built with Captivate 6) due to perceived file corruption. Upon investigating, the file will open correctly on the PC used to develop the slide initially (using Captivate 6), but will crash and cause an error when Captivate 7 attempts to open the file (tested on multiple systems).
The problem file(s) are a parent single slide Captivate project which contains a single slide quiz (which is published out as a SWF and embedded in the parent).
To resolve the issue we figured that recreating both slides in Captivate 7 would be easiest solution. After recreating both from scratch, the same issue occurs. The project can be opened without issue on the development PC with Captivate 7, yet crashes when any other PC with Captivate 7 attempts to open the source file.
Here is a screen cap of the error message which pops-up during the Captivate 7 crash.
Anyone have any ideas how to resolve this issue?
Cheers and thanks,
Patrick

Hi Lilybiri,
Yes, this slide has an CP-Published SWF in the CP-file. This procedure was used on multiple projects without issue. It only appears to have become an issue when Captivate 7 is introduced.
With respect to not having all of the slides in a single project; this has to do with the design of our client's product and the requirement to have every slide be its own project file. We have discussed the merits of not using this approach, but they expressed a reluctance to change the approach (there are internal aspects of their organization at play which we are not privy to).
I am guessing the best bet will be to re-design the approach on this particular problem slide then?
Cheers,
Patrick

LV RTE cannot open project files that have .lvlib references in Dependencies

I'm writing a LabVIEW DLL to inspect LabVIEW project files, and I've noticed that if a project has a .lvlib reference in its Dependencies, then the Run-Time Engine contradicts itself about whether or not it can find the project file:
Project.Open returns error 7 (file not found)
Project.GetFileLVVersion is successful
Here are snippets from my G and C code that exercise this behavior:
int openStatus = StatusSuccess;
char* projectVersion = createStringWithLength(VersionStringLength);
printf("Analyzing %s\n", pathString);
OpenProject(pathString, &openStatus, projectVersion, VersionStringLength);
printf(" Project written in LabVIEW %s\n", projectVersion);
if (openStatus == StatusSuccess)
printf(" Opened project file.\n");
else
printf("Error: Could not find project file, or file was not a project file (error code %i).\n", openStatus);
However, when running in the development environment, both methods succeed.
Is this a bug, and if so, is it fixed in LabVIEW 2014?
Here is how you can reproduce it:
Prerequisites:
LabVIEW 2013 SP1 32-bit
ConEmu for a good console -- https://code.google.com/p/conemu-maximus5/wiki/Downloads
minGW for compiling a program to use the LabVIEW DLL -- http://sourceforge.net/projects/mingw/files
.lvlib reference in Dependencies breaks Project.Open in LV RTE
Unzip the attachment into a temporary directory (eg c:\xtra\temp)
Open "OpenProject.lvproj" in LabVIEW.
Build "Open Project Library".
Using ConEmu with a bash prompt, navigate to the temporary directory.
Type make
$ make
patching file `builds/platdefines.h'
gcc -std=c99 -g OpenProject.c -o OpenProject.exe -lOpenProject -Lbuilds
6. Type OpenProject 'c:\xtra\temp\OpenProject.lvproj'
$ OpenProject 'c:\xtra\temp\OpenProject.lvproj'
Analyzing c:\xtra\temp\OpenProject.lvproj
Project written in LabVIEW 13.0
Opened project file.
7. Notice that both invoke nodes execute correctly.
8. Type OpenProject 'c:\xtra\temp\OpenProjectWithLvlibDep.lvproj'
$ OpenProject 'c:\xtra\temp\OpenProjectWithLvlibDep.lvproj'
Analyzing c:\xtra\temp\OpenProjectWithLvlibDep.lvproj
Project written in LabVIEW 13.0
Error: Could not find project file, or file was not a project file (error code 7).
9. Notice that the version node succeeded while the open one failed.
10. Type diff OpenProject.lvproj OpenProjectWithLvlibDep.lvproj
$ diff -u OpenProject.lvproj OpenProjectWithLvlibDep.lvproj
--- OpenProject.lvproj Tue Nov 4 11:28:28 2014
+++ OpenProjectWithLvlibDep.lvproj Tue Nov 4 11:32:37 2014
@@ -13,7 +13,11 @@
<Property Name="server.vi.propertiesEnabled" Type="Bool">true</Property>
<Property Name="specify.custom.address" Type="Bool">false</Property>
<Item Name="OpenProject.vi" Type="VI" URL="../OpenProject.vi"/>
- <Item Name="Dependencies" Type="Dependencies"/>
+ <Item Name="Dependencies" Type="Dependencies">
+ <Item Name="vi.lib" Type="Folder">
+ <Item Name="NI_MABase.lvlib" Type="Library" URL="/<vilib>/measure/NI_MABase.lvlib"/>
+ </Item>
+ </Item>
<Item Name="Build Specifications" Type="Build">
<Item Name="Open Project Library" Type="DLL">
<Property Name="App_copyErrors" Type="Bool">true</Property>
Here is another way to trigger this behavior, which also shows that LabVIEW only sometimes tidies the Dependencies item:
Open "OpenProject.lvproj" in LabVIEW.
Add a new VI to the project and place the "Application Directory" file path constant its block diagram.
Select "File » Save All (this Project)" and use the default name for the new VI.
Type OpenProject 'c:\xtra\temp\OpenProject.lvproj'
Notice there is an error again, as is expected.
Remove the "Application Directory" file path constant.
Select "File » Save All (this Project)"
Type OpenProject 'c:\xtra\temp\OpenProject.lvproj'
Notice the problem is gone, as is expected.
Re-add the "Application Directory" file path constant to the block diagram.
Select "File » Save All (this Project)"
Type OpenProject 'c:\xtra\temp\OpenProject.lvproj'
Notice there is no problem, which is surprising as there should be an error since the Dependencies item hasn't been tidied.
Close the new VI and remove it from the project.
Select "File » Save All (this Project)"
Open "OpenProject.lvproj" in a text editor.
Notice the Dependencies item has been tidied.
Re-add the VI back to the project.
Select "File » Save All (this Project)"
Type OpenProject 'c:\xtra\temp\OpenProject.lvproj'
Notice there is an error again, as is expected.
Solved!
Go to Solution.
Attachments:
LVRTE_OpenProject.zip ‏10 KB

NInjaneer_wow wrote:
The same behavior occurs in LabVIEW RTE: a new project with an Application Directory constant in a blank vi will return error 7 - file not found, but still return the correct version of LabVIEW in which the project was created.
I've been experimenting with workarounds for this behavior, and I found one.
When I provide the LabVIEW path for libdir in my executable's ini file, the run-time is able to load and inspect the project file.
libdir="C:\Program Files\National Instruments\LabVIEW 2013"
While it's expected that a stand-alone executable may be placed on a system that doesn't have the LabVIEW IDE, it's still surprising to me that the Run-Time Engine cannot find LabVIEW's standard library without some explicit guidance. What other considerations contribute to that behavior?
References:
LabVIEW configuration file/Paths -- http://labviewwiki.org/LabVIEW_configuration_file/Paths

Lost Power - Now Project Won't Open!

I'm working on an iMac (10.10.2) with an external hard drive.
I was working on the project and some construction next door caused the power to go out. Now the project won't open. Every time I try to open it, the program crashes. I can open other projects from the same hard drive, just not the project that I was working on.
HELP!

IIf that opens, then go into the Original Media folders and look through all the clips and see if they're OK. Any clip that has an actual image that appears in the Finder should be OK. Any clip that has a generic QT icon may be corrupted. See if it will open in the QT player. You can also use QuickLook in the Finder and step through the files in the list to see if the run.
if you were titling also check through all the Fonts on your system and make sure none have generic document icons.

Labview 8.2 close or crashes when opening up Test Exec. from labview 5.1

Why would Labview 8.2 close or crashes when opening up Test Exec. from 5.1? Labview 8.2 begins to load the Test Executive VI, then, stops and closes labview altogether. I remember getting it to load before but do not know what could be causing this? I am tasked with updating the old code from Labview 5.1 to Labview 8.2.1; actually Labview 8.5, since it is the latest.
Thanks, Mike

Dennis,
Thanks for the response. The odd thing is that I am able to open some of the subvi's. And I've opened the test executive before. Now, during the initial loading of the Test Executive, there are some drivers that are not executable by Labview 8.2.1 (i.e. ni-daq cards.... for MIO and DIO boards). Could that be it? I would expect the program to load but not run. I have gotten the program to load before, so I am confused by it not loading now. Thanks for the tip on Labview 8.5 as I was ultimately going to that version, too!
My ideal situation would be to load all drivers ( including Traditional Ni-daq and Ni-VXI 3.3.1, etc) and run this program using Labview 8.5 or 8.2.1 on an XP platform. This original program was created in Labview 5.1 and Windows NT. Any help and suggestions would be appreciated.
Thanks for your help,
Michael

Aperture suddenly becomes very slow opening library

Hi.
I've got only 100 or so photos, and Aperture suddenly becomes very slow, it take a couple of minutes now to open the library.
Just before this started to happen, I got a very short massage, saying something like, "It's repairing some files."
I wonder if there are some corrupt files there, causing very slow opening the program.
Is there any way to check this and fix this problem?
I'm using 3.4.3, and OS 10.8.3.
I appreciate your help.
Hiro

I'm surprised nobody has responded to this yet. Hopefully you have already figured it out, but if you double click on the aperture library while holding down the option and command keys, Aperture will bring up a dialog that gives you three options for dealing with potential library issues: repair permissions, repair the library or rebuild the library. You should try them in that order, and it is a good idea to back up your library first (especially before rebuilding the library).
Hope this helps.

LabVIEW 8.6.1 Project causes slow Open VI Reference

Similar Messages

Maybe you are looking for