soupy

Short answer is no. you can't easily modify dependency locations. Longer answer is yes. you can modify environment search paths to point to the new target and delete the old target files to force re-linking, but this is really the hard way and it's going to get you into re-linking trouble/hell. Correct answer is that you're not using vi packages correctly. The code that goes into a VI package should be able to stand on its own. You should be able to debug/test/validate all VI package source code before you build it into a package. Think of a VI package as formally released reusable source code. If you feel the need to constantly switch between built packages and source code, then you're not adequately validating/testing before building the package. Hope this helps.

agreed. this is sort of a hack. i wouldn't be surprised if this functionality broke in future labview versions. I'd suggest not ignoring all errors coming out of this so you'll know if something changed. instead, ignore only error 1 coming out of the close VI

yeah, close functions should always execute. you wouldn't want to have a shutdown error and leave thing allocated. you should keep this in mind when making your own tools. my teams has formalized our style to always call this VI "destroy.vi". it should have an 'X' on the icon and should always execute even if errors are passed in and should pass through incoming errors. This follows the NI paradigm. We believe that the more our code resembles NI code style & interface, the more likely it will get reused by ourselves and others (less learning curve).

here ya go. this only works if your cluster only contains user events but it'll close all data types. if your cluster needs to hold more than user events, you could probably get around things by storing user events in a sub-cluster.

one of my guys just got his recently. it took a month the get the test results back. I hope you have enough time to take the exam and make the summit.

cross posted here https://decibel.ni.com/content/message/64013

i'm doing something, but i don't know what to call it. is this an accepted design pattern? background: i have a configuration class for my application the configuration class contains paths to external (excel) files you must parse out the external files and put their information back into the configuration class. i refer to this step as "parsing" i'm passing the parsed configuration class over the network to an RT system, so my configuration class can't have any dependencies to non-RT stuff (e.g. Excel (ActiveX)) everything is dynamic dispatch so i can get some reuse out of this design pattern explanation:in this example, i have an array of configuration classes all parsing functions are in methods of a "parser" class (chain link wire) there is one parser class for each configuration class the configuration class knows the path to the parser class So, does anyone have an official name for this sort of thing? I've been referring it as "side loading". Anyone have any lessons learned on this approach? Am i running head first into any traps?

i don't think that we currently use more than one ES per BD, If we do, the secondary ES is in a subVI. Will things be broken if the subVI is inlined? (I assume it would) I'm quite concerned that this breaks existing code. The LV upgrade eval process is typically riddled with surprises and this just adds another pothole. Especially since the only way to fix this is to overhaul your application architecture which isn't exactly an easy change.

spacex is donating an "occupy mars" t-shirt and a model rocket

ah, that's the term i was looking for. yup. makes total sense now. better to have obscure names than hard to find bugs. thanks!

