Jon Kokott

I've been evaluating LV2011 and noticed that a feature from 2010 does not appear to be available in 2011. 2010: when in a .lvproj: File->Locate in project will locate the current VI within the project hierarchy. 2011 (and older than 2010 versions of labview) appear not to have this. I do use this and am somewhat disappointed Does anyone know why they would take that away? ~Jon

It appears LV 2011 now has an asynchronous call by reference node feature. I'll try it out sometime but I'm sure it will be vastly superior to this implementation. ~Jon

How many NICs do you have on each PC? I'm assuming you are running windows, and connected to an internet gateway/LAN on another connection. One thing that might help you is changing the interface metric of the individual NICs on each PC. Put the ones used in your setup as a 1, and all the other ones 2 or higher. This will probably mess up your internet connection, or make it unbearably slow when it works. ~Jon

Bought a ticket. Excited for my first NI week.

Correct me if I am wrong, but memory allocations for queues do not appear in a given VIs memory when using VI profiler. I assumed from this that queues would be "owned" (in terms of memory) by the active application. It seems counter intuitive that a VI hierarchy owns memory allocations and not the owning applications if this is the way labview displays memory allocations. I might be venting a little be here as I would be given the ability to define the application/"VI Hierarchy" owning a given chunk of memory than have labview decide for me. I suppose I can always go back to C (joking...)

I noticed something interesting today. If the daemon completes its run (the calling VI finishes execution), and has created any references (like queues, notifiers, etc.) it destroys them upon completion. I've tried to see if this was because it wasn't in opened using identical application references, but it does not seem to change the behavior. This means if you need any shared application memory you must open all references outside of the daemon source VI, or be ready to release them before the daemon completes. I'm not really sure why a queue reference is owned by the daemon alone, and cannot exist after the VI is closed. I'll think about adding an auto close VI daemon reference option to make the daemon wait indefinitely until the reference is manually closed.

I've been dabbling in Xnodes for a while and it seems that the act of opening a VI containing an Xnode generally causes code within the Xnode to run. Is their any way to prevent an Xnode from running its code at the time the VI is opened/compiled? Compiling is automatic in labview on open as far as I know. ~Jon

I've had this problem as well. Enabling debugging on the built executable (I blindly do it on all VIs) seems to allow the build to work properly. I think my problem had to do with what AQ mentioned earlier where I dynamically launch VIs using a static VI reference where the dynamic VIs are class members with the class on the connector pane.

I screwed up, this issue was fixed in SP1, it should be working. I know that even after upgrading to SP1, you are forced to "rewire" all the property nodes that you created before SP1. The property nodes did all kinds of strange things pre-SP1 on my machine, but I've used them pretty extensively in mostly dynamic dispatch methods (and I use the wizard often, but not always.) Did you upgrade to 2010 sp1 after creating the property node methods? I basically had to scrap every single one of them when I upgraded to SP1 just to prevent the type of issue you are having now (I would hang occasionally, alot of times it would hard crash LV (no save just total abort.) and sometimes it would just garble the data and look like total junk everywhere) sorry about that, it really is supposed to be fixed in SP1. ~Jon

the problem is with the way the properties are unbundled/bundled in the scripting of the property node. It has nothing to do with the static/dynamic nature of the assessor. The fact that you changed the implantation probably forced a wire propagation during compiling, and the act of rewiring is known to "correct" the error. at any rate, upgrading to SP2 will fix your problem.

You must upgrade to sp2. Property nodes have problems in sp1. http://lavag.org/topic/13940-class-property-node-failure-when-in-lvlib/ http://lavag.org/topic/13300-lvoop-property-nodes-and-dvrs/

Is the event you are registering for on the front panel of the Xcontrol's Facade.vi? why do you need to register for events in the first place? ~Jon

The two processes which you have executing in parallel (both inside case structures) are causing alot of thread swamping (thats my guess anyway.) Force those operations to occur serially (only one at a time.) and you get your expected processing increase in time. I'd be interested if building the VI into an executable helped the situation at all. ~Jon

You probably don't have VI scripting enabled in the labview enviornment. do a quick google search and it should tell you how to do it depending on the version of labview you are using (it requires a download pre 2010 i believe) a couple of pointers for your script, load all the VI references first before modifying. sometimes save dialogs will come up if you do not do it this way as they enter/leave memory. I would modifiy the code to do the following: one for loop to load the VIs (get the VI reference) one for loop to modify (disconnect from library, then test if it is a control, if it is, set it to standard control) one for loop to save them all to a new path. one more for loop to simple "save" them (do not put in a path) you have to double save because you are moving subVI dependencies and that is important to the loaded VIs. So even though you are saving the VI you modified, you have to resave to account for repathing. Do not save copies. The references will get all out of whack with cross links if you try to load your new copy VIs. just backup your work first in case something gets hosed. one more thing, when you get all dependencies in the library, feed it the constant string "VI" you don't have to for this particular .lvlib since there are only VIs in it, but if there was a virtual folder or something else it would break your script. ~Jon I'd modify it for you but I can't upload code right now. Its probably better in the long run that you learn to do it anyway. ~Jon

