Invoke node (parallely working VIs in a library)

Hello everyone,
I am trying to evaluate a temperature sensor.To do that I have to monitor thermocouple readings.Thermocouple is connected to FP-TC-120 temperature module. Besides, I have to acquire data from an optical spectrum analyzer. I am using 3650.VI to monitor the temperature and 86140B Trace_Screen Capture(2).llb o trace the data from the OSA.
I am trying to use Invoke Node VI to trace data from spectrum analyzer. To do that I specified the necessary file path as an input to the code. The problem is the necessary VI (Write Trace to File.VI) is inside of a llb. file and needs other codes to completely function.
That's when I run the code, (and when the stability condition is met) the computer asks me to save the spectrum analyzer data to a file called trace.csv. When I press ok, it just saves an empty file with a header (Power(dbm) Wavelength (nm)). Apparently it works parallely with other VI. How can I make use of the VIs inside of a .llb file with invoke node VI or should I use other VI to do combine temperature monitor VI with data tracing VI.
The second problem is with the stability criterion of temperature.In the attached VI, I check whether the thermocouple reading stays within 0.8 degree stability range for 900 seconds. I want to change this. I
want to check the stability of the temperature by comparing the final data with the previous ones. Is there any specific VI that should be exploited to check the fluctuations of waveforms?
 Thanks a lot
Solved!
Go to Solution.
Attachments:
3650.vi ‏107 KB
86140B Trace_Screen Capture(2).llb ‏143 KB

deniz wrote:
I tried to implement the first method you suggested. But i had trouble since I am just a beginner. Could you please be more specific in explaining the solution? I am stating the problem again. Once the stability criterion is met I want the case structure to execute on the increments of 30 second or so. How can I do that by using shift registers? I tried to do  what you suggested as in the code attached but it did not work. (I could not make the case structure dependent on two conditions)
I understood what you wanted perfectly fine. You just didn't implement it correctly. See attached. Please revisit my comment regarding the Write To Spreadsheet File that already exists inside of the "Trace Xfer" VI.
The other proplem is again about timing. The while loop execute only if the temperature value changes since it is dependent on FP Open sub VI.
The while loop has no dependence on the FP Open VI other than waiting for the error cluster and Fieldpoint refnum. There is no dependence on the while loop executing only if the temperature value changes. The while loop continuously acquires data, so I do not understand your statement. 
Thus, the elapsed time VIs that are inside of the loop does not progress at 1 second increments. Is there any way to set an elapsed time  that is independent of timestamp of thermocouple reading device? 
They can't and won't. The Elapsed Time VIs simply tell you ... elapsed time. They have no bearing on how fast the loop runs. It seems as if you have contradictory requirements. Do you want to the loop to run once a second and record, or run at the advise rate and only do something once a second, or run at the advise rate and only do something if the temperature changes?
Attachments:
3650.vi ‏116 KB