so everyone knows that a parent and child class cannot have VIs of the same name unless they are dynamic dispatch. The compile will fail if you violate this. so, my question is, why is this restricted? Is there a technical reason that this can't be done? I ask this because i am working on a set of configuration file classes that are written directly to file. To deal with non-trivial permutations, i'm following the recommendations here (http://thinkinging.com/2007/04/14/supporting-multiple-versions-of-a-file-format/) and including a revision number in every class, subclass and child class. Because of the above naming limitation, i'm going to have to dance around naming conflicts since every class will be responsible for upgrading itself to its latest revision and will have similar functions. (e.g. ideally every class could have a function called Upgrade1To2.vi to upgrade from revision 1 -->2) additionally, i'm pushing our team to use standard file naming terms and increase the modularity of our code via private methods, so I'm afraid that we're going to run into this issue more and more often. I understand that it could be non-obvious that you aren't dispatching to the child method. Maybe you could explicitly acknowledge this? Maybe it could be allowed if it were made private since private methods cannot be dispatched? You think this is good enough for the idea exchange? Anyone else find this useful?

I sent your articles to my colleagues in an email titled "egoless programming" and they thought it was a joke. I've got a lot of work to do here...

this is great! i'll be testing this immediately! I'm guessing that this will eventually be released publicly once your release cycle comes around?

i'm working on moving my large library of reuse code (2300+ VIs) into VI packages. because of the scale of my code base, i'm forced to migrate over a span of time (measured in months). This is leaving me open to configuration issues (as a consequence of using configuration management ). does anyone have any advice in this area? my issue is described in much more detail here http://forums.jki.net/topic/2103-rename-vi-dependencies i think that most of my issues can be solved by implementing this http://ideas.jki.net/topic/167846-rename-dependencies-without-renaming-package-files/ Thanks!

putting in a blank password make the "password type" switch back to "none" it may work if they add "locked (no password)" to the "Password type" dropdown

I've got pro. I don't think it's the same as you're doing. It requires the NI licensing and activation toolkit. Not going to be buying that for something that is easily accessible via property nodes.

it would be nice if the "locked" setting was available as a standard VIPM package setting so you don't have to keep track of it in postbuild scripts. have you suggested this to them on their idea exchange?

I second this recommendation. I read it while flying on a business trip and my OOP style has never been the same.

oohhh...we gotta get one of those....PO is in work...

great article! I love how it logically lays everything out. If you wanna see more cool hardware pics, here is an article on our test site. http://www.wired.com/autopia/2012/10/spacex-texas-rocket-test

yeah, those were super annoying. i think at some point i did something to make this stop happening. i don't see the setting in the "my ni" section. next time they call you, try asking them nicely to stop doing it. it never hurts to ask (nicely).

the big benefit to the classes is the ability to interact with NI personnel. you get a chance to ask those misc questions that aren't openly addressed in the forums. priceless! I personally squeeze every minute out of those guys that i can. I personally don't think that the class manuals teach much that can't be found in other existing documentation. of course, if you're looking to learn a particular skill, you'll learn it much faster in the class. If you don't need to lean it quickly, just casually research it and integrate it into your current projects. I don't think that taking classes are going to make you an excessively better programmer. You can't buy experience. I'd say you should focus on small projects to try out new ideas. Make sure that you are somewhat familiar with every labview primitive and stock library. You should be continually advancing. I'm a firm believer that when you look at code you authored 6 months ago you should say "Whoah! WTF was i thinking? That could have been done better!" In order to write good code, you gotta write bad code. Disclaimer: I have 5 years of LV experience. I don't have any certifications (except CLAD) because my company values experience over certificates.

There really isn't a correct way to do this as long as you steer clear of the following 'gotchas!' if you have a class in a library, renaming the library will reset the class mutation history. this is only a problem if you are flattening class data and saving it to a file or passing it over the network. this isn't a reason to avoid packaging classes in libraries, just a warning not to change the library name [*]if the case that you are passing data between different top level applications, put the type definition for that data inside a library and not a class! placing the typedef in a class will force the other application to open the entire class into memory or the exe build. i once added 7MB to an exe by adding a single type definition! [*]if you are using labview 2010, upgrade to 2011. libraries and classes are way less stable in 2010. This isn't an exhaustive list, so feel free to add to it.

What we want: Seeking LabVIEW Programmer with CLD or 3-5 years experience What you'll do: Design and maintain National Instruments SCXI/PXI data acquisition systems Identify hardware requirements and compatibility Assemble, setup, and validate DAQ hardware configurations Troubleshoot DAQ hardware related problems Benchmark system performance and performance margins [*]Design and maintain LabVIEW-based applications and utilities to support propulsion testing operations Software testing, quality assurance and benchmarking Performance tuning, improvement, usability, and automation Integration of new features into existing systems Full life cycle software development [*]Provide technical support for testing operations [*]Create and maintain software development standards [*]Evaluate new systems, technologies, and architectures to reduce development time, increase reliability, and to streamline operations [*]Perform other related duties, as assigned, for the purpose of ensuring an efficient and effective work environment. Full Job listing is here: Software Engineer Rev 6-7-11.zip Where to apply: Please visit www.spacex.com/careers to apply. What we do: SpaceX offers one of the best environments in the world for employees to learn, build real working systems and tackle exciting challenges every day. We operate in a fun, casual work environment and have great benefits including: competitive salary, stock options, medical/dental insurance and free gym memberships. By joining the SpaceX team, you are not just a part of history, you are making it. SpaceX is an Equal Opportunity Employer; employment with SpaceX is governed on the basis of merit, competence and qualifications and will not be influenced in any manner by race, color, religion, gender, national origin/ethnicity, veteran status, disability status, age, sexual orientation, marital status, mental or physical disability or any other legally protected status. To conform to US Government space technology export regulations, SpaceX hires only US citizens and US Permanent Residents. Our Texas team is an integral part of SpaceX operations and plays the critical role of testing our flight vehicles and spacecraft. Located on a 700 acre site in central Texas, the Texas Test Facility is responsible for testing hardware from development stages through acceptance for flight, and from component level to complete stage testing. Experiencing the rumbling of a rocket engine multiple times each day is just one of the highlights of working at our Test Facility. Obligatory cool videos: Old site tour (it's gotten about 10x cooler since then) http://www.spacex.co...d=38&cat=recent Falcon9 1st stage test http://www.spacex.co...d=43&cat=recent Falcon9 2nd stage test http://www.spacex.co...d=44&cat=recent Dragon propulsion module test http://www.spacex.co...d=50&cat=recent Falcon9 Flight 2 w/Dragon http://www.spacex.co...d=57&cat=recent