jgcode

Only been playing with 2009 for a few minutes or so... Is this the by ref implementation of LVOOP?

From the LabVIEW 2009 Help Manual here it is... The Application Builder no longer moves VIs with conflicting filenames outside of stand-alone applications, shared libraries, or Web services for build specifications you create in LabVIEW 2009. In LabVIEW 8.6 and earlier, the Application Builder saves VIs and library files in a flat list within the application and saves VIs with conflicting filenames outside the application in separate directories. If you build a stand-alone application or shared library using LabVIEW 2009, the Application Builder stores source files within the application using a layout similar to the directory structure of the source files on disk. For example, the following table lists the relative paths for a top-level VI, foo.vi, which calls a.vi and b.vi. C:\..\Application.exe represents the path to the application. Path to source files Path to files in application C:\Source\foo.vi C:\..\Application.exe\foo.vi C:\Source\xxx\a.vi C:\..\Application.exe\xxx\a.vi C:\Source\yyy\b.vi C:\..\Application.exe\yyy\b.vi To use the legacy file layout, place a checkmark in the Use LabVIEW 8.x file layout checkbox on the Advanced page of the Application Properties, Shared Library Properties, and Web Service Properties dialog boxes. LabVIEW enables this option by default for build specifications you load from previous LabVIEW versions.

You little ripper! Download is slow... I can't wait... ...do you have time to provide any details of how it works - Do the .LVLIB or LVOOP library's get complied into another type of binary file (e.g. compiled LVOOP) that can sit in an LLB/EXE? - Can LLBs now sit inside of LLB/EXE? - Or there is a underlying folder type structure in EXEs now? I am excited!

I really like the sound of the integrated TDMS with DAQmx and the the probe window. The new ICON editor looks brilliant too - just what was needed Its a shame they didn't go into detail about LVOOP enhancements other than slide 26. I wonder what they meant by "ability to easily deploy executables?" Does this mean that .exe's are now built cleaner - no files contained outside of the exe for duplicate names? Waiting for the download to complete - this is one of the first things I will try!

Awesome! Cheers for the links.. downloading now...

Very cool! Thanks for replying

* You bloody little ripper (aussie slang for thank you) * And the answer is.... "cut and paste your code!" I cannot even see scripting methods!?! I cut and pasted it into my new tool which is for a Right Click Framework package. And it was perfect - exactly what I was after. And yes scripting is fun and (very) addictive!! Thanks for posting Kurt & François.

Cheers Kurt! I will take a look - at the moment though it will be for instantiated LVOOP methods - from the existing options create: dynamic, static, data member etc...

Hi Does anyone know how to change the default save name of a VI. E.g. you open a new VI, click Save, and the default name that appears in the file dialog is usually Untitled X (or Read/Write Data Member for a class). I don't want to save the VI to disk, I just want to change the default save name so I don't have to edit it as much. I tried writing to the VI Name property and changing the appearance name but it did not work. I can't find anything on this searching. Does anyone one know how to? A private property (scripting) would be fine too. Cheers JG

Awesome plugin - well done

Cheers!

Mines gone now too! ???

Dude that is awesome - the mirror effect rocks! I love the new-look Volcano. Whoever designed it - Well Done! (From reading the first post was it you, Vugie?) [Edit button is near reply button over here]