You can disconnect a VI from its owning library with the "disconnectFromLibrary" method. As far as disconnecting all the typedefs from a library of VIs, I'm not aware of any way to do this without scripting. The best way to do this would be to 1. open the library reference (I prefer to open a VI in the library, and use a "library" property node read.) 2. Invoke node on library "Get All Decedents" and get the Control VIs from this 3. Read the "VI Reference" in a for loop of the decedent results. 4. Set the "VI Control Type" property to control. 5. Save each VI with an invoke node save. 6. While you are at it get all the standard VIs and "disconnectFromLibrary" method. 7. Save standard VIs 8. Save the library. That will disconnect all typedefs by saving them as a standard control instead of manually disconnecting them in each VI (that is a huge pain, I wouldn't even try.) the disconnectFromLibrary method will take them all outside of the .lvlib as well. Before you try any of this, make sure you back everything up, including the projects that use this library. Additionally I would run your script from the same project instance as the one that you use these VIs in. Sometimes Labview gets confused otherwise when you reopen the project. ~Jon

I think it is an invoke node. http://forums.ni.com...ode/td-p/768440 ~Jon

If you want to save some money, in the past NI has offered the associate developer's test free of charge at annual regional developer days. (if you are in a hurry that might not be an option.) As far as the CLD is concerned, you can usually wrangle a $200 gift certificate for showing up to various NI sponsored events (which being able to attend might be an issue considering your employers stance on the certification in the first place.) I would talk to your local NI rep about your situation, I've found them to be very reasonable as far as certification billing is concerned (they might even waive the fee.) ~Jon

I like the "Clean Up Diagram" feature. I probably use it 30 times a day, and it increase the speed with which I code. I have never found it useful for a top level VI, but frequently find it useful for subVIs. ~Jon

[bug]Source VIs contained in Libraries within libraries will error out. [temp fix] Move the library owning the source VI out of any other libraries and run the tool again.

1. The confines of your example as well as mine are both constructed such that one queue applies per class. There are much more elegant solutions available but given the starting point I kept the construction equally simple to your presented solution. 2. Again they are explicit located in the dynamic dispatch. The collection class and the data classes are NOT decoupled, they don't have to be. (hes not writing the end all be all messaging protocol.) 3. With a dequeue? I don't understand the question.

Here is my suggestion: 2 Class hierarchies Hierarchy 1. The first hierarchy is a class containing the 7 queues you are interested in using (This class does not need to be a class, its only reason is extensibility, generally if you don't use the dynamic dispatching feature, use a lvlib) Hierarchy 2 class hierarchy with a placeholding parent (must override) children are the datatypes you want to move to dequeue destinations.) dyanmic dispatch VI for enqueue (one input for the class in hierarchy one) once you are in the dynamic dispatch VI, select the Queue from the first class containing all the references (property node read, read member VI, unbundle, whatever) Why this is better: Its alot faster than testing for named queues (even if there are only 7, especially if there are 1000s.) Naming queues is really really bad practice if you ask me. ~Jon

"INSERT VI" is called in a CBR node. the reference fed into that node is saved.

I have a subpanel in a VI which is running (call it "VI CONTAINER"), but the front panel is not visible. It inserts another VI (call it "VI INSERT") When I execute the code (from a top level) I invoke "frontpanel.open (activate=true,state=standard)" on "VI CONTAINER"; THEN invoke Supanel.insert("VI INSERT") . The front panel of "VI INSERT" appears in the subpanel contained in "VI CONTAINER" but the controls/indicators never update. This only happens the first time I run the main VI. If I stop execution, then hit the run arrow again, after the subpanel.insert is called "VI INSERT" updates its front panel normally. what gives? This is especially bad because in a built application it never works, since it is always the first time run. (it will work in built applications if you stop execution, and hit the run after running it once it will work normally as well) I am calling "frontpanel.defer frontpanelupdates = FALSE" on "VI INSERT"'s front panel in numerous places and times, it doesn't help.

I posted a little premature and wanted to explore some options before I posted a question. I was trying to remove the post but it appeared there was no way to do that. that said... I would like to remove the alpha history from my LVCLASS. the mutation history is a great feature, but the build times are getting ridiculous for a a project with LVCLASS history spreading from 8.5 to 2010 sp1 (with service pack updates on many of the versions in between.) I wanted to know if anyone had a tool to do this, but it appears its should be a reasonably easy to write from scratch. I'm going to get all the classes in the project, rename them to some temporary name, save, then rename to a different name. According to the documentation that should clear the alpha (and hopefully improve my build time from an hour to like 10 minutes.) ~Jon

cant remove...