Open VI Reference and Stand-Alone

Hi!
Using LabView 7.1 under XP I made a vi which creates a report in Excel format.
The vi runs correctly but, If I do a Stand-Alone application of that vi, an error 7
(problem occured at Open VI Reference in New Report.vi) appears when I launch the exe. Why ?
Someone has any idea ?
Thanks

I my particular case, I only add the vi's that are dynamically called in the Source Files list of the Build Application (see attachment). I did nothing else !
On the other hand, I have Oslo observed that the "Current Vi's path" gives for example:
c:\directory1\directory2\Library.llb\viName.vi
when testing within LV while it gives
c:\directory1\directory2\Application.exe\viName.vi
when running the EXE. I have first expected to get
c:\directory1\directory2\Application.exe
when running the EXE and thought it was a bug of LV. However, there is no bug (here) and "Current Vi's path" works as described in the documentation:
"...If you build the VI into an application, this function returns the path to the VI in the application file, and treats the application file as a VI library.".
Regards,
Frédéric
Attachments:
ScreenShot.jpg ‏149 KB

Similar Messages

Can I backup between a testversion and stand-alone version?

Can I backup between a testversion and stand-alone version?

You are correct, the CC version is activated with your Adobe ID and password after you have signed up for the creative cloud plan. You can uninstall that CC version and install the standalone. It is the same program, and will open the same catalog. You don't need to back up anything. Just change over to the standalone program and start Lightroom. Everything will function just the same6.

Diff was java add in and stand alone java instance

Hi Guys ,
What is the diff between was java add in and stand alone java instance ?
Thanks
Sonam

Hai,
SCS is nothing but the SAP Central Services, it is AS Java instance of an SAP system containing the enqueue server and the message server.
JAVA Addin is inserted in exsisting ABAP only instance to have JAVA functionality. JAVA instance is assigned to an ABAP instance. The Internet Communication Manager (ICM) of the ABAP instance starts and stops the associated Java instance as required.
Netweaver JAVA (Stand alone) vs JAVA Addin:
Netweaver JAVA Addin installation is a dual installation that consists of Java and ABAP stack. Addin is required when you are implementing SAP XI (Exchange Infrastructure). Stand alone JAVA is required when you implement SAP EP (Enterprise Portal). It is generally not recommended to use dual installation for EP because this will expose the ABAP layer to the public Internet. So the ABAP stack is often used to host SAP ERP ECC (Enterprise Central Component), SAP CRM, SAP SCM, etc.,
Since the information hosted on ABAP stack is more sensitive in nature you are recommended to install Portal on the Netweaver AS Java server (Stand alone JAVA server).
By doing this you will be able to fully utilize the system resources for the portal and ensure good performance.
Regards,
Yoganand.V

Quirk, Open VI Reference and LLB