Here is a great piece of knowledge base from Adam Kemp. Twas posted on Info LabVIEW earlier this year. It maybe the reference you are thinking of? The PowerPoint is a good read. I agree. But as Crelf pointed out - if its a GUI then of course you are going to have FP objects inside the case structure. But its not then, yes, I too prefer to have them outside for a couple of reasons: I can define optional default values - or just select "use default if unwired". This is important e.g. on a basic SubVI with Errors I can pass the reference through the "in error" case, and not lose it (just like the LVOOP templates) It is much neater and easier to read (for me) - I can see what goes in (LHS) and what goes out (RHS) as nothing is hiding anywhere. Leads to optimised code (as per Adam Kemp's post) It helps me maintain a standard interface to the code module. If I am not building a class, but a standard Multi-Functional VI (MFVI) I usually have 1 input and 1 output - normally type-def cluster (sometimes variants) to the module for data (and also the Command Enum and error in/error our clusters). This makes the interface flexible, maintainable and scalable. And I don't need to handle a bunch of default values. Wrapper VIs bundle the inputs into the interface and they also pull out the required outputs from the interface for that method call into the connector pane. So the API is just like a basic SubVI to use. Any used values are disregarded.

My wife makes a mean curry, her Father is a genius at them. His special is a bacon bone curry that literally blows your head off. I did not eat heat/spicy food growing up so I am easing myself in I also do not understand why someone would want to eat something like that! Although I think the bacon bone is coming up for me, if I make it through that then I am really considered family

I always go with option 1. However as this is a typical FGV (Conditional Stop always TRUE) and not a MFVI/module (Conditional Stop determined by logic) as Daklu mentioned if it only iterates once then it probably does not matter. But with a MFVI - I saw some unexpected behaviour on RTOS with arrays that was seemed to be fixed going from Option 2 to Option 1 model. I guessed that on every iteration of the loop, the array is being re- read and possibly a new allocation is made??? I too am interested to know what is happening at the memory management level on multiple iterations. FWIW: I also put the command enum outside the loop as well. In fact even for SubVIs I put all controls on the left inline, and all indicators on the right inline for neatness/readability as well.

Sweet, got it to go - I had a bug, dammit (amateur mistake of releasing a ref) so the observation I made above can be ignored. Thanks heaps for the post, really like the way you case out the VI. Better than using a static ref because the VI will be in the build AND as you mentioned the Top Level will become broken. Also playing with the build in LV8.6.1 Running the build errors when Spawn button is pressed complaining the VI is not in memory. I figured this may be from the constant folding of the casing out and LabVIEW being smart - so I changed the constant to a control defaulted as false, re-built and it works. I guess this has changed from the version you are using and thought it may be of interest if you didn't already know? Enjoy the curry! (is it homemade?) - for brunch yesterday I had takeout Dosa Masala and Purri's with potatoes. :YumYum: Cheers mate JG

Hi Omar This sounds extremely interesting! Are you able to elborate, give a sneek peek or show us a demo vid (jing)? Cheers JG

Hi Kurt - I tried the above but no luck - do you have any examples? I still cannot seem to get two FP in memory at the same time. Lets say I spawn two re-enetrant VI's and open their front panels with Show Front Panel:Property Node. If both are instantiated at the ~same time (i.e. using For Loop) the FPs open but th VIs don't run (observing run arrow). If I use a delay, the first runs correctly, then the second runs correctly, but the second one stops when the first spawned VI completes execution. This is the only way I can get it to go in LV 8.6.1 as well. In order to create two independent FP in memory. Seems re-entrant VIs share the same FP memory (mentioned in below post). I did find some more info from searching here, here, here & here

Hi Kurt - thanks for your reply. I have noticed the "do not delete" comment for a property node for a control whilst trolling through some of your old code here

I was trolling through NI's code documents when I saw this post and it got me thinking: Which is the better way and why, to have multiple instances of a VI's front panel in memory at the same time. 1) Spawn (and specify re-entrancy on open ref node: 8) a re-entrant VI and invoke open front panel method OR 2) Spawn .VIT template I was under the impression the later is the way to do it. The user mentions in the post a problem with loading, and the need for a wait in the for loop. How does LabVIEW handle each approach (with respect to memory allocation?) Cheers

QUOTE (candidus @ May 25 2009, 05:19 PM) I didn't try that (obviously) I didn't think the order would matter as long as I kept the reference open. This worked for standard VIs but not ones that called .vit/.ctt files Thank you so much for posting! Cheers! :beer:

[Cross-posted to NI Forums] Hi I have VITs that call other VITs or CTTs in some of my templates. I want to programmatically open a reference to a template and save the new VIs/CTLs to disk but I am getting errors My code works fine for any VIs or VITs that only call other VIs or CTLs. However if the VI or VIT contains calls to other VITs or CTTs then it fails. When I try to get a reference to the new VI or CTL in memory the reference seems dead? Can anyone point me in the right direction? Cheers JG Download File:post-10325-1243008955.zip Coded in LV8.6 and Saved for Previous Version in LV8.0.

QUOTE (Karissap @ May 18 2009, 03:39 PM) Hi Karissa There seems to be a bug? where using the FP.Get.Image method with a splitter on the panel as it does not return the entire front panel (when Visible.Area.Only is toggled it gives the same result?) without a splitter it works. My only suggestion is to take the image subset as attached but expand the panel programmatically first to the lowest control to include all controls?? http://lavag.org/old_files/monthly_05_2009/post-10325-1242652061.png' target="_blank"> Cheers JG

Hi What is the standard practice for testing source distribution code: Should I write tests cases for source code OR source distribution code OR both? I can see issue with either choice: Source only - you want to test source to pick up any errors before you make it into a source distribution but... Distribution only - distribution may apply name changes and in case of an error with dependency code that meant the source was ok but the distribution isn't Both - best coverage, but redundant tests case, changes mean updating code (tests) in two places (due to re-naming etc..)! What do you guys do? Cheers :beer: JG