Similar Messages

  • Run VI Invoke Node: VI works, EXE doesn't?

    This is LV2009 with no patches or updates. I am calling buffer.vi by static reference with an invoke node set to Run VI. I don't have an incredibly good reason for doing this, but just don't want that code on the block diagram. I hate to put alot of effort into this since I can just drop the code on the main diagram and I'm sure it will work, but I don't understand why it gives me the error 1000: VI not in a state compatible with this operation?
    In the EXE, when I check the execution state of the buffer.vi before I tell it to run, it comes up bad. Same code in the VI, comes up idle. I also tried replacing the static VI reference with an open VI reference using the name of the buffer and received the same error. I have the buffer VI included in the build under always included.
    Solved!
    Go to Solution.

    "You did not compile the vi to be in the EXE, did you?"
    I'm not sure what you mean. I have included buffer.vi and all of its sub VIs in the build as Always Included. I am investigating creating a source distribution. Never done that before. I will let you know if it works.
    I attached snippets of the caller and buffer.vi itself. I was playing around with the caller, trying to abort if running and such...
    Edit: Sorry if its confusing, what I'm calling buffer.vi is actually Waveform FIFO AE.vi
    Message Edited by deskpilot on 04-08-2010 09:04 AM
    Attachments:
    Remote Call.png ‏34 KB
    Buffer.png ‏42 KB

  • Does "Run VI" invoke node work on strict references to REENTRANT VIs?

    I am using LV 6.02 on Windows 2000.
    I am trying to use the "Run VI" invoke node method with a reference to a Reentrant VI, with no success. (It works when VI is not reentrant. Perhaps there is a reason this cannot work. But if not, I wonder if there is a workaround, or if LabVIEW 6.1 has a fix?
    Hopefully the picture of the block diagram I included is sufficient...but I also included the actual code just in case.
    Thanks!
    Steve
    Attachments:
    block_diagram.jpg ‏66 KB
    Parent_VI_Example.vi ‏43 KB
    Prototype_subVI_shell_for_Simplex_Fit.vi ‏40 KB

    Hi, Labviewguru,
    Thanks for taking the time to look at my admittedly messy (flawed) block diagram. I will try to state my ultimate goal:
    You may be familiar with Levinberg-Marquardt nonlinear curve fit in Labview, which is about 5 VIs in a LLB file. In order to change the type of curve fitting, one has to either modify a formula node in the lowest subVI (Target Func and Deriv), or place a different subVI in there. That's fine until I want to have many different sorts of algorithms.
    What I was thinking of doing is instead passing Target Func and Deriv a reference to the VI which would perform the calculations. This would allow me to use the same fitting code to fit different types of data with substantially different methods--without modifyin
    g the low-level fitting code at all.
    I'm not sure this is going to make any sense to you, but thanks again for your help.
    In regards to your answer above, let me clarify somewhat. I had the call by reference node in there to prove that the reference to the VI was "good" and worked fine...this same reference was passed to the invoke node, which didn't have any apparent effect.
    Also, I don't think the path to the VI I am opening the reference to is redundant. It is required to tell the "Open VI reference" which VI to load.
    I agree that using references to pass values around is not generally a good idea: I was using that method for my supposed versatility in the future.
    Thanks,
    Steve

  • Method Not Found Invoke Node error 1316 using Solid Works IEdm

    Hi Forum members,
    I have been having a problem with calling a function in a dll file.  I have attached the VI as example.  When I use the GetFile method I get a reference to that.  I then use the Invoke node and recieve a list of methods, the first of which is ChangeState.  I select this method and wire all required inputs and when I run the program I receive the error at that invoke node that the method does not exist.  How is this possible?  I have tried various methods to ensure the inputs are all correct and none have worked.  I do not believe the fault lies in the inputs, but I cannot for the life of me find the problem...  Perhaps someone has experience using Solid Works in Labview?  Any help would be appreciated.!!
    Cheers
    Ben
    Attachments:
    SetFileSatus.vi ‏18 KB

    I have determined that there is a problem with the Invoke node not recognising the function.  This is a Labview problem as the function is listed and selectable, so when the error comes saying the function is not found, this is a problem with Labview and not the dll.  The Function when selected also has the right input parameters that automatically appear.  How is it then that the method is not found when the program is run?

  • How to get a LabVIEW class object to expose an invoke-node method?

    Hi,
          I like the property/invoke-node "paradigm" used for interacting with "objects".  Can LabVIEW-class objects expose their properties and methods this way?  Can one or more LabVIEW-class objects be compiled into a library or "assembly" (or other distrubution format) that allows the property/invoke-node usage?
    I've looked at (but not completely understood) "Creating LabVIEW Classes".  Have also searched for related posts.
    The pic below shows an invoke node wired to a class with a Public VI "VAT.Status.Hello.vi".  I'd like to see VAT.Status.Hello show-up as a Method.  (I just tried "Select Method", and selected "VAT.Status.Hello.vi" but dialog's "OK" button stays greyed-out.)
    Cheers.
    Message Edited by tbd on 03-29-2007 03:15 PM
    "Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
    Attachments:
    VATStat.JPG ‏54 KB

    Hi Aristos,
          Thanks for the reply!  It was a bit dissappointing, though.
    It appears the LabVIEW-class object will be moving away from (what seems to me) a convenient object-interface presented by the invoke-node/method paradigm - which allows us to interface with a large set of "objects" (.NET, ActiveX, LabVIEW GUI, VISA Resource, ?) in a similar manner and independent of the object's origin.  Being able to read the methods and parameters that appear in these nodes is also helpful for understanding diagram logic!
    I do like the option of dropping a friendly "VI looking" icon on the diagram, but perhaps an optional - even default - VI-icon representation for a class-object invoke-node is feasible - so the LabVIEW class-object could be the more generic object first, but with a traditional-G representation(?)
    Given the answer "We would like, someday, to support the property node"
    and "in the next version of LV, wiring the LV class to the property/invoke nodes will break the wire so we'll avoid confusion in the future",
    ... I guess you'll break the wire in the next version, but (perhaps) allow it again - if support of the property node is ever implemented?
    Regards.
    P.S. For the record, huge THANKS to whoever it was that straightened-out enumerated-types (somewhere) between LV4.1 and LV6.1.  Every time I add or remove an enumeration in a typedef, I silently give thanks to the bright and thoughtful soul(s) who made this valuable tool work so well!
    Hello. This is your friendly neighborhood R&D guy for LabVIEW classes.
    Regarding your request about property and invoke nodes as relates to LV classes....
    Short story: We would like, someday, to support the property node. We have no intention of ever supporting the invoke node.
    Long story: As we were creating LV classes, we had to evaluate the right programming interface for these things. We wanted LV classes to behave as new data types in LV. A developer should be able to create a LV class, then give it to someone who doesn't even know OO programming, and that second programmer could use the new data type without learning a lot of new concepts. From this principle, we held fast to the idea that the programming interface should be subVI calls whereever possible. The invoke node is really nothing more than a VI minus the icon. If you want, you can popup on any subvi node and uncheck the option "View as Icon". This will make the node display in a way that has the terminals listed as text, like the invoke node. So, at the end of the day, the invoke node is simply a subroutine call in LV that is language dependent, as opposed to the language independent iconography of LV generally.
    The property node is a slightly different story -- the functionality of a property node is actually different than an invoke node as its terminals are various subsets of the properties available, not a fixed list of parameters like the invoke node. The property node provides a nice interface for setting multiple properties in a block and only having to check a single error return. Very friendly. Our intent is to allow you to create a VI that has 5 terminals: object in, object out, error in, error out, and either a single input or a single output of your chosen type. VIs with this conpane could be marked as "properties" of the class and would show up when you wire the class wire to the property node. We would call the subVIs behind the scenes as needed to get/set the properties.
    This is on the longer term roadmap because it is "syntactic sugar" -- it sweetens the programming style, but it is not necessary to program effectively. You can get the same effect by writing those same VIs and stringing them along on a block diagram "railroad track" style. We'll probably get around to it in three or four versions of LV -- there are some major user requests that impact functionality that have to get done first.
    PS -- in the next version of LV, wiring the LV class to the property/invoke nodes will break the wire so we'll avoid confusion in the future of people thinking there's a way to use these nodes.
    Message Edited by Aristos Queue on 04-02-2007 09:56 AM
    Message Edited by tbd on 04-03-2007 12:39 PM
    "Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)

  • LabVIEW Applicatio​n throws Error in Run VI Invoke node

    Hi All,
    We are facing an issue with an application developed from LabVIEW 2010SP1.
    Application Description:
    In our application, there is a top level VI which tries to run VIs dynamically[using Run VI invoke node] from a particular folder. This folder is like a plugin - not part of Exe. This implies when the top level VI is launched, the plugin VIs under particular folder will not be in memory. When we try to run a VI dynamically from the  top level VI, the VI execution works perfectly in LabVIEW development mode.
    Problem Faced:
    When we created an EXE, it worked well in my PC [LabVIEW is installed]. We created an installer and tested in few other PCs.
    [Non LabVIEW PCs – Win XP and 7]. In few PCs it throws the following error, when the plugin VI is run dynamically.
    Error 1003 occurred at Invoke Node 
    Possible reason(s):
    LabVIEW:  The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.
    Method Name: Run VI
    We tried the following possible ways to find the reason for the issue:
    1. Installed LabVIEW - Issue got fixed.
    2. Installed .net 2.0 without installing LabVIEW - Issue got fixed.
    3. But in one of the Windows 7 [Non - LabVIEW PC] in which .net was already installed, we faced the same error.
       Only after installing LabVIEW the error got fixed.
    4. When .net 2.0 is uninstalled the EXE itself is broken.
    We are not sure what is the Exact reason fo the issue. Anyone faced these kind of issues? Please share the solution. Thanks in advance.
    Note:
    1. The VIs which are dynamically called is a plugin and not a part of EXE.
    2. These plugin VIs have no dependencies from vi library and is completely isolated.
    3. We are not using any .net related objects in any of the VIs.
    4. The plugin VIs use Call library function node in which a C DLL developed from Microsoft Visual Studio 2010 is used.
    Thanks,
    Meena
    Solved!
    Go to Solution.

    Error 1003: This clearly indicates that the 'Dynamic VI' is broken and now you should check for the various reasons, why the 'Dynamic VI' is broken.
    Also path of 'Dynamic VI' is not a problem.
    One thing that you may try is:
    -> First open just the 'Dynamic VI' in a new LabVIEW project and check for the 'Dependencies'.
    -> Now if any of the item in 'Dependencies', other than what is listed in vi.lib (lets call it 'Dependency.VI'), is also a part of your 'Main Exe', then its a problem. Because when you will execute the 'Main Exe', say in a new computer other than your development computer, it will load all its dependencies including 'Dependency.VI' (and the path will be within the 'Main Exe', but when it will try to (dynamically) load the 'Dynamic VI', this VI will also try to load the same 'Dependency.VI' but from different path and that will cause a conflict. I had experienced this.
    -> If thats the issue, you may want to rename (add suffix/prefix) to all dependencies of your 'Dynamic VI' which is common to the 'Main Exe'.
    Hope this solves your issue.
    I am not allergic to Kudos, in fact I love Kudos.
     Make your LabVIEW experience more CONVENIENT.

  • Excel ActiveX invoke nodes are broken

    I am using LabVIEW 2007.  We are using a VI that runs on most of the PC's in our facility however on some the "invoke node" related to Excel functions don't operate. They are broken and the VIs won't run.  We get errors that the "Invoke Node: contains unwired ro bad terminals".  When going to select methods or properties not all of the properties are shown as seen on the functional PCs. Some of the properties are missing from the selection menus, thus making it incompatible.
    Has anyone seen this problem and a solution?
    Thanks
    Manliff,

    What about separating the compiled code from the source?  I recognize that this will only work in LV2010, but I expect that that will prevent the compiler from breaking activeX code that depends on a different version than the local one...
    Testing this idea is on my to-do-list, but I was wondering if anyone has tried it already.
    -Barrett
    CLD

  • ActiveX Object Creation method to pass to an Invoke Node

    Hi!
    I'm trying to optimize the way in which I use MathCAD from LabVIEW.  One of my VIs is having really poor performance in terms of execution speed and memory usage.
    My VI converts a 2D LabVIEW array of doubles into a 2d Mathcad matrix and puts that matrix into a Mathcad worksheet.  The issue is that you do not just pass the 2d array of doubles into the SetValue invoke node as a variant.  You have to create a Mathcad.MatrixValue object, and then pass the object to the SetValue invoke node.
    Here is the example code provided in the Mathcad developers manual:
    SetElement Method
    var m = CreateObject("Mathcad.MatrixValue");
    for(row = 49; row >=
    0; --row)
    for(col = 9; col >= 0;
    --col)
    var val = row + col;
    m.SetElement(row, col, val);
    Here is my implimentation in LabVIEW:
    Here is my SubVI
     Here is my main VI:
    My SubVI is running out of memory and throwing the following error:
     Exception occured in mplrun: Exception of type 'System.OutOfMemoryException' was thrown. in NL SubVIs Library.lvlib:Convert LabVIEW 2d Array to MathCAD Variant Matrix (SubVI).vi->test.vi
    It doesn't always throw the error.  When I watch the memory consumption of LabVIEW it goes up to about 250k and then drops to 90k and slowly builds back up to 250k.  Initialy starting the code takes awhile too on my computer.  From start of VI until first loop iteration it is about 20 seconds, and then about 150-250ms after that.  Not very good performance.
    Any advice on how to optimize this code would be appreciated.  I'm not really sure when I should close some of these references.  I tried closing the reference in my converting SubVI, but I guess that destroys it so MathCAD can't use it.
    I'm in LabVIEW 2009.  Any help is appreciated. 
    Thanks for your time and input!
    -Nic

    I'm not sure this will solve your problems but it should help.  You need to close ALL of your references to Mathcad objects when you're done using them.  That means you need to close the reference to the Mathcad MatrixValue after you pass it to Mathcad (to do this you'll need to convert it back from a variant, or pass the reference directly out of your subVI), and you should also close the reference to the matrix that you get back after you've converted it to a LabVIEW array.  Otherwise you'll continuously allocate more and more memory rather than allowing it to be reused.
    Less importantly, you should also close your references to IMathcadWorksheets and IMathcadWorksheet (but since you only open them once it's not causing your memory problems).

  • Error 8 occurred at Invoke Node in AB_EXE.lvclass:Build.vi- AB_Build.lvclass:Bui

    During software build to make exe file, I got the following error message:
    Error 8 occurred at Invoke Node in AB_EXE.lvclass:Build.vi->AB_Build.lvclass:Build_from_Wizard.vi->AB_UI_FRAMEWORK.vi->AB_Item_OnDoProperties.vi->AB_Item_OnDoProperties.vi.ProxyCaller
    Possible reason(s):
    LabVIEW:  File permission error. You do not have the correct permissions for the file.
    =========================
    NI-488:  DMA hardware error detected.
    Method Name: Build:Application
    The vi was working fine before the build. It just access some text files and creates some excel files. No hardware is involved. See if anybody know how to solve this problem. Thanks.

    I am using LabVIEW 2014 and have been getting this error randomly, but fairly consistently on a recent build. I searched all over and could not find a solution that worked. However, just through trial and error I discovered that the problem is related to SSE2 Optimization in the Advanced properties window. I can consistently cause this error by enabling this feature and consistently compile successfully when it is disabled. Try turning this feature off and see if it solves the problem.
    ...UPDATE: After closing and re-opening LabVIEW this error came back, and did not seem to be affected by the SSE2 option. Not that it isn't related, but perhaps not the silver bullet I thought it was.
    I also got the error to go away sometimes when I compiled the EXE while the main program VI was open, whereas it gave the error most of the time when no VIs were open...again, nothing seems to consistently solve the problem...there is definitely some kind of bug in the appllication builder, and it seems like there are a lot of people that have been struggling with this for a long time (as far back as LV 8)...hopefully NI eventually finds this bug and squashes it!..although, I doubt that anybody at NI is even looking for it...

  • How to name a new Excel worksheet using an invoke node??

    I want output from my specific labview code to be written to a new and specific worksheet (meaning I want to provide the specific worksheet name) of an Excel spreadsheet my LabVIEW code will generate. My code will run in a loop where I want data that is generated in each pass of the loop to be written to a new worksheet each time through the loop. I know how to do this if I am ok with just having each worksheet be named 4, 5, 6, etc (on top of the 1, 2 and 3 that comes standard with a new Excel spreadsheet) but I want more meaningful names than just those numbers... So how do I add a new worksheet and give it a name of my choosing??? Also, when right click on an invoke node and then click on "Help for Item" which is right under the Methods selection that comes up, nothing happens, meaning I am not directed to any help file. I see that same behavior under LabVIEW 6.1 and also under LabVIEW 7.1. My guess is either I didn't buy some option required to have that help area be populated or I had it as some option but didn't know to install it when I originally installed LabVIEW??? Having that help available might help answer the question I pose above... I find working with ActiveX components to not be straightforward. Granted I haven't done it much and what I have done has been sort of follow examples and get it to work... But on this naming a new worksheet I have found no useful examples. My guess is it's easy but I'm clueless... Any help would be much appreciated... Note, in case it matters, I do not own the Report Generation tool/capability... thanks... bob...

    Hi, Paris1:
    Take a look at "Excel Workbook Properties", that is located in
    REPORT GENERATION
    -> EXCEL SPECIFIC
    -> EXCEL GENERAL
    -> EXCEL WORKBOOK PROPERTIES
    One of its outputs is "Current Worksheet Name".
    You can insert a ExcelWorkbookProperties VI in a blank VI and then double-click it.
    You will se a rose vi named Excel Get Properties
    And inside it (double-clicking it), the way Worksheet's name is got. If you "Change to Write" that property node, you can set it's name.
    This way is very complicated, it can be done faster, but this way you can see a process to do that, and checking it, you can build your own excel VIs to do specific tasks.
    Hope it helps,
    Aitortxo.

  • Error 1069 on Invoke Node

    Hello all,
    I'm trying to build an application we have. In one of the sub-vi's there's a call to invoke node to start another vi. When I run the program from the VI this works fine as it should. When I build my executable and have my .llb for the executable, the program gets to this point and I get the above error, Error 1069: The sub vi is not executable. I know there's no executable for this and the spawn vi that calls it is in the llb. Any ideas as to why it will work as a vi but not as an exe? Thanks for any help.
    Gary

    Aaron G wrote:
    Gary,
    A common reason for error 1069 is because you are attempting to launch the code from the executable environment and not a develoment environment. When it attempts to launch the VI, it may not find all of the subVIs, causing the VI to be reported as non-executable. One way around this is to open the VI that is dynamically launched, go to File>>Save With Options and choose Application Distribution. This will allow you to create an Application Distribution LLB file. If your executable launches the version of the VI that is in the Application Distribution LLB, it will work. As a word of caution, when saving files as an Application Distribution, the block diagrams are removed from the VIs, DO NOT OVERWRITE your existing VIs. You will never be able to edit them again if you do this. Alternatively, when you build the application, make sure that the VI is included as a dynamically launched VI in the list of included files.
    Regards,
    Aaron
    Aaron, thanks for the reply. I am saving with options and doing the Application Distribution. I'm also getting error 1003 but it's still saying the possible cause may be that the vi is not executable. The vi's that the invoke fails on are not included in the llb but according to the previous version of the software (in LV 6.1) it's not needed. (I checked the old llb file and the options in application builder.) I have the spawn vi which calls the invoke in the llb. The spawn takes a path, creates a reference and then does the invoke on this path. The vi's themselves are not in the llb. Will these need to be moved in? And if so will the paths need to be changed?

  • ActiveX Invoke Node returns -2146959355

    I ran the attached VI on LV 5.1.1 w/ no problems. Its purpose is to change the configuration of an HP16522A Pattern Generator accessed by LAN (hplogic1 is the mainframe's IP). I've also installed LV 6i at the same time, but whereas LV 5.1.1. still works fine, LV 6i fails - but only on the 'LoadFile' Invoke Node. Also, if I connect 'StatusMsg' Property Element to an indicator, LV 6i shuts down abnormally with a MS/C++ error.
    I've tried loading the LV 5.1.1 VI on LV6 but the result is the same.
    My OS is Win2000 5.00.2195/Service Pack 2.
    Attachments:
    hp16522_-_load_ascii_file.lv6.vi ‏45 KB

    One thing that you may try to solve this ActiveX error is to, in LabVIEW 6, select File>>VI Properties. Select Execution from the category box and set the Preferred Execution to user interface. This should solve the problem.
    Also, National Instruments has a LabVIEW driver for HP16522A, but it is somewhat different for LabVIEW 5.1 and 6i. The VIs, and the ActiveX objects they use may be different for these two versions. You may consider downloading the driver for LabVIEW 6i from:
    http://zone.ni.com/idnet97.nsf/9b2b33e1993d877786256436006ec498/16f803b84cc3b502862568ab005fb9ea?OpenDocument
    Zvezdana S.
    National Instruments

  • Invoke Node causes error in VI

    The attached VI is one of numerous VIs in an application that I "inherited".  I am attempting to rebuild the application to incorporate some changes I have made.  This VI has an error, which indicates that there is a bad or unwired terminal at the Invoke Node for the PrintOut method.  According to the Help system, all of the unwired parameters for this node are optional, so the node appears to be wired correctly.  What am I missing?  Thanks.

    Hello,
    Thanks for attaching the VI.  I believe the preview -> lost attachment issue has already been reported to the admins for this discussion forum.
    As for your VI, I'm guessing this problem is happening because you are running a different version of Office than the computer on which this application was originally developed.  On the PrintOut invoke node, try selecting another method in the method list.  Then try selecting "PrintOut" again.  This should re-link the method to the "PrintOut" method specific to the Word version on your computer, and you should be fine.  By the way, the VI opens just fine (no broken run arrow) on my machine, and I'm running Office XP.
    Let me know if this solves the problem.  Oh yeah, here's a tip.  I noticed that in this code, there is a Boolean constant wired to the "Close" method, but it's wired into a "To Variant" function to convert it to a variant.  This explicit conversion is not necessary...for any ActiveX property or invoke node that takes variant inputs, you can just wire the native LabVIEW type directly into the input (without an explicit conversion) and it will work fine...this should save you some time as you write new VIs, or edit this set of VIs you inherited.
    Good luck,
    -D
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

  • LVCompare Invoke Node Error

    I am trying to call LVCompare by inputting this into cmd:
    "C:\Program Files (x86)\National Instruments\Shared\LabVIEW Compare\LVCompare.exe" “C:\users\Temp\datalocation1\orange NEW.vi” “C:\users\Temp\datalocation2\orange.vi” –lvpath "C:\Program Files (x86)\National Instruments\LabVIEW 2011\LabVIEW.exe" –nobdcosm -nobdpos -nofppos
    But I receive an error message that says:
    "An error occurred while running LVCompare.
    Invoke Node in LVCompare.vi
    <APPEND>
    Method Name: <b>User Interaction:Compare VIs</b>"
    Has anyone else received this error? How do I fix this?
    Thank you!
    Amanda

    Seems you are using  LabVIEW Full Development system to run  LVCompare.exe.
    C:\Program Files (x86)\National Instruments\Shared\LabVIEW Compare\LVCompare.exe will only work with a LabVIEW Professional Development system.
    in order to use it you will need to upgrade to the LabVIEW Professional Development system.
    Thank you & Best regards
    syrpimp
    =======================================================
    “You must continue to gain expertise, but avoid thinking like an expert." -Denis Waitley

  • Frontpanel opened by Invoke Node blocks other FP

    Hello,
    In a project I am working on I would like to open and close a frontpanel displaying a few plots from a different VI. I have managed to create the Visualisation VI and am passing references to the Indicators and the VI itself on to the next block. I can open the FP by using an Invoke Node on the VI ref, but then I can only interact with the newly opened VI. To get back I have to close it by hitting X, I would prefer it if I could just have it running in the background or minimized once I click on my "main" Vi again. I have attached the required VIs.
    Solved!
    Go to Solution.
    Attachments:
    FP_Open_plots.zip ‏63 KB

    Hi,
    I can't see your code as I haven't upgraded to 2014 yet (shame on me ). Here is a Main VI that opens a Graph VI in two ways:
    1. Without running it, just by FP.Open. The main VI remains responsive. This is not really recommended but I think it was what you meant to do.
    2. (enable disabled diagram): by running the VI using the Run VI invoke node. In this way the Graph VI is called dynamically and the Main VI doesn't wait until it's done to continue.
    Good luck,
    Danielle
    "Wisdom comes from experience. Experience is often a result of lack of wisdom.”
    ― Terry Pratchett
    Attachments:
    Main VI.vi ‏11 KB
    Graph VI.vi ‏33 KB

Maybe you are looking for