Jump to content

Jon Kokott

Members
  • Content Count

    186
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Jon Kokott

  1. 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
  2. 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
  3. 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
  4. Bought a ticket. Excited for my first NI week.
  5. 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...)
  6. 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 c
  7. 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
  8. 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.
  9. 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 occasion
  10. 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.
  11. 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/
  12. 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
  13. 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
  14. 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 i
  15. 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
  16. I think it is an invoke node. http://forums.ni.com...ode/td-p/768440 ~Jon
  17. 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 eve
  18. 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
  19. [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.
  20. 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.
  21. 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
  22. "INSERT VI" is called in a CBR node. the reference fed into that node is saved.
  23. 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
  24. 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 al
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.