I found a strange quirk opening a VI Reference (on a PXI). The "normal" method of doing this is to Open Application Reference (to find the remote site) then to Open VI Reference with the path to the desired VI. Darren Nattinger pointed out (in 2006) that you can use just the name of the VI, provided the VI is on the same folder or LLB as the current VI.
Caveat -- this behavior is present in LabVIEW 7.0 (I'm maintaining some "legacy code"). I suspect it will be present in later versions, but haven't (yet) tested it.
Quirk 1 -- if the VI in question has been downloaded (or deployed) to the remote site, and hence is in memory, then the "path" information isn't used, only the VI name. Thus if you have a path "C:\ni-rt\startup\MyVI.vi" specified in the Open VI Reference, but have absolutely nothing in the startup folder on your PXI, but have "deployed" your Project, this call will work, even though the "path" part of the argument is not valid. Useful when testing.
Quirk 2 (and the "real" reason for this post) -- if the VI is embedded in an LLB, it depends on whether or not it is a "Top-level" VI or not. Suppose the path is C:\ni-rt\startup\MyLib.llb\MyVI.vi. Consider two VIs in this LLB -- TopLevel.vi and SubVI.vi (where TopLevel is at the top level of the LLB, whereas SubVI is not).
Case A -- the LLB has actually been downloaded to the remote site. Doing an Open VI Reference, with either the full path or just the VI name, works, whether or not you are calling TopLevel or SubVI. Nothing surprising here.
Case B -- you are taking advantage of Quirk 1, and have not actually put the file on the Remote site (i.e. there is nothing at the path specified). You have, however, downloaded the LLB to the Remote. Doing an Open VI Reference with SubVI, whether with full path or just VI name, works fine. However, trying to open TopLevel fails, with Error 7 (File Not Found), whether using full path or VI name.
Summary -- Quirk 2 is that Quirk 1 has a quirk if the VI being referenced is a top level VI in an LLB.
[My apologies if this is common knowledge -- I failed to find this behavior documented, but may have overlooked something].

Bob Schor wrote:
I found a strange quirk opening a VI Reference (on a PXI). The "normal" method of doing this is to Open Application Reference (to find the remote site) then to Open VI Reference with the path to the desired VI. Darren Nattinger pointed out (in 2006) that you can use just the name of the VI, provided the VI is on the same folder or LLB as the current VI.
Caveat -- this behavior is present in LabVIEW 7.0 (I'm maintaining some "legacy code"). I suspect it will be present in later versions, but haven't (yet) tested it.
Quirk 1 -- if the VI in question has been downloaded (or deployed) to the remote site, and hence is in memory, then the "path" information isn't used, only the VI name. Thus if you have a path "C:\ni-rt\startup\MyVI.vi" specified in the Open VI Reference, but have absolutely nothing in the startup folder on your PXI, but have "deployed" your Project, this call will work, even though the "path" part of the argument is not valid. Useful when testing.
Quirk 2 (and the "real" reason for this post) -- if the VI is embedded in an LLB, it depends on whether or not it is a "Top-level" VI or not. Suppose the path is C:\ni-rt\startup\MyLib.llb\MyVI.vi. Consider two VIs in this LLB -- TopLevel.vi and SubVI.vi (where TopLevel is at the top level of the LLB, whereas SubVI is not).
Case A -- the LLB has actually been downloaded to the remote site. Doing an Open VI Reference, with either the full path or just the VI name, works, whether or not you are calling TopLevel or SubVI. Nothing surprising here.
Case B -- you are taking advantage of Quirk 1, and have not actually put the file on the Remote site (i.e. there is nothing at the path specified). You have, however, downloaded the LLB to the Remote. Doing an Open VI Reference with SubVI, whether with full path or just VI name, works fine. However, trying to open TopLevel fails, with Error 7 (File Not Found), whether using full path or VI name.
Summary -- Quirk 2 is that Quirk 1 has a quirk if the VI being referenced is a top level VI in an LLB.
[My apologies if this is common knowledge -- I failed to find this behavior documented, but may have overlooked something].
This will likely not apply at all to >= 8.0. LabVIEWs Open VI Reference will now distinguish cleanly between absolute path and just the VI name itself. If you use just the VI name the VI needs to be in memory or for a built application included in the app. The quirk about VIs in the same LLB as the currently active VI sounds very strange to me but it may still work.
However if you specify an absolute path, Open VI Reference will bark with an error if the VI can not be found at that location or if the VI already loaded in memory with that name has not the same absolute path. This is supposedly to make it very hard to create cross linking even when using VI server.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Open VI reference and paths problem

Hi,
in my project I need to have a VI running independently from the calling VI so I use VI Server and "Open VI reference" to run the VI. However this is not without problems. The VI that I run is not in the same folder, as the caller VI and also not on a fixed location on disk, so I use relative paths (something like "..\subfolder\myVi.vi"). This works in the project and .exe but not e.g. in a .llb file where there seems to be no folder structure anymore.
Actually I'd prefer if this would not use paths on disk at all but if I could somehow create a reference to another VI in my project and it would even work if the VI's location on disk changed (and is updated in the project). I think it is quite confusing that I have to care about physical location of the VI here when I use the project browser for everything else. Is there a way to accomplish this? Or is there even a better way to start a VI that keeps running even after the caller stopped?
Thanks,
Tobias

As far as I've seen, every VI has the path ../Application.exe/currentvi.vi when you are running in a build. Therefore, to open another VI you have to strip the current vi's path once, and add the other vi.
I have written a VI that determines whether or not I'm running from a build, it is attached. It returns true if you're in a build, and also the current vi's path stripped once giving you ../Application.exe.
The way I use the VI is pictured below. I send the stripped path Is Executable returns and the relative path (minus the vi name) into a Select icon which is wired to the boolean Is Executable returns. Then I add the other VI name to the path.
Message Edited by elset191 on 04-21-2009 10:43 AM
Tim Elsey
LabVIEW 2010, 2012
Certified LabVIEW Architect
Attachments:
Is executable.vi ‏8 KB
untitled.JPG ‏7 KB

Smartview 11.1.2 and Stand Alone Essbase

Hi,
I am migrating some applications for a client and they are interested in using Smartview 11.1.2.
Currently, they are using the add in with their 9.2 environment and I just migrated all their apps to essbase 11.1.2 which is pretty slick. I installed the add in for 11.1.2 and that is working fine.
However, I know there is an interest in going to planning so they wanted to set up smart view as well. They don't use shared services but use native security in essbase. So when I am trying to establish the URL connection in Smartview 11.1.2 I am not able to connect to the shared service provider. These are the URL's i tried with both a shared and a private connection to attempt to connect to stand alone essbase in smartview 11.1.2:
http:server:13080/aps/APS
http:server:13080/aps/smartview
http:server:19000/workspace/SmartViewProviders
I didn't think the workspace URL would work since they aren't using worksapce. Any ideas on how to connect to stand alone, no shared service essbase for smartview using 11.1.2?
Any help is appreciated. Thanks,
DQ
Edited by: DQ on Jul 5, 2010 12:00 PM

In private connections type http:server:13080/aps/SmartView. The url is case sensitive you had http:server:13080/aps/smartview.
While on the topic, two points that I would like to mention:
1- I don't believe Essbase 11.1.2 still has native security but I will have to confirm.
2- Workspace gets installed by default in 11.1.2 and http:server:19000/workspace/SmartViewProviders is the right url to use for shared connections.

Optional applications selected via UDI interface and stand alone media

I'm running SCCM 2012 sp1 with MDT integration. I'm using a UDI from MDT to set some basic machine informatoin for imaging (select the OU in the domain, etc). I also have some optional apps that a tech can select from the UDI to install during
the TS.
All is working great with network based installations. However, I have a need for some installations using stand alone media. Is there a way to create stand alone media that will include those optional apps in the MDT UDI so that those apps can
install during the TS? I don't think there is, but there are more brilliant minds than mine out there so I thought I would ask. Maybe there's a way to generate stand alone media via a PS script or something, and have it include the additional
packages so they are on the media and can be called via the TS when it runs.
Thanks!

The root cause of this issue has nothing to do with UDI really, it is just the fact that installing applications using dynamic base variables is not supported in standalone media. As you say everything has to be directly referenced by the task sequence
for it to work.
We had this same issue a couple of years ago in ConfigMgr 2007 and ended up building our own standalone media wizard using the SDK. Sounds like a lot of work I know, but for us it was well worth it. We have just migrated it to ConfigMgr
2012 and updated it to support the app model.
The reason it made sense for us to invest the time in it was because we are a fairly large enterprise (160,000 seats) with a single task sequence used worldwide. The Windows 7 configuration requirements (not just in terms of app deployment) vary
dramatically from one country to another, but using variables to control deployment we have managed to retain a single TS but let the child site admins have some flexibility. As we have many small branches/agencies with no ConfigMgr infrastructure we
had to come up with a solution which retained and reused the single TS design but also worked offline. Standalone media is used to deploy Windows 7 to thousands of users. Getting the local apps to install wasn't our only issue, the size
of the media was also a problem due to the number of dependencies required to support deployment in every country (drivers, language packs, x86+x64 etc.).
So our standalone media wizard does this:
Reads in the collection variables (used to customise deployment, deploy apps etc.)
Prompts the user for various options like x86/x64, HW types etc.
Creates a copy of the global TS, the wizard then modifies the copy so that a custom TS is created dynamically just for the media.
It disables any unwanted actions in the local TS to remove drivers, x86/x64, language packs etc.
Adds install application actions for each of the apps specified in the dynamic app install variables.
Prompts user for normal standalone media options like ISO, USB, Password, DPs etc.
Creates media based on local/temporary TS.
Deletes the local/temporary TS when complete.
This solves the issue for zero touch deployment but does it work with UDI? Well the answer is yes and no. We do use UDI (but again built with the MDT UDI SDK). Out of the box, the answer is no. UDI brings a slightly different
issue in that not only are the apps not referenced by the TS (so they are not in the media) but you are also then trying to dynamically change which apps are installed during deployment. So even if the apps are directly referenced and in the media,
you still have to develop a way of controlling which TS app install actions run based on the user selection.
If you are willing to spend some time with the SDK then it can be done, you just may not find this worthwhile depending on the scale of your environment.
Mark.

Service Modules in 6500s, IPS/IDS and Stand-alone options.

Hi,
My first post here and it's a question regarding knowledge that I can't seem to find via CCW and through people I know.
Does the Service Module in the 6500 i.e. WS-SVC-ASASM1B-K9 come with or support an IPS/IDS option?
Does a stand-alone ASA5500 come with an installed IPS/IDS option.
Thanks.

> Does the Service Module in the 6500 i.e. WS-SVC-ASASM1B-K9 come with or support an IPS/IDS option?
On the Cat6k5 is the IDSM2. Thats a completely outdated module with 500 MBit/s of throuput. For the Datacenter designs Cisco recommends the standalone IPS 4500 instead a module if you need good IPS throughput.
> Does a stand-alone ASA5500 come with an installed IPS/IDS option.
The ASA has build-in IPS with a fixed signature-set that is not such rerlevant. The better way of doing IPS on the ASa is to have an optional IPS-module. These modules are didicated hardware on the legacy ASAs (the ones without -X) and pure software-modules on the new ASAs. The 5585 is an exception where IPS is also a dedicated hardware-module.
Sent from Cisco Technical Support iPad App

Communication between servlet(client behavior) and stand alone java program

Hello all:
I need to send a message (ascii characters sequence) from a servlet to a java program, but I'm not sure what is the best way to get it: socket, JMS or other mechanism that I don't know.
Is the servlet who is operating how client behavior.
Please, any comment will be appreciated, regards,
Ulises.

You can always start a ServerSocket on the client (kinda sounds funny, doesn't it) which will accept connections. You then open a plain old Socket on the server to connect to the client's listener. (Note, this is the reverse of a normal set-up). Once you have the connection established, you will call getOutputStream() to get a stream to write to. Likewise, you will call getInputStream() to read the data sent. You will want to investigate the java.net.* and java.io.* libraries.
- Saish

Report generation toolkit and Stand-Alone Application

I know this question has been posed many time already. I have been fighting this issue for a week now and I've exhaused all ideas I can think of.
I have an application that I moved to another PC. For the past year or so it has been running off of a machine that has LV installed (LV2010). The issue is none of the RGT VIs seem to be working. I know this is related to additional files that need to be included in the application, an believe me, I have tried, but nothing works. I have read through all the threads I can find related to this issue as well as documents and the LV Help.
--It is my understanding the the dynamic VIs for Excel and Word do not need to be included for LV versions higher than 8.2. But I tried anyway and nothing.
--I've added the folders LVClass and NIReport.llb folders to my project and "always included" in my application. Still nothing.
--I've tried adding NI_Excel.lvclass to my project as the instructions in the help say to do and included it into my application. Still zilch.
--I've tried different combinations of things to try and get this to work and I get the same result.
For some reason, the program cannot find the VIs it needs in order to generate the report. No errors are returned either from the application.
I should note that when I included the NI_Excel.lvclass to my application that the size of the program did not change. I thought this was strange. It appeared the files in the class did not get included since they were not greyed out; however, after including the NIReport.llb which contains this class, they did get included, but unfortunately this did not fix my issue.
One question I have is why do the files in the LVClass and NIReport.llb folders not appear in the Preview, but if you have "Use LabView 8.x file layout" under the Advanced page checked, they do? This should be unchecked I know, just curious as to what was witnessed.
I am hoping this is something simple that I have over-looked. I'm tired of beating my head into the wall. I appreciate any assistance you folks can give.
Thanks.
Reese, (former CLAD, future CLD)
Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home

Wayne.C wrote:
Mo,
The .exe created with the 8.x unchecked runs just fine. I did check and the .exe is larger due to the extra files inlcuded directly in the .exe vs the Data folder.
Yes, I noticed this as well.
Let me ask, if if the class libraries are in the dependencies, won't they be a part of the application? So why does it need to be included. NI_Excel.lvclass in in the dependencies.
Reese
Reese, (former CLAD, future CLD)
Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home

Difference between Standard EBS Rapid Planning and stand-alone Rapid Plan

Hello All,
We are currently working on installing ASCP and Rapid Planning as part of client R12 implementation.
As part of the installation, we identified VCP can be installed in 2 different ways
1) As a Standard EBS module
2) Standalone application on top of Web-logic.
Can anyone please confirm what could be the pros/cons if we go with option 1 and option 2 ?
Which option should be the best if we are planing to go RP with cloud ?
Appreciate your inputs if possible.
Cheers,
Krishna

Rapid planning always requires an EBS installation.
The difference between a standard EBS and standalone is that
1. a standard RP install (actually an ASCP install) is linked to an EBS source instance (ie data is collected from there)
2. a standalone install is where you install Oracle Applications 12.1 (ASCP installation) , only configure the ASCP setup (since RP requires certain ASCP functionality like collections/patches/profile settings). Data here is collected through legacy collections (ie coming from a non-EBS source)
There is no way to run RP just on weblogic
You mention R12, but bear in mind that RP only works on 12.1.x.
In your case if you have

Differences between application for App. Server and stand alone application

What are main differences?
Why to use App. Server. if it is possible easily make Server application that listens port using socket classes?

Can u please give a short example for 1, 3 and 4?The container will pool instances of your bean which aids in perfromance gain.
You can handle security issues declaratively.
The container manages the life cycle of your beans so that you can handle actions at bean's activation, passivation, initialization, destruction etc.

Stand-alone application generates error with function 'Ramp Pattern' (bug in application builder?)

Hello,
in my program a main.vi links to a sub-VI via 'open VI reference' and 'invoke node'. In this sub-VI the function 'Ramp Pattern' is used. The program itself runs normally, but if I build a stand-alone application using application builder I get an error message 'error 1003 occurred ..'. I believe this error is directly related to the build specifications which are as follows: the main.vi is referenced in a main build specification, the sub-VI in its own specification where the target is a LLB.
I appended an example-program that exhibits the error (when executing 'Application.exe' and pressing 'calculate ramp'). The error does not occur when disabling the 'ramp pattern' function and rebuilding the application.
I would rate this to be a bug in the application builder and would appreciate any help on how to solve this problem. However, due to the structure of the whole program the sub-VI has to remain in its own LLB.
Attachments:
RampPattern.zip ‏198 KB

There can be reasons why a VI might appear broken when loaded from an executable. For example, if you have different versions of the same VI or enum that differ in such a way as to break the calling VI, that can cause a broken arrow when loaded from the executable. If you have DLLs being called and the runtime engine can't find the DLL, that can cause a broken arrow that you might not see otherwise. Finally, there is a bug related to a VI appearing broken when its not.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

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 and Stand-Alone

Similar Messages

Maybe you are looking for